阿里QA导读：如何保证业务运行稳定？如何及时监控告警出业务运行出现的问题？对于追求精益求精的质量同学来说，端到端的把控，才让业务更信心满满的快速奔跑，请看来自阿里企业智能事业部同学的方案，是如何用技术赋能业务。
一、背景
关于稳定性建设工作的重要性和价值点毋需多言，然而怎么落地，各业务团队皆有各自打法。去年集团安全生产小组确定安全生产核心打法，制定五大战役和两专项重保，体系化地做稳定性这件事情。其中 1-5-10故障快恢，位于五大战役之首，该策略从集团 -》部门 -》 业务线逐步推广。当时我在负责IOT电子架签系统测试，线上架签已达百万量级以上，也亟需打造一套更加灵敏完善的稳定性建设方案。我们项目组承接部门安全生产目标，经过讨论确定优先解决1-5的问题，确保线上故障能在最短时间发现，最快速定位。由于运维团队主要负责产品在门店的使用情况，对产品技术实现不甚了解，且之前我已经负责建设了一部分业务实时质量保障能力，研发提出由我来继续完善稳定性建设工作。
稳定性建设是一项系统工程。包括监控，告警，降级，预案，演练，压测，灰度，变更管控，机制建设等。其中监控是整个方案最重要的一环，事前及时预警发现故障，事后提供数据排查问题。安全生产重点工作邮件中指出线上监控可细分为四个部分，分别是系统监控，链路监控，业务监控，SLA监控。目前集团监控工具也很多，如xflush，sunfire，alimonitor，A3，鹰眼，arms等等，能解决一部分系统监控，链路监控甚至业务监控的问题，但若要做更灵敏和更贴合业务的监控解决方案，则无法很好满足要求。因此研发经过一番调研，最终选择了SLS日志服务作为切入点，当时交给我的时候，我并未参与监控方案技术选型，也完全不知道接下来会做成什么样。随着本项工作的开展，直至完成，摸索出了一些经验。这篇文章就是在该过程中，对于用SLS日志服务能力，做业务监控最后一公里建设的方案实践总结。
二、目标
继第一篇《基于数据的洞察分析保障电子架签稳定性》文章介绍的方案之后，我们通过建设监控能力，采用数据挖掘中统计和聚类方法，能快速发现线上问题，可是不具备缩小问题排查范围并快速定位问题产生原因的能力。我们需要接收并处理应用服务器，IOT套件，AP基站，端侧设备等，在这条链路上每个节点的日志，分别分析。对于各类IOT设备，不同的端，面向客户不同，使用场景不同，质量模型不同，唯一相同的是技术层面，研发统一将日志采集并存储于SLS中，通过这些丰富的数据源，可以实现不同监控指标的配置，从而达到实时查看运行状态，实时报警的目标。
这一系列设备相关日志陆续接入SLS。最初解决的是电子架签的监控，此后陆续完成了其他IOT类设备的监控，如手环，温湿度传感器，工位探测器等。回头来看，我把解决问题思路总结为两部分，一是定义监控告警模型指标，二是技术实现。关于第一点，主要是综合和研发，PD共同协商，来确定系统监控指标。关于第二点，主要是通过查看SLS帮助文档摸索实践，或寻求SLS同学的技术支持。
虽然业务时刻在变化，技术通用性却很强，因此利用技术通用性，来建设不同业务监控告警能力。本文重点讲基于SLS配置监控告警的技术实现，希望能对不同业务线有参考作用。此时，我把自己当作开发人员，进行技术输出。我们假设监控告警指标已协商好，接下来要解决的问题则是监控数据如何获取，如何加工，如何展示，如何和告警联动等。我把过程中遇到的问题归结为如下几类：
三、解法
3.1 数据提取
3.1.1 json.json格式解析
温湿度传感器原始日志参数message，是一个json.json格式数据，解决方案如下：
a. 通过json_extract 解析message字段，根据参数key查询数值；
b. 通过cast将结果转成字符串类型；
c. 查询结果通过having语句进行设备类型过滤；
查询代码：
https://help.aliyun.com/document_detail/63454.html?spm=5176.11065259.1996646101.searchclickresult.943d6e26ZifWxQ
查询结果：
3.1.2 json.array.json格式解析
基站原始日志数据有个参数jsonData，是json格式，包含多个station列表，每个列表元素，又是一个json串，解决方案如下：
a. 通过json_extract 先解析jsonData字段，取出其内层的station字段，返回json类型；
b. 通过cast 将station转换成 array(json) 类型；
c. 通过unnest 把array(json) 展开成多行，以t来命名新生成的临时表，每个json值写入每一行中，行的名称为d，使用d来引用展开后的列；
d. 通过 json_extract_scalar 解析d的指定列，返回字符串类型；
查询代码：
https://help.aliyun.com/document_detail/84586.html?spm=5176.11065259.1996646101.searchclickresult.694c66354vYp9g
查询结果：
方法解析：
有些日志数据结构比较复杂，包含json，array，或者相互构成的嵌套关系，需要层层解开，取出对应的key和value，并可能用到cast类型转换，使其提取出符合我们期望的格式数据；
3.2 数据加工
3.2.1 创建oss外联表补充字段
温湿度传感器原始日志里，缺少机房字段，业务方期望结合机房信息发送告警。sls支持通过oss创建维表，来实现日志字段的富化，解决方案如下：
a. 创建oss的csv文件；
b. 在目标日志库里，通过create table xxx SQL语句创建虚拟外部表，和oss文件进行映射；
c. 验证成功定义外部表后，通过join语法完成日志库和oss外表的联合查询；
d. 若要增加温湿度传感器，只需要更新csv文件即可，sls的监控告警信息可自动同步；
创建语句代码：
https://help.aliyun.com/document_detail/87026.html?spm=5176.11065259.1996646101.searchclickresult.f95384eaEsMELP
关联查询代码：
https://help.aliyun.com/document_detail/70478.html?spm=5176.11065259.1996646101.searchclickresult.40824f0axcQk7p
查询结果：
方法解析：
有一些缺失的字段，可以用oss文件当作一张静态的维表，来关联查询，这种方法非常适用于一些场景，待监测的对象是固定的一批数据。比如一批温湿度传感器，一批工位探测器，一批测试的电子架签，一个门店的AP基站，这个方法在以下这些场景中都发挥过巨大作用：20周年的全场年会手环监控，20周年的分区域年会手环监控，双11光明顶AP基站监控，双11媒体指挥中心AP基站监控。像双11AP基站监控，是当天早上运维提供各区域的AP mac地址名单，因此当天分别创建oss外联表和分别创建告警，晚上即刻投入使用，即使封网也不受影响，相当灵活高效。
3.2.2 oss外联表字段乱码解法
有的时候，我们会遇到这类问题，新建的oss外联表，通过sls的sql语句查询，筛选出来结果为null，无论怎么调整都不行，此时可能是源csv文件的格式出现问题，可以用下面的格式化代码，格式化源csv文件，然后用格式化后的文件替换oss文件即可。
格式化代码：
echo 'id,a,b,c,d,e' > new.csvgrep -v 'id' xxx.csv >> new.csv3.2.3 oss和sls跨域解法
用外联表的时候，遇到一个比较麻烦的问题是，sls日志在弹内生产环境，而现在oss已是集团对外服务的中间件，部署在云上，和弹内环境属于不同集群，网络不通。此时，需要通过命令行方式创建oss文件。
创建语句代码：
https://help.aliyun.com/document_detail/87026.html?spm=5176.11065259.1996646101.searchclickresult.f95384eaEsMELP
查询结果：
通过这种方式，我们可以在sls上使用oss的外联表；
3.2.4 多个日志库关联查询解法
有时候，开发会把日志打在不同日志库里，因此我们需要关联不同日志库进行查询。有个很简单的方法，就是sls的sql语句里，用 select * from logstore_name 代替 select * from log;
查询结果：
方法解析：
在一个项目中，多个logstore可以直接查询，这种方法非常适合跨环境或者跨应用之间的日志串联。比如研发把同一应用日志分日常，预发，线上环境打印在不同日志库里，或者一条业务链路，需要跨越多个应用，根据关键字串联。
3.2.5 引入odps数据源解法
有时候，我们缺失的数据，是动态生成的，而非一份静态维表数据，这种情况下，我们可以把数据从odps里取出来，设置一个定时任务，比如：每天早上6:00把数据投递到SLS上。
ODPS投递给SLS的代码：
https://help.aliyun.com/document_detail/153354.html?spm=5176.11065259.1996646101.searchclickresult.3f6240e8CjMKHy
投递结果：
方法解析：
该方法可以解决sls日志缺失的问题，但是有一个注意事项，投递的日志作为logstoreB，要和sls原始日志logstoreA进行join关联的时候，查询的时候需要用时间段对齐函数date_turunc对齐时间，把查询时间做个特殊处理，以保证能查询到早上6:00投递进去的logstoreA日志。
时间对齐函数代码：
https://help.aliyun.com/document_detail/63451.html?spm=5176.11065259.1996646101.searchclickresult.1946246ce9jWaj
SLS双流JOIN查询的加工代码：
https://help.aliyun.com/document_detail/70478.html?spm=5176.11065259.1996646101.searchclickresult.5ff333469JjXqi
3.2.6 日志库动态生成法
有时候，我们由于日志数量太大，导致无效信息过多，需要精简，日志库在弹内生产环境，不支持数据加工功能，解决方案如下：
a. 新建一个空logstore；
b. 根据查询结果待转存的字段定义日志库的索引字段，确定字段类型；
c. 通过 insert 语法，筛选指定字段投递到新日志库，字段类型同上；
d. 把查询结果保存成告警，完成定时投递到新日志库中；
筛选字段代码：
https://help.aliyun.com/document_detail/158012.html?spm=5176.11065259.1996646101.searchclickresult.35684853Fdcpq9
查询结果：
方法解析：
该方法可以让我们更专注地关注特定日志。INSERT INTO SELECT 语句的作用是从一个表复制数据，然后把数据插入到一个已存在的表中。理论来说，这个方法可以把日志持续投递下去，从A->B->C->D 。。。
3.3 数据展示
3.3.1 仪表盘下钻
有时候，我们对于监控指标数据，需要进一步分析其内容，比如对于同一类型的错误码，希望分析每一条错误日志，解决方案如下：
a. 基于变量，配置查询日志下钻功能；
下钻效果：
https://help.aliyun.com/document_detail/88844.html?spm=5176.11065259.1996646101.searchclickresult.29147287ZIIcEg
3.3.2 变量替换
有时候，我们需要根据指定过滤条件，筛选各项监控指标。比如我们想根据指定门店查看架签状况。解决方案如下：
a. 基于变量，配置变量替换，从而可以使监控指标根据我们输入参数的要求而重新查询出结果。
技术方案链接：
https://help.aliyun.com/document_detail/93647.html?spm=5176.11065259.1996646101.searchclickresult.1c5b35e0JxmKr9
变量替换效果：
3.3.3 仪表盘订阅
有时候我们希望每天定时查看监控报表，而不需要登陆到SLS里面去。通过仪表盘订阅的方式，可以直接把仪表盘定时推送到钉钉群里，供想了解的人查看相关监控指标。解决方案如下；
配置方式：
结果展示：
方法解析：
该方法可以方便每天定时盯屏的同学，并及时把信息同步给相关同学，或者没有SLS日志账号权限的同学。
3.3.4 控制台内嵌分享
有时候，我们需要提供日志给没有分配账号权限的同学查询。如工位探测器信息秒级变化，业务方希望查看实时日志，并让外包同学边查看日志并核对办公区的有无人实际状况。解决方案如下：
a. 向日志管理员申请，创建STS子账号，并进行授权；
b. 根据获取到的AK／SK／roleArn参数，调用SDK代码，生成仪表盘访问链接；
生成链接代码：
https://help.aliyun.com/document_detail/74971.html?spm=ata.13261165.0.0.427b8534208sNq
方法解析：
该方法生成的链接，只允许一人访问，且最长1小时失效；因此可以做成服务方式来提供查询能力，过期之后可触发一次调用，重新生成一个访问链接。
3.4 告警联动
通过以上方式，处理完后的SLS日志，都可以配置成告警模式，发送钉钉机器人告警，或者邮件，或者电话，通知到相关人员，使测试能快速感知问题。
SLS 本身针对告警做了统计，可以对历史告警进行分析。
3.5 解决方案成果展示
3.5.1 链路监控
3.5.2 业务监控
3.5.3 链路和业务监控汇聚
3.5.4 提升测试效率
3.5.5 全局仪表盘配置
20周年年会手环监控大屏
四、总结
本文是对过去一年中保障的各类IOT设备，监控告警能力建设技术方案的一篇总结。核心思想是利用SLS日志服务能力，串联起各项日志，做基于业务维度指标的监控告警。通过确定质量模型，基本可做到1分钟发现问题，满足监控目标。取得的业务成果概括如下：
支撑了6款IOT设备的监控告警。
在对AP基站建设的时候，我们通过不断调整SQL语句，调试监控告警指标，从而完成了对最佳告警方式的验证，使告警更加准确，更加贴合业务，为后续工程化告警时间奠定了基础。
保障了19年双11 光明顶，媒体指挥中心的AP基站运行。
保障了AP基站终端离线的监控告警。
保障了电子架签全年线上稳定运行。
在做工位探测器测试时，引入了控制台内嵌分享技术，提升了测试效率500%；
搭建的测试服务，提供为蚂蚁行政业务方使用，便于业务方快速验证IOT设备的使用效果；
五、展望
关于告警降噪的场景，目前没有找到合适的解决方案，这是个很有意思的场景，且是刚需场景，期待接下来进一步完善该方向的探索实践工作。
写在最后
在做业务测试和安全生产的各项工作中，不论是测试还是研发，我们依赖很多日志数据。一则可以请求研发配合进行日志埋点，二则也可以掌握一些日志加工处理的技巧，利用技术能力去处理日志，以便于在无法改变原始日志的情况，如埋点条件不具备，或遇到封网时间，或研发无开发时间投入等情况下，达到测试或监控告警的目标。最终通过提升一些日志采集，加工，处理，可视化能力，能加强对于业务的质量保障能力。文章中的各个小节内容，自成一段，可独立阅读。若内容对于你的工作有些许参考作用，便倍感欣慰了，欢迎交流指正。
关注「阿里巴巴技术质量」阅读更多
2946
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
