Prometheus 原生默认的 UI 等功能怎么使用？
TMP 不同于开源的单机版 Prometheus，腾讯云 Prometheus 监控服务是采集和存储分离的结构，不提供原生默认的 UI 功能，查询功能请使用 Grafana 服务作为替代。
告警恢复时通知模板里面的 $value 不正确，如何处理？
告警恢复的 $value 是最后一次满足告警表达式条件的值无法获取不满足条件的值。从设计上来讲，告警表达式是作为一个整体的，告警表达式和普通场景下的 PromQL 查询没有任何区别，查询结果中的 series 如果满足持续时长就会被触发，当下次查询的结果不包含某个 series 时，该 series 对应的告警会变成恢复状态，Prometheus 无法自行对告警表达式进行拆解和解释，因为有些表达式本身是不包含阈值等比较关系的，例如：a and b 、123456789。
如何查看告警历史？
Prometheus 本身没有告警历史的概念，由于特殊原因无法完整的支持告警历史，但是相关告警及状态可以通过 ALERTS 或者 ALERTS_FOR_STATE 指标来进行查看。
另外，Prometheus 所有的告警目前都会投递到腾讯云可观测平台告警服务，然后再由腾讯云可观测平台的各种通知渠道发送到用户端，腾讯云可观测平台提供的告警历史功能可以一定程度上弥补这个缺陷，由于设计等概念上的不同不能作为完整替代但可用于排障等需求。您可以通过 告警历史功能 查看。 告警重复时间间隔和配置的时长不一致？
Prometheus 重复告警间隔 (repeat_interval) 并不是针对单个告警设置的，而是针对整个分组的，当分组中存在新告警或者告警恢复时整个分组都会通知出去，然后再按重复告警间隔进行重复通知，当前 Prometheus 监控服务 是按单个告警策略进行分组的，例如：单个告警策略可能是针对实例 A/B/C 是否重启的情况，当 A/B 重启后告警触发然后按照重复间隔进行通知，一段时间后 C 也重启了，这个重复告警的间隔就会被打断并重置，此时 A/B/C 作为一个“分组”都会一起通知到用户，目前基于腾讯云可观测平台投递的告警由于实现上的限制无法整个分组聚合作为单一的消息通知到用户，有需要的可以使用自定义 Alertmanager 或者 Grafana 服务。 原始指标存在的情况下，rate/irate 函数为什么没有产生任何数据?
rate/irate 函数需要至少两个数据点才能进行计算，所以要保证 rate/irate 计算的时间范围覆盖到至少两个数据点，考虑到网络等异常可能出现的数据点丢失的情况，这个时间范围官方推荐为四倍的采集间隔。
rate/irate 函数为什么计算出一个极大的异常值？
rate/irate 函数只能用于 Counter 类型的指标，Counter 类型的指标定义为严格递增的数字，Prometheus 查询时会处理 Counter 重置为 0 的问题， 如服务器重启等，正常情况下不对计算结果产生影响，除非出现数据点乱序的问题，例如 9999 和 10000 两个秒级的数据点乱序，导致异常值为 (10000+9999)-10000=9999（正常情况应该为 1），出现这种情况的典型场景如下： 存在多个采集组件采集同一个指标，并重复上报到同一个 Prometheus 实例，这时可能会产生乱序的问题，导致经过 Prometheus 的重置处理逻辑后产生一个极大的异常值。解决方案：如果采集组件采集同一个指标是不符合预期的建议排查并解决重复采集的问题；如果是为了保证采集组件的高可用性而设计的采集方案，那么不同的采集组件对所采集的所有指标需要额外加上 replica 或者其它标签进行区分。
通过 pushgateway 等方式直接上报到 Prometheus 监控服务 没有带上时间戳信息，Prometheus 监控服务 端会将当前时间作为指标的时间戳并存储，这样如果网络出现抖动等情况，数据点到达时间会变得无序或者不同进程/线程处理不同的数据点时赋予的时间戳信息导致乱序，从而导致计算出错。解决方案是在上报时带上时间戳信息，Prometheus 监控服务 内置的 pushgateway 上报方式本身只作为 remotewrite 的补充并没有实现完整的功能，非必要情况建议使用 Agent(remotewrite) 进行采集上报。 查询返回的数据点间隔为什么和抓取间隔不一样？
Prometheus 查询返回的数据点间隔由查询参数 interval/step 来决定，每个数据点都是严格按照 interval/step 来补齐对齐的，和抓取间隔没有一一对应的关系，在数据丢失过多或者抓取间隔过大的情况下不会进行数据补齐，存储端也不会存储任何抓取配置相关的信息，需要用户对自己的抓取配置自行处理。
查询为什么多返回了最近五分钟的数据？
Prometheus 默认会对某些查询的进行数据补齐，即使最近五分钟只有一个数据点可能也会返回五分钟多个数据点（根据查询的 step/interval 参数的不同而不同），这个是开源 Prometheus 的默认行为，暂时无法调整。一般情况下，并不影响正常使用。
PromQL 时间相关的函数如何处理本地时区？
Prometheus 内部所有的时间都是 UTC 时间，没有特殊情况，设计上也并没有考虑时区的概念可能会导致 day_of_* 系列函数使用起来不那么方便，短期内官方也不会支持，国内时区的临时解决方案可以这样：day_of_week(vector(time() + 8*3600))。
Prometheus 相关的使用限制可以调整吗？
Prometheus 相关的使用限制部分是可以调整的，大部分情况下超出这些使用限制可能会带来使用体验以及性能的降级，所以向上调整限制后不能保证调整之前的查询和写入性能基准，服务等级协议可能不再适用，对于潜在的相关风险需要用户有一定心理预期。
从图表上看告警满足持续时间而实际未触发？
Prometheus 告警检测的基本原理是每隔一分钟使用 Instant Query 查询数据，如果（持续）满足告警条件则触发。某些情况下 Prometheus 的 Range Query 会补齐填充数据，图表上连续的时间线，在告警组件的执行逻辑下可能就是不连续的，另外由于告警定时检查的特性，告警被检测到的时间可能会有些许延后，可以通过查询 ALERTS 或者 ALERTS_FOR_STATE 指标来查看告警的状态。