共计 6986 个字符，预计需要花费 18 分钟才能阅读完成。
作者：宋傲（凡星）
背景及现状
零碎架构简介
上图为阿里云外部理论应用的零碎架构，零碎主要用途为实时数据流的计算和存储。应用阿里云的容器服务 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 的火焰图等信息，而目前这些信息与可观测数据的联动较低。晋升数据联动，能够晋升问题排查效率。
第三，埋点老本管制。对于内部客户而言，埋点老本间接关系到客户应用阿里云的老本。咱们将定期地对自监控指标的维度、发散的维度等进行针对性的治理，并且对于无用的维度进行数据清理，将埋点老本管制在较低水平。
钉钉扫码，入群理解更多可观测实际
