日志监控实践：监控 Agent 集成 Lua 引擎实现多维度日志采集

作者简介

董涵    百度资深研发工程师

负责 百度智能运维（Noah） 服务管理和分布式监控架构研发工作，在 分布式系统 和大规模 数据处理、可用性工程方向有 广泛的实践经验。

干货概览

对于互联网行业来说，最有价值的数据往往蕴含在服务的日志之中。从日志中，我们不仅仅可以获取到服务的使用量、服务效果、问题定位信息等，还可以通过监控系统及时地识别出服务的 ” 健康 ” 状态，规避风险，推动服务优化升级 。

在 监控系统 中，日志处理就是采集服务运行时生成的原始日志，根据用户配置的解析规则，从中提取可用数据，形成监控指标的过程，这个过程一般由监控系统的日志采集Agent完成。

通用的日志采集Agent一般会提供多种日志解析方法，常用的有 分隔符 、 K:V 、 正则表达式 等。为了适配某些常用的系统或组件（例如：Nginx、Syslog等），有些日志采集Agent还会提供一些预制的日志解析配置，以期达到开箱即用的效果。

百度的业务场景十分复杂，涉及搜索服务、社区服务、金融服务、AI服务等，这些业务的程序所生产的日志格式存在较大差异，如何统一处理这些不同格式的日志成为一个重要的问题。今天，我们会从 百度Noah监控平台 的角度，讨论如 何解决这一问题 。

典型日志处理示例

1 K:V日志

如上图所示，这是一个典型的K:V形式组成的日志。

我们可以通过简单的 分隔符 将日志分隔开，并根据K:V的式样从日志中提取出uri、c_time、idc等监控项。

2 多行日志

这是一个C++程序的Stack信息。需要将多行日志作为一个Trace信息进行完整提取，并且将每一行里面的函数名、文件名、行号单独提取，统一推送，用于批量实例的 故障定位 。

这个例子需要具备两个能力，多行日志处理和单行日志内提取字符串。

3 混合日志

在这个例子中，每行日志混合了 服务名 、 代码位置 、 用户自定义数据 等信息。需要分别用分隔符、K:V和JSON解析的方式进行提取。

针对这些场景，一些开源方案（例如Logstash，Collectd）通过在配置文件中支持此类语义或插件的方式实现了此类功能。我们参考了这些开源实现，结合百度业务的场景，在 监控采集 Agent上通过日志插件功能实现日志处理需求。

实现插件时，需要重点考虑以下几方面：

1. 通用性 和易用性 ：需要尽可能满足用户定制化需求， 并且开发简单。

2. 性能 ：典型的日志采集场景中，需要每秒处理数MB甚至 数十MB的 日志文件，并完成字段切分、正则匹配、数据格式转换等操作，需要处理引擎有较强的性能。

3. 可用性和安全性 ：Agent运行在线上生产服务器上，对稳定和安全有相当高的要求。

Agent日志插件实现

这里还封装了通用的日志处理 工具 库，以Lua内置类的形式提供，包含JSON、Debug等工具。

可用性和安全

对用户代码，需要严格规范资源占用量。执行插件的任务，作为一个单独的进程，使用Cgroup和Ulimit等机制限制资源占用，同时也作为执行隔离的手段，规避单个脚本或插件引擎的Bug影响所有采集任务正常执行。
另外，在任务执行时间上，也由Agent加以控制，避免任务超时运行。
Lua本身提供的一些功能也做了屏蔽，例如io.open/io.popen/os.execute/os.remove等高危操作接口，避免从脚本调用外部程序，或做出删除系统文件等操作。

增强模式

经过一段时间的线上运行，在某些场景下，日志处理的性能无法满足需求。