5.1 查询语法 基础语法 Graylog 使用 Lucene 风格查询： 字段查询：field:value 短语查询：message:"login failed" 逻辑操作：AND / OR / NOT 时间范围 通过时间选择器设置范围 常用：最近 5 分钟、1 小时、24 小时 常见示例 source:api-01 AND http_status:500 service:order AND request_time:>1000 message:"timeout" OR message:"connection refused" 查询优化建议 优先使用结构化字段 选择合适时间范围 避免全量搜索 小结 本章介绍了查询语法。下一章讲保存搜索。 下一节：5.2 保存搜索 返回目录 | 返回首页

4.4 字段规范化 为什么要规范化 字段标准化是可检索性与可视化的关键。如果每个团队使用不同字段名，会导致搜索与仪表盘不可复用。 常见规范 IP：client_ip 方法：http_method 路径：request_path 状态码：http_status 耗时：request_time 服务名：service 环境：env 建议策略 建立 字段字典（Field Dictionary） 在 Pipelines 中统一命名 对关键字段设置类型（long/double/string） 示例规则 rule "normalize_http" when has_field("method") then set_field("http_method", to_string($message.method)); set_field("request_path", to_string($message.path)); end 小结 字段规范化是长期收 ...

4.3 Pipeline 规则实战 目标 通过示例演示如何解析 Nginx 访问日志，并标准化字段。 示例日志 127.0.0.1 - - [16/Feb/2026:10:00:00 +0800] "GET /api/ping HTTP/1.1" 200 12 "-" "curl/7.81.0" Grok 规则示例 rule "nginx_access_grok" when has_field("message") then let m = grok("%{IP:client_ip} - - \[%{HTTPDATE:ts}\] \"%{WORD:method} %{URIPATHPARAM:path} HTTP/%{NUMBER:http_version}\" % ...

4.2 Pipelines 概念 为什么需要 Pipelines Pipelines 是 Graylog 的规则引擎，适合复杂条件判断、字段清洗与标准化。 相比 Extractors，Pipelines 具备： 可版本管理 规则可复用 逻辑可读性更强 核心概念 Pipeline：包含多个 Stage Stage：包含多个 Rule Rule：具体规则逻辑 执行流程 日志进入 Stream Stream 触发 Pipeline Pipeline 依次执行 Stage 规则成功则设置字段/路由 示例规则（简化） rule "add_env" when has_field("source") then set_field("env", "prod"); end 小结 Pipelines 是生产环境的最佳实践。下一章进入规则实战。 下一节：4.3 Pipeline 规则实战 返回目录 | 返回首页

4.1 Extractors 入门 Extractors 的作用 Extractors 用于从原始日志中抽取字段，适合快速上手与简单场景。常见的抽取方式包括： Grok：基于正则模板 Regex：自定义正则表达式 JSON：直接解析 JSON 字段 何时使用 Extractors 小规模、快速解析 日志格式简单 不需要复杂条件判断 创建 Extractor 步骤 打开某条日志详情 点击字段区域 Extract 选择 Grok/Regex/JSON 测试并保存 示例（Regex） 日志： 127.0.0.1 - - [16/Feb/2026:10:00:00 +0800] "GET /api/ping HTTP/1.1" 200 12 Regex： ^(?<client_ip>\S+) .* "(?<method>\S+) (?<path>\S+)" 小结 Extractors 上手快，但不利于复杂规 ...

3.4 Beats/Sidecar 适用场景 当需要采集多台服务器日志并统一管理配置时，推荐使用 Graylog Sidecar + Beats。 Sidecar 的作用 统一下发采集配置 管理 Filebeat/Winlogbeat 等采集器 支持多平台（Linux/Windows） 基本流程 在 Graylog UI 创建 Sidecar 配置 安装 Sidecar 客户端 注册并分配配置 采集并发送到 Graylog Input 典型配置示例（Filebeat） filebeat.inputs: - type: log enabled: true paths: - /var/log/nginx/access.log output.logstash: hosts: ["graylog.example.com:5044"] 小结 Sidecar 适合大规模日志采集。下一章介绍 Extractors。 下一节：4.1 Extractors 入门 返回目录 | 返回首页

3.3 GELF 输入 为什么推荐 GELF GELF（Graylog Extended Log Format）是 Graylog 推荐的结构化日志格式。它支持 JSON 字段，能够减少后续解析的成本。 GELF 输入类型 GELF UDP GELF TCP GELF HTTP 建议使用 GELF TCP/HTTP 以保证可靠性。 示例（应用直接发送） 应用层可以使用 GELF SDK/库直接发送： { "version": "1.1", "host": "api-01", "short_message": "order created", "level": 6, "_service": "order", "_trace_id": "abc123" } 示例（Nginx GELF） 通过 log_format 输出 JSON，然后使用 Sidecar 或输入解析。 小结 GELF 是最适合结构化日志的输入方式。下一章介绍 Beats/Sidecar。 下一节：3.4 Beats/Sidecar 返回目录 | 返回 ...

3.2 Syslog 输入 适用场景 Syslog 是传统设备与操作系统最常见的日志协议。典型来源包括： Linux 系统日志 网络设备（交换机、防火墙） 应用网关与中间件 创建 Syslog Input System → Inputs 选择 Syslog UDP 或 Syslog TCP 绑定节点并配置端口（如 5140） 保存并启动 采集示例（Linux rsyslog） 在客户端 /etc/rsyslog.d/50-graylog.conf： *.* @@graylog.example.com:5140 # TCP # 或 *.* @graylog.example.com:5140 # UDP 重启 rsyslog： systemctl restart rsyslog 解析建议 Syslog 默认是文本，需要配合 Extractors 或 Pipelines 解析字段，比如： 主机名 程序名 日志级别 小结 Syslog Input 是最常用的入口之一。下一章介绍 GELF 输入。 下一节：3.3 GEL ...