【面试】你有使用过链路追踪技术吗?

这个问题之前也有被问过。的确,链路追踪技术对系统异常定位非常有用。目前公司的链路追踪已经形成数据闭环,下面我将简单说说我是如何为公司规划这套链路追踪技术的。

目前公司的链路追踪技术使用的解决方案是:Zipkin + Prometheus + Grafana

这时候,应该有小伙伴会说 Zipkin 不是自己就有可视化管理界面了吗,为什么还要这样集成来使用呢?

这是历史原因造成的,公司成立之初就已经使用 Zabbix 作为云服务资源监控,后来为了方便进行数据分析和汇报,将 Zabbix 接入 Grafana 进行展示。之后 Docker 容器通过 Cadvisor + Prometheus + Grafana 进行监控也是通过 Grafana 进行展示。再之后日志监控平台我们使用的是 Elasticsearch + Filebeat + Grafana 也是通过 Grafana 进行展示的… 所以咯,Zipkin 就还是接入到 Grafana 来输出吧。

至于如何实现 Zipkin 与 Prometheus 和 Grafana 集成就不说了,网上有大量的资料。由于篇幅关系我还是主要说一下实现思路吧,共分为 6 部分:

  1. 系统架构规划

由于链路信息发送方来自 Zipkin 客户端,因此必须在公司基础框架中默认集成了 Zipkin 客户端并在 Springboot 分包配置中编写一个默认服务端地址(如果服务端地址有变,可以在项目配置中重写配置信息)。通过这种方式能让每个分布式的微服务都具备链路监控能力。

  1. 日志收集规划

在集成 Zipkin 时需要提前配置好采样率,避免日志信息的过度采集。此外,日志需要按照公司规范进行输出,若公司规范与 Zipkin 要求出现冲突时需做到两者融合,并适当修订日志规范。

  1. Zipkin 服务端部署

虽然 Zipkin 服务端存储提供了关系型数据库和 Elasticsearch 两种模式,但一般都会选择配置成使用 Elasticsearch(数据不存在强事务要求,因此可以使用 NoSQL 数据库进行存储)方便检索。

这个时候,应该又有小伙伴会问,既然数据源是 Elasticsearch,那么直接通过 Grafana 采集 Elasticsearch 数据源就可以了,为什么还要加上 Prometheus 呢?

其实 Prometheus 在这套方案里面更多的是作为实时的、自动化的监控和告警工具使用的,下面我将会说到。

  1. 与监控系统集成

将 Zipkin 服务端接入现有监控系统 Prometheus,再由 Grafana 去读取 Prometheus 的实时数据流(这个就不多说了)。

  1. 快速定位链路问题

一般在项目上线前都会做模拟业务场景的压力测试。我们可以根据多轮压测结果进行数据建模,制定访问等级和响应标准。

之后再根据响应标准编写自动化脚本,找到服务间调用链路的高延迟节点,对性能瓶颈和容错性进行分析。还好, Grafana 为我们提供了大量免费的、优秀的数据挖掘模版,我们只需在官网找,花点时间总可以找到一两个适合自己的。根据分析结果我们可以尝试对调用链路进行拆分,寻找一些可行的异步或者缓存等方式优化响应速度。同理,遇到异常报错的时候根据 Trace ID 查询对应日志,快速定位故障服务。

  1. 与告警系统集成

Prometheus 中可以设置复杂的告警规则,上文说到的自动化脚本也是通过 Prometheus 配置 alertmanager 参数发送告警信息给运维管理人员。

目前公司采用 alertmanager 将告警信息推送到钉钉的,超过 4 小时没有处理完成的情况下会自动发送邮件给项目负责人,项目负责人会根据情况看看是否需要作为绩效扣分判定条件。

虽然说目前已经基本能够形成链路闭环,但其实还有很多方面可以做的。后面我还计划将 Prometheus 的告警触发通过调用 Rancher API 实现 Docker 应用故障的自动恢复和弹性扩容,这些有机会再跟各位说说吧。

你可能感兴趣的:(杂谈,面试,运维)