DevOps专题 |监控，可观测性与数据存储

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

不管监控，仍是可观测性，都是工程界的术语，并不是严格定义的概念。人们能够描述它，但很难定义它。因此本文不会纠结于这些名词之间的区别。

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

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

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

1、监控需求的产生

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

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

监控自己，不管是业界对监控的认知，监控工具/系统自身的能力，也在如下两个方向演进着：

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

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

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

2、可观测性的提出

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

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

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

• metrics
• logging
• tracing
• events

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

3、存储

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 的存储设计主要考虑

一、稀疏数据：tracing 数据一般是稀疏的，这一般有几个缘由

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

二、多维度查询：一般的解决思路

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

Events

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

它们一般意味着生产环境的变动。而故障，一般由于不恰当的变动引发。

对 events 的处理主要包括

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

总结

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

京东云监控具备实时展示监控数据变化及迅速报警等优点，可以知足平常业务监控管理和处理异常等场景。

目前京东云监控提供免费服务，点击【阅读】，了解更多关于京东云监控的内容。

欢迎点击“京东云”了解更多精彩内容