监控需求 :

• 系统出现问题 , 能及时感知
• 了解数据趋势，预测未来可能出问题
• 了解系统的水位，为服务扩缩容提供数据支撑
• 感知待优化点，如 : 中间件参数的调优
• 及时感知业务异常

可观测性

可观测性支柱 :

• 指标监控
• 日志监控
• 链路追踪

指标监控

指标监控 : 一般用折线图呈现

• 指标如有 : 机器的 CPU 利用率、数据库实例的流量、网站的在线人数
• 特点 : 只处理数字，历史数据存储成本较低，实时性好，生态庞大
• 开源产品 : Zabbix、Open-Falcon、Prometheus、Nightingale

日志监控

日志 :

• 作用 : 了解软件的运行情况、业务的运营情况
• 特点 : 一般数据量较大，不够结构化，存储成本较高
• 开源产品 : ELK、Loki

日志的数据源 :

• 操作系统的日志 : 感知系统级事件的发生
• 接入层的日志 : 知晓哪些域名、IP、URL 收到访问，是否成功 , 延迟情况
• 服务运行日志 : Exception 信息，调用堆栈

Kibana 查询 :

链路追踪

背景 : 随着微服务的普及，单体应用被拆为很多个小服务，服务之间有错综复杂的调用关系，排查较困难

思路 : 以请求串联上下游模块，为每个请求生成一个随机字符串作为请求 ID

• 服务之间互相调用的时，把该 ID 逐层往下传递，每层分别耗费了多长时间，是否正常处理，都能收集起来 , 并附到这个请求 ID 上
• 当追查问题时，用请求 ID 就能把所有信息串联起来

产品 : Skywalking、Jaeger、Zipkin

Zipkin 页面 :

开源产品

• Zabbix : 推荐监控设备
• Prometheus+Grafana : 推荐监控 Kubernetes
• Nightingale : 推荐监控传统设备、中间件，又兼顾 Kubernetes

Zabbix

Zabbix : 企业级的开源解决方案，擅长设备、网络、中间件的监控

• 主要监控设备和中间件

优点 :

• 对各种设备的兼容性较好，Agentd 能运行在很多平台
• 架构简单，用时序数据存储，易维护，备份，转储都较容易
• 社区庞大，资料多

缺点 :

• 用数据库做存储，无法水平扩展，容量有限。当 10 秒采集一次，上限大约能监控 600 台设备
• 数据结构较固化，没有灵活的标签设计，对云原生架构下动态多变的环境，无能为力

Zabbix 整体架构 :

Open-Falcon

Open-Falcon 由小米开源，想解决 Zabbix 的容量问题

Open-Falcon 架构图 :

优点 :

• 能处理大规模监控场景，比 Zabbix 的容量要大，能处理设备、中间件、应用层的监控
• 组件拆分较散，都用 Go 开发，Web 用 Python，易做二次开发

缺点 :

• 生态不够庞大，多数没回馈社区
• 核心开发人员离职，项目停滞不前

Prometheus

Prometheus 为 Kubernetes 而生。对 Kubernetes 做了直接的支持，提供了多种服务发现机制，简化Kubernetes 监控

Prometheus 架构图 :

优点

• 对 Kubernetes 支持很好
• 生态庞大，有很多 Exporter
• 支持很多时序库作为后端的 Backend 存储
• 支持多种不同语言的 SDK，供业务代码嵌入埋点

缺点 :

• 易用性较差，如 : 告警策略要修改配置文件，协同较麻烦
• Exporter 参差不齐，每个监控目标要一个 Exporter，管理成本较高
• Prometheus 默认只提供单机时序库，集群方案要依赖其他的时序库

Nightingale

Nightingale 与 Prometheus 做良好的整合，打造了更完备的方案

优点 :

• 较完备的 UI，有权限控制，协同较好
• 兼容并包，设计较开放，支持对接 Categraf、Telegraf、Grafana-Agent、Datadog-Agent 等采集器 , Prometheus的各种 Exporter
• 时序库能对接 Prometheus、VictoriaMetrics、M3DB、Thanos

缺点 :

• 告警引擎单独部署到各个机房，部署维护较麻烦
• 告警事件发送缺少聚合降噪收敛逻辑