微服务应用可观测性解决方案介绍
目录
6.2.1.2.4 CNCF采集标准组件OpenTelemetry
一、可观测性出现背景
彼得·德鲁克曾经说过：“如果你无法量化它，你就无法管理它。” 可观测性（Observability）是帮助微服务稳健运行的重要一环。“我们的系统是否还是正常的？”，“终端用户的体验是否符合预期？”，“我们如何在系统快要出问题之前主动发现系统的风险？”。如果说监控可以告诉我们系统出问题了，那么可观测就可以告诉我们系统哪里出问题了，什么原因导致的问题。可观测不但可以判断系统是否正常，还可以在系统出现问题之前，主动发现系统风险。
从系统的角度来讲，监控以 Ops 为主，聚焦在发现，确保系统稳定性。可观测性的目标是白盒化，注重 Recall+Precision，贯穿 Dev/Tester/Ops 等环节，通过多种观测手段，确保找到根因，防患于未然。
二、什么是可观测性（Observability）
2.1 可观测性的不同解析
2.1.1 百度维基解析
控制理论中的可观察性（observability）是指系统可以由其外部输出推断其其内部状态的程度。系统的可观察性和可控制性是数学上对偶的概念。它与可控制性（Controllability）一起，是由匈牙利数学家 Rudolf E. Kálmán 提出。
2.1.2 IBM解析
一般来说，可观察性是指您仅根据所了解的外部输出对复杂系统内部状态或条件的理解程度。 系统的可观察性越高，您就能越迅速、越准确地从发现的性能问题找到根本原因，而不必进行额外的测试或编码。
IBM官网出处：什么是可观测性？ | IBM
2.1.3 CNCF（云原生计算机基金会）组织解析
可观察性是系统的一种属性，描述了系统可以从其外部输出中被理解的程度。
比如通过 CPU 使用时间、内存使用、磁盘空间、延迟、系统运行的错误信息等来衡量，计算机系统或多或少是可以被观察到的状况。聚合分析这些数据，您可以查看这些可观察的数据来了解系统的运行状况。
2.1.4 我的个人理解
可观测性是对软件的一种度量能力。软件是一个复杂系统，怎么知道它的运行状况是否健康呢？怎么从外部窥见软件的运行状况和异常情况呢？怎么分析出现的异常呢？通过软件内部产生的数据信息（日志信息、链路信息、profilling 等等各种信息）并输出到外部，外部把这些信息通过聚合、计算，用一定的形式组织起来，然后用列表、图表形式展现出来，这样我们就可以肉眼去查看软件系统各种纬度的情况、系统当前所处的状态。
可观测性就像一个显微镜，它仔细观察软件系统的各种指标和状态，系统是否出现异常情况。
2.2 可观测性和监控的区别与联系
2.2.1 区别
监控告诉我们系统哪些部分是工作的，而可观测性，则告诉我们那里为什么不工作了。虽然可观测性是由传统监控发展而来，但是他们有着本质的不同。
2.2.2 联系
2.2.2.1 “监控”是“可观测性”能力的一部分
任何时代都需要监控，但监控早已不再是核心需求。 运维是传统监控的使用主体，通过告警与整体分析往往可以快速排障。然而，一旦需要剖析导致故障产生的深层原因往往就需要研发的介入。云原生环境，系统架构愈发复杂，通过研发追溯源代码定位故障节点难度较大，需要在设计系统之初就考虑这些问题。DevOps作为云原生技术的基础能力之一，改变了开发、运维之间的协作方式，从根本上为实现“可观测性”能力创造前提。
传统监控更多的是指运维自动化工具，主要用途是替代人自动监控系统运行情况，在系统发生异常时告警，最终还是需要人工去分析异常、故障诊断和根因分析。
但现代IT系统的关键词是分布式、池化、大数据、零信任、弹性、容错、云原生等，越来越庞大，越来越精细，越来越动态，同时也越来越复杂。通过人去寻找各种信息的关联性，再根据经验判断和优化，显然是不可行的，耗时耗力还无法找到问题根因。
可观测性不仅包含传统监控的能力，更多的是面向业务，强调将业务全过程透明化的理念，实现全景监控、智能运维和自修复能力等体系化的服务能力。
相比监控只能展示系统出问题的地方，可观测性则能够“更一进步”告诉我们为什么出问题，还会有哪里出问题。一个组织的系统可观测性越强，就能越迅速地了解为什么出现问题并修复。通过应用可观测性来对组织运营产生的实际数据进行分析，将所有数字化产品赋予可观测能力，在较短时间内推动主动决策，更进一步满足以用户为中心的数字化转型需求，从而增强企业竞争力。
三、可观测性的三大支柱内容
观测性支撑数据大致分为三大类：Metrics（聚合度量），Tracing（链路追踪） 和 Logging（事件日志）。
3.1 Metrics(聚合度量)
是?种聚合的度量数值，提供量化的系统内/外部各个维度的指标，?般包括Counter、Gauge、Timer、Histogram 等度量指标。
3.2 Tracing（链路追踪）
提供了?个请求从接收到处理完毕整个?命周期的跟踪路径，?向的是请求，可以轻松分析出请求中异常点，通常请求都是在分布式的系统中处理。?如?次请求的范围，也就是从浏览器或者?机端发起的任何?次调?，我们根据轨迹去追踪，经过哪些组件、微服务等，所以也叫做分布式链路追踪。
3.3 Logging（事件日志）
应?运?过程中产?的事件或者程序执?过程中产?的?些?志，可以给我们提供?些系统运?过程中的精细化信息，例如某个关键变量、事件、访问记录等。
我们可以将指标、追踪和日志数据的进行进一步关联、分析，推导出当前微服务系统所处的状况。
四、可观测性能解决什么问题
谷歌给出可观测性的核心价值很简单：快速排障（troubleshooting）。可观测性犹如整个IT系统的眼睛，它是运维人员发现问题、定位问题、解决问题的第一步，同时，也是运维监控的实现“先知、先觉、先行”的重要条件。
同时在以下方面也有突出的表现。
4.1 整合数据孤岛
- 以数据虚拟化和机器数据湖架构，整合机器数据孤岛，提升数字化效能，基于系统目标、结构、行为的数据治理
- 与多维度关联分析，有的放矢地处理问题，提升问题处理效能
4.2 快速高效排障
- 多种机器数据联动分析、全息观测、高效定位根因，智能降噪
- 以统一工作台实现业务问题衡量、预防、发现、定位、解决的端到端闭环
4.3 提升业务敏捷
- 内置可观测性场景化应用及低代码开发平台，为开发测试、IT运维、业务运营、安全合规等全业务运营流程提供可观测性能力，实现高效运维和运营
- DevOps全流程数据分析，提升研发效能
- 用户旅程端到端数据实时反馈，助力提升业务运营效能
- 业务SLO和成本实时监控与告警降噪，提升IT运维效能
- 日志数据实时采集和分析，提供安全与合规保障
五、云原生下微服务应用可观测性的挑战
目前，常见的微服务框架包括 Spring Cloud 和 Dubbo 等多语言微服务，并具备服务注册发现、服务配置、负载均衡、API 网关、分布式微服务等基本能力。其中，服务治理包括无损下线，服务容错，服务路由等能力。可观测性包括应用监控，链路追踪，日志管理，应用诊断等。
在云原生场景下微服务应用的可观测性主要面临如下三个挑战：
5.1 发现难
从云服务器 ECS 到 Kubernetes，微服务架构复杂度提升，观测对象复杂度提升，监测数据覆盖不全。
5.2 定位难
随着多种治理能力深入，可观测要求高，服务框架复杂度增加，技术门槛提升，数据本身复杂度提升，数据关联性差。
5.3 协作差
随着组织角色变化，可观测不只是运维工作，可能涉及研发人员；在目前应用安全要求越来越高的场景下，可能还涉及安全人员，多方的协作跨部门，跨组织，协作困难。
六、如何构建可观测性
6.1 构建可观测性的基础
6.1.1 标准化
传统的工具是垂直向的，在引入一个新的组件的同时也会引入一个与之对应的观测工具。尽管保证了数据的全面性，但丢失了数据的关联性和分析排查的连贯性。如果有一个统一的数据平台，把所有数据放在一个平台，似乎就能解决关联性的问题。但实际情况往往是，建立了一个观测指标、日志、链路的统一平台，数据堆在了一个地方，用的时候还是按传统的方式各看各的，关联性还得靠人的知识和经验。因此，可观测性能力的构建，最关键的其实是解决数据统一和关联的问题：把之前需要人去比对、过滤的事交给程序去处理，人的时间更多的用在判断和决策上。
中国信通院《可观测性技术发展白皮书》指出， 可观测平台能力的构建，需要具备统一数据模型、统一数据处理、统一数据分析、数据编排、数据展示的能力?。
那么，如何做数据统一和关联呢？
在统一数据平台上，由于数据是来自于各种观测工具的，虽然在数据格式上统一了，但不同工具的元数据截然不同。如果在统一数据平台上去梳理和映射这些元数据，将是庞杂、难维护、不可持续的。
那么该如何做呢？答案就是标准化。
6.1.1 标准化现状
只有将标准化、结构化的数据喂给观测平台，观测平台才能从中发现巨大价值。统一数据平台只是在数据格式上进行了标准化，而要想将数据关联还必须建立context的标准化，context就是数据的空间信息，再叠加上时间信息的关联就可以发挥真正的观测价值。
目前，CNCF为了统一这一乱象，推出了Open Telemetry（遥测）以期实现理想状态下的大一统：统一Logs、Trace、Metrics三种数据协议标准，使用一个Agent完成所有可观测性数据的采集和传输，适配众多云厂商，兼容CNCF上众多的开源与商业项目。
可以说Open Telemetry（遥测）是一套与平台无关、与厂商无关、与语言无关的追踪协议规范，意在让链路追踪可观测更加规范化。
但遗憾是，至今未有厂商或开源项目可以统一Open Telemetry后端，三种数据源的统一存储、展示与关联分析仍面临极大挑战，而解决以上问题的前提，仍然是统一数据源（数据格式）。总的来说，云原生可观测性方兴未艾，因为云原生的应用系统趋于规模化和复杂化，越是复杂的庞大机器越是会强调其可靠性和稳定性。未来，云原生可观测未来需要一个大一统的可落地产品，通过统一的标准汇聚三者的数据，挖掘交叉区域的价值。
6.2 可观测性实施路径
为了实现可观测性，您需要对系统和应?程序进?适当的?具来收集适当的遥测数据。您可以通过构建??的?具、使?开源软件或购买商业可观测性解决?案来制作可观测系统。在运维过程中可观测性是核心基础，如果无法了解系统状态，运维动作就无从发起。因此， 阶段一：可观测性阶段是运维的基础阶段?，在有健全的可观测性数据后才能结合大数据和人工智能来辅助运维，到达 阶段二 AIOPS 阶段即智能运维。
6.2.1 可观测性阶段建设
可以粗略将下四层（数据源、数据采集层、数据存储层、数据处理、应用与展示层）定义为可观测性阶段需要建设的内容，也是当前大多数企业正在实践的部分。
6.2.1.1 数据源
可观测的数据源大致分为三类，硬件、操作系统与网络以及软件。硬件如服务器的硬盘、电源、风扇和主板等；网络设备如交换机、路由器和网关等设备；安全设备如防火墙；机房设施如空调、电力等；这些硬件在运行时都会产生状态数据。操作系统其实也是一种软件，由于其特殊性这里将其单独归类，操作系统内会有 CPU、内存、存储相关的使用和状态数据，操作系统间会有通信的网络数据。应用软件是为了某种特定的用途而被开发的软件，他们是核心要保障稳定对象，特别是业务应用。
无论是硬件、操作系统还是应用软件，在云原生场景下都会为容器云提供资源或使用容器云的资源，这也是我们在云原生最佳七步实践要第一步就进行建设容器云的原因。
6.2.1.2 数据采集
在了解数据源后，对数据进行分析总结出三种独立的数据类型，他们分别从三个不同的维度来展示应用的状态，这三种数据类型分别是日志数据（Logging）、链路数据（Tracing）和指标数据（Metric）
日志是记录了发生在运行中的操作系统或其他软件中的事件。常见于事件日志、事物日志、消息日志等，而与可观测性相关主要就是事件日志。事件日志（Event logs）记录了在系统运行期间发生的事件，以便于了解系统活动和诊断问题。它对于了解复杂系统的活动轨迹至关重要，尤其是只有很少用户交互的应用程序（例如服务器应用程序）。常用的采集数据的方式有代理和埋点 2 种方式。
6.2.1.2.1 日志数据采集技术
常见的日志采集技术包含有：Filebeat，Fluentd，Fluent Bit，LogStash，Promtai，Vector，Mtail，Flume等，目前在 CNCF 推荐的 Fluentd是日志采集工具，也可以选择许多企业正在采用 Filebeat 和 Logstash。由网易开源的、目前已经是 CNCF 沙盒项目的 Loggie，由于其专为云原生场景设计，具有不错的发展潜力。常用的日志数据采集组合技术是 ELK（elasticsearch、logstash、kinbana）。
CNCF内容地址：Cloud Native Landscape (cncf.io)
6.2.1.2.2 链路追踪技术
链路追踪即调用链监控，特点是通过记录多个在请求间跨服务完成的逻辑请求信息，帮助开发人员优化性能和进行问题追踪。链路追踪可以捕获每个请求遇到的异常和错误，以及即时信息和有价值的数据。
CNCF内容地址：Cloud Native Landscape (cncf.io)
链路追踪的技术选型CNCF推荐使用的是FJaeger，也有很多企业选择 SkyWalking 或 Zipkin。
6.2.1.2.3 指标数据技术
指标数据是应用程序运行时产生的内部指标，以 API 接口的方式提供查询。指标数据具有时间的特性，不同的时间点的指标是不同的，因此用以存储指标数据的数据库一般称为时序列数据库。
CNCF内容地址：Cloud Native Landscape (cncf.io)
?
Prometheus 是指标数据的集大成者，是云原生场景下的不二选择。?指标数据的采集可由 Prometheus 直接采集应用（如请求 /metrics 接口），或由应用的 Exporter 间接采集。
6.2.1.2.4 CNCF采集标准组件OpenTelemetry
介绍可观测性还有一个无法绕开的话题就是 OpenTelemetry，OpenTelemetry 目标是将以上三个维度的数据格式进行标准化范 。OpenTelemetry 是一组 API、SDK、工具和集成，旨在创建和管理遥测数据，例如Trace、Metrics和Logs。该项目提供了一个与供应商无关的实现，可以将其配置为将遥测数据发送到您选择的后端。它支持各种流行的开源项目，包括 Jaeger 和 Prometheus｡ 主要解决的问题是观测性领域模型的统一，观测性数据收集的统一，观测性数据输出的统一。这些统一性主要体现在 API 规范，SDK 实现规范，接口规范等。OpenTelemetry 不会负责观测数据的存储，需要存储这些观测数据的 backend。OpenTelemetry 定义数据输出的规范，由各大厂商自行完成数据的持久化。
6.2.1.3 数据存储
采集到的数据需要进行一定的处理并进行存储保存，为下一步的数据应用和展示提供数据基础。
这里存储有 3 层含义，第一个是对采集的原始数据进行存储，第二个是对计算后的数据进行存储。第三个是有时我们会对原始数据进行暂存处理，比如暂存在 kafka 中。
6.2.1.3.1 数据存储技术
6.2.1.3.1.1 关系型数据库
关系型数据库推荐MySQL、PostgrSQL。
6.2.1.3.1.2 时序数据库
时序数据库推荐InfluxDB、OpenTSDB、TimescaleDB。
6.2.1.3.1.3 大数据常见数据库
面对大数据场景，可选Elasticsearch、MongoDB、ClickHouse、HBase、Hadoop等。
一般场景日志数据和链路追踪数据存储推荐使用 ElasticSearch，在大规模日志采集场景下可以添加 Kafka 作为缓冲。对需要进行大数据分析等场景时，也可以选择 HDFS/HBase 存储。
对于指标数据推荐使用 Prometheus 存储?（Prometheus 本身也实现了 TSDB 数据库），但是原生的 TSDB 对于大数据量的保存及查询支持不太友好，该数据库不能保证可靠性，且无法支持 Prometheus 集群架构。 而 Thanos 和 Cortex 都是在数据可靠性和集群高可用方面进行了优化增强 ，目前都是 CNCF 孵化中的项目，也是不错的选择。在大规模场景下还可以选择 openTSDB 或 Clickhouse 来进行指标数据存储。
6.2.1.4 数据处理
又可以叫数据计算处理，对采集到的原始数据进行各种纬度的计算处理，得到我们想要的一些监控指标数据。比如对于一些业务指标的计算，今天新增用户的数、7 天新增用户数、7 天某页面的 UV 等等数据指标。
6.2.1.4.1 数据处理技术
一般需要自己开发程序来进行数据处理，简单的指标计算可以通过 SQL 来进行统计。数据量比较大统计实时性高，可以使用 Storm，Spark、Flink 等大数据计算框架来进行计算统计。
6.2.1.5 应用与展示
应用与展示层是可观测性的最上层，是对采集数据的基础应用，也是当前企业主要的应用场景。
将复杂的数据以图或表形式展示出来，便于运维人员快速了解应用状态，基于经验做出判断或预测。
6.2.1.5.1 应用技术
对于日志数据和链路追踪数据的查看可以通过 Kibana 查看，对于指标数据推荐使用 Prometheus 进行展示?，也可以使用原生的Grafana、Thanos 或 Cortex 查看。
服务拓扑是通过数据流向和调用关系，以 UI 的方式将服务依赖关系拓扑呈现出来。实际业务中，应用之间的关联与依赖非常复杂，需要通过全局视角检查具体的局部异常。可以在服务拓扑查看应用在指定时间内的调用及其性能状况。
监控告警是最常用的场景，也是目前建设可观测系统的核心目标。监控告警通过事前配置好阈值，数据采集上来后通过计算与阈值比对，对于不符合规则要求的数据生成告警事件，通过告警渠道发送到目标设备，如邮箱、手机、企业IM等。推荐使用 Prometheus 生态中的 Alertmanager 进行告警通知，它能够满足大多数企业的告警需求。
对于可观测性数据的初级应用除以上几项外，有些企业还会尝试尽可能多的将三者的数据进行关联，使同一个应用不同维度的事件立体化的展示出来。如请求发生异常时，应用一般会将请求以日志的方式输出，调用链路也会上报调用异常，这两类数据可以通过 RquestID 或 TraceID 进行关联。
6.2.2 AIOPS 智能化阶段
将可观测性阶段成果+智能化层定义为 AIOPS要建设的内容。AIOPS 是将人工智能和大数据应用于运维的场景，辅助运维实现自动化、智能化，以达到无人值守亦能保证业务服务高效稳定运行的目的。
AIOPS 辅助运维的场景大致可以分为三大类：智能分析、智能决策和智能展示。
6.2.2.1 智能分析
智能分析是 AIOPS 的大脑，依托于大数据和人工智能技术对采集的日志、指标和链路数据进行分析，按需产生有价值的结果为智能决策和智能展示提供数据。
6.2.2.1.1 智能分析场景
智能分析的主要场景有 趋势预测、根因分析和推荐解决/优化方案。
6.2.2.1.1.1 趋势预测
趋势预测，预测可能会发生的事件。 例如可以根据磁盘空间增长率预测在多久之后磁盘空间会消耗殆尽；根据集群资源阶段情况分析集群资源水位波动，预测下个周期资源是否能够满足业务运行，以及是否是需要扩容还是缩容集群规模；
6.2.2.1.1.2 根因分析
根因分析，找到异常发生的根本原因 。
6.2.2.1.1.3 推荐解决/优化方案
推荐解决/优化方案，找到原因后还需要能够提供临时解决方案来解决问题。
6.2.2.2 智能决策
智能决策是建立在智能分析基础之上，同时依赖与之匹配的基础设施实现的为保证业务连续性、稳定性而做出的决策结论与自动化执行。智能决策的主要场景有智能决策和智能变更。
6.2.2.2.1 智能决策场景
6.2.2.2.1.1 智能决策
智能决策，根据分析得出结论并提供应对建议后，决策是否执行该建议。例如系统检测到一台服务器无法 ping 通，也没有在规定的时间上报数据，同机柜其他服务正常，其他维度数据......，分析判断出机器宕机的结论，建议重启机器；智能决策决定“重启机器”。
6.2.2.2.1.2 智能变更
智能变更 ，依托于基础设施的自动化对智能决策结果进行变更动作的执行。继续智能决策的机器宕机例子，在智能决策决定“重启机器”后，发起调用“重启机器”变更接口并传入相关参数后，智能变更系统通过相关手段如节点 Agent、SSH 或带外的方式对服务器进行重启，重启后机器恢复正常。
智能决策将智能分析的结果确定下来并执行，可以释放大量人力，妥妥的降本增效利器。但是，由于当前智能化系统本身的建设还不成熟，前期投入人力成本大，且在分析结论的准确性不高和决策执行自动化程度也不高时，可能会带来很多的工作量。
6.2.2.3 智能展示
智能展示支持将用户想要看到内容准备数据并以合适的方式展示。智能展示的场景主要由立体化观测、智慧大屏和智能客服。
6.2.2.3.1 智能展示场景
6.2.2.3.1.1 立体化观测
立体化观测 ，是对一个小目标的全方位微观观测。例如以一个应用为中心，观测他的运行环境、资源使用情况、代码方法执行情况、调用与被调用的请求情况等等，就像人体检一样全面。
6.2.2.3.1.2 智慧大屏
智慧大屏 ，是对一个大系统宏观展示。例如电商平台双11时的监控大屏，展示整体的状态、子系统运行状态、依赖的供应链状态等，状态的展示评估出一个健康程度。
6.2.2.3.1.3 智能客服
智能客服，可以将关键事件主动通知到目标接受人，或根据需要响应返回内容。在机器宕机例子中，可以考虑将机器宕机结论、建议重启机器、执行机器重启、机器重启成功恢复正常这些事件发送给运维人员，虽然不用运维人员主动参与但应该知情。同时，在运维人员问智能客服为什么机器会宕机时，智能客服能够准确回答原因，如“由于主版故障导致机器宕机，该主版处于维保期，建议联系厂家更换主板。”
AIOPS 目标是比较理想的，但目前并没有一套完整的技术栈来支撑该解决方案，大多数企业还停留在可观测性的基础应用阶段，期望不久的将来有新的技术或想法来促进 AIOPS 的发展。
6.2.2.4 人工智能技术
人工智能中以机器学习为例可以考虑 TensorFlow、PyTorch等。
以上第六部分内容介绍的可观测性建设方案内容，需要企业基于开源技术投入资源构建，往往需要投入大量成本和人力资源去搭建，且后期需要维护大量工程和基础设施，对于中小企业来说，可能不适用，接下来我们介绍下商业化产品。
七、商业化产品
7.1 IBM Instana
不做过多介绍，感兴趣可自行查阅官网。
官网地址：IBM Instana Observability
7.2 Azure Monitor
不做过多介绍，感兴趣可自行查阅官网。
官网地址：Azure Monitor - Modern Observability Tools | Microsoft Azure
7.3 Splunk
不做过多介绍，感兴趣可自行查阅官网。
官网地址：可观测性产品和解决方案 | Splunk
7.4 阿里ARMS
7.4.1 介绍
应用实时监控服务 ARMS，作为云原生可观测平台，应用实时监控服务 ARMS 包含前端监控、应用监控、云拨测等模块。覆盖浏览器、小程序、APP、分布式应用、容器等不同可观测环境与场景。帮助企业实现全栈性能监控与端到端追踪诊断。提高监控效率，压降运维工作量。
官网地址：ARMS全息排查功能，全新上线 (aliyun.com)
7.4.2 优势
7.4.2.1 端到端多场景覆盖
覆盖网络质量、Web 应用/小程序、后端应用、容器、云服务、基础设施等可观测场景
7.4.2.2 统一展现 & 多维分析
构建统一运维监控大盘提供多种模型快速进行瓶颈根因与根因分析
7.4.2.3 全链路调用链分析
完整的全样本全链路调用链追踪为故障定位提供详尽依据
7.4.2.4 智能告警
构建统一告警管理体系提供 AI 加持的告警管理与应急协同能力
7.4.2.5 开源开放
兼容 OpenTelemetry、Prometheus、Grafana 等开源标准
7.4.2.6 高可用 & 低成本
提供低消耗探针及高可用平台统一 GB 计费，压降监控成本消耗
7.4.3 适合场景
7.4.3.1 用户体验分析
针对 Web 应用、网站、小程序、APP应用进行性能监控与用户体验分析。对网络性能、页面性能、资源加载、JS 错误、ANR/崩溃/卡顿进行分析。
7.4.3.2 应用性能监控与诊断
针对 Java、PHP、Node.js等多语言、分布式、微服务应用进行性能监控与链路追踪。提供实时诊断、异常分析、日志分析、Arthas 诊断等多种诊断能力，快速进行根因分析。
7.4.3.3 云服务统一监控
针对多云的容器集群、云服务、自建服务的统一指标监控。覆盖系统层、多云、多集群、云服务、应用组件层（自建）、业务自定义等指标维度。提供各种云服务的数据源配置及预置大盘，实现各种可观测数据的统一展示。针对容器服务ACK、消息队列 Kafka 等主流云服务，提供 Grafana Pro 大盘，帮助运维进行更精细化指标观测。
7.4.3.4 统一监控大屏
针对多数据源进行统一管理，实现端到端的可观测数据统一展现
7.4.3.5 统一告警处理
针对多告警源进行统一管理，实现跨平台 、跨团队的应急协同。丰富的预置集成组件，覆盖阿里云日志服务SLS、Prometheus、ARMS、开源主流监控系统。支持短信、电话、钉钉、邮件、飞信等多种通知方式，同时也支持对接 Aone / Jira / PageDuty 等多种协同系统。
好了，本次分享就到这里，如果帮助到大家，欢迎大家点赞+关注+收藏，有疑问也欢迎大家评论留言！
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。 如若内容造成侵权/违法违规/事实不符，请联系我的编程经验分享网邮箱：veading@qq.com进行投诉反馈，一经查实，立即删除！