概述
日志服务的数据加工功能上线了！目前内测阶段，欢迎试用。
条件
- 区域：北京、上海、英国
- 目前在内测阶段，申请内测，可请提工单，或者通过加钉钉群11775223 @成喆 @唐恺 申请
解决问题
行业上数据加工的痛点
行业上80%的数据分析花费在数据规整上, 数据在接入、分析、投递、对接时存在各种数据加工的需求与痛点
- 数据源混合各种格式，难以简单提取，如交换机、服务器、容器、程序Logging模块等，通过文件、stdout、syslog、网络等途径收集的数据，混合了程序的各种格式的日志；如日志中的message字段，需要根据各种情况的正则匹配后提取；
- 单一场景，字段动态且不确定，例如NGNIX，的QueryString、HttpCookie、HttpBody信息中的字段，需要用自动KV或者多种正则提取；
- 源数据包含动态JSON格式的数据（如CVE数据、O365 Audit日志等），需要动态计算，提取合并字段，甚至分裂为多条日志进行处理；
- 某些常规日志包含了敏感信息（例如秘钥的密码，用户手机号、内部数据库连接字符串等），很难在提取时过滤掉或者做脱敏。
- 使用简单表格、CSV、OSS文件、RDS、外部API等进行数据富化。
- 数据量过大，需要做聚集（如将5分钟的多条网络连接数据，根据机器聚集成几条）
日志服务中数据处理的痛点
在数据加工上线之前，我们发现，日志服务的用户在各个阶段存在如下痛点：
1. 数据接入时
-
单一源包含多种格式，难以提取分发：
- 交换机、服务器、容器、Logging模块等，通过文件、标准输出、syslog、网络等途径收集时，里面是各种日志格式的混合，只能做部分提取，例如使用logtail先提取某些基础字段，例如时间、log level、IP等，但是日志主体message中很多有价值的信息因为混合了各种日志，无法在导入时提取
- 期望根据特定格式接入到不通目标时，难以实现
-
特定格式内容复杂多变，难以提取：
- 例如NGNIX，的QueryString中的字符串，或者HttpCookie、甚至HttpBody信息等，里面字段内容变化巨大，格式信息复杂度也很高，难以在提取的时候一次性使用正则表达式完成提取。
- 某些复杂JSON递归深度
- 某些常规日志包含了敏感信息（例如秘钥的密码，用户手机号、内部数据库连接字符串等），很难在提取时过滤掉或者做脱敏。
- 某些JSON日志信息包含多条日志，需要分裂为多条日志进行处理等，但无法操作
- 其他方法例如使用SDK规则后再上传、通过Logstash channel转换后导入等方法试图解决时，事情变得复杂，数据收集的性能也变得更慢
2. 查询分析时
接入后的数据，用户普遍使用SQL进行数据加工，存在以下痛点：
-
常规数据加工用SQL实现复杂冗长，难以编写、脆弱与维护:
- 常规简单的字段梳理、正则提取、富化等难以编写
- 源日志稍有变化即出现执行错误
- 过长的SQL难以理解、修改与维护
-
性能慢，数据量大或SQL复杂时，很容易超时：
- 经过字段计算的SQL失去索引优势
- 大量Metrics数据在groupby后跨长时间范围比较耗时
-
字段长度超过2KB时不支持计算
- SQL单个字段索引在2KB内，超过部分不支持，但超长字段普遍存在
-
无高级函数支持下，高级规则处理需求无法实现：
- 各种格式混合、动态字段等无法用SQL实现
- 日志分裂、特定逻辑计算（如UserAgent/SQL Pattern）无法实现
- 自定义聚集计算不支持
3. 归档时
- 投递到OSS、MaxCompute等并不支持内容上的过滤或者格式转换
4. 对接外部系统时
- 可以在其他系统（例如DataWorks、FunctionCompute）等中将日志导入进行规整后再导回日志服务，但在整个过程中因为要解决编程、配置、调试等方面的工作，相对要耗费不少功夫。
主要支持场景
场景1 – 数据规整（一对一）
场景2 – 数据分派（一对多）
场景3 – 多源汇集（多对一）
场景4 – 常规数据数据加工场景
提供了150多个内置函数，不需要写代码即可完成主要加工任务，同时提供灵活自定义函数(UDF)的能力，满足各种场景：
- 过滤（filter）：将特定的日志去掉
- 分裂（split）：将一条日志变成多条
- 转换（transform）：字段操作、内容转换等
- 富化（enrich）：关联外部资源，丰富字段信息等
- 聚合（Rollup）（待上线）：特定维度做聚集，减少日志量
- 自定义操作（待上线）：以上自定义操作，如SQL模式解析、自定义Agg操作等
优势
- 更快速简单的接入：通过logtail等各种渠道，只需要用最简单的方式接入一个无索引，短期存储的logstore即可。
- 更快的查询与更灵活的分析：通过开箱机用的规则与简单的语法，即可完成复杂的加工，并使得加工好的数据基于索引可以跟快的分析；分析的SQL不再冗长、低效与难以调整。
- 更多业务场景的可能：通过数据加工的富化、自定义加工等，可以进一步挖掘数据的价值，构建更高级的业务
- 更灵活的投递与生态对接：可以更简单的配置符合生态需要的规则
- 一站式托管的数据加工方案，免运维、自动扩展
其他常见问题
费用问题
- 加工服务本身消耗的机器与网络资源目前免费，但读取源logstore与写入目标logstore按照日志服务的标准正常收取。
- 根据情况，可以关闭源logstore的索引，并设置较短的保存时间。
参考
欢迎扫码加入官方钉钉群 (11775223)获得实时更新与阿里云工程师的及时直接的支持: 