prometheus的禅意是一套面向初学者的核心价值观和指南，用于监控应用程序并使用 Prometheus 编写规范的警报。
先监控，再提问
在开发过程中，你永远不知道以后需要问哪些问题。软件需要良好的监控，这不是可选项。没有标签的指标很廉价。要慷慨地使用它们，但在添加标签时要留意基数 。
第一条也是最重要的一条规则——如果你只能记住一件事，那就记住这一条。监控所有东西。
衡量用户关心的指标
你的用户是否关心数据库服务器宕机？他们是否关心 CPU 饱和？是的，但不是直接关心——他们关心的是他们的体验。他们关心是否能够访问他们请求的页面，以及他们的结果是否新鲜。用延迟和可用性来思考。让你的 SLO 指导你的仪器和 alerting。
RED 、USE 和 The Four Golden Signals 是已知的框架，可以帮助你开始。
你仍然应该衡量内部指标，如数据库可用性和 CPU 饱和——用它们来排查问题和容量规划。
Use causal metrics to answer why something is broken.标签是新型的层次结构
标签是新型的层次结构，功能更强大且灵活。标签是 Prometheus 强大的关键。使用标签，可以在后续对测量值进行分组和聚合。使用标签进行切片和切块。记住 先构建指标，再提出问题 ，尽可能提供更多上下文。然而，你必须 谨慎使用标签 。见下文解释。
避免缺失指标
直到发生某事才出现的时序数据难以处理。为避免这种情况，对于任何你知道可能提前存在的时序数据，请导出 0。使用零值初始化你的指标，以防止仪表板损坏和误发警报。欲了解更多详细说明，请查看 指标的生存问题 。
记住，标签创建时间序列，因此用你预期使用的标签初始化你的指标——你的客户端库无法知道你将拥有哪些标签。
基数很重要
每个唯一的标签组合都会创建一个新的时间序列。谨慎使用标签，注意你放入其中的内容。避免基数爆炸；无界的标签会使 Prometheus 爆炸。记住标签在维度上是乘法关系。
Prometheus performance almost always comes down to one thing: label cardinality.始终记住 基数是关键 。
命名很困难
一个指标名称在一个任务中必须具有单一的含义，理想情况下，在多个任务中也应该是相同的含义（例如 process_cpu_seconds_total）。
尊重约定而非偏好 。约定不是任何人的最爱，但约定却是每个人的最爱。有关详细内容，请参阅 Naming 的文档。
计数器很棒，而指标很糟糕
暴露原始计数器，并使用 rate() 和 increase() 让 Prometheus 为你计算速率。不要在目标上预先计算速率——那样会丢失信息。记住 先监控指标，再提出问题 。
当然，指标有其用途。用于周期性测量，根本没有可计数的东西时——温度、磁盘满度、队列深度。但如果某物只增加，就把它做成计数器。
不要添加用于聚合的指标；PromQL 可以为你完成它。
先计算速率，再进行聚合。
注意 计数器重置 。正如在 先计算速率再求和，切勿先求和再计算速率 中所述。一般来说，你可以安全直接应用于计数器值的数学运算只有 rate、irate、increase 和 resets。其他任何操作都会导致问题。
如果你能记录，就能为其创建指标
日志对于故障排除至关重要，但指标同样有价值——故障排除过程通常会在不同信号之间来回切换。不要低估指标在理解发生什么方面的价值。
每次记录事件时，考虑按广义类别进行计数。这是低成本且能提供高错误率警报以及事件概览的方法。记住，没有标签的指标很廉价——广泛使用计数器。
原生直方图几乎总是比经典直方图更好
原生直方图 解决了经典直方图的桶布局问题。它们无需预定义边界，可动态调整分辨率，且在稀疏表示中空桶不占用成本。如果您的仪器库或 OTel 支持原生直方图，请为新仪器优先选择原生直方图。
使用经典直方图时，创建正确的桶布局是一门艺术。为了确保你的观察结果的有效性和警报的正确性，你必须构思一个有意义的桶布局。这与“ 先确定仪器，再提出问题 ”的原则相冲突，因为你必须在测量之前对延迟有一个概念。让你的 SLO 指导你的桶布局；创建边界以匹配你的 SLO。
经典直方图下方的只是带标签的计数器，其中桶边界用作标签。在向直方图添加额外标签时要小心。记住， 标签是乘法性的 ， 基数很重要 。
如果能将其绘制出来，就可以对其进行告警
你不能全天候查看仪表板。Prometheus 将指标、仪表板和告警统一。PromQL 是每个 Prometheus 告警的核心，PromQL 查询是仪表板上任何图形的来源。使用它。
如果运行它，那么应该对其设置告警
始终确保至少有一个警报监控你的目标的存在性和健康状态。你不能依赖那些无法观察或采取行动的事情。
避免遗漏和不健康的目标。Prometheus 会自动为每个目标生成 up 指标。使用它。
警报应该是紧急的、重要的、可操作的、真实的
警报应该是紧急的、重要的、可操作的、真实的 。尽可能简单明了。
不要过度报警，报警疲劳是真实存在的。
基于症状的报警用于接警，基于原因的报警用于故障排除
与衡量用户关心的指标类似，关注真正重要的事项并触发警报。只要用户没有察觉，即使 CPU 饱和也无关紧要。让您的 SLO 引导您的警报。
并非每个警报都需要联系人员。基于原因的警报不应叫醒任何人——它们应该输入仪表板或工单队列，在需要时进行检查或在闲暇时批量处理。将联系人员保留给表明用户面影响症状的警报。
获取更多背景信息我的警报理念 。
请再给我五分钟。
Prometheus 告警规则允许你指定一个 for 持续时间，该持续时间决定了条件必须为真多久才会触发告警。如果你不指定它，一次失败的抓取就可能导致告警被触发。你需要有一定的容错性。一般来说，至少使用 5 分钟，除非你有特定的原因需要这样做。更多信息，请查看在告警上设置阈值 。
上下文是关键
为你的告警保留常见且有用的标签。它们对于路由和静音最有用。
这个想法的灵感来自于 Go 之禅 、Go 谚语 和 Python 之禅 。
*Thank you very much all others that contributed with their invaluable ideas.*
The initial rules are gathered from several sources from the community, such as [Prometheus Proverbs](https://www.youtube.com/watch?v=TwH3KXKbJqM) by [Björn Rabenstein](https://github.com/beorn7), [Best Practices and Beastly Pitfalls](https://www.youtube.com/watch?v=_MNYuTNfTb4) by [Julius Volz](https://github.com/juliusv), [Patterns for Instrumenting Your Go Services](https://www.youtube.com/watch?v=LU6D5cNeHks) by [Bartek Plotka](https://github.com/bwplotka) and [Kemal Akkoyun](https://github.com/kakkoyun), [Instrumenting Applications and Alerting with Prometheus](https://www.youtube.com/watch?v=sHKWD8XnmmY) by [Simon Pasquier](https://github.com/simonpasquier) and [Robust Perception Blog](https://www.robustperception.io/blog) by [Brian Brazil](https://github.com/brian-brazil).