为什么要构建监控系统
在后移动互联网时代，良好的用户体验是增长的基础，稳定的使用体验就是用户体验的基础。大型的互联网公司，特别是面向 C 端客户的公司，对业务系统稳定性的要求越来越高，因此对线上问题发现和处理的速度要求通常是分钟级的。比如滴滴等出行公司，打车服务停摆 10 分钟都会导致导致乘客、司机大规模投诉，不仅造成经济损失，而且严重平台商誉和用户口碑。
大型互联网公司的业务系统都是大规模的分布式系统，各种业务应用和基础组件（数据库、缓存、消息队列等）共同交织成复杂的依赖网络，任何节点都可能出现故障，导致系统不可用。因此，业务系统的监控非常重要，通过监控及时发现和干预问题，避免事故或降低事故影响范围。
本文将从监控系统整体架构设计、监控系统技术方案落地这两部分阐述了百亿级大数据实时监控系统的建设过程，旨在帮助大家了解监控系统设计思路，对于监控系统建设提供专业指导，快速构建监控系统。
监控系统整体设计
一、监控系统需求
世界上并不存在完全可靠的系统，程序、机器、网络等都可能在运行中出现故障，进而导致服务异常。因此监控的目标就是，高效及时地发现、定位系统异常问题，期望缩短异常的平均修复时间，从而降低异常造成的损失。
为了实现缩短异常的平均修复时间这一目标，监控系统应该具有这些能力：
1.数据采集能力：全面、准确、快速、低损耗地获取监控日志及数据。
2.数据汇聚能力：将相关数据汇聚起来，方便加工，得到我们需要关注的数据。
3.数据分析与处理能力：对需要关注的数据提供异常指标检测、故障诊断等分析方法，以及数据过滤、采样、转换等处理手段。
4.数据存储能力：为海量日志与监控指标提供高性能存储。
5.监控告警能力：指定监控规则，触发规则后提供电话、邮件、微信、短信等各类告警机制。
6.数据展示能力：提供监控数据与告警的 Dashboard 展示功能，加速问题定位。
7.高可用：整个监控系统需要做到高可用，监控就是为了发现异常，如果由于异常导致自身不可用，肯定是减分的。
二、监控系统架构
根据对监控系统需求的调研，可以将监控系统整体的数据流转过程抽象为以下几个阶段：采集 -> 汇聚 -> 处理 -> 存储 -> 分析 -> 展示 -> 告警。
从中我们可以总结出监控系统的一般架构：
从下往上来分析，首先是数据采集层，提供众多采集手段，包括 Agent 采集、RPC 埋点、HTTP 上报等，可以通过 Agent 采集宿主机监控数据和日志，或者 RPC 埋点上报，也可以由用户直接通过 HTTP 推送进行数据采集。
成功采集到的数据，需要经过统一的数据汇聚层，将相关联的数据进行汇聚。例如同一业务系统的所有服务器数据将会汇聚到一个相同的消息队列中，便于异常检测。
数据完成汇聚后，将分为三条数据流处理：数据处理、数据分析、数据存储。
1.数据处理层：对原始监控数据进行加工，通过数据清洗与转换将数据格式化，并进行基础的聚合计算，例如累加计算 10 台服务器的 ERROR 日志次数；
2.数据分析层：对标准化后的数据进行关联分析、异常检测、故障诊断等，为后续的告警提供判断依据；
3.数据存储层：对日志、指标、时序数据进行存储，便于 Dashbord 展示，可用于进一步的数据挖掘。
数据流处理完成后，进入监控告警层，对符合监控、告警规则的事件进行告警推送。
数据流最终到达数据展示层，提供常见的用户交互页面：如监控面板、告警面板等。
监控系统方案落地
一、技术选型
方案 1: 流计算 Oceanus + Elastic Stack
提到监控系统方案，大家首先想到的肯定是 Elastic Stack（Elasticsearch、Logstash、Kibana、Beats），其活跃的社区、简单的安装流程、便捷的使用方式等优势吸引了大量用户，当前许多互联网公司的监控系统架构都是基于开源 Elastic stack 搭建的。
Elastic Stack 由 Elasticsearch、Logstash、Kibana 和 Beats 组成。下面分别对各个组件进行简单的介绍。
Elasticsearch 是一款实时全文搜索和分析引擎。作为 Elastic stack 的核心，Elasticsearch 可用于搜索各种类型的数据：从文本、数字和地理空间数据到其他类型的结构化和非结构化数据，主要支持搜索、分析、存储数据三大功能。Elasticsearch 基于 Apache Lucene 搜索引擎库构建，它易于使用且可扩展。
Logstash 是一款日志聚合器，它可以从各种输入源动态采集监控日志和数据，对其进行转换后，将数据传送到各种支持的输出目的地。许多用户将转换后的数据发送到 Elasticsearch，在其中对日志、监控数据进行索引与搜索。
Kibana 是工作在 Elasticsearch 之上的可视化层，为用户提供数据分析和可视化的能力，可将存储在 Elasticsearch 中的数据转换为易于使用的图表、图形、直方图和其他可视化表示，进而深入挖掘数据特征。
Beats 是一款轻量级日志采集器，目前 Beats 包含多种工具：Metricbeat、Filebeat、Heartbeat 等。每个 Beat 都有一个简单的任务：采集日志或数据并发送到输出目的地。
Elastic Stack 运行于分布式系统之上，为用户提供了一个性能强大的平台，该平台通过采集、过滤、传输、储存，对海量日志和监控数据进行集中管理和准实时搜索、分析，提供准实时搜索、监控、事件消息和分析报表等简单易用的功能，帮助运维人员进行线上业务的实时监控，业务异常时及时定位原因、排除故障，深度挖掘日志的大数据价值。
但是 Elastic Stack 也存在一些不足。首先 Beats 只有采集日志与监控数据的功能，无法对数据进行处理；另外 Logstash 的数据处理功能很弱，无法满足复杂的数据处理需求，且不支持监控数据缓存，存在数据丢失的隐患。
综上所述，在将监控数据与日志信息保存到 Elasticsearch 之前，需要引入消息队列缓存数据，并使用大数据实时计算引擎对数据进行实时的过滤、转换、聚合。
而腾讯云流计算 Oceanus 恰好可以实现这些功能。流计算 Oceanus 是大数据产品生态体系的实时化分析利器，是基于 Apache Flink 构建的具备一站开发、无缝连接、亚秒延时、低廉成本、安全稳定等特点的企业级实时大数据分析平台。流计算 Oceanus 能很好地满足监控场景下海量实时数据处理的需求，监控系统可以利用 Oceanus 的实时计算能力，对监控日志与数据进行清洗、转换并完成聚合分析，实时计算的结果可以直接用于监控告警展示，极大地提升了运维人员在故障发生时的决策能力。
使用 Elastic Stack 还需要关注的点是监控面板。Kibana 的长处在于日志分析，且仅适用于 Elasticsearch，不支持任何其他类型的数据源；它的面板展示能力还有提高的空间，而且具有陡峭的学习曲线，对于非技术业务用户来说很难上手。因此可以考虑使用其他的数据可视化工具代替 Kibana 作为监控面板，让 Kibana 专注于日志分析。综合对比现有的可视化工具后，我们选择使用 Grafana。
在实际应用场景中，可以使用 Beats 采集日志与监控数据，将 Kafka 作为 Beats 的输出端。Kafka 实时接收到 Beats 采集的数据后，使用流计算 Oceanus（Flink）进行实时处理与聚合，将满足需求的数据输出到 Elasticsearch 中进行分布式检索，通过 Kibana 进行日志分析，最后采用 Grafana 作为监控面板。流程如下图所示：
flink+es
方案 2: Zabbix + Prometheus + Grafana
本文来自微信公众号“腾讯云开发者”（ID：QcloudCommunity）。大作社经授权转载，该文观点仅代表作者本人，大作社平台仅提供信息存储空间服务。
