温馨提示×

温馨提示×

您好,登录后才能下订单哦!

密码登录×
登录注册×
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》

互联网中监控的示例分析

发布时间:2021-11-02 14:33:14 来源:亿速云 阅读:170 作者:小新 栏目:系统运维

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

一、监控需求的产生

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

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

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

向AI问一下细节

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

AI