|
对于 DevOps 而言，监控是其中重要的一环，上一次的专题内容中，我们与大家分享了大型企业级监控系统的设计。今天我们将和大家从另一个角度进一步探讨互联网工程技术领域的监控设计(monitoring)：系统的可观测性(observerbality)。
无论监控，还是可观测性，都是工程界的术语，并非严格定义的概念。人们可以描述它，但很难定义它。所以本文不会纠结于这些名词之间的区别。
在实践中，所有这些概念/术语，目标都是增强工程师对于线上系统运行情况的了解。
对工程师而言，监控/可观测性工程存在的意义，是帮助工程师发现问题，定位问题，解决问题。
对系统自身而言，这些工作都是通过数据的采集/存储/分析，以及进一步迭代来完成。
一、监控需求的产生
当程序被交付，部署到生产环境，才是其生命周期中最长的部分的开始。人们需要了解生产环境是否一切正常，监控需求自然而然产生。
互联网发展过程中涌现大量监控相关的工具/系统，Ganlia, Zabbix, RRDTools, Graphite，各自在不同的层面为“是否正常”提供答案。
监控本身，无论是业界对监控的认知，监控工具/系统自身的能力，也在以下两个方向演进着：
-
黑盒到白盒
-
资源到业务
这个阶段监控的愿景是很明确的，如何落地则各显神通。
直到 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
（编辑：新余站长网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
