从微软Azure SQL云服务说起，大数据在运维中如何应用

Telemetry在现代云服务的运维中是必不可少的部分，本文将主要讨论telemetry的采集，存储和应用。

（全文共1970字 预计阅读时长：2分钟）

两代不同系统的比较

在一代系统中，我们的Telemetry 在系统内部采集、处理和存储，这给系统带来了以下问题：

我们采用了一些新技术解决以上问题，例如，我们把日志定时传到Azure Blob Storage，然后用Hadoop做批处理，输出到数据仓库。另外，我写了一个脚本（script）的数据通道去定时采集数据，把不同数据源的数据整合在数据仓库了，然后预警和做报表。

在二代系统中，我们采用Azure统一的数据采集系统 (MDS)，每个用户数据库有对应的采集代理服务 (Collection Agent)，把数据即时的推送到Azure Blob storage，其优点包括：

基于MDS的系统无法满足存储超大量的数据和快速灵活的查询两大要求。于是，在MDS的基础上，我们进行了一系列的后续处理，使大数据系统更完善。我们现有三种类型的数据源:

实时数据：服务系统提供接口允许工程师实时了解系统的状态，这对live site解决用户问题非常有效。

近实时数据:数据从采集到应用的延迟一般在5到10分钟。经常使用在预警和live site中。

长期数据：一般延迟为数小时到一天。一般数据巨量，用在对实时性要求不高的大数据查询中。

表1是我们的数据源比较。其中 Cosmos 是微软的大数据引擎，在公司内部广泛应用， 对外的产品名是Azure Data Lake。它有无限制的存储和可以查询海量数据的优点。对用户透明和零管理是我们选用Cosmos的主要原因。为解决系统故障的要求，我们引用了微软APPInsight的In-Memory大数据方案Kusto，这是一个基于行压缩的内存数据引擎微软大数据，可以快速处理各种类型的查询。

表1 不同类型的数据

图1为我们的系统的结构图，注意：我们已经用Cosmos替代了Hadoop。

图1 系统结构图

大数据在运维方面的应用

● 2.1 关键绩效指标（KPI：Key Performance Indicator）

在telemetry数据的基础上，我们建立有以下指标：

以上指标每天都在不同场合Review，并且驱动后续工作。我们用这种方法去支撑很多决策，帮助所有人都能熟练的使用数据做决策 (Data Driven Culture and Data Drive Engineer).

●2.2对服务报警和监控

我们利用了报警和监控机制，有效地解决服务中的问题，包括故障的分级，TTD/TTM和即时有效报警的重要性等系统的运维主要围绕着报警和解决问题展开。工程师们每天都要在LiveSite上化大量的时间和精力，并且把经验和教训反馈到开发的规程中。故障的生命周期如图2所示。

故障的分级

预警的类型：

集中在如何解决用户故障，而不是修改缺陷。

提供一个平台让用户方便的编写，测试，部署警报脚本。

图2 故障的整个生命周期

●2.3故障自动检测和修复系统（Auto Mitigator System）

究竟如何自动检测和修复系统，我们开发了一套反馈系统，可以从运维数据中检测故障，检测的结果会输入到WAFL引擎（Windows Azure Feedback Loop）中，引擎自动对我们的数据中心发送命令去解决故障。

WAFL系统大大减少了人的干预，并且可以快速解决用户问题。由于任何系统都有可能有缺陷，我们引入了审核（Auditing）、节流（Throttling）和假设测试（what if mode）去控制本系统对用户数据库的影响。如图3所示。

WAFL 通过以下手段缩短故障解决时间：

图3 Auto Mitigator 系统架构

运维方面的文化

我们在运维方面的文化、制度和安全上积累了不少好的经验，如图4所示，尤其是二代的系统运营采用了DevOps模式，把每个人都培养成全能的工程师。

图4 二代的系统运营模式

（编辑：武汉站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!