Prometheus简介
Prometheus受启发于Google的Brogmon监控系统（相似的Kubernetes是从Google的Brog系统演变而来），从2012年开始由前Google工程师在Soundcloud以开源软件的形式进行研发，并且于2015年早期对外发布早期版本。2016年5月继Kubernetes之后成为第二个正式加入CNCF基金会的项目，同年6月正式发布1.0版本。2017年底发布了基于全新存储层的2.0版本，能更好地与容器平台、云平台配合。
Prometheus作为新一代的云原生监控系统，目前已经有超过650+位贡献者参与到Prometheus的研发工作上，并且超过120+项的第三方集成。
整体架构图
Prometheus从exporter拉取数据，或者间接地通过网关gateway拉取数据（如果在k8s内部署，可以使用服务发现的方式），它默认本地存储抓取的所有数据，并通过一定规则进行清理和整理数据，并把得到的结果存储到新的时间序列中，采集到的数据有两个去向，一个是报警，另一个是可视化。PromQL和其他API可视化地展示收集的数据，并通过Alertmanager提供报警能力。
组件内容
- Prometheus Server
负责从 Exporter 拉取和存储监控数据,并提供一套灵活的查询语言（PromQL）
- Retrieval: 采样模块
- TSDB: 存储模块默认本地存储为tsdb
- HTTP Server: 提供http接口查询和面板，默认端口为9090
- Exporters/Jobs
负责收集目标对象（host, container…）的性能数据，并通过 HTTP 接口供 Prometheus Server 获取。支持数据库、硬件、消息中间件、存储系统、http服务器、jmx等。只要符合接口格式，就可以被采集。 - Short-lived jobs
瞬时任务的场景，无法通过pull方式拉取，需要使用push方式，与PushGateway搭配使用 - PushGateway
可选组件，主要用于短期的 jobs。由于这类 jobs 存在时间较短，可能在 Prometheus 来 pull 之前就消失了。为此，这次 jobs 可以直接向 Prometheus server 端推送它们的 metrics。这种方式主要用于服务层面的 metrics，对于机器层面的 metrices，需要使用 node exporter。 - 客户端sdk
官方提供的客户端类库有go、java、scala、python、ruby，其他还有很多第三方开发的类库，支持nodejs、php、erlang等 - Alertmanager
从 Prometheus server 端接收到 alerts 后，会进行去除重复数据，分组，并路由到对收的接受方式，发出报警。常见的接收方式有：电子邮件，pagerduty，OpsGenie, webhook 等。 - Service Discovery
服务发现，Prometheus支持多种服务发现机制：文件，DNS，Consul,Kubernetes,OpenStack,EC2等等。基于服务发现的过程并不复杂，通过第三方提供的接口，Prometheus查询到需要监控的Target列表，然后轮训这些Target获取监控数据。
其大概的工作流程是：
- Prometheus server 定期从配置好的 jobs 或者 exporters 中拉 metrics，或者接收来自 Pushgateway 发过来的 metrics，或者从其他的 Prometheus server 中拉 metrics。
- Prometheus server 在本地存储收集到的 metrics，并运行已定义好的 alert.rules，记录新的时间序列或者向 Alertmanager 推送警报。
- Alertmanager 根据配置文件，对接收到的警报进行处理，发出告警。
报警系统 包括⼏种主要的展现形式 ：短信报警，邮件报警，电话报警（语⾳播报） , 通讯软件（微信、企业微信、钉钉、飞书等） - 在图形界面中，可视化采集数据。
数据采集
应该采集监测什么？
- 从服务的类型来讲，应该监测所有类型的服务：在线服务、离线服务和批处理任务
- 从单一服务的实现来讲，应该监测服务的关键逻辑，比如关键逻辑执行的总数、失败次数、重试次数等
- 从服务的质量来讲，应该监测服务的请求总数、请求错误率和请求响应时间
- 从系统资源上来讲，应该监测资源的利用率、饱和度和错误
Prometheus 将采集的数据分为 Counter、Gauge、Histogram、Summary 四种类型。需要注意的是，这只是一种逻辑分类，Prometheus 内部并没有使用采集的数据的类型信息，而是将它们做为无类型的数据进行处理。这在未来可能会改变。下面，我们将具体介绍这四种类型。
Counter
Counter 是计数器类型，适合单调递增的场景，比如请求的总数、完成的任务总数、出现的错误总数等。它拥有很好的不相关性，不会因为重启而重置为 0。
Gauge
Gauge 用来表示可增可减的值，比如 CPU 和内存的使用量、IO 大小等。
Histogram
Histogram 是一种累积直方图，它通常用来描述监控项的长尾效应。举个例子：假设使用 Hitogram 来分析 API 调用的响应时间，使用数组 [30ms, 100ms, 300ms, 1s, 3s, 5s, 10s] 将响应时间分为 8 个区间。那么每次采集到响应时间，比如 200ms，那么对应的区间 (0, 30ms], (30ms, 100ms], (100ms, 300ms] 的计数都会加 1。最终以响应时间为横坐标，每个区间的计数值为纵坐标，就能得到 API 调用响应时间的累积直方图。
Summary
Summary 和 Histogram 类似，它记录的是监控项的分位数。什么是分位数？举个例子：假设对于一个 http 请求调用了 100 次，得到 100 个响应时间值。将这 100 个时间响应值按照从小到大的顺序排列，那么 0.9 分位数（90% 位置）就代表着第 90 个数。通过 Histogram 可以近似的计算出百分位数，但是结果并不准确，而 Summary 是在客户端计算的，比 Histogram 更准确。不过，Summary 计算消耗的资源更多，并且计算的指标不能再获取平均数或者关联其他指标，所以它通常独立使用。
告警
报警系统中 最重要的⼀个概念之⼀ 就是对报警阈值的理解。
阈值(Trigger Value) ，是监控系统中 对数据到达某⼀个临界值的定义。
例如：通过监控发现，当前某⼀台机器的CPU突然升⾼，到达了 99%的使⽤率， 99 就是作为⼀次报警的触发阈值。
Pagerduty 的年头不短了，在企业中 尤其是外企 出镜率⾮常⾼。
虽然是收费监控，但是费⽤对于⼀个企业来说很便宜 甚⾄对于 个⼈⽤户来说其实也不算⾼。
Pagerduty是一套付费监控报警系统，经常作为SRE/运维人员的监控报警工具，可以和市面上常见的监控工具直接整合，例如和zabbix整合，我遇到的最多的场景还是和zabbix整合，当有服务器出现异常的时候，zabbix会通过pagerduty对当前设置的值班的人员进行短信+电话通知.
支持的API Client Libraries
Pagerduty 拥有 短信，电话，邮件 所有的报警机制。
Pagerduty 还有⾮常实⽤的必要的 运维值班管理制度 和 报警升级等等 扩展功能。
Pagerduty的优点⾮常多，使⽤率⾮常⾼（外企⼏乎清⼀⾊的使⽤，国内企业很多也在使⽤）
但是有优点就肯定也有不⾜
Pagerduty有⼏个⼩问题 需要提⾼
• 对中⽂的⽀持不好 或者说⼏乎不⽀持 （指的是 语⾳播报⽅⾯ ）
• 站点主要在美国和海外 ⽹速有时候不太给⼒ => 可以⾛代理的⽅式 加快速度
优势
Prometheus相⽐其他⽼款监控的 不可被替代的巨⼤优势，以及⼀些不⾜有待提⾼的地⽅。
- 监控数据的精细程度 绝对的第⼀ 可以精确到 1～5秒的采集精度 4 5分钟 理想的状态 我们来算算采集精度 （存储 性能）
- 集群部署的速度 监控脚本的制作 （指的是熟练之后） ⾮常快速 ⼤⼤缩短监控的搭建时间成本
- 周边插件很丰富 exporter pushgateway ⼤多数都不需要⾃⼰开发了
- 本⾝基于数学计算模型，⼤量的实⽤函数 可以实现很复杂规则的业务逻辑监控（例如QPS的曲线 弯曲 凸起 下跌的 ⽐例等等模糊概念）
- 可以嵌⼊很多开源⼯具的内部 进⾏监控 数据更准时 更可信（其他监控很难做到这⼀点）
- 本⾝是开源的，更新速度快， bug修复快。⽀持N多种语⾔做本⾝和插件的⼆次开发
- 图形很⾼⼤上 很美观 ⽼板特别喜欢看这种业务图 （主要是指跟Grafana的结合）
- ⼀些不⾜的地⽅
因其数据采集的精度 如果集群数量太⼤，那么单点的监控有性能瓶颈 ⽬前尚不⽀持集群 只能workaround - 学习成本太⼤，尤其是其独有的数学命令⾏
- 对磁盘资源也是耗费的较⼤，这个具体要看 监控的集群量 和 监控项的多少 和保存时间的长短
- 本⾝的使⽤ 需要使⽤者的数学不能太差 要有⼀定的数学头脑
关注公众号 soft张三丰
