微博增值团队可观测性探索与实践-回顾与反思-上篇

前言

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 语言技术栈）

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 扩展：性能较低，无法满足团队高并发场景下的最低性能损耗需求。

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

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

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

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

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

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

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

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

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

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

5. 建立健全的故障排查流程：团队制定了一套故障排查流程（待完成），以便在接收到告警后，快速进行问题定位和解决。维护 OnCall 文档。

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

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

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

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

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

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

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

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

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

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

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

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

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

技术选型

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

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

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

实施过程

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

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

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

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

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

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

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

团队协作

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

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

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

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

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

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