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 youAlertmanager与之前版本的区别
通过路由规则树处理警报，之前仅仅是列表(功能更强大) 可以通过模版定制化警报的通知(有默认配置) 多条警报可以聚合成一条通知 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)对警报系统使用的经验总结。
警报分类(类型、级别，通知方式) 警报规则创建指导 警报处理的完整流程
运维前线阅读 3,243评论 0赞 5
张蓉萍阅读 172评论 0赞 0
