建设DevOps统一运维监控平台，先从日志监控说起

本文转自微信号EAWorld。扫描下方二维码，关注成功后，回复“普元方法+”，将会获得热门课堂免费学习机会！

前言

---

随着Devops、云计算、微服务、容器等理念的逐步落地和大力发展，机器越来越多，应用越来越多，服务越来越微，应用运行基础环境越来多样化，容器、虚拟机、物理机不一而足。

面对动辄几百上千个虚拟机、容器，数十种要监控的对象，现有的监控系统还能否支撑的住？来自于容器、虚拟机、物理机的应用日志、系统服务日志如何采用同一套方案快速、完整的收集和检索？怎样的架构、技术方案才更适合如此庞大繁杂的监控需求呢？本文主要从以下几个方面来分享下笔者在日志监控方面的一些经验。

目录
一、DevOps浪潮下带来的监控挑战
二、统一监控平台架构解析
三、日志监控的技术栈
四、日志监控经典方案ELK
五、微服务+容器云背景下的日志监控实践Journald+fluentd+elasticsearch
六、如何选择适合自己的日志监控方案？

一、DevOps浪潮下带来的监控挑战

---

现在Devops、云计算、微服务、容器等理念正在逐步落地和大力发展，机器越来越多，应用越来越多，服务越来越微，应用运行基础环境越来多样化，容器，监控面临的压力越来越大。挑战主要有：

• 监控源的多样化挑战
  业务、应用、网络设备、存储设备、物理机、虚拟机、容器、数据库、各种系统软件等等，需要监控的对象越来越多，指标也多种多样，如何以一个统一的视角，监控到所有的数据？

• 海量数据的分析处理挑战
  设备越来越多，应用越来越多，要监控的数据自然也排山倒海般袭来，怎样的监控系统才能应对大数据的采集、存储和实时分析展现呢？

• 软硬件数据资源的管理分析挑战
  数据是采集到了，采集全了，那么如何对他们进行分析呢？应用、系统软件和运行环境、网络、存储设备的关联关系是否能准确体现呢，某个点发生了故障、问题影响的链路是否能快速找到并进行处理呢？监控离不开和软硬件资源管理的结合。

面对这些挑战，是否感觉压力山大呢？一个监控平台，拥有哪些能力才能满足如此大的挑战呢？

一个好的统一监控平台，应当具备如图所示的能力：

• 高度抽象模型，扩展监控指标：正如之前所说，监控源、指标的多样化，要求我们必须要进行监控模型的高度抽象，并且针对于指标可以动态扩展，这样才能保证监控平台的健壮性和可扩展性。

• 多种监控视图：监控数据自然不能只是简单的表格展现，饼图、柱状图、折线图、仪表盘等等，监控的数据需要结合实际情况选择最佳的图标展现。

• 强大的数据加工能力：海量的数据必须要有足够强大的数据加工、分析处理能力才能得到直观的结果。

• 多种数据采集技术：数据源的不同决定了采集的技术也是有区别的。

• 多种报警机制：短信、邮件、企业内部通讯工具等等，结合不同场景选择不同的报警机制。

• 全路径问题跟踪：一个请求有可能牵扯到数个系统、数十个接口的调用，出了问题有可能是其中任何一个环节，也有可能是应用所处运行环境、网络、存储的问题，所以问题的定位离不开全路径的跟踪。

二、统一监控平台架构解析

---

统一监控平台由七大角色构成：监控源、数据采集、数据存储、数据分析、数据展现、预警中心、CMDB(企业软硬件资产管理)。

监控源
从层次上来分，大致可以分为三层，业务应用层、中间件层、基础设施层。业务应用层主要包括应用软件、企业消息总线等，中间件层包括数据库、缓存、配置中心、等各种系统软件，基础设施层主要有物