前言

截止 23 年 3 月末，微博增值团队从上线一站式可观测平台到现在也运行了差不多两年的时间了。在这两年里，团队成员通过一站式可观测平台不断优化和改进服务，提高了整体系统的性能与稳定性（3 个 9 到 4 个 9，tp99 case by case 优化，平均下降 100ms），同时降低问题发现和定位的时间（5 分钟发现问题，30 分钟内定位问题），从而使开发人员能够专注于创新和业务发展。

今天本文主要想说一些整个一站式可观测平台发展过程中需要回顾与反思的一些点。在回顾的过程中，我将从以下几个方面进行思考与总结：

1. 目标与需求

2. 技术选型

3. 实施过程

4. 团队协作

5. 用户体验

6. 成本和效益

7. 风险管理

8. 组织和文化

项目开发是一个复杂的过程，需要考虑众多因素。因此，在开发过程中需要不断进行反思和总结，及时发掘问题和给出改进方案，为项目的成功发展提供有效保证。由于篇幅较长，为了便于阅读消化，本文将分为上下两篇来进行整理。上篇主要讲一下目标与需求、技术选型、实施过程和团队协作。

目标与需求

在项目开发过程中，项目的目标和需求是开发的基础。确立好项目目标和需求后，才能从根本上保证项目的开发方向和成果符合用户的期望。在项目开发过程中，需要充分考虑用户的需求和期望，以此为基础制定项目的目标。同时，项目的目标应该具有明确性、可量化性、可操作性和可验证性等特征，以便于评估项目成果是否达到预期目标。在整个开发周期中，需要不断关注用户需求和反馈，及时调整项目目标和需求，以确保项目的持续适应性和可持续发展性。审视我们当初设定的目标和需求是否得到了满足，是否有新的需求和挑战出现，以便对现有解决方案进行持续优化和改进。

回顾目标：

1. 寻找更趁手的工具，让开发人员更专注于开发本身。(缺少排查问题工具、开发人员人肉或凭经验排查问题。频繁代码上线 debug。)

2. 希望 90%的问题能通过报警主动发现，而非用户反馈。（减少异常影响范围）

3. 期望问题从发现到定位的耗时缩短至 15-30 分钟，缩短 MTTR（平均修复时间）。

4. 希望服务 RT（响应时间）降低 30%。

5. 找到一个能够将 Metric、Log、Trace 数据串联统一管理的解决方案，自动关联并分析相关数据，尽可能实现根因分析，且成本相对较低。（开发维护仅 1 人、自运维机器数量有限、Go 语言技术栈）

为了寻找更趁手的工具，让开发人员更专注于开发本身，团队经历了以下几个阶段的尝试和探索：

第一阶段：使用 ELK+Grafana+Graphite 等工具，作为监控和日志分析方案。历史遗留方案。

这套方案的优点在于：

1. 多功能性：ELK+Grafana+Graphite 可以同时提供监控和日志分析功能。通过使用这些工具，系统管理员可以识别并解决问题，提供系统运行的全方位视图，并在故障时快速诊断问题。

2. 高度可定制性：这套方案支持定制数据源、处理方式、视图、警报等设置。系统管理员可以根据其需要创建自己的监控和分析规则和视图，以适应特定环境或应用程序的需求。

3. 易于安装和使用：这套解决方案可以很容易地在不同的操作系统上安装和部署。同时，它的学习曲线相对较低，即使是新手也可以迅速开始工作。

但是，这套方案也有一些缺点：

1. 部署复杂性：虽然这套方案相对容易安装和使用，但是在处理更复杂的数据源时可能会出现问题。如果需要监控多个分布式系统，这套方案的部署和配置变得极其复杂。

2. 对硬件要求高：这套方案对硬件资源的需求比其他工具更高。大量的日志和指标数据需要被处理和存储，需要更高的 CPU 和内存资源才能保证系统的性能稳定和响应快速。 filebeat 贼吃资源。

3. 有限的警报功能：虽然这套方案提供了警报功能，但是对于大规模或复杂系统，警报功能可能不够完整和灵活。

ELK+Grafana+Graphite 方案总体来说是一种灵活、高度可定制的监控和日志分析解决方案，但需要根据具体情况仔细考虑其优劣和适配性。对于我们团队来说最大的问题，过去的运维标准不统一，维护成本高。ELK 成本过高。排查问题需要主动埋点日志。

第二阶段：引入 APM 工具 SkyWalking，提高监控覆盖度并快速定位性能瓶颈。SkyWalking APM 引入了 Trace 的概念，帮助团队找到性能瓶颈和项目依赖。对于存量 PHP、Go 的业务团队来说，引入 SkyWalking APM 工具的优缺点如下。

优点：

1. 提高监控覆盖度：通过 SkyWalking 的引入，开发人员可以实时监控应用程序在生产环境中的状态，包括请求量、响应时间、调用链等指标。这使得开发人员能够及时识别并解决潜在问题。

2. 快速定位性能瓶颈：SkyWalking 的 Trace 功能可以记录应用程序每个请求的详细调用情况，开发人员通过 Trace 可以知晓应用程序每个组件和操作的性能表现。这样，开发人员可以轻松快速的定位性能问题的瓶颈。

3. 可视化和易用性强：SkyWalking 提供很好的 UI 展现，并且支持多种语言、多协议、多场景的性能录制、唯一跟踪 ID、多维度的性能分析等多个要素，以此实现一种科学的应用性能可视化。

缺点：

1. 学习成本：SkyWalking 相较于 ELK+Grafana+Graphite 方案来说，有一定的学习复杂性。要求开发团队对日志和应用性能监控进行更深入的了解。最基础也要知道什么是 Trace。

2. 需要占用一部分系统资源：由于 SkyWalking 需要收集大量应用程序数据，并记录调用链，所以需要占用一定的系统资源。SkyWalking 服务 Java 技术栈，默认存储是 es，机器成本压力巨大。

3. 有限的可扩展性：SkyWalking 当前不支持一些定制化功能，因此无法对于某些特殊情况或特定业务进行适配和扩展。 同样也是因为 Java 技术栈，与团队相性不符。

4. PHP Agent 扩展：性能较低，无法满足团队高并发场景下的最低性能损耗需求。

引入 SkyWalking APM 工具可以提高 PHP 应用程序在生产环境中的监控和性能分析能力，但需要开发人员在使用时充分考虑其缺点，并综合评估是否适合项目使用。这段经历对于团队的最大收获是引入了 Trace，初步了解到了可观测性的概念，同时在不断优化 SkyWalking 相关生态的同时，积累了许多关于 PHP 扩展开发、ClickHouse 等相关技术积累。也在后面起到了至关重要的作用。

第三阶段：在了解到 OpenTelemetry 项目后，团队决定基于 OpenTelemetry 来提升服务的可观测性。OpenTelemetry 提供了一种统一的方法来收集、处理和传输 Metric、Log、Trace 等数据，有助于实现根因分析，同时也降低了成本。利用开源社区减少团队内部维护成本。同时参与社区，达到正向循环。

基于 OpenTelemetry 提升服务可观测性的方案，优缺点如下。

优点：

1. 更简单的数据采集：OpenTelemetry 提供了一个统一的数据采集 API，可以轻松收集应用程序的性能数据，包括指标（Metric）、日志（Log）和跟踪（Trace）数据。这使得开发者不需要考虑不同的数据格式、协议等，可以大大简化数据采集过程。（可观测性的事实标准）

2. 提高监控覆盖率：OpenTelemetry 可以集成多种语言、框架和第三方组件，支持跟踪数据流在分布式系统架构中的各个应用程序中的传播过程，从而可以监控任何一个节点的信息流转状态。

3. 开放源代码、可定制性强：OpenTelemetry 是一个开源项目，可以自由定制并集成各种工具和平台。此外，它也可以在多种云平台的支持下运行，甚至可扩展到对于混合云部署环境的集成。厂商无绑定。未来可以随意切换任意的后端 APM 服务。用户一次接入，随意切换。

缺点：

1. 学习成本：尽管 OpenTelemetry API 的设计易理解、易使用，但是在深入使用 OpenTelemetry 的不同特性时，开发者需要更多地学习其背后的概念和工作原理。同时，因为 OpenTelemetry 也是一个较为新的项目，社区还在发展中，开发者需要有耐心去了解和熟悉最新的变化和发展趋势。

2. 需要占用一定的系统资源：由于 OpenTelemetry 会占用系统资源来提供监控和跟踪，尤其是在处理大量数据时，需要增加硬件资源和系统负载。对于一些自身资源较为有限的应用程序或系统，这可能会带来不利影响。回过头来从整体实践结果来看，需要增加硬件资源和系统负载非常低，在可预期范围内。

3. 不支持所有应用：OpenTelemetry 尚未支持所有语言和框架。如果应用生态系统中的某个组件不受支持，监控的完整度可能会有所受限。不过由于整体方案设计的非常优雅，我们只需要针对性开发扩展就好。

OpenTelemetry 作为一个新兴的且市场火爆的项目，目前尚处于快速发展的初期阶段，可以使监控工作更高效、更简单。开发者需要认真考虑使用 OpenTelemetry 的成本、复杂性和适用性，并结合自己的特定业务需求作出最佳的决策。目前大部分已发布 Bete 版本。部分已发布 Realase 版本。已趋于稳定。

为了实现 90%的问题能通过报警主动发现，而非用户反馈，团队采取了以下措施：

1. 引入 APM 工具：团队先后尝试了 SkyWalking 和 OpenTelemetry，通过这些工具提高监控覆盖度，快速定位性能瓶颈，从而及时发现问题。后续自研了 Tiros 的 APM 工具。更加轻量简单的 APM 工具，同时集成了微博内部生态。方便业务无心智的使用。

2. 设定合理的告警阈值：团队在收集和分析各种性能指标的基础上，设定合理的告警阈值，确保在出现问题时能够迅速触发告警。提供统一建议的告警模板，业务人员开箱即用。

3. 优化告警方式：团队通过对告警方式的优化，实现了报警信息的实时推送，提高了问题响应速度。指标最小 1s、告警最小 1min 颗粒度。

4. 持续改进：团队不断地优化监控系统，完善告警规则，以便更准确地发现潜在问题。

5. 建立健全的故障排查流程：以便在接收到告警后，快速进行问题定位和解决。维护 OnCall 文档。

团队的这些措施可以大大提高监控覆盖度和问题发现率，但要实现 90%的问题能够通过报警主动发现，还需要不断改进和创新。

首先，团队可以继续引入更多的监控工具，并逐步强化监控的精细化。例如，可以尝试引入更加细致的监控指标，对代码中的异常进行更加精细的监控和分析。同时，还可以对多个工具进行整合和优化，以进一步提高监控效果和减少告警误报率。引入根因分析能力。更加快速的发现问题，定位问题。

其次，团队可以进一步优化告警方式和处理流程。例如，可以设计人工干预的监控，设定特定的策略和告警动作，以最大程度地减少误报和深化问题的定位和排除。

最后，团队可以制定更加周密和科学的故障排查流程，结合实际情况采用合适的方法和流程来分析和解决可能存在的问题。同时，还可以持续学习和发掘新的问题排除方法和经验，以进一步提高监控效果和质量。

总的来说，团队通过引入 APM 工具、设定告警阈值、优化告警方式、持续改进监控系统以及建立健全的故障排查流程等措施，已经取得了一定的成果，在实现 90%的问题主动发现方面也已经有了很大的提升。随着技术和管理的不断进步，该目标在未来也有望得到更好地实现。

为了将问题从发现到定位的耗时缩短至 15-30 分钟，并缩短 MTTR（平均修复时间），团队进行了以下工作：

1. 引入 APM 工具：通过使用 SkyWalking 和 OpenTelemetry 等工具，团队可以实时监控应用性能，从而更快地发现并定位问题。

2. 优化监控和告警：团队设定了合理的告警阈值，并优化了告警方式，以便在问题发生时及时收到报警信息，提高问题响应速度。

3. 制定故障排查流程：团队建立了一套明确的故障排查流程，指导开发人员快速定位并解决问题，提高问题处理效率。

4. 提升团队技能：团队成员不断学习和提高相关技能，以便更熟练地运用各种工具和方法进行问题定位和修复。

5. 制定 SLA（服务等级协议）：团队制定了明确的服务等级协议，为问题处理设定了时间目标，有助于团队成员更有目标感地进行问题解决。

6. 持续改进：团队根据问题处理过程中的经验教训，不断优化故障排查流程，提高问题定位和修复的速度。

7. 实施知识管理：团队将故障排查经验和解决方案进行文档化，以便于其他成员在遇到类似问题时快速参考和应用。

通过上述努力，团队在问题发现、定位和修复方面取得了显著的成果，90%的问题处理时间缩短至 15-30 分钟，从而降低 MTTR。然而，实际效果可能因项目和团队具体情况而有所差异，需要不断地持续优化和改进。

为了将服务 RT（响应时间）降低 30%，我们进行了以下工作：

1. 优化应用性能：通过代码审查、性能测试和负载测试，团队发现并修复了性能瓶颈，提高了应用程序的运行效率。

2. 采用缓存策略：团队引入了合适的缓存策略，Redis、Mecached、system momery，减少数据库查询次数，提高数据访问速度。部分特殊场景引入基于内存的布隆过滤器，快速筛选无用流量。

3. 异步处理：对于耗时较长的任务，拆分异步处理，减轻服务器压力，提高响应速度。

4. 传统物理机迁移 k8s：应用架构设计：对传统物理机部署的应用进行分析和重构，设计支持容器化的应用架构，考虑镜像管理、网络配置等方面的问题。持续集成和部署：采用 CI/CD 工具和 Docker 镜像仓库，实现自动化构建、测试和部署，确保快速、稳定地交付应用。容器编排：使用 Kubernetes 等容器编排工具，在集群中执行容器调度、负载均衡等管理操作，确保应用高可用性和弹性伸缩。优化资源分配：k8s 支持为容器设置资源限制（如 CPU 和内存），这有助于提高资源利用率并确保关键服务得到优先处理。通过合理配置资源，可以提高应用性能，降低响应时间。

5. 代码优化：团队针对关键路径进行代码优化，如减少循环嵌套、避免不必要的计算等，提高代码执行效率。超时时间优化，fallback 机制优化等等。

6. 监控与调优：团队实施实时监控，通过收集和分析性能指标，找出待优化的部分，持续进行性能调优。

通过以上工作，团队旨在降低服务的响应时间，提高系统性能和用户体验。然而，实际效果可能因项目和团队具体情况而有所差异，还需要持续关注并不断优化，这将是一个持续的治理过程，而非一劳永逸。

技术选型

技术选型是项目成功的关键因素之一。在选择技术方案的时候，需要考虑多方面因素，包括性能、可维护性、安全性、可扩展性、成本效益等。在选择技术方案时，需要全面分析技术特点和应用场景，并根据实际情况进行选择。同时，也需要关注技术的更新和发展，及时更新技术选型，以确保项目的技术质量和竞争力。

整体架构图

1. 数据收集：PHP：使用 OpenTelemetry PHP 自动埋点+手动埋点结合的方式来实现对自定义指标的收集和埋点。自动埋点解决通用性问题，手动埋点解决具体垂类问题，手动埋点可以更灵活地设置指标的采集范围和采集条件，同时也可以在数据收集时对指标进行一个初步的过滤和预处理，从而提高数据收集的效率和准确度。Go：使用 OpenTelemetry Go 主动埋点来实现自动收集的指标数据。相较于 PHP 的手动埋点，Go 的主动埋点更加方便快捷，能够自动收集应用程序的指标数据，并将其发送到 OTLP 收集器中。

2. 数据处理和分析：数据处理：使用 OpenTelemetry OTLP 架构提供的 FilterProcessor 和 AttributeProcessor 进行数据过滤和标签自动归一、清洗染色等逻辑处理。FilterProcessor 可以有效地过滤掉不需要的指标数据，AttributeProcessor 则可以对数据进行进一步的处理和优化，如进行自动归一化、标准化、清洗、染色等。这些处理操作可以在数据处理的同时提高数据的质量和准确性，便于进行后续的数据分析。数据存储和分析：使用 ClickHouse 作为 OTLP 的数据存储介质，并开发了 Exporter 插件，用于对数据进行更深入的分析。ClickHouse 是一个高性能的列式数据库，相较于传统的行式数据库，能够更有效地存储和处理大数据量指标数据。而 Exporter 插件则能够为数据提供更多的分析和诊断能力，如 MySQL 慢查询统计、缓存统计、带宽使用等。

3. OTLP：Receiver：开发了 OtlpUDPReceiver 插件用于支持 UDP 数据接收。UDP 是一种轻量级的传输协议，在网络消息传输时具有较高的传输效率和速度，对数据传输的实时性和准确性能够提供更好的保障。Extension：开发了内部权限校验扩展，用于对所有 Receiver 接收到的数据进行身份统计校验。此扩展可以有效地保证数据传输的安全性和完整性，避免了数据被篡改或者冒充的危险。Processor：开发了 FilterProcessor 和 AttributeProcessor 两个插件，分别用于数据过滤和标签自动归一、清洗染色等逻辑处理。这些 Processor 可以对数据进行预处理和过滤，避免了不必要的数据传输和存储，同时还能够提高数据的质量和准确性。Exporter：开发了 Exporter 插件，用于对数据进行更深入的分析，如 MySQL 慢查询统计、缓存统计、带宽使用等。通过 Exporter 插件可以更全面地了解指标在应用程序中的使用情况和性能表现，从而能够优化应用程序的运行效率和性能。

更多实现细节请参考： 微博增值团队可观测性探索与实践-初探 、微博增值团队可观测性探索与实践-实践

实施过程

实施过程是项目成功的保证之一。在实施过程中，需要全程跟踪、监控项目开发进度、质量和成本等指标，及时调整和协调项目开发中的问题和冲突，确保项目按时、按质、按量完成。同时，也需要保持代码质量和文档规范，确保项目的可维护性和可持续发展性。在项目实施过程中，需要注重项目交付和用户培训等环节，提高用户满意度和项目成果转化效益。回顾项目实施过程中遇到的问题和挑战，分析原因并提炼经验教训，从而为今后类似项目的实施提供参考。

1. 明确项目目标：首先，需要澄清项目目标，以确保团队对项目进行正确的方向。同时，需要确定项目的时间表和预算。

2. 确定可观测性指标：在定义可观测性指标时，需要从整体层面出发，考虑需要观测哪些数据。这些指标应该与项目目标有关，例如：应用或系统的可用性、性能和用户满意度等等。

3. 选择可观测性工具：选择合适的工具对于实现可观测性是至关重要的。

4. 设置监控方案：根据设定的可观测性指标，需要设置监控，以观测应用程序或系统的实际运行情况。一些监控方案包括容器监控、日志监控、性能监控、安全监控等方式。

5. 定义警报规则：当监控方案中的指标超过或低于设定的阈值时，必须触发警报。警报规则需要根据设定的指标和团队所需的响应时间进行定义，以便最小化业务数据损失。

6. 自动化测试和交付：自动化测试和交付是项目实现可观测性的重要步骤之一。这可以确保应用程序或系统在运行时的健康状态，从而最大程度地减少监视和警报所需的时间和资源。

7. 制定持续改进策略：持续改进是实现可观测性的关键。需要确定改进计划，以最大限度地调整监测、指标和警报规则，从而提高系统或应用程序的可靠性和稳定性。

团队协作

团队协作是项目成功的重要保证之一。在团队协作中，需要明确角色分工、沟通协调机制和团队文化建设等方面。同时，也需要关注团队成员的专业技能和人际交往能力的提升，以提高团队的绩效和协同能力。反思团队间的沟通、协作和知识共享是否得到了有效实现，以便进一步优化团队协作机制，提高工作效率。如何在团队内推广，培训，甚至推广到其他大团队。

将可观测性系统推广到其他兄弟部门总结为以下步骤：

1. 明确推广的目标和意义：在向其他兄弟部门介绍可观测性系统之前，需要明确推广的目标和意义，以便让其他兄弟部门更好地了解和接受这一概念。

2. 强调可观测性系统的作用和优点：可观测性系统可以帮助兄弟部门更好地监控和优化业务过程，提高运营效率和质量，减少故障和风险，提升客户体验和满意度。

3. 说明可观测性系统的实现方法和技术：可观测性系统需要借助一些技术手段来实现，例如：日志收集、指标监控、分布式追踪等。需要向其他兄弟部门介绍这些技术手段，以便让他们更好地理解可观测性系统的实现原理和流程。

4. 提供可观测性系统的相关培训和支持：为了让其他兄弟部门更好地掌握和使用可观测性系统，需要提供相关培训和支持，例如：技术文档、培训课程、专家指导等。需要让其他兄弟部门知道，他们可以随时向故障解决团队寻求帮助和支持。

5. 建立可观测性系统的建设机制：为了更好地推广和应用可观测性系统，需要建立相应的机制和流程，需要让其他兄弟部门参与到这些机制和流程中，以便更好地发挥可观测性系统的作用和优势。

6. 捆绑生态：捆绑 k8s 服务、捆绑团队框架，接入生态的用户可以体验开箱即用的快感。后面回顾来看，这是整个生态能推动的最大功臣。大家最初其实并不需要可观测性，或者对于他们来说并不是刚需，从他们的刚需出发，解决他们的问题，身边推广自身产品。实现互助共赢。

篇幅原因，用户体验、成本和效益、风险管理、组织和文化将在 微博增值团队可观测性探索与实践-回顾与反思-下篇 中更新。暂时先想到这些，文章后续可能会因更多的思考而进行调整。

作者介绍：

张铃崎，前微博研发工程师。目前在百度任职。

• 欢迎关注我们的 Github 项目 https://github.com/open-telemetry/docs-cn
  

• 想加入技术社群联系社区创始人微信 nizhanali