test

TakinTalks稳定性社区

于 2024-04-15 15:52:52 发布

阅读量864

点赞数 19

文章标签：容量治理

本文链接：https://blog.csdn.net/shulieTech/article/details/137784166

版权

一、可观测体系化改造前，面临哪些问题？ 1.1 需求压力面对业务和人员变动的挑战，我们的IT运维和产研需要新的应对策略。尽管业务量稳定，人员减少却给SRE团队带来问题——首先，人手不足迫使我们追求标准化流程以提高效率，建立统一监控框架成为迫切需求。其次，报警系统混乱，各业务线如大学教育、成人教育和国际教育等各自独立，我们目标是简化并统一报警流程，减少不必要的干扰。第三，监控数据不统一，日志和追踪数据分散。我们计划实现数据标准化，优化数据展示。

同时，研发团队也因人手减少而挑战重重，他们需要更多运维数据，改善报警响应，以及统一信息查询系统。为此，我们从运维和研发两端寻求统一和标准化的解决方案。

1.2 技术压力我们管理的教育业务跨越多个领域，造成技术堆栈既复杂又多元。用户所见的界面只是冰山一角，它背后隐藏着一个错综复杂的技术框架。在这样一个环境下，面对人手不足和业务增长的双重压力，我们得精心挑选关键技术，提升性能，同时剔除冗余部分。目标是打造一个更高效、更精简的可观测系统。

1.3 重心压力此外，SRE团队还面临工作重点的压力。我们的任务不仅是减少MTTR，缩短系统响应时间，更要确保业务的持续稳定运行。问题是，我们怎么利用现有技术栈增强系统的可观测性，从而提升其稳定性？

在人力资源减少的情况下，我们怎样将平台化和标准化融入日常工作？我们不仅追求成本效益和运营效率，系统安全性的保障也是至关重要的。这些都是SRE团队目前面临的主要压力点。

二、可观测标准化进行了哪些改造？ 2.1 应用 SRE 监控全景图首要步骤是仔细评估并确定所需的报警类型，包括监控分类、监控对象、监控指标。

随后，着手确定哪些工具可以从多个维度——用户体验、业务应用以及服务——进行监控工作。此外，还涉及到基础服务监控，并对监控指标、日志、以及追踪工具的使用进行了全面梳理。

我们进行了一系列调研，旨在简化现有技术栈并实施落地。监控的分类也已经大致完成。然而，我们意识到，仅以底层数据、端点或服务的监控数据为基础是远远不够的。

我们还发现，监控数据的有效性受到了应用标签不足的限制。我们尚未在系统前置中加入足够的应用属性，这一步骤对于后续的标签应用和服务链路间关联至关重要。因此，我们需要加强这一方面的数据丰富度。具体来说，我们将探索结合应用CMDB来关联下游文件和数据库的属性，并确保文件与数据库之间的一致性。这个过程需要进行细致的数据标记和处理。

除了监控数据的收集之外，我们认为运维视角应当拓展到传统监控和开发工作之外。实践经验表明，许多监控维度并不能总是准确地反映出实际问题。我们观察到，约七八成的重大问题通常与应用变更、迭代或是底层文件和基础设施的更新密切相关。因此，我们的任务是把这些事件维度纳入我们的监控体系，实现全面监控和问题跟踪。这也是我们需要深入研究并解决的一个问题。

2.2 监控系统组件改造前后对比 2.2.1 改造前在深入剖析我们监控系统组件改造的成果之前，可以先简单了解下改造前监控系统组件的实际状态。

简要概述一下，从数据采集到监控、报警通知，再到数据展示的整个链路，都体现了原有系统的具体情况。尽管此图已经尽可能地被简化，但实际的监控系统比它所示要复杂得多。显而易见，旧的数据采集系统不仅混合了新老技术，也留下了不同时代技术发展的痕迹。

在指标存储层面，我们曾经采用了基于Prometheus、Zabbix、Nagios的架构，同时结合了ES进行日志存储。关于日志报警，我们利用Watcher等工具进行了配置。至于指标监控，我们依赖于Prometheus和Alertmanager等规则配置器，有时则直接通过Grafana-Alert配置数据源和报警。

我们的报警机制相当杂乱无章，主要依靠Prometheus和Alertmanager来构建报警通道，但也有一些直接基于C语言的报警实现。在进行底层架构调整之前，我们使用了许多复杂的技术栈。

针对改造前的底层调用架构，我们识别出了几个关键的问题点：

1、指标监控存储使用多种，不便于统一管理

2、持久化指标存储Thanos不便于轻量数据接入、架构复杂不便于维护、使用对象存储资源长期存储成本较高

3、日志监控采集单一，ES日志收集较重，不便于运维日志轻量级使用

4、公有云、私有云告警数据，APM告警、日志告警、指标告警需要单独配置

5、没有统一的告警平台进行指标查看、规则制定、标签管理、告警管理、权限管理、故障自愈等功能

2.2.2 改造后在完成监控系统组件的改造后，我们的基础设施监控框架经历了根本性的转变。我们重构了从监控数据的采集、处理到报警通知的整个流程，并建立了一个统一的监控平台。这个平台不仅提升了数据收集的效率，还简化了报警通道的处理逻辑。我们的主监控链路以红色标识，形成了新的系统核心，而原有的、现逐步淘汰的旧系统则以黑色表示。

在指标存储方面，我们选择了基于Prometheus的解决方案，它为我们提供了一个更高效和统一的指标管理体系。对于日志存储，我们舍弃了之前复杂的三日志系统及基于ES的架构，转而采用了Loki系统。Loki系统不仅优化了运维日志的收集过程，也增强了我们对于硬件监控数据采集与分析的能力。

此外，我们还引入了“黑科技”，包括基于APM的工具用于性能监控，以及改进了日志收敛和报警处理。我们已经摆脱了依赖于Alertmanager的告警机制，转而使用了自主开发的告警系统，并对开源的报警工具进行了二次开发以满足我们的需求。

这次改造显著提升了从指标的统一性到轻量级存储方案的效率，降低了日志分类和存储成本，并聚合了Source、Trace、APM、Log等多样化的监控数据，实现了告警的统一处理。同时，我们也集成了多云环境的监控数据，简化了公共云指标的采集和告警管理。

核心的改进点在于监控平台的统一性。我们现在能够更高效地管理前置的数据采集、监控过程以及告警分发。通过这个平台，我们可以进行全面的展示、事件管理、告警管理以及标签管理等多方面的操作，从而实现了监控系统的全面优化和提升。

2.3 核心改造方案前文已经概述了告警分类以及监控系统改造前后的情况。现在，我将详细说明我们改造计划的核心策略。

2.3.1 数据采集 2.3.1.1 通用类方案我们首先对数据采集的问题进行了深入探讨。我们面临的主要挑战是选取合适的采集工具，并确保能够全面采集云环境及本地环境的数据。应对这一挑战，我们选择了基于Telegraf的二次开发，以构建一个横跨Kubernetes平台的统一数据采集架构。通过规范化Telegraf的输入和输出插件，我们实现了数据采集的标准化和一致性，有效地提升了效率并降低了成本。