近日，关于云平台自身的可靠性问题又成为大家关注的焦点。系统一定会有故障，相信作为用户都能理解，但用户需要在故障发生后，能尽快知晓造成故障的根本原因和修复计划，以便有效调整受影响的业务来降低损失；也需要在一次故障解决后，开发运维团队可以总结出经验教训，来提升自己管理运营能力，和提出之后的预防措施。过程中，最好有详细、准确和实时的数据作为佐证，使团队间的沟通无阻、协同高效，这就需要提到可观测性能力。
「观测云」guance.com 是一个可提供强大的系统可观测能力的 SaaS 平台，帮助用户确保他们的系统持续健康和稳定地运行。可作为一个 SaaS 平台，我们是如何构建自己的可观测性呢？观测云提供的可观测服务，能直接用来监测自己吗，还是需要用到其他更厉害的工具，或是更复杂的方法？
对观测云节点的整体自监测方案
有句话是神医难自医，当医生自己生病了，只能找另一个医生来治疗自己。监测平台对自身的监测亦是如此，因为自身已在功能故障的情况下，无法确保可对自身实施有效的故障诊断和修复。
「观测云」的自监测解决方案，利用了本身多站点的特性，实现不同站点间的互相监测。「观测云」目前有中国区1（杭州）、中国区2（宁夏）、中国区3（张家口）、中国区4（广州）四个国内 SaaS 服务节点，以及一个海外1（俄勒冈）节点，互相作为对方的观测平台。
可用性监测
可用性监测是指站点、API 等在不同地域、不同运营商网络下的定时拨测，观测云的可用性监测支持国内四大地域（华北、华东、西南、西北）、三大网络运营商网络（移动、电信、联通）的 12 个节点，以及四个海外节点。
对于观测云自身，我们**从三个维度进行可用性监测：URL、地域、网络运营商。**可用性监测的目的是监控我们的站点或 API URL 在不同地域及网络运营商下的可用性及响应延时情况，但是由于不同网络运营商可能存在的网络波动，因此我们需要考虑一个容差，我们的最佳实践是某个 URL 在某个地域的网络运营商下，15 分钟内超过 3 次不可用，视为此 URL 不可用，需要进行告警。实际可以根据业务的需要来进行最佳实践配置监测。
监测告警
监测的告警根据重要级别分为两级，第一级是通过钉钉群通知告警，如发生错误日志、错误链路等，第二级是比如基础设施的不可用等重要监控（比如磁盘剩余过小、数据库等中间件的不可用等）还需要对相关人进行短信通知，第二级问题的响应度需要更高。
平台业务指标监测
平台业务指标，主要包括每一项数据的增量、工作空间维度的数据增量、活跃程度等等统计指标数据。这些业务指标既不是数据库等各种标准中间件，也不是业务服务自身可以吐露出来的指标，需要自己编程去各种业务数据存储中去定时统计采集出来，以指标或日志的形式打到观测云平台中，我们是利用 Function 数据处理平台来实现的。说明页：func.guance.com。
- 使用 Function 平台接入业务指标数据架构：
- 业务看板效果：
各个业务服务状态监测
常见的基础设施及标准中间件等组件，可以直接采集其指标及日志等数据；各业务服务自身的指标，需要服务自身来暴露指标，一般都遵循 OpenMetrics 标准。OpenMetrics 是一种云原生下的高度可扩展指标协议，它定义了大规模上报云原生指标的事实标准，同时支持文本表示协议和 Protocol Buffers 协议，它也是云原生下的事实标准监控方案 Prometheus 的标准数据采集方案，使用观测云的采集器 DataKit 也可以直接采集，或者对接 Prometheus 获取数据。
- 任务调度服务，我们需要重点关注 任务队列排队任务数、任务调度总数等指标
- 数据的接收、预处理、写入存储、查询服务，我们需要重点关注的是 查询响应时间、写入响应时间、写入错误数、数据队列中的待写入数量等指标
- 用户平台后端，我们需要重点关注当前在线用户数、每个工作空间活跃用户、Redis 用量等指标
每个服务暴露了自身的指标后，需要配置应用的服务指标仪表板，这里的一大原则是服务暴露的指标可以尽量多，仪表板可以只展示最重要的指标，一个仪表板上指标过多，会让看的人抓不到重点。其余的可以作为监控指标，去配置监控项。
以观测云的数据服务 Kodo 为例，它的服务指标观测仪表板：
问题汇总和 SLO
「观测云」内部的各开发和运维团队，可通过仪表板获得多维度的数据汇聚展示，即可将前端收集到的所有需关注事件、告警、或报错都汇总到同一个仪表板上，做到一目了然，不必在各个不同的仪表板，甚至不同监测工具间频繁切换。当需要定位一个具体的报错来源时，通过点击该报错条目在仪表板上的关联链接，即可下钻到对应的数据查看器，展示出相关联的上下文数据条目，每个条目又可以再次下钻出更多细节，所以能很快挖掘到故障根因。
- 观测云的问题汇总仪表版如下：
- 各维度问题统计仪表板：
当前阶段的系统运行状态，会通过 SLO 信息同步给所有团队。SLO 是对 SLI 的一个度量，用来度量产品的服务质量情况。SLI 是一个比较复杂的定义过程，需要根据不同服务场景以及服务等级需求来定义，最基本的是基于可用性的定义，比如站点 URL 拨测达到不可用次数、链路或日志的错误率达到一个比值（我们定义的是错误率达到 0.05%）。SLI 标准的定义一般可以从系统的性能、可用性、服务质量等几方面来考虑，实际应用中的 SLI 度量值需要根据实际业务来调整实践。
- SLO 仪表板：
结语
观测云的使命是「向全球用户提供最好的可观测性服务」，希望通过这篇对自身可观测性构建的简述，为更多用户提供借鉴，有任何想法和建议欢迎在留言区内或加入社群讨论。
