建设DevOps统一运维监控平台，先从日志监控说起
发布时间：2018-02-12 浏览：226打印字号：大中小
面对动辄几百上千个虚拟机、容器，数十种要监控的对象，现有的监控系统还能否支撑的住？来自于容器、虚拟机、物理机的应用日志、系统服务日志如何采用同一套方案快速、完整的收集和检索？怎样的架构、技术方案才更适合如此庞大繁杂的监控需求呢？本文主要从以下几个方面来分享在日志监控方面的一些经验。
一、DevOps浪潮下带来的监控挑战
现在Devops、云计算、微服务、容器等理念正在逐步落地和大力发展，机器越来越多，应用越来越多，服务越来越微，应用运行基础环境越来多样化，容器，监控面临的压力越来越大。挑战主要有：
监控源的多样化挑战 业务、应用、网络设备、存储设备、物理机、虚拟机、容器、数据库、各种系统软件等等，需要监控的对象越来越多，指标也多种多样，如何以一个统一的视角，监控到所有的数据？
海量数据的分析处理挑战 设备越来越多，应用越来越多，要监控的数据自然也排山倒海般袭来，怎样的监控系统才能应对大数据的采集、存储和实时分析展现呢？
软硬件数据资源的管理分析挑战 数据是采集到了，采集全了，那么如何对他们进行分析呢？应用、系统软件和运行环境、网络、存储设备的关联关系是否能准确体现呢，某个点发生了故障、问题影响的链路是否能快速找到并进行处理呢？监控离不开和软硬件资源管理的结合。
面对这些挑战，是否感觉压力山大呢？一个监控平台，拥有哪些能力才能满足如此大的挑战呢？
高度抽象模型，扩展监控指标：正如之前所说，监控源、指标的多样化，要求我们必须要进行监控模型的高度抽象，并且针对于指标可以动态扩展，这样才能保证监控平台的健壮性和可扩展性。
多种监控视图：监控数据自然不能只是简单的表格展现，饼图、柱状图、折线图、仪表盘等等，监控的数据需要结合实际情况选择优质的图标展现。
强大的数据加工能力：海量的数据必须要有足够强大的数据加工、分析处理能力才能得到直观的结果。
多种数据采集技术：数据源的不同决定了采集的技术也是有区别的。
多种报警机制：短信、邮件、企业内部通讯工具等等，结合不同场景选择不同的报警机制。
全路径问题跟踪：一个请求有可能牵扯到数个系统、数十个接口的调用，出了问题有可能是其中任何一个环节，也有可能是应用所处运行环境、网络、存储的问题，所以问题的定位离不开全路径的跟踪。
统一监控平台由七大角色构成：监控源、数据采集、数据存储、数据分析、数据展现、预警中心、CMDB(企业软硬件资产管理)。
监控源 从层次上来分，大致可以分为三层，业务应用层、中间件层、基础设施层。业务应用层主要包括应用软件、企业消息总线等，中间件层包括数据库、缓存、配置中心、等各种系统软件，基础设施层主要有物理机、虚拟机、容器、网络设备、存储设备等等。
数据采集 数据源如此多样，数据采集的任务自然轻松不了。数据采集从指标上划分可以分为业务指标、应用指标、系统软件监控指标、系统指标。
应用监控指标如：可用性、异常、吞吐量、响应时间、当前等待笔数、资源占用率、请求量、日志大小、性能、队列深度、线程数、服务调用次数、访问量、服务可用性等，业务监控指标如大额流水、流水区域、流水明细、请求笔数、响应时间、响应笔数等，系统监控指标如：CPU负载、内存负载、磁盘负载、网络IO、磁盘IO、tcp连接数、进程数等。
从采集方式来说通常可以分为接口采集、客户端agent采集、通过网络协议主动抓取（http、snmp等）
数据存储 采集到的数据一般都会存储到文件系统（如HDFS）、索引系统（如elasticsearch）、指标库（如influxdb）、消息队列（如kafka，做消息临时存储或者缓冲）、数据库（如mysql）
数据分析 针对采集到的数据，进行数据的处理。处理分两类：实时处理和批处理。技术包括Map/Reduce计算、全日志检索、流式计算、指标计算等，重点是根据不同的场景需求选择不同的计算方式。
数据展现 将处理的结果进行图表展现，在多屏时代，跨设备的支持必不可少。
预警 如果在数据处理过程发现了问题，则需要进行异常的分析、风险的预估以及事件的触发或告警。
CMDB(企业软硬件资产管理) CMDB在统一监控平台中是很重要的一环，监控源虽然种类繁多，但是他们大都有着关系，如应用运行在运行环境中，应用的正常运行又依赖网络和存储设备，一个应用也会依赖于其他的应用（业务依赖），一旦其中任何一个环节出了问题，都会导致应用的不可用。CMDB除了存储软硬件资产外，还要存储这样一份资产间的关联关系，一个资产发生了故障，要能根据这个关系迅速得知哪些其他的资产会被影响，然后逐一解决问题。
三、日志监控的技术栈
既然前面讲了整个监控系统的架构，下面就按照架构中的角色来分类看看有哪些常用的开源技术。由于篇幅原因，这里无法详细描述每一个技术的细节，大家感兴趣的话，可以一一了解下。
日志源
syslog 守护进程的任务是记录系统日志。它从应用程序和服务中获取格式各异的日志消息并保存到磁盘上，消息的元数据是组件名、优先级、时间戳、进程标签和 PID，日志格式很是宽泛，没有定义结构化的格式，所以系统的分析和日志消息处理也就变得十分混乱，同时性能和其他的一些缺点随着时间推移也慢慢被放大，后来慢慢被Rsyslog所取代。
Rsyslog可以说是Syslog的升级版，它涵盖SysLog的常用功能，不过在功能和性能上更为出色。
Red Hat Enterprise Linux 7与SUSE Linux Enterprise Server 12这些新一代的Linux发行版本使用systemd管理服务。
journal是systemd的一个组件，由journald处理。Journald是为Linux服务器打造的新系统日志方式，它标志着文本日志文件的终结，它不再存储日志文件，而是将日志信息写入到二进制文件，使用journalctl阅读。它捕获系统日志信息、内核日志信息，以及来自原始RAM磁盘的信息，早期启动信息以及所有服务中写入STDOUT和STDERR数据流的信息。Journald快速改变着服务器如何处理日志信息与管理员如何访问的方式。
数据采集
日志的采集工作大都是通过客户端进行，客户端除了一些直接可用的工具（如fluentd、flume、logstash）外，还可以通过log4j的appender、自行写脚本实现等。
fluentd是开源社区中流行的日志收集工具，fluentd基于CRuby实现，并对性能表现关键的一些组件用C语言重新实现，整体性能相当不错。优点是设计简洁，pipeline内数据传递可靠性高。缺点是相较于logstash和flume，其插件支持相对少一些。
flume是由JAVA实现的一个分布式的、可靠的、高性能、可扩展的的日志收集框架，Flume比较看重数据的传输，使用基于事务的数据传递方式来保证事件传递的可靠性，几乎没有数据的解析预处理。仅仅是数据的产生，封装成event然后传输。同时使用zookeeper进行负载均衡，不过JVM带来的问题自然是内存占用相对较高。
Logstash相比大家都比较熟悉了，是ELK中的L，logstash基于JRuby实现，可以跨平台运行在JVM上。logstash安装简单，使用简单，结构也简单，所有操作全在配置文件设定，运行调用配置文件即可。同时社区活跃，生态圈提供了大量的插件。早期Logstash并不支持数据的高可靠传递，所以在一些关键业务数据的采集上，使用logstash就不如flume更加可靠。不过在5.1.1版本发布了持久化队列的beta版，显然logstash也在快速改进自己的缺陷。
数据缓冲
在大批量的监控数据涌过来后，考虑到网络的压力和数据处理的瓶颈，一般会在存储前先经过一层数据缓冲，将采集到的数据先放置到消息队列中，然后再从分布式队列中读取数据并存储。这张图是新浪的日志检索系统的架构图，可以看到数据采集后，经过kafka缓冲，然后再使用logstash去读取kafka中的数据并存储到es中：
关于分布式队列这里就不详细讲解了，常用有kafka，rabbitmq，zeromq等。
数据存储&分析 存储和分析息息相关，监控数据的处理通常分为实时处理和非实时处理（如大数据的批处理框架hadoop等），如Elasticsearch就是一个实时的分布式搜索和分析引擎，它可以用于全文搜索，结构化搜索以及分析。
除了ES外，还有一些流式大数据处理框架可以做到实时或者准实时的处理大数据流。如Spark和Storm。关于大数据处理的内容因为本人也没有多少实践经验，就不在此多做分享了。后面主要还是针对于Elasticsearch这一框架进行介绍。
数据展现 Kibana和Elasticsearch可以说是无缝衔接，再加上Logstash，组成的ELK赫赫有名，很多企业都会直接采用这一种框架。
Kibana确实也能满足大部分的监控需求，但是其毕竟只能依靠现有的数据进行展现，如果需要和外部数据结合处理，就会无法满足了，并且在自己构建一个统一监控平台时，需要将日志和性能等监控数据结合CMDB、预警中心、等统一展现，所以对于kibana的替换就无法避免了。我们是通过使用JAVA去查询Elasticsearch的数据，结合其他数据统一分析，将展现的结果进行滚动展现或者用图表显示。
（本文转自微信号EAWorld）
