成都做网站设广告推广接单平台

现代服务架构常常谈及三个性： 弹性，韧性，可观测性。今天且按下其他两性不表，着重聊一聊可观测性。本文就几个主题对可观测性展开讨论：

1. 可观测性是什么
2. 可观测性是必须的吗
3. 企业的可观测性落地 
4. 可观测性理念

可观测性是什么？

从概念上讲，可观测性的源自于控制论，即通过获取系统运行数据以推测系统运行状况，进而推断系统状态，进行系统诊断调整的过程和能力。如果要说清楚什么是可观测性，可以与其前辈，监控进行比较。

1. 可观测性描述的是系统，而非这个支持可观测性的平台或机制。这是迥异于传统监控的。传统的监控是由外而内的一个过程，传统的企业组织架构，常常会有相对独立的研发部门和运维部门。研发部门负责开发，运维部门负责实施，稳定性由运维部门负责，自然监控也由运维团队设置，这导致一个问题：研发部门开发设计的时候缺少对线上状态监控的考虑，导致运维团队缺乏有效的监控机制来监控系统，只能做一些系统表征的识别判断，进程端口是否存活，cpu内存是否过载等等，但伴随着越来越复杂的软件架构，特别是微服务架构的场景，简单的表征无法有效的反馈系统状态，传统监控力所不逮。而可观测性是个由内向外的过程，其不仅仅是一种观测机制，更强调是一种开发实施观念，即数据采集是由开发部门要保证的，埋点是常态，研发过程要保证关键数据应采尽采，而运维部门只是这些数据的使用者，甚至进一步弱化部门之间的隔阂，运维只提供可观测性的平台和工具，整个可观测性的采集，分析，稳定性的保证都是由研发部门负责的，运维团队逐步进化为SRE。
2. 传统监控缺乏对系统的诊断能力，其往往只能观察到问题的点，而无法将这些表象的问题关联，更遑论进行深入的问题分析。常常是一个故障导致告警风暴，关键告警信息隐藏在次生的告警中。可观测性依赖常规的可观测性三要素：Trace, Log, Metric进行信息关联，支持多维度的关联查询，甚至进行线上Profiling的采集，进行实时的系统状态分析。
3. 传统监控是由故障驱动的，缺乏预见性。监控所监控的对象，往往是基于经验的，经验之外的场景，只能由故障驱动补全。今日故障添加对inode数量的监控，明日故障添加对socket个数的监控。而为了保证稳定性，很多监控是基于预警设计的，阈值设置的很保守，导致经常性的触发。研发和运维疲于日常的告警排查，最终又没有发现什么问题，常常上演狼来了的故事。而可观测性的实施角度不再是某个指标，某个特征。而是通过指定的可观测性数据的采集，汇总。对这些数据分析进而判断是否真的有问题，是否应该报警。对于预见性的告警，通过定义SLO来识别是否是真的狼来了。
4. 监控是运行在系统层面，监控目标往往是服务，接口，链路等，是站在开发和运维的角度来观测分析。而可观测性强调监测业务，通过业务指标判断应用是否受损。

这里再系统的总结一下什么是可观测性：通过采集运行中的系统数据，包括：Trace，Log，Metric，乃至Event，DEM（Digital Experience Monitoring）信息，进行系统分析和诊断。其数据通过多维度的关联，以支持多种角度的展示和分析。空间上多维度数据关联，纵向上将主机，容器，进程等信息关联，横向上通过Trace进行调用关系关联。分析问题常常是通过受损的业务指标下钻系统组件，再通过各种关联，定位问题根因。

可观测性是必须的吗？

软件行业没有银弹，每钟技术都有其适用的场景，也会带来新的问题和挑战。如果一个系统结构简单，部署规模小，可能一个简单的监控就够用了。但如果期望稳定性达到三个9,四个9乃至五个9，那么可能就需要应用可观测性来进行更高的稳定性保证。尤其是当处于一个存量的市场竞争环境中，产品形态上又与对手没有拉开身位的优势，拼的就是产品的质量和稳定性。当系统复杂到一定程度的时候，其线上会出现故障不是偶然而是必然，这就必须要有一种机制来进行线上的系统监控和实时诊断，甚至能够进行运营分析，那就不得不使用可观测性，即使其会引入额外的开发复杂度，增加额外的开发周期。

稳定性保证是一个复杂的系统工程，投入很多的时候，不能像业务产品一样获取明显的收益效果，投入减少又可能会导致故障而产生巨大影响。当一个企业增长到一定程度，其不光对内有增长盈利的诉求，在资本市场上有市值管理的诉求，在社会上也有稳定可靠的民众诉求。我们已经看到过很多因为故障而导致市值暴跌，冲上热搜讨全民论的情况，其对一个企业的影响不可谓不大。而可观测性是进行系统稳定性保障工作的重要工具。如何进行可观测性评估，我觉得可以通过以下几个方面考虑：

1. 系统复杂性: 如果系统是分布式的或由多个微服务组成，具备了一定的复杂性，那么可观测性是非常重要的，因为它可以帮助理解系统的整体行为和各个组件之间的交互。
2. 业务需求: 如果业务对系统的可靠性和性能有高要求，即所谓的几个9，那么可观测性可以帮助快速识别和解决问题，减少停机时间。
3. 故障排查: 在系统出现问题时，是否能够快速定位和解决问题？是否还需要登陆线上机器定位？可观测性可以提供详细的诊断信息，帮助工程师更快地找到问题根源。
4. 性能优化: 是否需要持续监控和优化系统性能？全链路压测耗时长，效果差？可观测性可以提供实时的性能数据，帮助识别瓶颈和优化资源使用。
5. 用户体验: 用户体验是否受到系统性能的影响？可观测性对数字体验的监控，可以帮助了解用户交互的各个方面，确保提供最佳的用户体验。
6. 合规性和安全性: 是否需要满足特定的合规性要求或安全标准？可观测性可以帮助记录和审计系统活动，确保合规性。
7. 团队能力: 团队是否具备实施和维护可观测性系统的能力？需要考虑团队的技术水平和资源。
8. 成本效益: 实施可观测性是否具有成本效益？需要评估可观测性带来的价值与其实施和维护成本之间的平衡。

简而言之一句话，有条件上，没有条件，创造条件也要上。

企业的可观测性落地 

一个标准的可观测性平台，主要解决几个问题：

1. 数据的收集：采集和处理
2. 数据的存储：持久化落盘
3. 数据的分析：展示和告警等

所以进一步，可以拆分为几个组件：

1. 数据采集端，常见的技术包括SDK, Agent, 探针等，开源组件包括老派的zabbix, 新派的Prometheus exporter等
2. 数据处理，将采集到的数据进行清洗转换，和数据湖的数据处理过程有些类似，进行标准化和非标准化的数据转换。关键数据的聚合计算，告警生成等，常见的技术Apache Flink，Spark进行流式处理，Kafka进行数据传输等
3. 数据存储，常见的有列式存储的OLAP数据库，ClickHouse 、 Doris等，也有时序数据库：Prometheu 、 VictoriaMetrics等。也可能需要图数据库存储关联关系，包括: Neo4j 、 Amazon Neptune等
4. 数据可视化分析，将存储的结构化数据通过图表直观的展示分析。典型的开源组件：Grafana。一般将报警策略和通知也会相应的展示在页面中。
5. AI分析：运行中的系统的状态时刻的处于动态变化当中，故障的分析定位，告警的识别跟进靠人力依然不够及时，这就需要有AI帮助定位识别根因，进一步缩短故障实现，AIOps是大模型带给运维领域的变化。

一个企业是否要自建可观测性平台呢？通过上述的几个模块，我们可以知道一个可观测性平台已经是一个复杂的项目，如果企业有能力自建可观测平台，自然是一个最好的选择，因为通过第一节中什么是可观测性的讨论，我们已经知道要获取可观测性，需要很大程度的入侵现有代码，业务方需要埋点，需要引入SDK. 需要输出特征日志。当然这也和当前的系统情况有关：

1. 全量的采购三方服务，使用其提供的SDK, Agent进行数据采集。有一定的开发适配工作，但平台适配性好，接入过程比较顺滑。缺点是会与三方平台绑定。
2. 不一定需要大而全的采用外部系统，如果系统已经进行了数据采集工作，可以将数据对接三方平台，因为可观测的复杂度大多是在平台的数据处理存储分析上，而非数据的采集上。这要求系统使用标准的可观测性数据格式，包括OpenMetric, Opentelemetry等协议标准，与平台解耦，降低接入成本
3. 就使用现在的数据场景，要求外部平台非侵入性的进行数据采集。一定程度上也能做到，但数据的利用程度会降低。举一个简单的例子：多维度数据如何进行关联？最直观的是通过Trace ID进行关联，但非入侵的情况无法有效的插入和追踪Trace ID,，如果有过线程切换，调用链很难再被有效追踪。这就需要其他的关联信息，比如：实体关联，所有的数据都要关联到实体上，然后通过实体的关系确定数据的关联关系。时间关联，数据中的时间戳判断发生在同一时刻的数据具有关联关系等。其准确度都会有所降低。

不论是自研还是采购，可观测性平台都与其他系统有显著区别，其与开发的绑定之深，导致不论哪个选择都影响颇大。

可观测性理念

前面提到了可观测性选型，实现等方面，希望能让大家对可观测性有了一个初步的认识。最后一节再讨论下可观测性为什么是一种理念，其为研发流程，稳定性工程带来了什么变化。

1. 数据驱动决策：可观测性强调通过数据来驱动系统设计、开发、运维和优化，通过实时数据分析来做出的业务和技术决策，即所谓数据决策。

2. 全生命周期集成：可观测性应从开发阶段开始考虑，并贯穿于测试、部署和运维，在设计阶段就考虑如何采集和利用数据，以便在系统上线后能够有效监控和诊断。

3. 跨职能协作：打破开发和运维之间的壁垒，促进DevOps文化，研发团队负责数据埋点和采集，负责数据的使用和分析，运维团队提供平台。

4. 持续改进：通过可观测性数据不断评估和优化系统性能和稳定性，定期回顾和调整监控策略和告警阈值，以适应系统变化。

5. 用户体验优先：通过监控用户交互数据来确保最佳用户体验，识别和解决影响用户体验的问题。

6. 透明性和可见性: 提供系统内部状态的透明视图，帮助团队快速理解和响应问题, 确保所有相关人员都能访问和理解可观测性数据。

7. 平台将数据汇总，最终的数据为不同角色展示为不同的表达：

      a. 业务负责人关心业务指标的健康状况，比如电商的推广的成单量，出行应用的撮合成单量等，系统中的某个服务是否健康，其并不关心

      b. 具体服务的负责人则关心自己负责服务的健康情况，其TPS, 查询耗时等等状况

      c. 运维负责人则关系资源的使用情况, 系统是否过载等

8. 通过SLO识别告警是否有效，只有影响到SLO的告警是紧迫告警，避免狼来了的情况, 业务团队为SLO负责。通过SLO定义SLA，量化团队的稳定性程度。 

可观测性不仅仅是一种技术手段，更是一种稳定性保证的实施理念，其在CNCF的landspace中独占一席，可见其重要程度。落地引进的过程，对团队的组织架构，系统的落地实施，都会产生深远的影响。