关于Prometheus监控实践的思考

运维原则(方法论)-监控方向

• 监控是基础设施必须存在,先买服务器,后装监控.再部署服务并投入使用.
• 监控架构越简单越好,可用性越高越好,任何服务挂了,监控也不能挂.
• 需要处理的告警,才发出来,发出来了就要处理.如果是误报,则屏蔽.不需要处理的可以团队内部做数据分析.
• 首选运维架构:云+云监控+k8s+prometheus.

版本选择

• 最新版

使用场景

• 资源监控
• 应用资源或性能监控
• 不适用日志,事件,调用链等等
• 水平扩展方案欠缺
• 监控数据保留时间7-14days(google SRE建议)

集群解决方案

• 使用Thanos

如何实现监控数据采集和展示

• 官方提供各种exporter(node,es,kafka,mysql,k8s),这里不赘述.
• 自建exporter
• Grafana官方提供exporter对应Dashboard模板

监控指标方法论(Google SRE)

Google 在"Sre Handbook"中提出了"四个黄金信号"：延迟、流量、错误数、饱和度

• Use 方法：Utilization:资源繁忙的时间百分比，例如节点 CPU 使用率、Saturation:资源必须完成的工作量，通常是队列长度或节点负载、Errors:错误事件的计数。
• Red 方法：Rate:每秒请求数、Errors:失败的请求数、Duration:这些请求所花费的时间，延迟测量的分布

常见采集标准

USE 报告问题的原因。RED 报告用户体验，更有可能报告问题的症状。
警报的最佳实践是针对症状而不是原因发出警报，因此应在 RED 仪表板上进行警报。

• 在线服务：如 Web 服务、数据库等，一般关心请求速率，延迟和错误率即 RED 方法
• 离线服务：如日志处理、消息队列等，一般关注队列数量、进行中的数量，处理速度以及发生的错误即 Use 方法
• 批处理任务：和离线任务很像，但是离线任务是长期运行的，批处理任务是按计划运行的，如持续集成就是批处理任务，对应 K8S 中的 job 或 cronjob， 一般关注所花的时间、错误数等，因为运行周期短，很可能还没采集到就运行结束了。
• 底座安全：如k8s事件，linux操作，进程监控。在特殊场景下，无法保证未知的操作是否存在安全隐患。

容量规划

存储空间

磁盘大小=保留时间每秒获取样本数样本大小
样例 一天存储空间 1.63GB=86400 * 1.63 * 12500 / (1024 * 3)

这里用aws-prod环境举例:

样本大小

rate(prometheus_tsdb_compaction_chunk_size_bytes_sum[1h])/rate(prometheus_tsdb_compaction_chunk_samples_sum[1h]) 1.63 bytes 

每秒获取样本数

rate(prometheus_tsdb_head_samples_appended_total[1h]) 1.25w 

采集数据实战经验

自研服务

关键业务

• 核心功能状态
• 事件错误

API类

• 资源
• 错误率,响应速度,容量监控(峰值监控)
  开源中间件(建议使用官方exporter和dashboard,已经很成熟)

中间件

队列

• 资源,队列数量,消费情况

数据库(关系型,非关系型,缓存)

• 资源,连接数
• 慢查询, 查询速率

负载均衡

• 网络流量,QPS

计算资源(服务器)

• 网络流量,tcp连接情况
• 硬盘空间,iops,io速率