作者 | 白玙、珂帆

对于运维人而言，随着互联网行业野蛮生长逐渐结束，“如何降本提效”、“用数据说话”或已成为当下工作的核心主题。纵观纷繁复杂的日常运维场景，其背后大多有着明晰的导向目标，比如对产品服务质量负责的要求，对资源使用效率提升的要求，对技术成本控制的要求。

为达成上述目标，运维人在聚焦日常运维平台搭建之余，也开始逐渐重视数据建设，以期通过数据驱动运维。我们一定都听过「增长黑客」，但数据驱动运维又是什么？在这里，我们姑且笼统定义为通过对业务目标、运维流程的识别，借助全栈不同数据源的整合，将业务应用和基础设施关联在一起，构建完整数据分析体系，从而精准量化评估运维全过程以及服务质量，最大限度降低服务运行的成本，保障服务运行的安全。

这样的定义听起来似乎跟运维人的日常工作习惯与流程并无二致，那接下来我们具体来聊聊「数据驱动运维」。

我们为什么需要数据驱动运维？

首先，那下面的几个常见运维场景，运维人一定不意外：

缺少跨系统监控的统一视图

企业历史积淀的监控系统较多，既有如云资源监控、网络资源监控、存储资源监控等通用基础监控，也有如业务监控、数据库监控、各种中间件监控等定向监控。这些监控背后数据种类多、格式不统一，且分散在各自系统中。各系统拥有独立的权限管理方式以及数据展现方式，导致在故障发生时，缺少统一的视图汇总各类数据，无法有效辅助运维人员进行故障分析。运维人员无法直观地判断异常指标间的关联关系，需要各个系统不断跳转并反复查看，手工进行数据整合和分析判断。

缺少业务视角的指标关联

在故障发生时，往往最先反应在业务指标上，然而业务指标通常缺少与其他各种类型运维监控数据、告警数据关联关系，导致运维人员在故障处理的过程中效率较低。监控工具缺少与业务数据、告警数据和系统关系数据的有效整合，使得故障定位的过程需要多个系统运维人员共同参与分析，很难直接从业务角度来发现监控数据之间的关系。

缺少纵深交互的分析能力

系统故障无法完全避免，故障管理的重点是对故障快速响应和恢复服务。通常运维人员在故障定位时，很大程度上依赖运维经验，而监控工具更多是提供单一层面、单一指标的排查方式，无法有效结合应用架构及相关指标进行关联分析。导致在故障定位时存在根因定位不准确、定位不够及时等情况。随着系统复杂度不断增加，系统可用性要求不断提升，监控工具不再单纯是统一的整合和展示，还需要更有效的分析手段，通过关联、下钻等交互方式辅助查找故障根源。

缺少针对场景的定制能力

特定行业的业务场景相对较为固定，监控工具缺少针对具体运维场景进行数据整合和展示，以及定制数据关联和分析的功能，使得运维人员在特定场景下的故障处理效率较低。

数据驱动运维背后的价值到底是什么？

当我们考虑建立数据驱动的运维数据分析体系，或许以下几点价值让大家更容易接受：

1、业务支撑。通过将全栈数据打通与统一呈现，完整展现用户体验、产品业务和应用服务的关联关系，运维人可以快速了解业务场景的全局视图，量化产品业务健康度的同时，掌握应用服务异常对用户体验、产品业务的影响。增加运维与业务的交互，展现运维对产品业务的支撑价值。

2、跨团队协同。从基础设施、上层组件、应用服务、第三方接口到用户体验，基于应用的拓扑架构汇聚各类指标、事件，统一到同一平台展现。通过共享数据看板让不同职能、不同团队的协作方对数据口径、数据定义达成一致，进一步提升日常协作的沟通效率，避免无效的对焦扯皮。

3、故障管理。全面采集基础设施、平台组件、应用服务、业务流程等不同来源对应的告警信息按照资源、性能类型等不同维度进行可视化展现。让各类问题的统计分析更加多元、直观的展现给运维人员。在进行故障修复时，可以更快速的定位故障源头。

4、辅助决策。借助全栈数据打通与统一展现提高数据丰富度，进行针对性的运维数据分析，挖掘更细颗粒度的指标与数据。通过数据整合关联，辅助精准分析和决策，为最终业务结果提供有效支撑。

想要数据驱动运维，建立面向业务、面向用户的端到端运维数据分析体系成为不可或缺的环。但我们又需要哪些数据？

我们需要哪些数据？

想要解决以上场景，我们就需要大量的数据去进行分析，从而实现数据驱动运维。但数据驱动运维是一个不断演进的动态过程，我们很难在运维数据可视化分析体系的搭建初期就清晰的规划，我们需要哪些数据，又要摒弃哪些数据。因此，我们采集尽可能多的数据，再进行分门别类的整合。在这一过程中，我们尝试进行以下分类：

面向业务

对于运维来说，端是非常重要的数据采集点。端采集的数据可以更直接反映用户对产品的感知。这其中涵盖面向运营的产品业务数据，也包括面向运维的产品技术指标。通过相互关联，可以让运维人在某些场景下，快速找到事件相关性。比如说当前资源容量规划与业务增长之间的关系，订单支付成功率与服务调用的关系等等。

面向服务 & 接口

作为面向应用的能力封装，各类服务的特征和采集都与传统资源采集方法截然不同。不同的服务需要关注的指标都非常不同。用户在客户端发生请求之后，会产生大量的调用。虽然接口调用数据存在数据量大、不同语言不同采集方式等问题，但在故障发现和运维优化等方面，接口调用数据最有说服力，直观展现相关服务健康度。

面向资源

产品在向用户提供相关服务的背后，CPU、内存、磁盘 IO 等资源决定着服务的支撑力度。虽然云原生帮助企业实现更加迅捷地扩缩容。但运维扔需要建立相应容量模型来计算资源使用率，以应对业务突发情况。

我们如何选型数据可视化平台？

有了数据以及对应的面向业务、面向用户的端到端运维数据分析模型，我们该如何将之具像化呢？数据可视化的前提是监控数据的整合，在数据展示方面，Kibana 和 Grafana 是目前比较成熟的开源技术方案，适合利用日志和指标数据进行各种定制化图表的配置和展示。但两者存在一定的差异：

Kibana

Kibana 技术应用于日志数据分析及展示场景，在展现 Elasticsearch 存储的日志数据方面有很大优势，可以轻松地执行高级数据分析，并以各种图标、表格和地图形式进行数据可视化展示。Kibana 使得理解海量日志数据变得很容易，它简单的、基于浏览器的界面能够快速创建和共享动态仪表板，实时显示 Elasticsearch 的查询结果。

Grafana

Grafana 技术应用于海量指标数据的分析和展示场景，它是一个跨平台的开源度量分析和可视化工具，作为云原生可观测性的统一展示解决方案，其主要特性包括灵活且易用性强的客户端图表，丰富的仪表盘插件，具备实时查询海量指标数据并以热图、折线图、图表等多种方式进行展示的能力。这其中包括支持指定指标、图表类型、时间范围以及数据聚合方式的自定义配置以满足各种具体监控场景的需要。包括 Graphite、InfluxDB、OpenTSDB、Prometheus 和 Elasticsearch 等不同时序的数据源接入，并在同一面板展示不同数据源，将来自不同数据源，但同一业务的数据集中展示。通过 Grafana，任何人都可以创建和共享动态仪表盘，以促进协作和透明度，高效协同数据分析、故障排除。

Grafana 主要包括以下几个部分：

数据源

对于 Grafana 而言，Prometheus 这类为其提供数据的对象均称为数据源（Data Source）。目前，Grafana 官方提供了对 Graphite、InfluxDB、OpenTSDB、Prometheus、Elasticsearch,、CloudWatch 的支持。对于 Grafana 管理员而言，只需要将这些对象以数据源的形式添加到 Grafana 中，Grafana 便可以轻松实现对这些数据的可视化工作。

仪表盘

通过数据源定义好可视化的数据来源之后，可以通过数据看板来组织和管理数据可视化图表。在数据看板中最基本的可视化单元为一个 Panel（面板）。Panel 通过如趋势图，热力图的形式展示可视化数据。并且在数据看板中每个 Panel 是一个完全独立的部分。

通过 Panel 的 Query Editor（查询编辑器）我们可以为每一个 Panel 自己查询的数据源以及数据查询方式，以 Prometheus 作为数据源举例，那在 Query Editor 中，实际使用的是 PromQL，而 Panel 则会负责从特定的 Prometheus 中查询出相应数据并可视化。由于每个 Panel 完全独立，因此在一个数据看板中，往往可能会包含来自多个数据源的数据。Grafana 通过插件形式提供了多种 Panel 实现如：Graph Panel、Heatmap Panel、SingleStat Panel、Table Panel 等。用户还可通过插件安装更多类型 Panel 面板。

组织管理

作为一个可视化工具，Grafana 除了提供灵活的可视化定制能力以外，还提供面向企业的组织级管理能力。在 Grafana 中，数据看板是属于一个组织。例如企业创建多个组织，用户可以属于一个或多个不同组织。并且在不同组织下，为用户赋予不同的权限，根据企业组织架构定义整个管理模型。

看到这里，大抵会觉得 Grafana 开源版本简直是最佳选择，但在平台搭建过程中，运维人依旧会遇到很多开源项目的通病：

搭建前期，购买机器、配置网络、构建环境、安装部署、准备域名和 IP 地址等前期繁琐的准备工作；

使用过程中，使用了非常多云服务之后，数据接入困难，不知如何下手；

由于 SLA 无法保障，在关键时刻监控平台服务无法使用；

想要连接专有网络 VPC 内各自建数据源，并通过邮件、短信等渠道进行告警触达，需要自行详细配置。

相较于开源版本，阿里云Grafana服务优势是什么？

为了帮助大家更加快速的构建 Grafana，我们对众多使用开源版本的用户进行了相应调研，我们发现开源版本的用户需求主要集中在以下几点：

全托管的自动弹性(免服务器运维、高可用);
支持多方数据源（ARMS、Prometheus、SLS、用户自建数据源）、报警功能集成;
阿里云及其他云厂商的官方数据源预建数据大盘;
数据访问安全(云账户管理 /子账号授权 / 用户组/用户授权)
提供多种版本选择、插件版本选择、企业级插件支持
提供独立的访问域名/链接
自建 Grafana 迁移至托管 Grafana 的便利性(迁移工具/配置导入)

对此，阿里云推出 Grafana 托管服务，让运维能够更快速的搭建数据可视化平台。除去以上几点，我们在打造 Grafana 托管服务时也进行了以下的改进与优化：为了更好的运维管理和成本考虑,托管服务集群采用 ACK 集群；为了保证各用户数据隔离安全和数据库升级迁移维护的便利性，我们采用独立数据库方案，其他如服务状态机设计、云服务接入、用户鉴权、授权、独立域名等都是经过考虑权衡。

因此，我们可以看到阿里云 Grafana 服务包括以上优势：

默认集成各种云服务：默认集成 ARMS、Prometheus、云监控、SLS 等监控服务，更提供 MySQL、RocketMQ、ElasticSearch 各种云服务数据源配置，实现运维监控统一大盘展现。
海量插件任意选：近百种数据源插件覆盖主流技术产品，轻松连接已有数据源并实时展现相关数据，无需数据迁移或摄取。
自定义报警体系：一键快速创建报警，并整合相关所有报警，轻松搭建报警体系，让报警管理更高效。
多维度数据查询：支持跨不同查询与数据源的汇总、组合等计算，让数据查询更加灵活。
自建数据源整合：打通同地域多 VPC，并添加到同一数据源、工作区，实现统一查询展示与告警，降低数据管理成本。
快速创建看板：轻松配置、自定义和浏览所有面板，让运维可视化建设更加简单。

场景实践

云原生一体化大盘监控

场景挑战

监控范围非常繁杂，各类监控难以互相融合；对线上服务，如 HTTP、数据存储、消息队列等服务进行监控，出现异常时快速报警。

最佳方案

结合阿里云 Prometheus，全面覆盖日志监控、调用链路监控、指标监控等多种方式，为实际生产中排查问题提供重要支持，并满足基础监控、运行时监控、错误监控等不同需求。借助阿里云 Grafana 服务，所提供的预置的丰富的 Kubernetes 基础监控以及常用服务预设看板，节省自建监控面板的时间成本；