Prometheus官方文档

入门指导

• Instructions and example code for a Prometheus workshop.

• 手把手教你构建Prometheus系统

• Prometheus Server
• Node Exporter
• The expression language
• Instrument code(使用Prometheus客户端库构建应用代码，通过Prometheus监控应用)
• Dashboard
• Alerting
• Pushgateway

• 提出一些问题，这些问题有助于你对Prometheus的使用和理解
• 安排一些任务，通过完成这些任务(没有答案)，帮助你使用Prometheus系统
• 文章相对比较老(2016.08.05, Prometheus < 2.0)，不过对入门来说很有参考价值

• How To Install Prometheus using Docker on Ubuntu 14.04.

这个文章相对比较老，不过可以作为基于Docker部署Prometheus，Node Exporter，Grafana的入门参考：

• 使用Docker部署相关Prometheus组件
• Prometheus，Node Exporter，Grafana的简单书用
• 例子中Prometheus的版本是2.0之前的，有些命令参数已经不再使用了

博客

• 官方博客

• SoundCloud中关于Prometheus的博客

必读。这篇博客对Prometheus整体做了一个概括性的、比较详细的介绍(Prometheus起源于SoundCloud)：

• Prometheus的前世今生
• Pormetheus的设计哲学
• 文章相对比较老(2015.01.26)，有些内容不适于Prometheus 2.0

• Robust Perception blogs about Prometheus.

Prometheus

• Monitoring without Consensus (推荐)

• 对监控系统来说，关键特性等级：可靠性>准确性>一致性>持久性。监控系统最重要的是可用性，没必要依赖集群
• 集群更看中一致性，而不是可靠性；并且集群会有各种各样的问题，很难保证可靠性
• 集群更适用于一个节点性能无法满足需要的应用，而Prometheus十分高效，不需要集群
• Prometheus的高可用性是通过运行多个相同的Prometheus实例来实现的，实例之间独立
• 多个独立Prometheus实例，会造成数据有轻微的不一致。但是这个不一致，并不影响监控、报警的正确性；也不会影响监控数据的准确性。所以这个不一致，无所谓
• 警报需要处理警报中的噪声
• 一天之后的监控数据针对监控和报警来说，不会再有意义；当然性能分析等等除外
• 基础设施和服务down，不可避免，不用过于担心；需要有个强壮的监控系统

• High Availability Prometheus Alerting and Notification

• 高可用
• 至少两个同样的Prometheus服务
• 使用Alertmanager本身提供的集群功能
• 配置所有的Prometheus实例与所有的Alertmanager通信

• Relabelling can discard targets, timeseries and alerts

• <relabel_config> 配置是通过修改 label 来控制某些 target 不被抓取
• <metric_relabel_configs> 配置是通过修改 label 来控制某些时间序列不被抓取
• <relabel_config> 配置是通过修改 label 来控制某些 alert 不被发送给Alertmanager
• <relabel_config> 配置是通过修改 label 来控制某些时间序列不被写入远端
• relabel行为中，drop and keep行为(特殊)类似与过滤器，如果label不匹配，相应数据会被丢弃；而其它的relabel行为，会继续处理数据(不论匹配与否)

• Scaling and Federating Prometheus

• 一个单点的Prometheus能够处理百万级别的时间序列；也就是：上千个服务，每个服务上千个样本，采集间隔10s
• 如果你有多个数据中心，希望能够看到“全局”级别的聚合数据，需要使用Prometheus的联盟功能
• 如果你的数据量很大(一个Prometheus性能无法满足)，需要根据数据进行分区(分片)；比如根据前端、后端、主机等，每一个分区一个Prometheus，再构成Prometheus联盟
• 如果数据量再大；再分，再联盟

Alert

• Reduce Noise From Disk Space Alerts(August 7, 2015)

• 通过例子简单介绍Prometheus警报规则语法
• 应用Prometheus predict_linear() 函数作警报预测
• Simple linear regression

• Alerting on Down Instances(September 1, 2015)

• 监控、告警实例是否down (通过 up metrics)
• 监控、告警down实例的百分比

• Audio Alerting with Prometheus

• 简单使用Blackbox Exporter (这个Exporter是个好东西)
• 简单使用relabel功能
• 发送通知给webhook(使用webhook处理警报信息)

• What Alertmanager 0.1.0 means for you

Alertmanager与之前版本的区别

• 通过路由规则树处理警报，之前仅仅是列表(功能更强大)
• 可以通过模版定制化警报的通知(有默认配置)
• 多条警报可以聚合成一条通知

• Sending email with the Alertmanager via Gmail

• 配置Alertmanager，通过Gmail发送警报邮件
• Alertmanager默认的警报信息模版，信息不够详细

• Prometheus and Alertmanager Architecture

• 问什么Prometheus和Alertmanager是分离的
• Prometheus十分注重可靠性而不是持久化
• 为什么不使用分布式数据库(可靠性很难保证)
• 针对当前分布式数据库的研究--Jepsen

• Sending alert notifications to multiple destinations

• 警报路由匹配时，当匹配成功，其它路由规则就不会再处理该警报(一般情况)
  *continue 可以改变上述默认行为，匹配成功之后会继续匹配之后的规则，直至匹配成功

• Using time series as alert thresholds

• 警报阈值，除了静态配置外，还可以通过 recording rules 或者 exporter 生成阈值时间序列(包含标签)
• 阈值时间序列可以通过 group_left 操作与相应的时间序列匹配
• 上述方法可以与 use labels to direct email notifications 结合使用(alertmanager可以更具label数据，动态处理)

• Using labels to direct email notifications

• A handy feature of the Alertmanager is that almost all notification fields are templatable. This can be used to route emails based on labels.
• 前提，目标地址(比如，邮件目的地址)需要存在于标签集中：
  mymetric{job="myjob",email_to="foo@example.org",instance="host1"}
• Alertmanager需要配合做两件事情：1、通过分组，确保每个目标地址(比如，邮件地址)有对应的通知；2、通过警报模版丰富通知内容，发送给目标地址

• Alerting on gauges in Prometheus 2.0

• Prometheus 2.0的一个主要改变是对 staleness 的处理
• Prometheus 2.0允许对消失的 targets 和 时间序列进行跟踪
• 上述变化会影响警报规则的创建，比如，如何监控实例是否down：用avg_over_time(up{job="jobname"} [5m]) < 0.9，替换up{job="jobname"} < 1。否则会引起误报或者不报

• Alerting on crash loops with Prometheus

• 监控应用频繁的重启
• Prometheus客户端库会提供 process_start_time_seconds metric，表示进程的开始时间(如果进程重启，这个时间序列的值就会变化)
• avg without(instance)(changes(process_start_time_seconds[1h]))：一个job一个小时内重启的平均次数
• 如果进程重启频率高于采集频率，上述数据会丢失部分(不过对监控没有影响)
• 上述监控方法依赖于：目标的label集不变(尽管应用重启)

• Why not send graphs with alerts?

• 带宽的限制
• 额外的工作
• 通知中可以包含dashboard的链接，而不是曲线图本身

• When to Alert with Prometheus

• 如何正确的使用警报系统是一门艺术，少而精
• 警报不能太少(无法有效的监控)，也不能太多(噪声太多，无法有效的抓住问题重点)
• 即要有当前状态警报，也要有预测警报
• 严重问题的警报、需要立即修复问题的警报
• 关于用户体验的警报，是非常重要的警报
• 在线服务警报：alerting on conditions like high latency and error rates as high up in the stack as possible
• 针对容量警报(比如，磁盘)：alerts to detect when you will run out of space that will lead to an outage.
• 批量任务警报：alert when a job has not succeeded recently enough
• 警报通知需要有相应dashboard的链接，为oncall提供数据支持
• 监控监控系统本身

• What percentage of time is my service down for?

• 使用 Black Exporter 监控服务宕机的时长

Metrics

• What’s “up” Doc?

• 由于 up 不是来源于 scrape 本身， metric_relabel_configs 不适用于它
• 只要 service discovery 能够返回 target，up的值就是 1(不论真实的实例是否真的存在)
• 有类似于 up 的 metrics，以 scrape_ 开头
• 除了 up，有时有必要使用 Blackbox Exporter 来检测 target 的健康情况

Alert补充资料

• My Philosophy on Alerting

一个有着7年oncall经验的人(Rob Ewaschuk)对警报系统使用的经验总结。

• 警报分类(类型、级别，通知方式)
• 警报规则创建指导
• 警报处理的完整流程

思考

• How to have alerts to ensure that Prometheus servers, Alertmanagers, PushGateways, and other monitoring infrastructure are available and running correctly?