接上篇：
https://developer.aliyun.com/article/1222696?spm=a2c6h.13148508.setting.23.4f394f0em1x0Jq
Trace也使用Cmonitor来实现相关能力。日志方面，系统组件的日志、K8s控制面的日志、JVM的DCLog等，主要通过arms-Promtail（采集应用日志的探针）将日志投递到Loki内做长期存储。
K8s系统事件的日志，主要基于ARMS事件中心的功能对K8s的关键事件、Pod调度上的OOM、Error等事件进行监护。
上图为部分系统截图。
比如trace相关控制台可以查看每个请求经过的组件、接收用时、处理时长、回应耗时等标准信息。
日志收集方面，通过在Grafana里配置Loki的数据源，即可轻松根据关键字或Pod标签快速获取到Pod或某个service下挂载的Pod日志，对排查问题提供了极大便利。
上图为ARMS提供的事件中心工作台截图。工作台提供了关键事件列表，可以对等级较高的事件进行订阅，订阅只需简单几步：填写基本规则，选择需要匹配事件的模式，选择告警发送对象，即可对关键事件进行监控，实现及时响应的目的。
完成数据收集后，下一步需要打造高效可用的数据可视化和问题排查工具。
Prometheus与Grafana是一对黄金搭档，因此我们也选择了Grafana作为数据可视化的工具。上图列举了大盘配置过程中的要点：
• 加载大盘时需要控制每个panel上的查询时间线，避免在前端展现过多时间线，导致浏览器渲染压力大。而且，对于问题排查而言，一次性显示多时间线并没有帮助；
• 大盘配置了很多灵活的Variable，可以随意在一张大盘上切换各种数据源和查询条件；
• 使用Transform让Table Panel灵活展现统计信息；
• 分清Range和Instant查询开关，避免无用的范围查询拖慢大盘显示速度。
上图为监控节点信息、K8s集群Pod信息的大盘。整体布局一目了然，通过不同颜色对关键信息进行标记，通过Grafana的动态阈值功能将数字以不同的形式展现，提升问题排查效率。
上图为节点水位大盘，展示了磁盘iops、读写时间、网络流量、内存使用率、CPU使用率等重要信息。
上图为全局SLO大盘。通过Grafana托管服务配置自定义大盘，这也是ARMS最新上线的功能，在云上托管Grafana实例，即可通过云账号直接登录到Grafana界面，其中包含阿里云定制的特有功能。
上图大盘中包含了全局latency、QPS、成功率、错误码的分布情况、QPS的变化趋势，以及一些较细粒度的信息，比如单分片、负载均衡、Gateway组件、center组件等。如遇发版，可以通过带上版本号查看前后版本的区别，可以在pannel中以变量的形式展现datasource，也可以选择全球各个region进行切换查看。
集群中依赖Kafka客户端和服务端，其监控来源于云监控集成。
内部组件强依赖于Kafka，通过指标监控Kafka以及它与broker之间的连接数、平均消息长度、位点提交速率、消费流量等。Producer端提供了缓冲区的占用率、活跃的producer数等信息。
如果组件使用Java编写，还需要监控JVM相关的GC情况，大盘能够提供JVMmemory的情况、GC相关情况、CPU使用率、线程数、线程状态等。此外，比如发版或有动态加载的类，在加载类的统计中可以查看是否存在持续上升的状态等。
如果希望使用电子表格统计集群中的安装状态或重点客户状态，可以使用Grafana的transform功能将整个大盘打造成电子表格式的体验。可以用transform将字段映射到一张电子表格上，打开filter后还可通过筛选各种字段得出查询结果。
日志信息的展示需要通过在Grafana里查询Loki的数据，比如center里有查询日志，其中包含很多原始信息，比如此次查询的时间、UID等。通过后处理的方式，首先将想要的日志按行的方式进行筛选，然后通过模式匹配提取信息，后续还可以按照PromQL将其中某些字段的做大小关系的匹配，最终将匹配出来的日志格式进行二次处理。
上图为告警和分级响应机制流程，依次为告警配置、人员排班、告警触发、应急处理、事后复盘和机制优化，最后将机制优化体现在告警配置上，形成完整的闭环。
以上流程是自建的告警系统，通过依赖自建系统定时跑任务检查指标，然后调用钉钉的webhook或其他运维系统的webhook发出告警，流程中存在几点不足：
• 自建系统的稳定性需要自己负责，如果告警系统的稳定性比运维系统更差，则告警系统的存在无意义。其次，随着整个集群开服的region越来越多，配置越来越复杂，自己维护配置并保证配置全球生效难以实现；
• 依赖手工排班，极易出现漏排或backup缺失；
• 告警触发阶段触发条件非常单一，难以在告警触发链路上增加额外的业务逻辑，如动态阈值、动态打标等；
• 应急处理阶段，信息发送非常频繁，无法主动认领和主动关闭。系统出现问题时，同类告警会在群里高密度发送，无法主动屏蔽告警也是缺陷之一；
• 事后复盘优化的时候没有数据支撑，无法根据已有的告警统计信息来优化整个流程。
因此，我们选择基于ARMS来建立告警系统。ARMS强大的告警和分级响应机制为我们带来了诸多便利：
• 告警模板全球生效功能：只需配置一次告警规则，即可使不同的集群生效告警规则。比如没有告警模板时需要对每个cluster里的指标单独配置告警。而有了模板后，只需通过告警规则模板的方式将PromQL或告警的AlertRule apply到全球各个region集群，非常方便；
• 告警排班表和动态通知：系统能够动态实现轮班替班工作，比手工排班更靠谱；
• 事件处理流和告警富化：可以通过ARMS的事件处理流、告警中心的事件处理流和告警富化功能，在告警触发后动态地打上标记，并且做分级处理。如上图，可以给告警打上优先级标签，优先级较高的告警等级升级为P1，并且可以动态地修改告警接收人；
为了实现上述功能，首先需要有数据源来提供打标的依据。在告警运维中心的控制台上有数据源的功能，告警触发时可以通过HTTP请求或RPC请求调用数据源，而后可以从HTTP URL里获取打标的结果。此接口的实现主要通过IFC轻量工具在线写好代码，代码主要负责读取ACM配置中心里的信息配置项，然后读取配置项并对外暴露HTTP接口，提供给告警运维中心动态地调用。
完成以上步骤后，还需配置事件处理流，将需要的信息通过匹配更新模式的方式传递到上述接口，并返回优先级，最终打到告警上。
• 告警的认领、关闭和屏蔽：ARMS 提供了认领、关闭、关注、屏蔽等实用功能，显著提升了告警质量；
• 告警的认领接手率统计大盘：复盘的时候需要知道每个人处理了多少告警、处理时长、告警平均恢复时间等，引入了认领、关闭、恢复、屏蔽机制后，ARMS告警中心在后台记录了事件的日志，通过对日志的分析即可提供有用的复盘信息。
得到告警信息后，用户希望可以在白屏化的界面上处理问题，因此我们引入了基于Grafana的白屏化运维工具链。其原理为，在配置大盘的时候引入动态信息，并将其以链接的形式拼接到大盘里。
我们内部有各种系统，如果没有官方的链接拼接，则需要自己首拼 URL 或手动搜索，效率非常低。而通过在Grafana里嵌入链接的方式，将运维动作固化成链接之间的跳转，对于效率的提升非常有帮助。能够通过Grafana一套工具将所有工作完成，将运维动作标准化、固化，减少人工出错的可能性。
3. 总结和未来工作
第一， 告警准确度和接手率的优化。目前还没有很好的方式能够将告警的复盘信息高效地利用起来，未来我们将尝试通过告警准确度和接手率的信息，及时调整不合理的告警阈值，也可能会尝试多阈值的告警，比如告警在A到B范围之内是多少等级，在B以上是多少等级。
第二， 多类型数据联动。比如在排查问题的时候，除了Metrics、Trace和Log之外，还有profiler、CPU的火焰图等信息，而目前这些信息与可观测数据的联动较低。提升数据联动，可以提升问题排查效率。
第三， 埋点成本控制。对于外部客户而言，埋点成本直接关系到客户使用阿里云的成本。我们将定期地对自监控指标的维度、发散的维度等进行针对性的治理，并且对于无用的维度进行数据清理，将埋点成本控制在较低水平。
