作者：宋傲（凡星）
背景及现状
体系架构简介
上图为阿里云内部实际运用的体系架构，体系首要用途为实时数据流的核算和存储。运用阿里云的容器服务 ACK 作为体系底座，容器化的布置、发布、管控等全部依据 K8s 规范。运用自己开发的 Gateway service 作为体系流量入口，并依据 LoadBalancer 类型的 service 布置。
此架构也是运用 K8s 做体系较为常见的做法，经过 ACK 供给的 CCM 组件自动将 service 和底层 SLB 实例进行绑定，经过此实例接受外部流量。Gateway 收到上报的数据流后，将数据放入 Kafka 并在某个 topic 中进行数据缓冲。当 Consumer 感知到数据流的上报后，则会从 Kafka 相应的 topic 中对数据进行进一步核算处理，并将终究成果写入存储介质。
此处存在两种存储介质：其间阿里云块存储 ESSD 相对较快，但价格较高；文件存储 NAS 首要用于存放性能要求较低的数据。元数据由 ACM 进行管理，自研的组件 Consumer 和 Center 担任从存储介质中查询核算成果，并返回给用户。
体系现状
体系现在为全球开服，布置在全球将近 20 个 region 中，从图中也能够间接看出数据读写链路较长，需求经过多个组件的处理。监控目标也较为杂乱，包括根底设施（调度、存储、网络等）、中间件（Kafka）、事务组件（Gateway、Center、Consumer）。
作业内容
- 可观测数据的搜集
可观测性首要包括Metrics、Tracing 和 Logging三类数据。三类数据各司其职，相辅相成。
Metrics 担任答复体系是否呈现问题，它也是体系的自监控体系入口。针对 Metrics 做反常的告警或问题的排查，能够快速确认体系是否有问题，是否需求人为介入处理。
Tracing 担任答复体系问题呈现在什么方位，它能够供给组件之间的调用联系、每一次恳求以及哪两个组件之间的调用进程呈现了问题等具体细节。
找到呈现问题的组件后，需求经过最具体的问题日志即 Logging 来定位问题根因。
- 数据可视化&问题排查
搜集到三类数据后，下一步需求经过大盘将数据用可视化的方法展示，能够一眼确认问题所在，使问题排查更高效。
- 告警&应急处理
确认问题后，需求经过告警和应急处理流程来处理问题。
应急处理进程首要有以下几个要害：
第一，需求分级的告警通知和晋级策略，能够快速找到相应的人员处理告警。与此同时，若原定人员因为某些原因无法及时处理，还需将告警晋级到其他人员以及时处理。
第二，问题招领和处理流程规范化。
第三，过后计算及复盘。体系呈现毛病并处理后，还需求过后的计算以及复盘作业，让体系经过毛病和经验防止后续再呈现相同的问题，让体系更稳定。
第四，运维处理东西化、白屏化，尽量减少手动输入命令的作业，将整套规范的处理动作用东西进行固化。
实践经验共享
可观测数据搜集&接入
- 目标（Metrics）数据
监控的第一步是搜集可观测数据，这些数据在体系里能够分为三个层面。
最上层为运用层，首要关怀中心事务接口的健康度，经过RED（Rate、Error、Duration）三个黄金目标进行衡量。其间 Rate 指接口的 QPS 或 TPS ，Error 指过错率或过错数，Duration 指接口在多长时刻内能够返回。能够经过黄金目标来界说 SLO 并分配 Error Budget 。假如 Error Budget 很快耗尽，则应及时调整 SLO，直到体系优化到足够完善后，再将其调高。也能够经过 Apdex Score 衡量服务的健康度，核算公式如上图所示。此外，运用层也会关怀与事务强相关的目标，比方营收、用户数、UV、PV 等。
中间层为中间件和存储，首要关怀体系里许多运用的 Kafka client 端消费位点的提交状况、生产者缓冲区的占用率、是否会提前将缓冲区占满导致新的音讯进不来、消费延迟、均匀音讯巨细等，比方 Kafka Broker 端的水位、读写流量、磁盘运用率等，再比方云盘 ESSD 的挂载成功率、IOPS、磁盘空余空间等。
最下层是根底设施层，关怀的目标较为杂乱，典型的有比方 ECS（K8s Node） CPU 内存水位、重启次数、定时运维事情等，比方 K8s 中心组件的 API server、 ETCD、调度相关目标等，比方事务 Pod 的 Pending 状况、是否有资源可供足够的调度、OOMKilled 事情、Error 事情等，再比方 VPC/SLB 相关的出口带宽、丢掉连接数等。
监控 ECS 节点需求运用 node-exporter Daemonset 的方法布置，K8s 云原生的中心组件能够经过 Metrics 接口将目标露出，供 Prometheus 抓取。Kafka 或存储组件因为运用了阿里云的云产品，本身供给了根底监控目标，能够直接接入。ACK 对 CSI 存储插件也供给了十分中心的目标比方挂载率、iops、空间占用率等，也需求接入。运用层包括 Java 运用和 Go 运用，Java 运用 MicroMeter 或 Spring Boot Actuator 做监控，Go 运用直接运用 Prometheus 官方 SDK 做埋点。
依据 ACK 和 K8s 体系， Metrics 协议的最佳选型即 Prometheus。开源自建的 Prometheus 与云保管的接入难度不相上下，但可靠性、运维本钱等方面，云保管的 Prometheus 更优于自建。比方运用 ARMS 体系，能够直接在集群里装置十分轻量级的探针，然后将数据中心化存储在全保管的存储组件，并围绕它做监控、告警、可视化等，整个进程十分便利，不需求自建开源组件。云保管在搜集才能和存储才能上也更有优势。
Prometheus 针对 ECS 节点、K8s 中心组件、Kafka 和存储组件都供给了一键接入的才能。
K8s 根底监控和节点状况接入首要经过 ACK 组件管理中心，只需简略地装置相关组件，即可运用该才能。
Kafka 的接入首要经过 Prometheus 云服务实例，云服务实例现在现已接入阿里云十分完整的 PaaS 层云产品。接入 Kafka 时，所需填写的目标都为常见目标，无需额定学习本钱。
云盘 ESSD 监控的接入首要经过 CSI 存储插件监控。ACK 里的 csi-provisioner 组件供给了很有用的可观测性才能，能够经过它供给的信息及时检查哪块盘没有挂载上、哪块盘挂在后 iops 达不到要求或装备告警，以及时发现云盘的反常状况。
经过 ARMS Prometheus 接入，预置搜集的 job 比方 K8s cluster 等级、node 等级的 PV 状况都能够很便利地进行监控。
运用层不存在一键接入的便捷方法，需求经过运用埋点+服务发现的方法，将整个运用的 Metrics 接口露出出来，供给给 ARMS Prometheus 的探针抓取。
Java 运用需求运用 MicroMeter 或 Spring Boot Actuator 进行埋点。
以上图代码为例，MicroMeter 中许多 JVM 相关信息能够简略地经过几行代码进行露出，其他更有协助的信息，比方进程等级的 memory 或 thread、system 信息等也能够经过很简略的方法将其接入。设置完埋点后，需求在内部发动 server ，将 Metrics 信息经过 HTTP 接口的方法露出，最后绑定指定的端口。至此，埋点流程结束。
此外，假如有事务目标，只需将自己的目标注册到大局的 Prometheus Registry 即可。
ARMS 探针抓取露出的端点，只需添加 ServiceMonitor ，由 ServiceMonitor 直接经过操控台白屏化的方法，简略地写几行 YAML 的界说，即可完整地将整个监控的搜集、存储和可视化跑通。
Go 运用与 Java 大同小异，只是埋点方法有所区别，首要运用 Prometheus 官方的 SDK 埋点。
以上图为例，比方体系里有一个查询组件关怀每一条查询的时刻分布，能够运用 Prometheus 里面直方图类型的目标，记载每个恳求的时刻分布，并在埋点的时分指定常用的分统进行计算。再由 ServiceMonitor 将 Go 运用的 endpoint 写入，终究在操控台上完结整套运用的接入。
ARMS 还供给了依据 eBPF 的无侵入可观测性完结方案，首要适用于不期望修正代码的场景，运用无侵入的方法监控体系接口的 RED，经过 ARMS Cmonitor 探针结合 eBPF 的方法，经过体系内核的 filter 完结信息的抓取和存储。
运用上述方法需求在集群里额定装置 Cmonitor App，装置后可在 Daemonset 看到 Cmonitor Agent，每个节点都需求发动 Cmonitor Agent，作用是经过 eBPF 的方法注册到体系内核中，抓取整台机器的网络流量，然后过滤出想要的 service 网络的拓扑等信息。如上图，它能够监控整个体系的 QPS 、呼应时刻的分布等信息。
- 链路（Trace）和日志（Log）数据
Trace 也运用 Cmonitor 来完结相关才能。日志方面，体系组件的日志、K8s 操控面的日志、JVM 的 DCLog 等，首要经过 arms-Promtail （搜集运用日志的探针）将日志投递到 Loki 内做长时间存储。
K8s 体系事情的日志，首要依据 ARMS 事情中心的功用对 K8s 的要害事情、Pod 调度上的 OOM 、Error 等事情进行监护。
- 读写链路监控和问题定位
上图为部分体系截图。
比方 trace 相关操控台能够检查每个恳求经过的组件、接纳用时、处理时长、回应耗时等规范信息。
- 组件运转日志搜集和存储
日志搜集方面，经过在 Grafana 里装备 Loki 的数据源，即可轻松依据要害字或 Pod 标签快速获取到 Pod 或某个 service 下挂载的 Pod 日志，对排查问题供给了极大便利。
- K8s 运转事情搜集和监控
上图为 ARMS 供给的事情中心作业台截图。作业台供给了要害事情列表，能够对等级较高的事情进行订阅，订阅只需简略几步：填写根本规矩，挑选需求匹配事情的方式，挑选告警发送目标，即可对要害事情进行监控，完结及时呼应的意图。
数据可视化及问题排查
- Grafana 大盘装备实践
完结数据搜集后，下一步需求打造高效可用的数据可视化和问题排查东西。
Prometheus 与 Grafana 是一对黄金搭档，因而咱们也挑选了 Grafana 作为数据可视化的东西。上图列举了大盘装备进程中的要害：
-
加载大盘时需求操控每个 panel 上的查询时刻线，防止在前端展示过多时刻线，导致浏览器烘托压力大。而且，关于问题排查而言，一次性显现多时刻线并没有协助。
-
大盘装备了许多灵敏的 Variable ，能够随意在一张大盘上切换各种数据源和查询条件。
-
运用 Transform 让 Table Panel 灵敏展示计算信息。
-
分清 Range 和 Instant 查询开关，防止无用的规模查询拖慢大盘显现速度。
K8s集群总览
上图为监控节点信息、 K8s 集群 Pod 信息的大盘。全体布局一望而知，经过不同色彩对要害信息进行符号，经过 Grafana 的动态阈值功用将数字以不同的方式展示，提高问题排查功率。
节点水位
上图为节点水位大盘，展示了磁盘iops 、读写时刻、网络流量、内存运用率、CPU运用率等重要信息。
大局 SLO
上图为大局 SLO 大盘。经过 Grafana 保管服务装备自界说大盘，这也是 ARMS 最新上线的功用，在云上保管 Grafana 实例，即可经过云账号直接登录到 Grafana 界面，其间包括阿里云定制的特有功用。
大盘中包括了大局 latency、QPS、成功率、过错码的分布状况、QPS 的变化趋势，以及一些较细粒度的信息，比方单分片、负载均衡、Gateway 组件、center 组件等。如遇发版，能够经过带上版本号检查前后版本的区别，能够在 pannel 中以变量的方式展示 datasource，也能够挑选全球各个 region 进行切换检查。
Kafka 客户端及服务端监控
集群中依靠 Kafka 客户端和服务端，其监控来源于云监控集成。
内部组件强依靠于 Kafka，经过目标监控 Kafka 以及它与 broker 之间的连接数、均匀音讯长度、位点提交速率、消费流量等。Producer 端供给了缓冲区的占用率、活泼的 producer 数等信息。
Java 运用运转状况监控
假如组件运用 Java 编写，还需求监控 JVM 相关的 GC 状况，大盘能够供给 JVM memory 的状况、GC 相关状况、CPU 运用率、线程数、线程状况等。此外，比方发版或有动态加载的类，在加载类的计算中能够检查是否存在持续上升的状况等。
Table 格式的过错类型复盘计算表
假如期望运用电子表格计算集群中的装置状况或要点客户状况，能够运用 Grafana 的 transform 功用将整个大盘打造成电子表格式的体验。能够用 transform 将字段映射到一张电子表格上，打开 filter 后还可经过筛选各种字段得出查询成果。
- 问题排查事例共享
日志信息的展示需求经过在 Grafana 里查询 Loki 的数据，比方 center 里有查询日志，其间包括许多原始信息，比方此次查询的时刻、UID 等。经过后处理的方法，首要将想要的日志按行的方法进行筛选，然后经过方式匹配提取信息，后续还能够按照 PromQL 将其间某些字段的做巨细联系的匹配，终究将匹配出来的日志格式进行二次处理。
告警和分级呼应机制
上图为告警和分级呼应机制流程，依次为告警装备、人员排班、告警触发、应急处理、过后复盘和机制优化，最后将机制优化体现在告警装备上，形成完整的闭环。
以上流程是自建的告警体系，经过依靠自建体系定时跑使命检查目标，然后调用钉钉的 webhook 或其他运维体系的 webhook 发出告警，流程中存在几点缺乏：
- 自建体系的稳定性需求自己担任，假如告警体系的稳定性比运维体系更差，则告警体系的存在无意义。其次，随着整个集群开服的 region 越来越多，装备越来越杂乱，自己保护装备并保证装备全球收效难以完结。
- 依靠手艺排班，极易呈现漏排或 backup 缺失。
- 告警触发阶段触发条件十分单一，难以在告警触发链路上添加额定的事务逻辑，如动态阈值、动态打标等。
- 应急处理阶段，信息发送十分频频，无法自动招领和自动封闭。体系呈现问题时，同类告警会在群里高密度发送，无法自动屏蔽告警也是缺陷之一。
- 过后复盘优化的时分没有数据支撑，无法依据已有的告警计算信息来优化整个流程。
因而，咱们挑选依据 ARMS 来树立告警体系。ARMS 强大的告警和分级呼应机制为咱们带来了许多便利：
- 告警模板全球收效功用：只需装备一次告警规矩，即可使不同的集群收效告警规矩。比方没有告警模板时需求对每个 cluster 里的目标独自装备告警。而有了模板后，只需经过告警规矩模板的方法将 PromQL 或告警的 AlertRule apply 到全球各个 region 集群，十分便利。
2.告警排班表和动态通知：体系能够动态完结轮班替班作业，比手艺排班更靠谱。
3.事情处理流和告警富化：能够经过 ARMS 的事情处理流、告警中心的事情处理流和告警富化功用，在告警触发后动态地打上符号，而且做分级处理。如上图，能够给告警打上优先级标签，优先级较高的告警等级晋级为 P1，而且能够动态地修正告警接纳人。
为了完结上述功用，首要需求有数据源来供给打标的依据。在告警运维中心的操控台上有数据源的功用，告警触发时能够经过 HTTP 恳求或 RPC 恳求调用数据源，然后能够从 HTTP URL 里获取打标的成果。此接口的完结首要经过 IFC 轻量东西在线写好代码，代码首要担任读取 ACM 装备中心里的信息装备项，然后读取装备项并对外露出 HTTP 接口，供给给告警运维中心动态地调用。
完结以上过程后，还需装备事情处理流，将需求的信息经过匹配更新方式的方法传递到上述接口，并返回优先级，终究打到告警上。
4.告警的招领、封闭和屏蔽：ARMS 供给了招领、封闭、重视、屏蔽等实用功用，明显提高了告警质量。
5.告警的招领接手率计算大盘：复盘的时分需求知道每个人处理了多少告警、处理时长、告警均匀恢复时刻等，引进了招领、封闭、恢复、屏蔽机制后，ARMS告警中心在后台记载了事情的日志，经过对日志的剖析即可供给有用的复盘信息。
得到告警信息后，用户期望能够在白屏化的界面上处理问题，因而咱们引进了依据 Grafana 的白屏化运维东西链。其原理为，在装备大盘的时分引进动态信息，并将其以链接的方式拼接到大盘里。
咱们内部有各种体系，假如没有官方的链接拼接，则需求自己首拼 URL 或手动查找，功率十分低。而经过在 Grafana 里嵌入链接的方法，将运维动作固化成链接之间的跳转，关于功率的提高十分有协助。能够经过 Grafana 一套东西将所有作业完结，将运维动作规范化、固化，减少人工出错的可能性。
总结和未来作业
第一，告警准确度和接手率的优化。现在还没有很好的方法能够将告警的复盘信息高效地利用起来，未来咱们将测验经过告警准确度和接手率的信息，及时调整不合理的告警阈值，也可能会测验多阈值的告警，比方告警在 A 到 B 规模之内是多少等级，在 B 以上是多少等级。
第二，多类型数据联动。比方在排查问题的时分，除了 Metrics 、Trace 和 Log 之外，还有 profiler、CPU 的火焰图等信息，而现在这些信息与可观测数据的联动较低。提高数据联动，能够提高问题排查功率。
第三，埋点本钱操控。关于外部客户而言，埋点本钱直接联系到客户运用阿里云的本钱。咱们将定期地对自监控目标的维度、发散的维度等进行针对性的管理，而且关于无用的维度进行数据清理，将埋点本钱操控在较低水平。
钉钉扫码，入群了解更多可观测实践
