概述

云计算发展到今天，云以及云原生都已经日渐发展成熟，基于云原生的软件系统复杂度越来越高，传统的监控软件已经无法满足云原生时代下的软件监控需求，由此在计算机领域也发展出一个新兴的概念：可观测性（Observability）。可观测性在工业领域中已经是一个发展了几十年的成熟概念，但是在计算机领域还是一个比较新兴的概念。
基于对系统的可观测性的重要性，我们推出了云时代的系统可观测产品 - “观测云”，旨在解决云计算以及云原生时代系统为每一个完整的应用构建全链路的可观测性的云服务平台。“观测云”是由驻云科技自 2018 年以来全力打造的产品，产品的目标是为中国的广大基于云计算的开发项目组提供服务，相较于复杂多变的开源产品，如ELK，Prometheus，Grafana，Skywalking 等，“观测云”不单纯的只是提供一种监控类的产品，更重要的是提供整体的可观测性服务，我们除了在底层存储和系统架构上是一体化的基础上，也把所有关于云计算及云原生相关的技术栈进行了完整的分析和解构，任何项目团队可以非常轻松的使用我们的产品，无需再投入太多的精力去研究或者改造不成熟的开源产品，同时“观测云”是以服务方式，按需按量的方式收取费用，完全根据用户产生的数据量收取费用，无需投入硬件，同时对于付费客户，我们还会建立专业的服务团队，帮助客户构建基于数据的核心保障体系。

观测云自身的可观测

“观测云”是提供给广大互联网用户的系统可观测平台，为用户提供强大的系统可观测服务，保障用户系统的持续健康稳定运行。那么在保障用户系统的持续健康稳定运行的同时，我们观测云平台自身如何保障自身的稳定，持续为用户提供可观测服务？
有句话是神医难自医，神医自己遇到事可以找谁？只能找另一个神医。监控平台自身的监控也是如此，如果监控平台自身出了问题，又怎么去保障业务系统的持续稳定运行呢？
另一方面，如果使用观测平台对平台自身实施自观测，必然会造成一个观测数据的自迭代。什么是自迭代？就是要完成对平台进行观测这个动作本身就会产生各种日志、链路等数据，要采集、处理这些数据本身又产生了大量数据。所以自观测本身是一个不太经济的做法。
我们“观测云”平台目前有“中国区1（杭州）”、“中国区2（宁夏）”两个国内 SaaS 服务节点，以及一个“海外1（俄勒冈）”节点，正好可以互相作为对方的观测平台。
中国区1（杭州）节点地址：https://console.guance.com
中国区2（宁夏）节点地址：https://aws-console.guance.com
海外区1（俄勒冈）节点地址：https://us1-console.guance.com

观测数据的采集

观测云平台的部署架构

观测云平台是云原生的微服务架构，部署上完全基于云原生的 Kubernetes 底座。我们的观测云也有一套完整的云原生平台可观测解决方案。

如何进行数据接入

与传统的监控方案相比，我们观测云 SaaS 的不仅接入方便、快速，基本上只要一个 DataKit 就可以完成你所有的观测数据的接入。杭州节点、宁夏节点都可以免费注册使用，对于上规模的客户，计费价格上也十分灵活，完全按需付费，功能免费，根据用户接入的数据量来付费。
观测的基础是数据，那么如何接入数据？主要有几种方式：
1、在宿主机上安装 DataKit，参考如何在宿主机上安装 DataKit
2、在 Kubernetes 集群 DaemonSet 方式部署 DataKit，参考如何 DaemonSet 安装 DataKit
3、使用 Func 平台采集业务相关数据，再通过 DataKit 接入到观测云。 DataKit 支持大量的标准技术栈数据的采集，但是对于业务数据等标准 DataKit 无法采集的数据，可以通过我们的可编程平台 Func 来编程采集，参考如何快速开始 Func 平台

数据接入架构图如下：
观测云平台自身观测实践方案 - 图1

采集哪些观测数据

可观测的三大支柱信号有指标、日志、链路。系统的可观测基本都是围绕这三大类信号数据展开。对一个系统的可观测实施，我们需要去采集这个系统的这些信号数据，然后对信号数据进行可视化分析与监控等来实现对系统的高可靠性与健康的运行保障。
观测云平台，对于以上三大观测信号，我们可以去采集哪些数据？

1. 基础设施

基础设施主要是主机、容器、进程几大类的对象数据以及这些对象的指标数据，这部分数据的采集十分简单傻瓜式，安装好采集器 DataKit 之后，默认就开启了这些数据的采集。
如果是云主机，可以开启云属性的采集，DataKit 默认会带上主机的云属性，可参考如何开启云主机的云属性同步，采集的信息可在主机详情中查看：

对于使用 Kubernetes 部署的应用服务接入观测，推荐使用 DaemonSet 方式安装 DataKit。

2. 日志 Log

日志是可观测的一大重点，可观测的三大支柱中，指标和链路更多的是告诉你哪里出了问题，或者辅助你定位系统问题，好的日志输出能最直接的告诉你发生问题的原因。
当然，这个需要应用服务自身能合理规范的输出日志，这个涉及到系统架构层面的日志规范，具体不展开说，可以参考我们的如何设计日志内容一文，这也是我们在自身可观测实践过程的一个总结。
我们的 DataKit 采集器支持多种日志采集方式：
1、采集磁盘文件日志的 tailf 方式
2、云原生 Sidecar 方式 logfwd 采集
3、云原生容器 Annotation 方式采集 stdout 日志
4、远程推送日志到 DataKit 的方式，比如使用 fluentd、logstash 以及像 log4j 等日志框架支持的 HTTP 方式直接推送日志
我们的观测云在实践中主要使用第三种采集方式，应用服务将自身的日志输出到 stdout，然后在 Kubernetes 的 Deployment 在添加 Annotations 来开启日志的采集，Annotation 的 Key 固定为 datakit/logs，Value 配置如下 JSON：

[
  {
    "source": "front-backend",
    "service": "front-backend",
    "pipeline": "py.p"
  }
]

JSON 中的 pipeline 字段，配置了日志字段切割提取的 pipeline 文件。
这种日志采集方式，我们是通过 Docker 的日志接口来同步 stdout 日志的，对于使用 containerd 的新版本Kubernetes 不适用，所以云原生的应用，我们推荐使用第二种方式，使用 logfwd 采集云原生容器日志。

3. 应用性能监测 APM

观测支持多种 OpenTracing 开源采集方案接入，如 SkyWalking、Jaeger、 ZipKin、DDtrace 等，用户侧使用不同的技术栈的应用服务，可以选择合适的 OpenTracing 框架接入。我们观测云平台，使用了多种技术栈：golang、Python、nodejs 等，使用 DDtrace 作为链路采集框架方案，接入需要根据服务使用的语言选择不同的 DDtrace agent，将 agent 一起打包在各个服务镜像中，在启动时可以注入 DDtrace 环境变量的方式来配置链路的采集，减少对应用服务代码的耦合。

4. 用户访问监测 RUM

用户访问监测 RUM，主要是监测 Web 端、移动端、小程序端等各种客户端的用户访问数据，如页面性能、资源加载耗时、前端错误信息等数据，通过分析这些用户访问的数据，可以直观的观测到用户在访问您的站点时的用户体验情况，甚至分析您的站点用户跳失率等数据。
我们观测云支持 Web、移动、小程序等各种客户端的接入 SDK，我们观测云自身主要接入是用户平台 Web 端 Studio，只需要在 Web 框架页面中引入RUM 的 web SDK，再加一些简单的配置即完成了 RUM 数据的采集接入，对源站点无代码侵入：

<script
src="https://static.dataflux.cn/browser-sdk/v2/dataflux-rum.js" 
type="text/javascript"
></script>
<script>
  window.DATAFLUX_RUM &&
  window.DATAFLUX_RUM.init({
  applicationId: '<DATAFLUX_APPLICATION_ID>',
  datakitOrigin: '<DATAKIT ORIGIN>',
  env: 'production',
  version: '1.0.0',
  trackInteractions: true,
})
</script>

详细可以参考我们的 RUM 手册 Web 应用接入，需要注意的是需要一个 datakitOrigin，这个是需要在用户侧部署一个我们的 DataKit，用户站点的 RUM 数据通过这个 DataKit 上报到观测云中心，数据流程大致如下：
观测云平台自身观测实践方案 - 图3

5. 各种数据库及中间件指标

观测云主要使用的几大数据库中间件：Elasticsearch、InfluxDB、MySQL、Redis、NSQ 等。
DataKit 支持以上所有的中间件指标采集。数据库中间件的指标采集与其他日志、主机对象指标等的采集不同，这些指标是通过定时调用各个中间件的 API 获取指标，所以 Daemonset 方式部署的 DataKit 在配置这些中间件采集时，需要保证同一时刻只有一个 DataKit 在运行这些中间件的数据采集，为此，我们的 DataKit 支持选举功能，开启选举功能后会自动在一个 Group 中选出一个作为远程采集的 DataKit，不会每个 DataKit 都去采集一遍而造成重复采集，参考 DataKit 选举支持。

6. 应用服务自身指标

除了以上几项观测云标准支持对象、日志、链路、用户访问监测以及各种数据库及中间件的指标采集之外，我们还需要各种服务自身的业务等指标，服务的业务指标需要服务的开发者自己设计及提供云原生的 OpenMetrics 接口暴露指标，我们 DataKit 支持 Prometheus 的集成接入，参考 Prometheus Exportor 数据采集。
服务服务自身可以暴露些什么指标？比如：
任务调度服务，我们需要重点关注 任务队列排队任务数、任务调度总数等指标
数据的接收、预处理、写入存储、查询服务，我们需要重点关注的是 查询响应时间、写入响应时间、写入错误数、数据队列中的待写入数量等指标
用户平台后端，我们需要重点关注当前在线用户数、每个工作空间活跃用户、Redis 用量等指标
每个服务暴露了自身的指标后，需要配置应用的服务指标仪表板，这里的一大原则是服务暴露的指标可以尽量多，仪表板可以只展示最重要的指标，一个仪表板上指标过多，会让看的人抓不到重点。其余的可以作为监控指标，去配置监控项。

7. 关联用户访问监测、应用服务链路及日志数据

对于以上采集的各类数据，我们可以通过统一增加全局 Tag，以及自带的一些默认 Tag 等实现数据之间的关联，但这些颗粒度比较粗，对于业务分析以及统一监控上还是不够，因此我们需要将 RUM、APM、Log 等数据进行更细粒度的关联，观测云的最佳实践是通过 trace_id 来将数据进行有机关联，从用户访问 RUM 开始生成 trace_id，到后端服务 APM 以及 Log 的输出都带上统一的 trace_id。
详细可以参考我们的最佳实践方案 RUM-APM-LOG 联动分析，方案以 Java 应用为示例讲解。

其他的健康监测

1. 可用性监测

可用性监测是指站点、API 等在不同地域、不同运营商网络下的定时拨测，我们观测云的可用性监测支持国内四大地域(华北、华东、西南、西北)、三大网络运营商网络（移动、电信、联通）的 12 个节点，以及四个海外节点。
可以定时去拨测您的站点或 API 在不同地域或不同网络运营商的可用性以及延时大小等数据。
对于我们观测云自身，开启了前后台 URL、后端 API 地址、数据网关等的拨测。

2. 安全巡检

安全巡检是一种新型安全的系统安全巡检方案，所有的巡检脚本在可控的范围中运行，避免像直接使用 Shell 写巡检脚本的严重不安全行为。观测云的安全巡功能检提供海量的可更新的规则库脚本，包括系统、容器、网络、安全等一系列的巡检，并且一直在更新增加中。
可参考文档安全巡检如何安装、如何配置。

数据的可视化分析

1. 基础设施仪表板

观测云内置了大量的主机、容器、各种数据库中间件的即开仪表板，完成上述数据的采集后，直接创建这些即开型仪表板，即可快速完成这些指标数据的可视化。

我们观测云平台相关的几个基础设施仪表版：

2. 各个业务服务指标仪表板

常见的基础设施及标准中间件等组件，我们都支持直接采集其指标及日志等数据，但是各自业务服务自身的指标，需要服务自身来暴露指标，比如数据IO、工作队列繁忙程度、任务处理量、接口错误率、平均查询响应时间等服务指标需要业务服务自身吐露出来。
OpenMetrics 是一种云原生下的高度可扩展指标协议，它定义了大规模上报云原生指标的事实标准，同时支持文本表示协议和Protocol Buffers协议，它也是云原生下的事实标准监控方案 Prometheus 的标准数据采集方案。
我们的 DataKit 支持直接使用 Prometheus 接入数据，可参考文档：Prometheus Exportor 数据采集。
以观测云的数据服务 Kodo 为例，它的服务指标观测仪表板：

3. 平台业务指标仪表板

平台业务指标，采集了平台所有的主要指标，主要包括每一项数据的增量、工作空间维度的数据增量、活跃程度等等统计指标数据。
业务指标数据如何采集？业务指标即不是数据库等各种标准中间件，也不是业务服务自身可以吐露出来的指标，需要自己编程去各种业务数据存储中去定时统计采集出来，以指标或日志的形式打到观测云平台中。
那么如何实现这些业务指标数据的采集？可以利用我们的 Function 数据处理平台轻松实现。如何使用 Function 平台可以参考文档 Function 数据处理平台官网。
使用 Function 平台接入业务指标数据架构：
观测云平台自身观测实践方案 - 图7
如下是我们观测云平台的部分指标仪表展示：

从我们的指标中可以近 7 日 13 亿的 Trace 增量、63 亿的日志增量，可以体现出我们观测云的强大能力，当然能力远不止如此。

4. 问题汇总仪表板

问题汇总仪表板，是基于上述所有采集的数据配置的所有有错误的数据的汇总展示，将所有的错误数据或者有问题的数据或者是需要重点关注的问题数据都汇总到一个仪表板，方便随时关注，不需要一个个查看器去找问题数据。
观测云的问题汇总仪表版如下：

对采集的数据进行监控

以上采集的数据包含了指标（各种基础设施与中间件等的指标）、日志（所有应用服务、系统及中间件的日志）、链路（所有应用服务的链路数据）三大可观测支柱信号，这些信号数据中已经包含了 Google 的 SRE 工程小组定义的监控四大黄金信号：延迟（Latency），流量（Traffic），错误（Errors）和饱和度（Saturation）。

1. 监控项

基于以上的指导思想，我们可以构建出一个完整的监控体系，主要分为以下几大类的监控项：

基础设施类监控：主机、MySQL、Elasticsearch、Redis、InfluxDB 等的基础监控（CPU、内存、磁盘容量等）
错误日志监控：基于日志数据构建的错误日志检测

要做好日志监控，一定要做好日志规范，至少做到以下两点：合理的日志 Level 定义、采集上来的日志要对 Level 进行切割提取 Tag。

错误链路监控：基于链路数据构建的错误链路检测

主要检测 HTTP Status Code 为 5xx 的错误链路，因为 4xx 的 Code 基本是一些 Warning 一类的，不需要重点监控告警，比如用户访问一个不存在的资源，会产生一个 404 错误，这个不是服务代码中可以避免的。

可用性监控：基于可用性监测产生的拨测结果做检测

我们对三个维度进行可用性监控：URL、地域、网络运营商，可用性监控的目的是监控我们的站点或API URL在不同地域及网络运营商下的可用性及响应延时情况，但是由于不同网络运营商可能存在的网络波动，因此我们需要考虑一个容差，我们的最佳实践是某个 URL 在某个地域的网络运营商下，15 分钟内超过 3 次不可用，视为此 URL 不可用，需要进行告警。
实际可以根据业务的需要来进行最佳实践配置监控。

2. 监控告警

监控的告警根据重要级别分为两级，第一级是通过钉钉群通知告警，如发生错误日志、错误链路等，第二级是比如基础设施的不可用等重要监控（比如磁盘剩余过小、数据库等中间件的不可用等）还需要对相关人进行短信通知，第二级问题的响应度需要更高。

3. SLO

SLO 是对 SLI 的一个度量，用来度量产品的服务质量情况。SLI 是一个比较复杂的定义过程，需要根据不同服务场景以及服务等级需求来定义，最基本的是基于可用性的定义，比如站点 URL 拨测达到不可用次数、链路或日志的错误率达到一个比值（我们定义的是错误率达到 0.05%）；某1分钟的监控指标达到目标的定义值，就表示这1分钟 SLO 未达标，属于 downtime，需要扣除这 1 分钟的服务可用时间；某个中间件或某个重要核心组件的不可用等也可以作为 downtime。
SLI 标准的定义一般可以从系统的性能、可用性、服务质量等几方面来考虑，实际应用中的 SLI 度量值需要根据实际业务来调整实践。

笔记本功能的最佳使用实践

观测云的笔记本功能是一个辅助你更好的实践可观测的一个工具，比如用于可观测实施问题记录、系统观测问题跟踪记录等。

1. 可观测搭建问题笔记

主要用于记录一些可观测实施过程或者后期维护中的一些操作记录，比如变更了日志的采集方式，需要记录下当时的操作时间、操作人、操作内容等记录，以便后续对问题回溯，以及一些可观测经验的输出。

2. 日常巡检与生产问题的跟踪记录

主要是用于记录日常巡检或者监控告警到的问题的一个跟踪记录，某些问题的解决需要一些时间过程，可以在笔记中记录下问题，由专人去跟踪问题的解决情况。