1.前言
背景
衡量一个公司技术成熟与否的重要因素是一个公司的运维系统的水准,运维系统的核心便是监控与报警,诸多初创公司或传统行业区别于成熟大厂的主要方面便是难以建立快速有效的监控与质量体系抑或是他们本身便不够重视。今天我们要讨论的便是一款优秀的监控报警框架。
Prometheus
Prometheus 是什么?简而言之,Prometheus 是一款基于 Google 内部 Borgmon 监控系统理念衍生出的一种非 Google 官方的开源的监控报警框架。
然而这款“非官方”的报警框架,在 2015 年正式加入 Cloud Native Computing Foundation(云原生计算基金会),摇身一变成为一款炙手可热的“生态级”监控框架,与 K8s,gRPC,Docker 结合,变成了实现“坚持和整合开源技术来编排容器作为微服务架构”这一愿景不可或缺的一环。
Prometheus 有什么区别于其他基于 TSDB(时序数据库)的监控产品之处呢?选择 Prometheus 的原因又是什么?
经过几天的搭建调研,笔者总结出以下几点:
- 灵活而强大的查询语句(PromQL):在同一个查询语句,可以对多个 Metrics 进行乘法、加法、连接、取分数位等操作
- 易于管理: Prometheus Server 是一个单独的二进制文件,可直接在本地工作,不依赖于分布式存储
- 高效:平均每个采样点仅占 3.5 bytes,且一个 Prometheus Server 可以处理数百万的 Metrics
- 使用 pull 模式采集时间序列数据,代码侵入低
- 低成本实现高配置化 Metics 配置(Push Gateway),这是我认为最为主要的一点,Metics 的个性化推送有相应的 SDK,支持 Golang、Java、Python 等语言
- 低成本部署,第一次搭建完成 Prometheus 之后,我们会发现,原来部署是如此的 easy,所有的组件都是一个二进制文件,并且原生支持 Docker 容器化部署,易于扩展
其余优点或不足,需各位在使用之余慢慢发现了。
无需赘言,我们现在开始从 0 搭建一套 Prometheus 系统,为大家演示一下其用法与接入流程。
2. Prometheus 工作流程
引用官方一张图
简单来说,其工作流程与所有监控系统类似:收集的 Client->处理的 Sever->报警系统/ UI 展示系统。
Client
其中收集的 Client 可以分为两大类:
- PushGateway
- 其他的 Exporter
为何如此区分,PushGateway 可以理解为一个通用的 Metics 接收的 Sever,其不止承担由 Sever 端 pull 各种 Metics 的作用,同样可以接收由各种渠道(脚本,业务系统)发送来的 point,这种场景非常适合于进行业务监控。PushGateway 的用法笔者将在下文详述。
而其他的 Exporter 是指 Prometheus 官方推出的各种Exporter,例如,节点硬件监控(CPU,内存等)-node_exporter,MySQL 监控 -MySQL Server Exporter 等等,或是由一些第三方推出的监控客户端等。具体的 Exporter 种类可见:https://prometheus.io/docs/instrumenting/exporters/
Sever
Prometheus 的 Sever 本质上只有一个二进制文件,部署十分方便,同时由一个 yml 配置文件来管控 Sever 的所有行为,Prometheus 的 Sever 需要从各个 Client 拉取 Metics,这个过程支持服务发现,同时把拉取到的点录入时序数据库,并输出一个 API 以供查询和 UI 展示
报警/UI
Prometheus 官方推出的报警