关于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速率

你可能感兴趣的:(关于Prometheus监控实践的思考)