前述
在构建全球可观测性平台的征程中，我们选择了一个质朴而真实的标题: “迈出的一小步”，以此来表明我们至今的进展。虽然我们已经存在了一些全球可观测性平台的基本要素，但仍然缺乏一个完整的、系统化的架构。目前我们所实现的，只是可观测性平台概念的一部分。我们从底层开始构建了一个六层模型，可是直到目前，我们只完成了下三层，而完成这些的过程，花费了我们整整一年的时间。
站在今天这个时间点回望，我们的系统已经稳定运行一年。之所以在此之前并未与大家分享我们的进展，是出于一个简单而朴实的想法: 经过一年的稳定运行，我们的成果将更具说服力。现在，我们希望借此机会与大家分享在构建全球监控系统过程中遇到的挑战和我们所获得的宝贵经验。
对于构建全球监控系统，有些人可能会认为这不过是组合已有的监控工具，如 Zabbix、Prometheus、Grafana 等。确实，这些工具是构建监控系统的一部分，但实际情况远比简单部署更为复杂。一个完善的监控体系不仅需要多层模型，还要与公司的业务场景紧密结合。特别是在公司已有监控系统的情况下，从 0到 1的创造过程或许相对容易，但是从 0.5 到 0 再到 1，这一过程无疑充满了挑战。这需要推翻以往的工作，甚至可能被视为否定前人的努力，这种经历只有亲身经历过的人才能够真正理解。
现状分析
在我们全球监控系统架构建设之初，面临的现状可以说是错综复杂。我们拥有的不仅是九套分散在全球的监控系统，还包括了从技术到业务场景、从数据中心到地理位置的多维度分布。技术上，我们集成了包括 Prometheus、Zabbix、Thanos、Percona 在内的多套监控工具。业务场景上，则涵盖了大数据、数据库、ToB（面向企业的服务）、ToC（面向消费者的服务）以及基础架构等多个监控系统。数据中心分布在阿里云、华为云、Azure、AWS、IBM 云以及自建 IDC，地理位置覆盖了美国、澳大利亚、欧洲、新加坡、日本、香港、深圳等多个国家和地区。
这种分散的监控布局带来了一系列问题:
- 监控不统一: 不同系统间缺乏集中化管理，难以形成统一的监控视图。
- 数据不统一: 由于监控系统的多样性，数据采集和格式各异，汇总分析成了一大难题。
- 多入口: 监控系统众多导致运维、开发、业务人员面临多个操作界面，工作效率低下。
- 监控告警混乱: 告警系统的不统一使得告警信息泛滥，难以快速准确地响应紧急情况。
- 监控盲区: 在这样复杂的监控环境下，难免出现监控盲点，威胁系统的稳定性与安全性。
为了克服这些挑战，我们提出并开始实施统一全球监控系统的计划。这一计划的目标是实现监控资源的集中管理，统一数据格式与告警机制，简化操作流程，并最大限度地减少监控盲区。通过这一系列措施，我们旨在打造一个更加高效、可靠且易于管理的全球监控体系。
技术选型
当我们决定整合全球监控系统时，我们首先开展了一系列的全面调研，以评估不同开源监控系统的优势和局限性。我们深入分析了包括: Prometheus、Zabbix、Thanos、Percona、Nightingale、VictoriaMetrics 等在内的多个解决方案。在考虑了业务需求、二次开发能力、以及地理位置分布等因素后，我们最终确定了以 Prometheus 和 VictoriaMetrics 为核心的组合方案。我们的选择主要基于以下关键因素:
- 监控系统熟悉度: 团队部分同事对 Prometheus 等监控工具有一定的实践及使用经验。这意味着无论是运维人员还是开发人员，都无需经过繁琐的新系统培训，从而加快了整合进程并提升了团队的接受度。
- 开源生态及社区活跃度: Prometheus 和 VictoriaMetrics 都在开源监控领域内占有一席之地，拥有活跃的社区支持。Prometheus 在 GitHub 上有超过 52.2K Star，而 VictoriaMetrics 也有超过 10.6K Star。尽管 VictoriaMetrics 在国内的用户群体相对较小，但 Prometheus 在互联网公司的应用还是很广泛的，这也表明了其在行业内的认可度。借助活跃的社区，我们能够在遇到问题时迅速获取支持。
- 文档完善度: 无论是 Prometheus 还是 VictoriaMetrics，它们都提供了详尽的文档，这也是任何开源项目能够成功的关键因素之一。特别是 VictoriaMetrics，其官方文档为我们解决问题提供了极大的帮助，尽管需要投入时间去啃官方文档。
- 兼容性: 考虑到如果从零开始会涉及到重大的更换成本，特别是在现有的 Kubernetes 环境中集成的 Prometheus 等系统，我们需要确保新方案与现有基础设施的兼容性。
- 技术路线: 考虑到我们的技术发展方向主要是微服务架构，并且正在将尚未微服务化的业务转向容器化，因此我们倾向于选择支持云原生的监控解决方案。
- 业务需求: 在构建监控体系时，运维团队往往忽略了业务层的需求，这可能是由于运维人员与业务之间的隔阂所致。但在我们的场景中，业务团队需要实时掌握 ToC 服务的性能指标，因此我们需要一个能够适应这一需求的监控系统。
综合以上因素，我们坚信 Prometheus 与 VictoriaMetrics 的组合方案将为我们提供一个强大、灵活且可扩展的监控平台。此组合方案不仅能够满足我们当前的监控需求，还能够适应我们未来可能的扩展和技术演进。
我们的目标是构建一个能够提供一致性视图、简化告警流程、增强数据分析能力，并最终提高运营效率的监控体系（注意这里说的是运营，还非运维）。通过 Prometheus 我们可以利用其强大的数据收集和查询能力来监控我们的微服务架构。而 VictoriaMetrics 则以其高性能和可扩展性，为我们处理大规模监控数据提供了可靠支持。此外，这个组合方案的另一个优势是其自然地与我们现有的云原生技术栈相融合。随着我们业务的容器化转型，Prometheus 和 VictoriaMetrics 提供的原生支持保证了监控系统的无缝集成和高效运作。最后，我们也意识到业务团队与监控系统之间的沟通至关重要。因此，我们计划在监控平台中构建更加友好的用户界面，让业务团队能够更直观地监控服务性能，从而更快地响应客户需求和市场变化。我们通过定期的沟通和反馈会议，确保运维团队和业务团队之间保持紧密的协作。通过统一高效的全球监控系统的落地，不仅能够提升我们的运营能力，还能够满足业务的增长和客户满意度的提升。
监控架构设计
当我们的架构设计仅限于单一数据中心或地区时，部署一套 Prometheus 监控系统可能已经足够。但在面对跨越不同业务场景和地理位置的复杂需求时，考虑的因素自然增多。以下是在设计全球监控系统时需深入分析的关键点:
- 全球数据同步: 全球数据同步的挑战在于如何实现实时或近实时的数据传输。在此过程中，数据量、压缩比、网络异常时的数据续传机制、带宽限制以及不同网络的互联互通能力都是需要认真考虑的参数。
- 高可用性: 之前各业务线或部门拥有独立的监控系统，一个系统的故障不会波及到其他部门。但随着统一监控系统的引入，我们必须确保在任何节点发生异常时，整个监控系统仍然能够维持高可用性。
- 系统响应速度: 统一监控系统会面临大量的并发用户请求和数据写入操作，这些都会导致显著的 I/O 读写负载。因此，保证系统的响应速度，确保用户体验和监控效率至关重要。
- 成本效益: 自 2022 年以来，互联网公司普遍推进降本增效，我们需要在不牺牲生产效率的前提下，找到低成本的解决方案。
- 快速发现、快速接入: 手动接入和管理监控对象容易出错且效率低下，我们需要一个能够自动发现新资源并快速集成的系统。
针对这些挑战，我们逐一制定了系列解决策略:
- 全球网络连接: 虽然建立全球虚拟专用网络听起来只是一项简单任务，但实际上我们需要克服合规性、合法性、不同云服务商之间的兼容性问题以及网段划分的合理性等多方面的挑战。通过与多家云服务商就 VPN 进行对接后，发现其中存在兼容性问题，最后我们决定自建 VPN，并解决早期网段规划设计中的网段冲突问题。
- 分布式存储架构: 为了实现高可用性，我们选择了基于 VictoriaMetrics 的分布式存储架构。这个过程中我们遇到了一些问题，比如: 当 vmauth 如果有一个 url_prefix 中的 url 地址不可用时，它没办法像 nginx 一样自动剔除，需要手动人为剔除，为此我们使用了 Nginx 替换方案。对此，我们向开源社区提交了问题报告 Issues。这只是众多问题中的一个例子，我们将在后续的文档中详细叙述。
- 分布式监控与查询优化: 为了应对全球数千用户的并发访问，我们采取读写 API 接口分离负载均衡策略，并针对 Grafana Dashboard 的数据提取展示进行了调优，其中包括优化查询 SQL 效率、引入负载均衡以及按需扩展资源。
- 成本控制与资源优化: 在监控平台的资源配置和扩展方面，我们采用了容器化技术和 Kubernetes 集群管理，以实现资源的弹性伸缩。另外 VictoriaMetrics 底层使用 HDD 存储，以降低整个硬件投入成本。并且对 Prometheus Samples Appended 针对性进行优化，由最初的 60 多万降至目前的 15 万，以降低资源占用率，实现资源使用的最优化。
- 自动化运维流程: 为提高效率和减少人为错误，我们引入了 Consul 自动服务发现，并对其进行平台化管理，同时与 CMDB 联动，实现自动发现、自动接入。
- 安全性与合规性: 随着全球网络的扩展，安全性和合规性成为了我们不得不面对的重要议题。我们对权限进行了颗粒度细化，包括但不限于 IP 黑白名单、数据加密、访问控制、日志审计和定期的安全合规审查，以确保监控数据和基础设施的安全。
- 持续的性能监测和调优: 我们基于不同的 GOS 服务等级，建立了告警机制、响应机制完善、指标量化（MTBF 故障前平均时间、MTTR 平均修复时间、MTTA 平均确认时间、MTTF 平均故障时间），并持续跟踪监控系统的性能指标，通过收集和分析性能数据，我们能够及时发现瓶颈和潜在问题，并迅速采取行动进行优化。
通过这一系列的策略和持续的优化，不仅能够满足高可用性和快速响应的要求，而且还能够在严格的成本控制下提供服务。
服务标签化设计
构建一个高效的监控架构设计只是初步工作的开始。要确保各种业务服务能够以标准化的方式接入监控系统，同时避免告警系统的混乱，我们必须采取一系列措施。首先，我们深入分析了实际业务场景，基于此明确了一系列关键的监控标签，包括: 数据中心（DC）、服务类别（ST）、操作系统（OS）、业务服务与主机命名管理、运维环境（RE）、业务总线（BBus）、服务等级与告警级别（GOS）、自定义指标集（CMS）以及业务线（LOO）等。这些标签的标准化设计有助于明确资源归属和监控责任，提升监控效率。
进一步地，基于 LOO 从业务服务角度出发，我们又制定了服务归属组（SRG）、业务系统层（BSL）和系统模块层（SML）等监控标签，以更精确地划分和管理业务服务。我们确保整个监控体系的设计和实施都以业务为导向，这与传统的仅依赖运维视角的设计理念截然不同。
在这一过程中，我们制定了 15 个针对业务服务的监控标签，并对 30 多个自定义指标集进行了标准化处理，对数千个服务进行了细致梳理。通过这些措施，我们不仅提升了监控系统的准确性和响应速度，还大幅降低了告警的误报率和漏报率。
为了进一步验证这些监控标签和指标的有效性，我们在一个示例项目（Demo）中进行了实践应用，并从中收集反馈和数据，以便不断优化监控方案。这一系列的工作最终指向一个目标：实现监控平台化，即创建一个可扩展、易于集成、并能够适应不断变化业务需求的监控系统。通过平台化，我们能够确保即便是在快速发展和变化的业务环境中，监控系统也能够持续提供必要的支持和洞察。
告警体系设计
建立一个全面的告警体系是一项复杂的任务，但其挑战不在于告警平台本身的系统设计，而在于如何根据不同业务线（LOO）下的各个系统模块层（SML）制定合适的告警阈值。这一过程必须充分考虑业务的具体特点，包括业务面向的客户群体是面向消费者（ToC）还是面向企业（ToB）等。
对于 ToC 业务，由于其直接关联到公司的收入和用户体验，任何服务中断都可能立即影响收益和品牌声誉。因此，对这类业务模块的告警阈值需要设定得更为敏感和细致。例如，在处理交易或支付系统时，即使是微小的异常也应迅速触发告警，以便及时响应。
相比之下，ToB 业务可能主要服务于企业内部用户，对公司直接收入的影响较小。在这种情况下，我们可以适当提高告警阈值，以减少不必要的干扰，优化资源分配，并保持业务流程的连贯性。然而，这并不意味着可以忽视 ToB 业务的监控，因为长期的服务中断或性能下降仍然会对企业内部效率产生负面影响。
在制定告警阈值的过程中，需要跨部门合作，确保运维、开发、业务和运营团队都参与到讨论中。这种协作确保了告警阈值的制定既符合技术可行性，又能满足业务需求和客户期望。此外，持续监控和分析告警数据对于不断调整和优化阈值至关重要，因此，告警体系应该具备灵活性，以适应业务发展和变化。
最终目标是创建一个动态的告警体系，它不仅能够准确地反映系统的健康状况，还能够通过智能化的告警处理减少误报和漏报，进而提升整个组织的运营效率和服务质量。
Demo 验证与平台化
系统设计的核心应始终着眼于用户体验，因为不是所有用户都对 Prometheus、Grafana、VictoriaMetrics 等监控工具有深入学习和了解。系统的成功部署和有效运行依赖于用户的熟悉度和使用率，我们需要综合考量投入产出比。而这些用户包括开发人员、业务团队以及运维人员。特别是运维团队，作为系统日常运维的第一责任人，如果连他们对这些工具的使用都不熟悉，系统的有效落地将难以保障。
为了确保系统的顺利落地，我们鼓励所有运维人员积极参与系统的测试和验证当中。参与感的培养是至关重要的，它可以激发团队成员学习新技术的兴趣，提高接受和应用新系统的意愿。
在系统上线前，我们在测试环境中对整个监控架构和服务标签化体系进行了全面的验证。我们探索了如何实现快速的服务发现，服务接入流程的优化，以及多平台统一告警指纹的设计与告警抑制机制建立。同时，我们识别了可以平台化的组件，将它们抽象化并集成到平台中，以实现更高效的管理和维护。这些组件包括 Consul 集群管理、节点管理、模板管理、服务管理、告警中心、以及设备维护周期告警抑制等。
在这个过程中，我们设计并优化了 30 多套针对不同指标的模板，以及 30 多套 Grafana Dashboard，以满足不同监控需求。这些模板和 Dashboard 不仅提高了监控数据的可视性，还简化了用户的操作过程，使得即便是不熟悉监控工具的用户也能够轻松地管理和解读监控数据。
总之，为了系统的顺利落地和持续运行，我们不断优化用户界面和用户体验，减少技术门槛，以确保每个团队成员都能够对系统有深刻的理解和熟练的动手操作能力。
方案落地
通过前期系列的监控架构设计、服务标签化设计、告警体系设计、Demo 验证以及监控平台化，我们为整个监控方案的落地奠定了坚实的基础。这些前期准备工作使得最终的部署和实施变得更加顺畅。基于前期 Demo 所确定的方向，我们能够明确下一步的实施路径，并在此基础上进行系统的部署。
在这个过程中，我们耗费了约 3 个月的时间来细化和执行部署计划。我们特别关注了新旧监控系统之间的平滑切换，以确保业务连续性和监控数据的一致性。为了做到这一点，我们实行了逐步迁移的策略，从而避免了在切换期间可能出现的服务中断。
同时，我们也深刻认识到告警疲劳的问题，即过多的无关紧要的告警可能导致运维团队、开发团队、业务团队对真正重要的警报变得麻木。为了解决这个问题，我们优化了告警策略，实施了智能告警分级和告警抑制机制，以减少不必要的干扰，确保能够集中精力处理真正重要的事件。
此外，为了确保全面的监控覆盖和系统的高可用性，我们还对监控架构进行了冗余设计，并实现了自动故障转移。通过这些措施，我们保障了监控系统的稳定性和可靠性，从而为业务的持续运营提供了强有力的支持。
在整个方案的落地过程中，我们不断收集用户反馈，并根据这些反馈对系统进行迭代优化。我们意识到，系统的部署并不是终点，而是一个持续改进的过程。我们致力于不断提升系统的性能，改善用户体验，并确保监控方案能够与企业的成长和变化同步发展。
总结分享
事实上整个构建过程中，我们的关键在于不断地进行思考分析、Demo、复盘，只要大方向正确，那么整个方案的成功就有望。在规划可观测性平台时，我们设计了一个六层模型，并在 2023 年的建设中成功地实施了下三层。对于上三层，我们虽然只完成了一小部分，但 2024 年我们将致力于持续推进上三层的落地。
为了迅速实现下三层的落地，我们暂时搁置了一些底层业务逻辑的开发，例如配置管理数据库（CMDB）。我们认识到 CMDB 对于构建六层模型的重要性，以及实现整个系统血缘关联的重要性，因此在 2024 年我们将重点进行底层业务逻辑的规划与实施。
我们在构建整个可观测性平台的过程中遇到的最大挑战，并非平台本身的设计，而是如何实现不同业务线、运维、开发和运营团队之间的协同工作。在其他业务部门面临大量需求和业绩压力的背景下，跨部门合作的有效性成了我们作为主导者和设计者需要重点解决的问题。
在整个可观测性平台的实施过程中，我们取得了还不错的成效，并且这些成果得到了多个业务部门的认可。我们与他们分享了我们的设计逻辑和理念，特别是物流部门和仓库部门等。我们意识到，无论是运维还是业务部门的需求，他们的核心底层逻辑和原理都存在共性。例如，物流部门需要高效地管理全球物流系统，寻找更合理、更有效的运营链路至关重要。这不仅涉及对物流路径的优化，还包括如何实现成本控制和服务质量提升。同样，仓库部门负责全球各地仓库的库存管理，其中标签化体系的建立对于库存的快速识别和追踪至关重要。另外，仓库、物流、客户之间的最小路径优化，能够有效减少物流和库存成本，提升整体的运营效率。同时底层基础数据模型也非常重要。
这些管理要求和优化过程与我们在可观测性平台上所做的工作有着惊人的相似性。我们的服务标签化管理、预警机制以及管理策略都是为了实现更加精确和高效的资源管理。通过将这些原理应用于 IT 运维和业务流程中，我们能够帮助其它业务团队实现更加精细化和智能化的管理，同时也为业务部门提供了新的视角和策略以优化他们的业务流程。
在未来的工作中，我们将继续深入探索可观测性平台的潜力，并将这些原理应用于更广泛的业务场景中。我们相信通过跨部门合作和知识共享，我们可以进一步提升整个组织的运营效率和服务质量，同时降低成本。
在后续的系列文章中，我们将分享更多关于可观测性平台建设的细节，包括我们的设计思路、实施策略，以及如何实际落地中遇到的挑战。我们希望这些经验能够为同行和业界提供参考，共同推动可观测性领域的发展。
