站在用户的角度思考问题，与客户深入沟通，找到丰满网站设计与丰满网站推广的解决方案，凭借多年的经验，让设计与互联网技术结合，创造个性化、用户体验好的作品，建站类型包括：成都做网站、网站建设、企业官网、英文网站、手机端网站、网站推广、主机域名、网络空间、企业邮箱。业务覆盖丰满地区。

对于DevOps而言，监控是其中重要的一环，上一次的专题内容中，我们与大家分享了 大型企业级监控系统的设计。今天我们将和大家从另一个角度进一步探讨互联网工程技术领域的监控设计(monitoring)：系统的可观测性(observerbality)。

无论监控，还是可观测性，都是工程界的术语，并非严格定义的概念。人们可以描述它，但很难定义它。所以本文不会纠结于这些名词之间的区别。

在实践中，所有这些概念/术语，目标都是增强工程师对于线上系统运行情况的了解。

对工程师而言，监控/可观测性工程存在的意义，是帮助工程师发现问题，定位问题，解决问题。

对系统自身而言，这些工作都是通过数据的采集/存储/分析，以及进一步迭代来完成。

一、监控需求的产生

当程序被交付，部署到生产环境，才是其生命周期中最长的部分的开始。人们需要了解生产环境是否一切正常，监控需求自然而然产生。

互联网发展过程中涌现大量监控相关的工具/系统，Ganlia, Zabbix, RRDTools, Graphite，各自在不同的层面为“是否正常”提供答案。

监控本身，无论是业界对监控的认知，监控工具/系统自身的能力，也在以下两个方向演进着：

1. 黑盒到白盒
2. 资源到业务

这个阶段监控的愿景是很明确的，如何落地则各显神通。

直到 Etsy 于 2011 年通过博客公开了他们的 监控实践，利用 StatsD（已开源），以非常简单统一的方式，实现资源/业务层面的数据采集/存储/分析。后来的监控系统，尤其是基于 metrics 的监控系统，大多受过 StatsD 的启发和影响。

二、可观测性的提出

互联网工程界，Twitter 应该是最早提出可观测性 的组织。在这系列文章中，Twitter 集中阐述了他们的可观测性技术栈，其中包括了 Zipkin，Google Dapper 的开源实现。

如前言所说，本文不纠结于几个名词之间的包含关系。

抛开这些名词的辩论，可观测性相对于过去监控，大的变化就是系统需要处理的数据，从 metrics 为主，扩展到了更广的领域。综合起来，大约有几类数据被看作是可观测性的支柱(pillar)

• metrics
• logging
• tracing
• events

因此，一个现代化的监控系统/可观测性工程系统，也就必须具备妥善存储以上几种数据的能力。

三、存储

Metrics

Metrics，通常是数值类型的时间序列数据。这类需求的存在如此广泛，以至于衍生了专门服务于这个目标的数据库子类，时间序列数据库，TSDB。

TSDB 经历了大约如下几个方面的重要演进

• 数据模型。描述信息从 metric naming 中剥离出来，形成 tag。现代的 tsdb 通常都已采用 tag 化的数据模型。
• 数据类型。从简单的数值记录，到为不同场景衍生出 gauge, counter, timer 等等更多的数据类型
• 索引结构。索引结构跟数据模型密切相关，在 tag 为主的现代 tsdb, 倒排索引已经是主流索引结构。
• 数据存储。从 rrdtool 写环形队列到文件的时代，到 OpenTSDB 这样自行编解码写入底层数据库，再到 Facebook 提出的时序数据压缩算法，通常会是若干种技术的综合使用，并且针对不同的数据类型采用不同方案

Metrics 存储，或者是 TSDB 的研究和演进，我们会有另外的文章专门介绍。

logging

logging 通常会是工程师定位生产环境问题最直接的手段。日志的处理大约在如下几个方面进行演进

• 集中存储/检索。使得工程师免于分别登陆机器查看日志之苦，日志被统一采集，集中存储于日志服务，并提供统一的检索服务。这个过程牵扯到例如日志格式统一，解析，结构化等等问题。
• 日志的监控。
• 原文中的关键字，例如 error, fatal 大概率意味着值得关注的错误产生
• 从日志中提取的 metrics，例如 access log 中携带的大量数据，都可以被提取成有用的信息。至于提取的手段，有的通过客户端在日志本地进行解析，有的在集中存储过程中进行解析。

tracing

随着互联网工程日渐复杂，尤其是微服务的风潮下，分布式 tracing 通常是理解系统，定位系统故障的最重要手段。

在存储层面，tracing 已经有相对明确的方案，无论是 OpenZipkin，还是 CNCF 的 Jaeger ，都提供几乎开箱即用的后端软件，其中当然包括存储。

Tracing 的存储设计主要考虑

1、稀疏数据：tracing 数据通常是稀疏的，这通常有几个原因

• 不同业务的 trace 路径通常不同，也就是 span 不同，因而稀疏
• 同种业务的 trace ，在不同内外部条件下，路径也不同。例如访问数据库，是否命中缓存，都会产生不同的 span 链
• 访问正常/异常的 trace ，产生不同 span

2、多维度查询：通常的解决思路

• 二级索引：在以 HBase, Cassandra 为基础的方案中比较常见
• 引入倒排索引，在二级索引方案无法满足全部查询请求时，可能会引入 Elasticsearch 辅助索引，提升查询灵活性

Events

同样是一个难以定义，但是很容易描述的术语。我们把，一次部署，一次配置变更，一次dns 切换，诸如此类的变更，称为事件。

它们通常意味着生产环境的变更。而故障，通常因为不恰当的变更引起。

对 events 的处理主要包括

• 集中存储 ：事件种类很多，较难归纳共同的查询纬度，所以倒排索引在这种无法事先确定查询纬度的场景下，是非常合适的存储结构
• Dashboard ： 以恰当的方式，把事件查询 /展示出来。上文提到 Etsy 的博客中，展示了很好的实践方法，使得工程师能够通过 dashboard ，非常轻松确认网站登陆失败，与登录模块部署事件之间的关系。

总结

现代的监控，或者可观测性工程，通常是对不同类型数据的采集/存储/分析。这些数据各有特点，因而存储也不存在银弹。通常是根据各自特点，独立设计存储方案，上层提供一个统一、综合的存储系统。

京东云监控具有实时展现监控数据变化及迅速报警等优势，能够满足日常业务监控管理和处理异常等场景。

目前京东云 监控提供免费服务，点击【 阅读 】，了解更多关于京东云监控的内容。
当前文章：DevOps专题|监控，可观测性与数据存储-创新互联
本文路径：http://kswsj.cn/article/dppjjd.html