三种信号不是互相替代，是调查的顺序
一句话总结
Trace回答“在哪里”，Metric回答“什么时候多少”，Log回答“为什么”。所以调查顺序是固定的——Metric → Trace → Log。
为什么需要这个？
一旦出现故障，人们通常会先查看日志。30分钟后，他们仍然在阅读日志。日志是最详细的，但也是最昂贵的，在不知道要找什么的情况下打开它，就会发现是一片文字海洋。
指标优先的原因有三个。价格便宜，总是打开， Cardinality 低。因为同时满足这三个条件，指标是唯一可以成为通知依据的信号。Trace 是被采样的，因此无法保证“现在这个瞬间正在变差”，而且日志量大，无法承受实时汇总成本。
三个信号并不替代彼此，只有三个桥梁连接彼此。从指标到轨迹，从轨迹到日志，从日志到指标，从指标到事件，这些桥梁使三个工具相互连接。如果没有这些桥梁，即使购买了所有三个工具，调查仍然依赖人的直觉。
怎么行动
在Metric中，真正决定因素是类型选择。类型选择不是品味。如果选择错误，以后想做的计算在原理上就不可能了。
- Counter：当重复次数增加并重新开始时，变为0。值本身没有意义，只有通过rate才有意义。
- Gauge：上下波动。表示当前状态。
- Histogram：桶计数的集合。用于知道氛围的值。
- Summary: 在实例中已经计算出百分位数并输出。所以没有办法合并多个实例。不能作为服务水平指标使用。
为什么延迟时间时仪表无法显示，可以通过算术来确认。如果刮擦间隔为15秒，每秒请求为500件，那么仪表只会存储7500件中1件的值。其余的则从未存在过。这种时间序列无法求出p99，即使以后再处理也不会恢复。
在现场相遇的样子
在发布后不久，经常会遇到看起来流量减少的仪表板。原因几乎总是相同的。是把rate改成了sum外面挂起来的。计数器重置校正只有在单独的时序单元中才准确。如果一个板重新启动，累计后不会被识别为重置。正确的形式是sum(rate(x[5m])) by (route)，rate(sum(x)[5m:])是错误的。
另一个是安静的错误。在histogram_quantile中，删除by (le)后，会返回没有错误的错误数字。没有人看例外，所以那个面板会在仪表板上停留几个月。
Cardinality决定预算
在指标设计中，最难推翻的错误是在标签上输入无限大的值。时间序列的数量是标签值组合的乘积增加。如果标签有三个，每个值有10·5·4种，时间序列是200个，但只要再附加一个用户ID，就会乘以用户数量。如果用户有10万人，就有200万个。
特别是危险的标签是确定的。用户ID、请求ID、会话ID、电子邮件、IP地址，以及没有加工直接输入的路径。/orders/8213如果像这样用标签写上嵌入标识器的路径，每个订单都会产生一个时间序列。正确的形式是/orders/:id通过路由模式进行正则化，这种正则化是框架在路由时已经知道的值，所以通常可以免费获得。
这样切出的信息不是丢弃的，而是**转移到其他信号中。**这就是为什么将三个信号分开的原因。
| 想知道的事情 | 应该放下的地方 | 理由 |
|---|---|---|
| 这个路由有多慢 | 指标 | 值的种类少，必须一直打开 |
| 这个缓慢的请求在哪里花费了时间 | Trace | 请求单位标识符自然附加 |
| 提出那个请求的用户是谁 | 记录 | 无数量限制，通过搜索查找 |
直方图尤其需要小心。因为一个桶就是一个时间序列，所以如果一个20个桶的直方图贴上200个标签组合，那个指标就会产生超过400个时间序列。所以直方图只用在真正需要氛围的指标上，桶的边界要密集地靠近服务水平目标附近，其余的要粗略地把握。如果目标是300ms，但桶在100ms后直接跳到1秒，那么直方图无法判断p99是否超过了300ms。
症状通常不是在仪表板上出现，而是首先在存储器方面出现。 普罗米修斯的内存不断增加，刮痕在时间内无法结束，查询速度变慢。这时topk(10, count by (__name__)({__name__=~".+"}))从序列中出现次数最多的指标开始计数，罪犯几乎总是有一个人或两个人。
下次实习要做的事情
实习环境中，真正的普罗米修斯服务器以包含12小时数据的状态漂浮着。包含两次错误激增的区间、一次只有延迟尾巴的区间，以及不断减少的磁盘。
不仅要把查询写在文件里，而且promq直接扔出去，读取返回的数字。你们写的问题是否能找到那三个事件，会告诉你正确与否——PromQL之所以很难，不是因为语法，而是因为错误的问题也会毫无错误地返回合理的数字。