|
|
51CTO旗下网站
|
|
移动端

2.2 多维度、多数据源

《智能运维:从0搭建大规模分布式AIOps系统》第1篇开门见山:运维发展史,本篇主要展现运维的发展历史和经历的不同历史阶段,以及运维工作的现状。本节为大家介绍多维度、多数据源。

作者:彭冬/朱伟/刘俊来源:电子工业出版社|2018-11-27 12:25

2.2 多维度、多数据源

如图2-2所示,这是一个多维度模型示例。真实世界的情况是(至少按弦理论学家所说的是),除我们可以感知的3个“延展维”外,还有6个“蜷缩维”,它们的尺寸在普朗克长度的数量级,因此我们无法感知到。

当然,运维数据中的“多维度”,还没有复杂到这样难以理解。

在相对复杂的业务场景下,一个“事件”除包含我们常用的“时间”(何时发生)、“地点”(哪个服务器/组件)、“内容”(包括错误码、状态值等)外,还应当包含地区、机房、服务池、业务线、服务、接口等,这就是多维度数据。

很多时候,数据分析人员可能要使用各种维度、组合各种指标来生成报告、Dashboard、告警规则等,所以是否支持多维度的数据存储和查询分析,是衡量一个系统是否具有灵活性的重要指标。

对多维度数据的处理,很多时候是一个协议/模型设计问题,甚至都不会牵扯具体的分析和处理框架,设计良好的协议和存储模型,能够兼顾简洁性和多维度。

在后面的章节中,我们会介绍协议/模型设计中的多维度。

. 在单一Key中包含维度信息。

. 在Tag中标注不同维度。

实践中,通常会混合使用多种存储介质和计算模型。

. 监控数据:时序数据库(RRD、Whisper、TSDB)。

. 告警事件:Redis。

. 分析报表:MySQL。

. 日志检索:Elasticsearch、Hadoop/Hive。

这里列出的只是一部分。

如何从异构的多数据源中获取数据,还要考虑当其中某个数据源失效、服务延迟时,能否不影响整个系统的稳定性。这考量的不仅仅是各种数据格式/API的适配能力,而且在多依赖系统中快速失败和SLA也是要涉及的点。

多数据源还有一个关键问题就是如何做到数据和展现分离。如果展现和数据的契合度太高,那么随便一点变更都会导致前端界面展现部分的更改,带来的工作量可能会非常大,很多烂尾的系统都有这个因素存在的可能性。


喜欢的朋友可以添加我们的微信账号:

51CTO读书频道二维码


51CTO读书会第9群:808517103

【责任编辑:book TEL:(010)68476606】

回书目   上一节   下一节
点赞 0
分享:
大家都在看
猜你喜欢

订阅专栏+更多

活学活用 Ubuntu Server

活学活用 Ubuntu Server

实战直通车
共35章 | UbuntuServer

218人订阅学习

Java EE速成指南

Java EE速成指南

掌握Java核心
共30章 | 51CTO王波

83人订阅学习

Mysql DBA修炼之路

Mysql DBA修炼之路

MySQL入门到高阶
共24章 | 武凤涛

471人订阅学习

读 书 +更多

鸟哥的Linux私房菜——服务器架设篇(第二版)

本书是对连续三年蝉联畅销书排行榜前10名的《Linux鸟哥私房菜——服务器架设篇》的升级版,新版本根据目前服务器与网络环境做了大幅度修订...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO播客