（2019 年度“嘉环杯”获奖论文一等奖）基于ELK 实现CDN 日志多维可视化管理分析

施益峰 屠智玮

中国移动通信集团江苏有限公司

0 引言

设备日志的收集与分析一直都是运维中至关重要的一环。最初，运维人员在各台设备上用传统的Linux 等工具（如cat、tail、sed、awk、grep 等）对日志进行简单的分析和处理，以命令级别的操作为主。随着互联网的兴起与硬件的更新，日志的产生与体量成几何倍的增长，分散管理的成本变得越来越高，高级运维人员通过编写脚本，汇总日志进行集中化管理，但查询耗时长，排障时效性低。

CDN 可实现互联网信息源的高速接入和就近访问，从而改善用户上网体验，是运营商增强互联网应用能力的重要手段，故CDN 产品竞争愈演愈烈，各个厂家推出的CDN产品群雄逐鹿。随之带来的问题也日益凸显，各CDN 厂商针对自家的产品都推出了一套运维管理平台，质量参差不齐，存在分析优化需求响应慢、开发周期长、对外互不兼容等问题，使得运营商在管理时过于繁琐，运维效率低下。运营商如果能把各CDN 厂商的日志进行集中管理，并提供全文检索功能，不仅可以提高诊断的效率，而且可以实现实时系统监测、网络安全、事件管理等功能，从而使运营商突破各CDN 厂家间的壁垒，摆脱各维护平台彼此孤立的困境。依托统一分析平台集中监控各平台的运行情况，由此开展集中调度与运营。基于此，本文向大家推荐一款开源利器——ELK 组件（Elastic Stack），提供分布式实时日志（数据）搜集和分析的监控系统。

1 架构介绍

ELK 组 件 是 由Elasticsearch、Logstash、Kibana 三 个核心组件首字母组成的简称，在Logstash 前端增加了一个Beats 模块，是轻量级采集程序的统称，比较常见的有：Filebeat、MetricBeat、PacketBeat、HeartBeat 等。本 文 主 要针对CDN 业务日志进行采集，因此选择专门用于收集日志数据的Filebeat，如图1 所示。

图1 ELK 架构

1.1 日志采集模块——Filebeat

轻量级的日志采集器Filebeat，内置有多种模块（auditd、Apache、NGINX、System、MySQL 等），可针对常见格式的日志简化收集过程。将其部署在CDN 系统的各类服务器（业务服务器、日志服务器、信安服务器等），转发、汇总日志与文件。此工具采用背压敏感协议，实时监测传输通道的拥堵情况，合理控制传输负载，减轻后端压力。

1.2 日志解析模块——Logstash

Logstash对接数据源，是负责搜集、分析、过滤日志的工具。它支持几乎任何类型的日志，包括系统日志、错误日志和自定义应用程序日志。它可以从许多来源接收日志，这些来源包括 syslog、消息传递（例如RabbitMQ）和JMX，在日志汇总处理后，能以多种方式输出数据，包括电子邮件、websockets 和Elasticsearch。

1.3 日志存储模块——Elasticsearch

Elasticsearch 是实时分析的分布式搜索引擎，是Elastic Stack 的核心，提供搜集、分析、存储数据三大功能。使用倒排索引，并减少磁盘随机读取次数，采用内存压缩算法来提升查询效率。

1.4 分析呈现模块——Kibana

Kibana 是基于Web 形式的ELK 前端展示工具，可管理、搜索、查看存储于Elasticsearch索引中的数据，并配合多种图表，例如饼图、折线图、热力图等，进行高级的聚合分析，创建满足各项需求的可视化报表。

2 实验部署

2.1 环境搭建

实验环境由4 台戴尔R720 服务器来搭建，采用CentOS 7 系统。用其中一台服务器（以下简称Server1）来部署Logstash、Kibana，进行日志的收集与Web 服务器的搭建；剩余三台服务器（以下简称Server2、3、4）搭建Elasticsearch 集群，采用主、备节点的方式，在每台设备上创建2 个节点。

由于节点数已达到6 个，且Server1 在Logstash 和Kibana搭建后还留余足够的硬件资源，为了更好的实现管理，在Server1 上搭建了负载均衡（SLB）节点，将所有的写入、查询操作均通过这个节点来分配任务，使整套Elastic Stack 变得完整、灵活。

至此，由4 台服务器组成的集群如下：1 个Logstash 节点，1 个Kibana 节点，1 个集群负载均衡节点，8 个Elasticsearch 节点，共11 个节点。如图2 所示。

图2 Kibana 上可视化的节点信息监控

2.2 日志接入

移动CDN 涉及多个厂家，先尝试将某个CDN 厂商的日志进行接入适配，其他厂家后续只需针对日志格式和字段含义作相应改动即可快速移植。该CDN 厂商日志包含19 个主要字段，日志格式：%h %i %s %t %a %R %m %e %d %u %l %p %T %c %f %P %N %r %b，具体字段说明如表1 所示。

表1 日志格式

掌握CDN 日志格式及各字段含义后，将日志接入ELK系统需要三步：（1）Logstash 配置，实现对日志字段的映射适配；（2）Filebeat 配置，实现对CDN 服务器进行数据采集；（3）Kibana 配置索引，实现Web 界面展示。具体部署配置方法见下文详细描述。

2.2.1 Logstash 适配

Logstash 配置文件中分为input、日志字段映射、output 三个部分。

（1）在Logstash 中新增该日志适配文件，配置input，此段设定日志通过Filebeat 上传至Logstash 的接口通道。如图3中红框（1）所示。

（2）根据日志的格式进行映射描述。本次接入日志格式是用空格来隔开字段，所以在配置映射转换前先进行配置，再根据表1 中的“日志说明”进行对应的字段排列，一一转换为Logstash 能识别的格式。再根据部分字段性质的不同，对取值结果进行“integer、float”二次加工，最后标记时间戳，在接收到日志时对其进行标注，方便管理。如图3 中红框（2）所示。

（3）设定output，此处配置决定了日志通过Logstash 过滤、处理后，上传至Elasticsearch 的接口通道。在host 处填写Elasticsearch 的负载均衡节点IP 与对应端口，将处理完成的日志按照“厂商+时间戳”的格式，形成一份索引，方便将同厂商日志在Kibana 上进行汇聚管理。如图3 中红框（3）所示。

图3 Logstash 日志识别配置

2.2.2 Filebeat 采集

配置Filebeat.yml 文件，在input 打开日志收集功能，paths填入服务器收集日志的路径，在output 处填上Logstash 的地址与接口。为了更方便的标记我们所接入的设备，建议在最下方加上一个“tag”，用于表示主机、归属、厂商、业务等信息。

2.2.3 Kibana 呈现

将配置完成的Filebeat 部署在需要收集日志的服务器，与Logstash 端网络打通后，即可按配置好的路径进行日志的抓取，并实时向Logstash 传输。

在Logstash 接收到日志后，执行已生效的配置，归档为索引后传输给Elasticsearch。至此，我们就可以登录Kibana，在侧边菜单栏中的Management 下进入/Elasticsearch/Index Management 路径，看到已经上传成功的“test_2019.xx.xx”索引，附带上该索引的健康状态、副本数、已录入的日志条数、已使用的存储大小等信息。代表着从服务器Filebeat（日志上传）→Logstash（日志收集）→ElasticSearch（分析处理）→Kibana（Web展现管理）全流程的打通。

在Kibana 菜单栏的首位——Discover 下，可以看到接入的日志已按照Logstash 中配置的字段映射，被拆分成易于检索的单个字段。在日志详单的左边，还能看到单个字段在当前的时间段内将每条日志对应的信息进行汇总处理后，计算出单位时间内的字段类型占比，如图4 所示。

图4 Kibana Discover 菜单中的日志索引展示

3 现网应用

经过上述实验，已成功实现CDN 日志采集、分析、Web呈现的全流程，对接入日志的字段进行适配，并添加索引后，便可以在Kibana 的核心组件Visualization 中创建热力图、直方图、饼图、时间轴等各类数据可视化视图。如法炮制实现其他CDN 厂家日志接入ELK 系统，并逐步批量覆盖全省所有CDN 厂家的所有CDN 服务器。

图5 Kibana Visualization 菜单

在内容网络CDN 业务中，通过HTTP 状态码来判断业务质量是最直观、基础的；以状态码数量统计出的“服务成功率”也是CDN 业务中常见指标之一。以此指标为例，进行指标随时间变化的视图创建。

通过筛选，采用Visualization 中的Visual Builder 来自定义实现：选择日志对应的建立好的索引，进入配置视图：“Aggregation”选项中提供了将索引中的字段进行平均、基数、百分比、过滤比率、方差、热门点击等丰富的汇聚选项。由于服务成功率指标是由HTTP 状态码的错误/正常的数量比率来计算的，因此选择Filter Ratio（过滤比率）来将字段“httpstatus”中全量计数作为Denominator 分母，将其中的5xx 计数作为Numerator 分子，以实现根据时间轴来计算HTTP 错误码数占服务总数的比值曲线。

图6 Kibana 请求失败率视图展示

单纯观察所有日志汇总后的HTTP 错误码曲线，依旧无法具体定位故障点，且汇总后数据量过大，当部分业务错误率突增，不足以影响全量数据时，无法体现。因此，在接入的业务、节点越来越多的情况下，需要在现有视图的基础上进行衍生：

（1）分组维度

某些厂商的CDN 业务分组数量众多，不同的分组代表不同的节点，也对应了不同的业务，汇聚后定位识别困难。

通过对服务器节点信息字段的关联，可将原视图上某厂商CDN 日志全量汇总的单一曲线，转由该厂商CDN 分组为单位的多条曲线，实现多分组多业务的服务状态监控，方便运维人员进行定位和排查，实际效果如图6 所示。

（2）业务域名维度

某些厂商的CDN 业务架构不同，分组数量少，同分组内同时服务多个业务，日志汇聚后需要进行区分识别。

由于日志字段中没有域名字段，无法直接选择进行字段关联，因此，对携带域名信息的“URL 字段”进行识别、提取。URL的格式是规范统一的，所以可在Logstash中对“URL字段”进行过滤，根据“/”的分割，取得对应域名字符，并映射为新字段，完成“域名字段”的创建。

通过对域名字段的关联，可将该CDN 分组内的混合业务日志，清楚地由域名维度区分识别，实现单分组内多个业务的服务状态监控。

（3）物理设备维度

某些CDN 节点承载重要业务，或承担负载均衡、调度管理等重要职责，需要对此类节点设备进行重点监控。因此，需要详细至单台设备IP 维度进行监控。但是，部分设备上报日志、特殊设备收集信息中不包含设备IP 信息，只能选择在设备上传数据至Logstash 前，通过Filebeat 在output 配置对应设备IP、归属等信息进行标识，再由Logstash 中映射新字段后完成创建。

通过对设备IP 字段的关联，可对重点关注设备进行详细监控，实现单分组内多设备点对点监控，第一时间发现异常设备，进行应急处理，及时止损对业务的影响。

通过上述三种维度衍生配置出的报表可以直观、实时地展现业务服务情况随时间趋势的变化，发现其中某个分组、某个业务的服务状态异常。但是，对于业务分组内服务的数个网站、域名、报错信息等进一步详细信息，还是无法知晓并具体定位是哪些服务受到了影响。

Kibana 上丰富灵活的视图，可以通过自由组合来进一步多维度地展现数据分析的信息。通过Pie 视图，以配置服务域名字段/报错信息为基准，同时筛选并关联业务分组与HTTP错误码两个字段，并配置需要查询的时间段，即可将此Pie 视图联合Visual Builder 视图共同定位至服务异常的具体业务，实现多分组多业务中，将Top 错误域名、Top 报错信息，同步实时呈现。如图7 所示。

图7 多维监控报表展示

至截稿前，笔者通过不断对该分析系统的更新与迭代，已可按地市节点、服务分组、业务域名、物理设备等维度可视化呈现，并可通过将状态码、命中率、时延、下载速率、流量、码率等指标关联下钻分析定位质差，成功发现数十起CDN 业务因设备硬件故障、上游回源异常、本地软件错误等情况导致的业务波动影响。与此同时，利用灵活的自定义特性与合理高效的检索架构，实现了多厂家平面日志的汇聚展现，突破运营商在现网运维中面临的困境，极大提高CDN 运营能力与排障效率。

4 结束语

本文主要是从“基于Elastic Stack 对CDN 业务多平面日志分析系统的架构、搭建与实现”入手，对每一部分展开说明。本系统降低了日志管理分析的成本，在日志的收集处理、检索分析和展示方面，凸显出良好的灵活性与包容性，能有效协助运营商解决单业务系统内多个厂家各自独立、互不兼容的“老大难”问题，提升运维效率。目前该系统已推广至互联网电视等业务领域，其他需进行日志分析的专业领域均可参照此文介绍的部署方法平滑便捷地移植。

本文只是对ELK 系统的初步探索，此系统各个组件都拥有丰富友好的开源接口，下一步将继续研究，加入Python 等其他优秀的开源技术，深挖优化日志分析平台，依托此平台实现多业务多平面日志的统一采集、汇聚呈现与分析预警。