这篇文章主要为大家展示了“互联网中监控的示例分析”，内容简而易懂，条理清晰，希望能够帮助大家解决疑惑，下面让小编带领大家一起研究并学习一下“互联网中监控的示例分析”这篇文章吧。

成都创新互联是一家网站设计公司，集创意、互联网应用、软件技术为一体的创意网站建设服务商，主营产品：自适应网站建设、高端网站设计、营销型网站。我们专注企业品牌在网站中的整体树立，网络互动的体验，以及在手机等移动端的优质呈现。做网站、成都网站设计、移动互联产品、网络运营、VI设计、云产品.运维为核心业务。为用户提供一站式解决方案，我们深知市场的竞争激烈，认真对待每位客户，为客户提供赏析悦目的作品，网站的价值服务。

一、监控需求的产生

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

互联网发展过程中涌现大量监控相关的工具/系统，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 ，非常轻松确认网站登陆失败，与登录模块部署事件之间的关系。

以上是“互联网中监控的示例分析”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注创新互联行业资讯频道！

网站栏目：互联网中监控的示例分析
转载注明：http://scgulin.cn/article/pihgec.html