这篇文章主要为大家展示了“互联网中监控的示例分析”，内容简而易懂，条理清晰，希望能够帮助大家解决疑惑，下面让小编带领大家一起研究并学习一下“互联网中监控的示例分析”这篇文章吧。
成都创新互联是一家网站设计公司，集创意、互联网应用、软件技术为一体的创意网站建设服务商，主营产品：自适应网站建设、高端网站设计、营销型网站。我们专注企业品牌在网站中的整体树立，网络互动的体验，以及在手机等移动端的优质呈现。做网站、成都网站设计、移动互联产品、网络运营、VI设计、云产品.运维为核心业务。为用户提供一站式解决方案，我们深知市场的竞争激烈，认真对待每位客户，为客户提供赏析悦目的作品，网站的价值服务。
当程序被交付，部署到生产环境，才是其生命周期中最长的部分的开始。人们需要了解生产环境是否一切正常，监控需求自然而然产生。
互联网发展过程中涌现大量监控相关的工具/系统，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
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 ，非常轻松确认网站登陆失败，与登录模块部署事件之间的关系。
以上是“互联网中监控的示例分析”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注创新互联行业资讯频道！