误解——这无疑是阐释我早期 Prometheus 体验的恰当词汇。彼时，我怀揣着丰富的 Graphite 使用经验以及中等程度的 InfluxDB 经验，开始接触 Prometheus。 在我眼中，Graphite 是一个性能卓越却有着相当局限性的系统。在 Graphite 里，指标仅仅是字符串（嗯，是带点的那种），而且其值始终是以最低可达的 1 秒分辨率进行聚合存储的。不过，也正是因为这些限制，才使得 Graphite 拥有了较快的速度。 相较而言，InfluxDB 采用的是 Metrics 2.0 格式，每个指标都具备多个标签和字段。它甚至允许以令人赞叹的纳秒精度来存储非聚合数据点。然而，这种强大的能力必须谨慎运用，否则，使用者将会遭遇各种各样的性能问题。
Prometheus：从误解到深入理解的探索之旅
在探索监控系统的征程中，我与 Prometheus 的相遇充满了波折，也让我对它有了全新的认识。
初始的期待与困惑
最初，我带着对 Graphite 和 InfluxDB 的经验来接触 Prometheus。Graphite 在我眼中是个高性能但局限明显的系统，其指标只是特定格式的字符串，值以最低 1 秒分辨率聚合存储，不过这也成就了它的速度。InfluxDB 则不同，采用 Metrics 2.0 格式，每个指标有多个标签和字段，还能以纳秒精度存储非聚合数据点，但这种能力若使用不当，性能问题便会接踵而至。
出于某种特殊的缘由，我原本以为 Prometheus 会介于这二者之间，是一个兼具二者优点的系统——有着丰富的标签指标、能够存储非聚合值，还具备高查询性能。刚开始的时候，我确实有这种感觉。然而，随着使用的深入，问题逐渐浮现。我常常无法对某些查询结果给出合理的解释，那种困惑就像面对一个无解之谜。有时候，我在指标中怎么也找不到理应存在的证据，指标所呈现的画面和我分析原始数据（比如 Web 服务器访问日志）时亲眼所见的完全不同。
深入探究背后的原因
为了弄清楚状况，我开始寻求更多细节。我渴望知晓指标是如何收集、存储的，查询执行模型又是怎样的。这一探究可不得了，一开始，我被自己的发现震惊到了。很多时候，Prometheus 的行为与 Graphite 和 InfluxDB 相比，显得毫无逻辑。后来我才意识到，我遗漏了一个关键信息。
Graphite 和 InfluxDB 都是纯粹的时间序列数据库 (TSDB)，它们虽常用作存储监控指标，但每个特定设置都伴随着权衡和附加功能来解决性能、可靠性问题。比如 Graphite 前端常有类似 statsd 的守护进程预聚合，对旧数据点有不同汇总策略。用户也都清楚这些，查询近期数据期望秒级精度，查询较久数据就知道每个点是一分钟聚合数据。
但 Prometheus 不是传统的 TSDB，它是一个以监控为核心，底层使用 TSDB 的系统。这就意味着，在 Graphite 安装中常见的权衡问题，Prometheus 开发者虽有考虑，但并非所有都在文档中详细说明。所以，当查询结果奇怪时，可能是我对 Prometheus 整体理解有偏差，不只是查询执行模型。在监控环境中，追求纯 TSDB 的精准结果成本可能过高。Prometheus 作为指标收集系统，为监控而生，收集、存储和查询性能良好，但在数据精度（如每 10 - 30 秒抓取一次指标）、完整性（容忍 5 分钟回溯增量丢失抓取）或对延迟分布的处理（如 histogram_quantile() 的工作方式）上有所牺牲。
重新审视与持续学习
意识到这种差异后，我重新审视了对 Prometheus 的期望。同时，我仍在寻找更好的方法理解 PromQL 的查询执行模型。网上关于 Prometheus 和 PromQL 的文章虽多，但大多只是对查询语言的浅显介绍。经过大量搜索，我发现了 PromLabs 和 Robust Perception 的博客，它们是 Prometheus 创建者所写，内容深奥，对我理解很有帮助。
不过，实践出真知。我搭建了本地的 Prometheus 游乐场来实践，巩固学习成果。我也努力记录所学，主要是为了方便自己回顾，当然，也欢迎大家查看我其他关于 Prometheus 的帖子。希望我的这些经历能给同样探索 Prometheus 的小伙伴们一些启发。
