转载自公众号【工匠小猪猪的技术世界】原文地址https://mp.weixin.qq.com/s/Tnx60stl5aWKxmZxi0NfKg
最近我在研究Prometheus，在研究吴叶磊的文章以后，对于Prometheus存在的问题做了一次再梳理的评注，如下所示：
Prometheus本身已经成为了云原生中指标监控的事实标准，几乎所有 Kubernetes 的核心组件以及其它云原生系统都以 Prometheus 的指标格式输出自己的运行时监控信息。
甚至绝大多数中间件（比如 MySQL、Kafka、Redis、ES）也都有社区提供的Prometheus Exporter。
很多人都从Prometheus的优点开始说起，比如概念、安装、搭建、使用，那我反其道而行之，先从Prometheus的潜在问题开始说起。
Prometheus does one thing, and it does it well
Prometheus最核心的是监控指标，但是如果考虑动态伸缩、远端存储、平台化就需要做一些额外的扩展和整合工作。
2019年了，Prometheus除了仍然还不支持分布式、不支持数据导入/导出、不支持通过 api 修改监控目标和报警规则，还有着如下的一些问题，在使用之初就需要了解。
风险规避
一、自监控
Prometheus在云原生上可以用来监控其他一系列系统，那么这里问一个尖锐的问题，Prometheus的自监控谁来做？我们都知道Prometheus也可以提供自身的监控指标项，但是如果Prometheus本身就宕机了，那么Prometheus本身如何做告警？
因此，强烈建议在上生产环境之前，一定要确保至少有两个独立的 Prometheus 实例互相做交叉监控。 交叉监控的配置也很简单，每台 Prometheus 都拉取其余所有 Prometheus 的指标即可。
二、Alertmanager警报系统挂掉了怎么办
如果Alertmanager挂掉了，警报就发不出来了，对于开发、运维人员来说，Prometheus就成了一个哑巴，我们该如何处理？
因此，对于Prometheus来说，要做HA集群，包括警报系统Alertmanager。
除此之外还有一个经典的兜底措施叫做 “Dead man’s switch”: 定义一条永远会触发的告警，不断通知，假如哪天这条通知停了，那么说明报警链路出问题了。
三、准确性与运维简易性的权衡
和ELK等其他日志架构相比，Prometheus的运维相对比较简单。
在使用Prometheus之初必须明确清楚，Prometheus放弃了一部分数据准确性，无法和日志系统一样做到100%准确，但是可以获取高纯度的监控趋势
- 比如在两次采样的间隔中，内存用量有一个瞬时小尖峰，那么这次小尖峰我们是观察不到的；
- 再比如 QPS、RT、P95、P99 这些值都只能估算，无法和日志系统一样做到 100% 准确
四、任何版本的Prometheus都不支持NFS
这个案例还有一些实际生产案例都告诉我们，Prometheus存储文件如果使用NFS上有发生损坏丢失历史数据的可能性
五、尽早干掉维度过高的坏指标
如果Prometheus 里有 50% 以上的存储空间和 80% 以上的计算资源(CPU、内存)都被两三个高维度指标占据，这里就需要考虑是否需要治理。对于这些高指标，可以换其他的方式，比如数仓或者日志流等等去处理。
并不是业务方所有的指标都可以直接不管不顾得往Label里塞
解决方法：用警报规则找出维度过高的坏指标，然后在 Scrape 配置里 Drop 掉导致维度过高的 label。
# 统计每个指标的时间序列数，超出 10000 的报警
count by (__name__)({__name__=~".+"}) > 10000
“坏指标”报警出来之后，就可以用 metric_relabel_config 的 drop 操作删掉有问题的 label（比如 userId、email 这些一看就是问题户）
六、PromQL要先 rate() 再 sum()，不能 sum() 完再 rate()
这背后与 rate() 的实现方式有关，rate() 在设计上假定对应的指标是一个 Counter，也就是只有 incr(增加) 和 reset(归0) 两种行为。而做了 sum() 或其他聚合之后，得到的就不再是一个 Counter 了，举个例子，比如 sum() 的计算对象中有一个归0了，那整体的和会下降，而不是归零，这会影响 rate() 中判断 reset(归0) 的逻辑，从而导致错误的结果。写 PromQL 时这个坑容易避免，但碰到 Recording Rule 就不那么容易了，因为不去看配置的话大家也想不到 new_metric 是怎么来的。
Recording Rule规则：一步到位，直接算出需要的值，避免算出一个中间结果再拿去做聚合。
七、警报和历史趋势图未必 Match
最近半年常常被问两个问题：
- 我的历史趋势图看上去超过水位线了，警报为什么没报？
- 我的历史趋势图看上去挺正常的，警报为什么报了？
这其中有一个原因是：趋势图上每个采样点的采样时间和警报规则每次的计算时间不是严格一致的。当时间区间拉得比较大的时候，采样点非常稀疏，不如警报计算的间隔来得密集，这个现象尤为明显，比如时序图采样了 0秒，60秒，120秒三个点。而警报在15秒，30秒，45秒连续计算出了异常，那在图上就看不出来。另外，经过越多的聚合以及函数操作，不同时间点的数据差异会来得越明显，有时确实容易混淆。
这个其实不是问题，碰到时将趋势图的采样间隔拉到最小，仔细比对一下，就能验证警报的准确性。而对于聚合很复杂的警报，可以先写一条 Recording Rule, 再针对 Recording Rule 产生的新指标来建警报。这种范式也能帮助我们更高效地去建分级警报（超过不同阈值对应不同的紧急程度）
八、Alertmanager 的 group_interval 会影响 resolved 通知
Alertmanager 里有一个叫 group_interval 的配置，用于控制同一个 group 内的警报最快多久通知一次。这里有一个问题是 firing(激活) 和 resolved(已消除) 的警报通知是共享同一个 group 的。也就是说，假设我们的 group_interval 是默认的 5 分钟，那么一条警报激活十几秒后立马就消除了，它的消除通知会在报警通知的 5 分钟之后才到，因为在发完报警通知之后，这个 Group 需要等待 5 分钟的 group_interval 才能进行下一次通知。
这个设计让”警报消除就立马发送消除通知”变得几乎不可能，因为假如把 group_interval 变得很小的话，警报通知就会过于频繁，而调大的话，就会拖累到消除通知。
这个问题修改一点源码即可解决，不过无伤大雅，不修也完全没问题。
九、Prometheus 本身没有提供管理配置的 API 接口
Prometheus Operator Make Prometheus as a Service By k8s
Prometheus 本身没有提供管理配置的 API 接口，尤其是管理监控目标和管理警报规则，没有提供好用的多实例管理手段。除了写脚本以外，可以了解一下 Prometheus Operator。
什么是 Operator？Operator = Controller + CRD。假如你不了解什么是 Controller 和 CRD，可以看一个 Kubernetes 本身的例子：我们提交一个 Deployment 对象来声明期望状态，比如 3 个副本；而 Kubernetes 的 Controller 会不断地干活（跑控制循环）来达成期望状态，比如看到只有 2 个副本就创建一个，看到有 4 个副本了就删除一个。在这里，Deployment 是 Kubernetes 本身的 API 对象。那假如我们想自己设计一些 API 对象来完成需求呢？Kubernetes 本身提供了 CRD(Custom Resource Definition)，允许我们定义新的 API 对象。但在定义完之后，Kubernetes 本身当然不可能知道这些 API 对象的期望状态该如何到达。这时，我们就要写对应的 Controller 去实现这个逻辑。而这种自定义 API 对象 + 自己写 Controller 去解决问题的模式，就是 Operator Pattern。
https://aleiwu.com/post/prometheus-operator/
