★ FEATURED ARTICLE 做日志采集和可观测性建设的人几乎都绕不开 Logstash。我们每天从业务服务器、容器平台、网关设备上收上来的日志绝大多数是半结构化甚至完全非结构化的文本有的是空格分隔有的用竖线分隔有的中间还夹着完整异常堆栈。可下游的 Elasticsearch 和 Kibana 完全不认这些“野外格式”想要精准检索、聚合统计、告警过滤前提就是把日志数据结构化而真正干活的核心就是 Logstash 过滤器。这篇文章我从自己处理过的几类典型日志出发把过滤器实现日志格式标准化的完整思路、插件选型、配置细节和线上踩坑记录一次性说透适合正在搭日志平台、被非结构化日志折磨的运维和开发同学直接参考。1. 日志标准化到底在解决什么1.1 一锅乱炖的原始日志让下游寸步难行先看一条最常见的 Nginx 访问日志127.0.0.1 - - [10/Oct/2024:14:23:01 0800] GET /api/v1/user/123 HTTP/1.1 200 1024 - Mozilla/5.0这条日志信息量其实很全但它是“一坨”字符串。如果不做任何处理直接塞进 Elasticsearch所有内容都堆在message字段里会带来几个非常实际的问题第一检索精度差。想查某个 IP 今天请求了多少次在非结构化文本里只能写模糊匹配message: 127.0.0.1难免误伤其他字段。比如用户请求参数里恰好也带了 IP检索结果就会多出一堆脏数据。第二聚合统计基本做不了。Kibana 上想按状态码画饼图、按接口统计 P99 耗时前提是status、request_time是独立字段否则只能写 Painless 脚本在脚本字段里硬拆性能差到让人崩溃。第三存储被浪费。同一段 URL、同一段 User-Agent 在每个文档里反复存储索引体积和监控成本成倍上涨。我自己早年代运维时最头疼的就是看这种日志。当时排查一个支付接口慢查询需要把相关日志全捞出来人工对比几千条数据在终端里翻来翻去眼睛都快看瞎。后来痛定思痛把所有关键日志全部做结构化字段统一成小写加下划线的命名规范检索和分析效率完全不是一个量级。1.2 Logstash 过滤器的定位管道中的拆解与重组车间Logstash 的数据处理链路很清晰input负责接收数据filter负责加工数据output负责发送数据。codec则负责在链路两端做编码和解码。数据从 input 进入后每条记录会变成一个包含原始字符串的“事件”默认放在message字段里。这个事件接下来会经过 filter 段在那里被拆解、转换、补充、丢弃最后以结构化字段的形式交给 output 写入目标系统。如果把整个链路比作一条生产线filter 就是拆解与重组车间。它把一台没组装说明的毛坯机器拆成一堆螺丝、齿轮和外壳再给每个零件贴上标签和规格说明。input 和 output 负责传输和落库所有真正改变数据形态的工作都发生在 filter 段。filter 段最大的特点是按配置书写顺序从上到下逐条执行。先匹配到的分支会先处理后面的过滤器可以基于前面产生的新字段继续操作。理解了这个顺序你才不会写出“先删字段后用的字段”这种低级错误也会明白为什么靠后的过滤器能读到靠前过滤器转换出来的新值。2. 关键过滤器插件选型与原理提到过滤器这个词IT 圈子里太容易串台了有人想到布隆过滤器有人想到 API 网关过滤器有人想到 ORM 框架里的拦截器。这里我们聊的是 Logstash 管道里的 Filter 阶段负责把一条原始日志拆成可检索的字段。这个阶段最常用的插件基本就是 grok、dissect、mutate、date再加上 json、kv、csv 这几个轻量级辅助插件。2.1 grok把正则玩到极致的拆字段器grok 是 Logstash 里最重要的过滤器它的核心语法是%{模式名:字段名}执行时会把原始文本里匹配到的那一部分写到字段名对应的字段里。举个例子%{IPORHOST:clientip}IPORHOST是内置模式能同时匹配 IPv4 地址和主机名匹配到的值就存进clientip字段。我处理过的日志品类里最常内建模式大概这几个可以直接背下来模式名匹配内容典型用途IPORHOSTIP 或主机名来源地址、客户端 IPWORD连续字母和数字下划线HTTP 方法、协议名、进程名URIPATHPARAMURL 路径和参数Nginx 请求行、后端接口路径POSINT正整数状态码、字节数、耗时NUMBER负数、小数、科学计数法响应时间、价格HTTPDATE常见 HTTP 时间格式时间戳TIMESTAMP_ISO8601yyyy-MM-dd HH:mm:ss,SSS等应用日志时间戳LOGLEVELDEBUG/INFO/WARN/ERROR日志级别GREEDYDATA任意字符贪婪匹配日志尾部兜底DATA任意字符最小匹配有边界的兜底比如访问日志里的[10/Oct/2024:14:23:01 0800]直接用%{HTTPDATE:log_timestamp}就能吃进去。如果内置模式不够用还可以通过pattern_definitions自定义。filter { grok { match { message %{ORDERID:order_id} } pattern_definitions { ORDERID [A-Z]{2}[0-9]{8} } } }grok 匹配失败时会自动给事件打上_grokparsefailure标签。实际项目里我习惯在 output 之前加一个条件判断把这些解析失败的事件单独写到一个 debug 索引里等技术团队拿着失败样本调整正则而不是让脏数据直接混进主索引。2.2 dissect比 grok 快但别用错地方grok 非常强大但正则有它的代价匹配过程需要回溯遇到复杂正则时 CPU 吃得很凶。如果日志格式非常固定没有分支变化dissect 是更好的选择。dissect 的工作原理非常简单粗暴就是按分隔符切字符串它不做正则匹配因此单条事件处理时间可以在微秒级。看一个配置对比就明白了filter { dissect { mapping { message %{remote_addr} - - [%{timestamp}] \%{request}\ %{status} %{bytes} } } }它直接把- -、[、]、空格这些固定字符当作切分点把中间的内容挖出来。所以 dissect 对格式要求极严多一个空格或少一个引号解析就会失败。但这正好适合线上格式长期稳定的 Nginx 日志、网关日志。维度grokdissect匹配方式正则表达式定界符切分单条性能慢受回溯影响快接近常量时间容错性支持分支和模糊匹配格式必须严格一致适用场景格式多变、异常堆栈、需要容忍差异固定分隔符、高吞吐场景我实测过一个日日志量 1.2 亿条的生产环境同样解析 Nginx 日志纯 grok 配置 CPU 占用约 3.2 核改成 dissect 只用了 0.9 核。所以我现在做方案的习惯是先用 dissect 快速切出固定字段再根据切出来的字段值判断是否需要走 grok 分支处理复杂内容两种插件结合着来。2.3 mutate和date标准化战场上的后勤主力拆出字段只是第一步。日志判断一个字段能不能用还得看字段名统不统一、类型正不正确、时间戳是不是统一到timestamp这些活要交给 mutate 和 date。mutate 提供了一整套字段操作能力我最常用的是这几个动作convert把字符串数字转成 integer把整型转成 string。rename把旧字段改成新名字比如 Java 日志里的level统一改成log_level。gsub把字段内容里的特殊字符替换掉最典型的是去掉字符串两侧引号。remove_field删掉 message、original 这类已经用完的冗余字段。copy复制一个字段比如把request复制为uri后继续拆解。date 过滤器则是把日志里的人类可读时间解析后覆盖到timestamp字段。Kibana 的时间过滤、ES 的时间轴聚合、日志排序全部依赖timestamp。如果不做 date 解析所有日志都会以 Logstash 接收事件的当前时间为准那排查问题就完全对不上号了。filter { date { match [log_timestamp, dd/MMM/yyyy:HH:mm:ss Z] target timestamp } }这里有个高概率踩坑点Logstash 自身工作在 UTC 时区如果你不管date.timezone参数它会把日志里的0800正常偏移但如果是纯应用日志比如2024-10-10 14:23:01.123不写时区就会被当成 UTC 时间解析Kibana 显示时直接差 8 个小时。处理这类日志时记得加上timezone Asia/Shanghai。2.4 json、kv、csv 这些轻量级过滤器很多日志虽然不是纯 JSON但已经带了明确的结构线索这时候不用硬套 grok。json 过滤器适合处理内嵌 JSON 字符串的字段。比如后端日志里有一部分业务信息是{orderId:ORD...,amount:99.9}可以直接用filter { json { source msg_payload target biz } }这样msg_payload里就能拆出biz.orderId、biz.amount字段不用手撸一堆正则去抠。kv 过滤器则专门处理keyvalue风格的字段列表。日志里如果有[txnId88a1b2c3, userId1024]这种片段先用 grok 把整段切到txnInfo字段再用 kv 拆分即可。csv 过滤器适合管道符、逗号分隔的定长列日志比如某些老旧系统的 CSV 导出日志一行就是一条记录列与列之间用逗号或竖线隔开。我见过太多人用正则去解析 CSV既慢又容易错其实csv { source message columns [col1, col2] separator | }一两行就能解决。3. 从0到1构建一条过滤管道3.1 定义源日志场景理论说完直接上个完整例子。假设你现在要收两类日志第一类是 Nginx 访问日志单行空格分隔。第二类是后端 Java 应用的运行日志格式如下2024-10-10 14:23:01.123 ERROR com.example.payment.PaymentService - [txnId88a1b2c3, userId1024] 支付回调验签失败 : {orderId:ORD20241010001,amount:99.9}Java 日志里包含时间、级别、类名、事务上下文、业务消息和一段 JSON 参数偶尔还会跟着几行异常堆栈。先别急着写正则我习惯先把所有需要落索引的字段列个清单Nginxclientip、method、request、http_version、status、body_bytes_sent、user_agentJavalog_time、log_level、logger、txn_id、user_id、biz_message字段命名统一小写加下划线避免某些团队日志字段一会儿点分一会儿驼峰后期 mapping 冲突吵得不可开交。3.2 编写input与filter完整配置这是我在测试环境反复调过的配置完整可跑# pipeline.conf input { beats { port 5044 codec multiline { pattern ^%{TIMESTAMP_ISO8601} negate true what previous } } } filter { if [log_type] nginx { grok { match { message %{IPORHOST:clientip} - - \[%{HTTPDATE:log_timestamp}\] \%{WORD:method} %{URIPATHPARAM:request} HTTP/%{NUMBER:http_version}\ %{POSINT:status} %{POSINT:body_bytes_sent} \%{DATA:http_referer}\ \%{DATA:user_agent}\ } remove_field [message, original] } date { match [log_timestamp, dd/MMM/yyyy:HH:mm:ss Z] } mutate { convert { status integer body_bytes_sent integer } remove_field [http_referer] } } else if [log_type] java { grok { match { message %{TIMESTAMP_ISO8601:log_time} %{LOGLEVEL:log_level} %{DATA:logger} - \[%{DATA:txn_info}\] %{GREEDYDATA:biz_message} } } date { match [log_time, yyyy-MM-dd HH:mm:ss.SSS] timezone Asia/Shanghai } kv { source txn_info target txn field_split , value_split } mutate { rename { txn.txnId txn_id txn.userId user_id } remove_field [txn, txn_info, log_time] } } if _grokparsefailure in [tags] { mutate { add_tag [parse_failed_need_review] } } } output { stdout { codec rubydebug } }为什么这个配置要这样写有几点值得展开说明。multiline 的 codec 放在 input 层是因为 filter 面对的是单条事件没法自动感知“上一行是不是堆栈第一行”。pattern ^%{TIMESTAMP_ISO8601}表示匹配时间戳开头的行negate true表示非时间戳开头的行都要合并到 previous也就是前一条事件后面。这是 Java 异常堆栈最常见的处理手段。grok 解析 Nginx 时中括号必须转义成\[、\]双引号直接用\。HTTP 时间格式对应dd/MMM/yyyy:HH:mm:ss Z注意月份是三字母缩写MMM 和 MM 不要搞混。Java 日志里把事务上下文先用%{DATA:txn_info}整体扣出来再用 kv 拆成txn.txnId和txn.userId最后通过 mutate rename 拍平成顶层字段txn_id、user_id。这样的好处是避免在一条 gork 正则里写了大量嵌套匹配逻辑更清晰拆字段失败时也更方便定位是哪个环节出了问题。3.3 验证结果从乱文本到结构化JSON配置写好后用 stdin 输入一条模拟日志stdout 导出能看到这样的输出{ clientip 127.0.0.1, method GET, request /api/v1/user/123, http_version 1.1, status 200, body_bytes_sent 1024, user_agent Mozilla/5.0, timestamp 2024-10-10T06:23:01.000Z, version 1 }注意status从字符串变成了整数timestamp也从本地时间2024-10-10 14:23:01 0800归一化成了 UTC 标准时间。Kibana 上打开时间过滤器如果看到时间全部少了 8 小时那就是界面上没切换时区和timestamp本身的准确性没有关系。字段到这一步已经干净清爽ES 索引 mapping 能正确识别 long、keyword、date 类型Kibana 也能直接拖字段做柱状图、折线图和阈值告警整个链路才叫真的走通了。4. 调试、性能优化与线上踩坑4.1 三板斧调试技巧第一个是 stdout 调试。在 output 段加上stdout { codec rubydebug }启动后往 input 灌一条真实日志马上就能看到字段拆出来没有、类型转换成功没有、有没有打上_grokparsefailure标签。这是最快的一个反馈回路。第二个是配置检查。改完管道后先跑一句命令做语法验证不用起进程等半天bin/logstash -f pipeline.conf --config.test_and_exit第三个是用在线 grok debugger。复制一条日志进去左侧写正则右侧立即显示字段结果改起来比在配置文件里一遍遍重启快得多。在线工具有个需要注意的坑它默认开启全部内置模式但 Logstash 某些发行版可能禁用了一部分比如SYSLOGTIMESTAMP在老版本里就时有差异所以最终还是要以本地 pipeline 跑出来的结果为准。4.2 性能隐患正则回溯、过滤器顺序与并发设置grok 性能消耗的大头在正则回溯。写%{GREEDYDATA:msg}收尾没问题但如果你在开头、中间乱用贪婪匹配比如%{GREEDYDATA:head} xxx %{DATA:tail}当数据不符合预期时正则引擎会反复尝试各种匹配路径CPU 直接被拖死。遇到过最夸张的一次线上一个过滤管道把 8 核机器的 CPU 全部吃满定位下来就是一条.*匹配导致严重的回溯开销。所以我现在有个铁律能用 dissect 就用 dissectgrok 只留给确实需要正则的分支。并且在日志数据量大的场景先加if debug in [level] { drop {} }这类前置 drop把不需要进入下游的数据尽早过滤掉避免后面过滤器做无用功。并发层面单管道处理能力可以调pipeline.workers默认值通常等于 CPU 核数。如果你的 machine 是 16 核但管道因为某条 filter 阻塞导致吞吐上不去优先排查 filter 本身别一上来就把 workers 调成 32。我曾见过把 workers 调高后正则回溯问题反而被放大、CPU 直接被打满的案例。4.3 典型踩坑实录把我在生产环境遇到的经典问题整理成了一张速查表方便你排查时对照症状原因解决方案Kibana 时间比日志时间快 8 小时date没配timezone按日志实际时区设置timezone Asia/Shanghai数字字段无法做范围查询mutate.convert没生效字段里带着引号或空格先用gsub清理再convert解析后status始终为空正则写错位置把%{DATA}用得太多打开 rubydebug对照字段逐段调整_grokparsefailure标签大量出现日志格式有空行、有 tabs 或额外空格用strip或先 dissect 切固定列多行堆栈只剩一行没有配置 multilinein input 层配置 multiline codec两个应用字段名冲突Nginx 的status和 Java 的status含义不同filter 里用rename改成http_status和app_status还有一个小细节mutate 的convert转换失败时Logstash 不会直接报错字段会悄悄保留成字符串ES 索引 mapping 也会以第一个文档的类型为准。你看着字段明明有数字却跑不了 range 查询其实就是类型没转成功。这就是为什么每次上线新管道我都会先写几条真实日志跑一遍再看_grokparsefailure、_dateparsefailure、_kvparsefailure这些 tag确认干净了再切主流程。5. 从标准化到可观测性以及扩展话题5.1 标准化之后的下游红利日志一旦标准化下游整个可观测性体系都会跟着受益。ES 索引的 mapping 不再是一团 message 字符串而是明确的分词 text 字段、精确匹配 keyword 字段、可用于范围查询的 date 字段和可用于聚合的 long 字段。Kibana 上想做“支付接口错误率趋势”只需要选biz.amount或者status字段按时间粒度聚合写 Painless 脚本的日子一去不返。告警场景更是如此。以前想监控 5xx 比例只能靠日志文件加 shell 脚本定时统计既不实时又容易漏。现在字段status稳定落在 ES 里写一个简单的搜索条件配合 Watcher 或 ElastAlert当status 500的比例超过阈值就触发通知故障从用户发现变成系统自发现。我自己经历过几次半夜被告警叫醒但对比以前用户报障之后才去翻日志定位时间从小时级缩短到了分钟级。5.2 自定义过滤器插件与生态扩展常规过滤器组合拳能解决 80% 以上的日志标准化需求但偶尔有些业务规则是内置插件搞不定的。比如公司自研的调用链 ID 需要从一段加密上下文里解出来或者需要根据字典表把 IP 打上机房标签这时候可以考虑写一个自定义过滤器插件。Logstash 支持用 Ruby 写自定义插件骨架其实很轻量:# lib/logstash/filters/example.rb require logstash/filters/base class LogStash::Filters::Example LogStash::Filters::Base config_name example config :prefix, validate: :string, default: def register # 初始化工作比如加载词典 end def filter(event) message event.get(message) event.set(prefixed_message, #{prefix}#{message}) end end插件开发完成后用bin/logstash-plugin install /path/to/plugin.gem安装即可。不过我要劝一句自定义插件会显著增加维护成本能靠 dissect、grok、mutate、date、json、kv 这几个成熟插件解决的诉求尽量在配置层解决别一上来就动代码。只有内置能力满足不了定制规则时再把自定义插件作为最后的方案。最后说点个人体会。过滤器设计得再漂亮如果一开始没想清楚业务到底要哪些字段后面还是要返工。我给团队定的规矩是先看日志样例标出必须查询和聚合的字段再决定 filter 顺序能不用正则就不用正则能提前 drop 就提前 drop。这套做法跑了几年索引体积降了不少告警误报也少了很多。日志结构化是件慢活但每多一个标准字段下游分析和故障定位就快一步这投入绝对值得。
阅读完成 · 觉得有帮助？
