我构建了公司第一个监控系统，这里是我学到的
本文是作者在落地 Prometheus 监控系统时学到的经验和教训。作者是：Naomi Kriger，原文地址：https://medium.com/data-science-collective/i-built-my-companys-first-monitoring-system-here-s-what-i-learned-bed76942cc72
创建公司的第一个监控系统就像让盲人看到视力一样。它可以改变游戏规则，可以及早发现问题并快速解决问题。但到达那里的道路可能会很乏味，甚至最终的结果也可能比预期的更复杂。
这一过程充满了障碍 —— 需要在代码中埋点，可能会遇到反模式导致的陷阱，看起来一切正常却丢失指标，对于“良好的可观测性”大家的理解和期望不一致…
在本文中，我将分享我希望在开始之前就知道的经验教训 - 这些见解可以为您节省数小时的反复试验时间，帮助您避免陷阱，并帮助您构建一个不仅功能强大而且真正有影响力的监控系统。
开始之前
我们的监控系统是使用 Prometheus 堆栈（包括 Grafana 和 AlertManager）构建的，因此我分享的一些经验教训是针对该生态系统的挑战而构建的。
1. 自定义指标=完全可控,手工维护
当你的可观测性堆栈让你完全控制时——就像 Prometheus 所做的那样——它也会把责任放在你身上。您可以选择要监视的内容、放置指标的位置以及如何解释它们。这种灵活性是强大的，但它是以时间、精力和各种疏漏为代价的。
编写自定义指标意味着逐个业务流程浏览代码库，确定重要内容，并在需要时注入计数器（Counter）、直方图（Histogram）和仪表（Gauge）。它需要对系统进行深入的了解 —— 在技术和功能上，同时收集利益相关者的需求，映射为可观测性需求，并留出试错的空间。
好处？
- 可观测性完全根据我们的需求量身定制。
缺点？
- 它是劳动密集型的——特别是与一些提供更多开箱即用自动埋点的竞争对手相比。
- 责任完全在我身上——任何不受监控的业务流都意味着盲点。
如今，随着 Cursor 或 Claude-Code 等人工智能辅助 IDE 的兴起，我想知道体验会有多大不同。让 AI 建议或注入指标可能不会消除仔细审查的需要 - 您仍然希望避免指标膨胀或错位 - 但它可以显着提高覆盖范围和成本效益。你试过吗？我很想听听你的教训或技巧。
2. 尽早了解最佳实践 - 它可以重塑很多
在编写第一个指标之前了解工具堆栈的最佳实践可以产生很大的影响 —— 不仅在系统性能方面，而且在可观测性策略的整体方面。它可以大大减少仪表板延迟，让指标数据库更可控，并帮助您避免日后痛苦的重写。
它还教你什么不该做。例如，添加 session_id 或 user_id 等标签可能看起来很有用，直到您意识到它们会导致高基数和数据库膨胀。这是一个常见的错误，但违反了 Prometheus 的基本原理（ 见此处 ）。尽早了解这一点可以完全改变您监控某些流量的计划方式。
在某些情况下，这些教训甚至可能会让您重新思考 Prometheus 是否是适合这项工作的工具。虽然 Prometheus 非常适合跨服务的聚合可观测性，但它并不是为高粒度、每个实体的跟踪而构建的。如果这种详细程度对您的用例至关重要，您可能需要另一种更适合跟踪级或事件级洞察的工具来做补充（或替换 Prometheus）。
3. 不要相信绿灯 - 验证您的指标管道
当我编写第一个指标时，一切似乎都很好——我看到它在 /metrics 端点上公开，拉入 Prometheus，并在 Grafana 中可视化。我很高兴。但几天后，一些指标只是……不见了。我没有改变系统中任何有意义的东西。整个堆栈似乎按预期工作。
那么发生了什么？
事实证明，Prometheus 收集指标的方式不同，具体取决于受监控的服务是在单进程还是多进程模式下运行。我正在开发的具体服务是在 Gunicorn 上运行的具有多个 worker 的 FastAPI 应用程序——但 Prometheus 的默认设置假设是单进程环境。结果，只有一个 Worker 的指标被暴露，而其他指标则被静默忽略。
修复方法是显式启用 Prometheus 多进程模式并使用正确的多进程收集器。Prometheus 没有抛出错误，它只是悄悄地未能报告关键指标。
教训：当运行具有多个进程或工作线程的服务时，Prometheus 需要特殊的设置——否则，你的指标可能会消失得无影无踪。始终验证您的指标是否反映了现实，而不仅仅是 /metrics 端点是否可用，或者指标是否存在。永远不要假设“没有错误”意味着“一切都很好”。
4. 可观测性需要对完成有一个明确的定义——就像任何其他功能一样
与大多数产品功能不同，可观测性通常没有明确的产品经理、用户故事或明确定义的“完成定义”。当您从头开始构建监控平台时尤其如此。
您的利益相关者通常是其他工程师，包括您自己的队友。每个人对“好的仪表板”是什么样子都有不同的想法。将其乘以使用仪表板的人数，您就得到了……很多意见。有人会说——甚至太多了。
此外，当这是公司第一次使用可观测性时，期望很少一致。什么才算“完整”MVP？仪表板应该有多高级别？警报在有用之前应该有多嘈杂？
以下是我建议处理这样一个项目的方式：
- 定义什么是 MVP 与长期目标，并准备好随着项目的发展进行调整
- 规划您的用户及其特定的可观测性需求
- 在关键里程碑收集结构化反馈
- 期望迭代工作，并帮助团队预测反馈、修订和试错都是流程的一部分
可观测性不仅仅是一项技术任务，它还是一个具有用户、反馈循环和不断变化的需求的产品。
最后的思考
构建我们的第一个监控系统是我做过的最有价值和最令人沮丧的项目之一。它使我们的系统更加可靠，改进了我们调试故障的方式，并迫使我们考虑规模和清晰度——无论是在代码中还是在文化中。
但它也教会了我表面之下隐藏着多少细微差别。Prometheus 很强大，但并不简单。它需要深思熟虑的设计、深思熟虑的迭代和清晰的沟通。
如果您即将开始自己的可观测性之旅，我希望这些经验教训能让您抢占先机。如果你自己也走过这条路——你从惨痛的道路上学到了什么教训？我很想听听他们的声音。
