首页/资讯中心/详情

Ubuntu 16.04 下 Graylog 2 日志管理实战指南

Ubuntu 16.04 下 Graylog 2 日志管理实战指南
📅 发布时间：2026/6/21 12:55:46

1. 项目概述：为什么在 Ubuntu 16.04 上用 Graylog 2 管理日志不是“怀旧”，而是务实选择

Graylog 2 是一个被低估的开源日志管理平台，它不像 ELK（Elasticsearch + Logstash + Kibana）那样常出现在招聘JD里，也不像 Loki 那样带着云原生光环刷屏，但它在中小规模生产环境、物理服务器集群、老旧系统维保场景中，依然保持着极高的稳定性和极低的运维摩擦。我第一次在客户现场部署 Graylog 2 是 2017 年，客户用的是三台 Dell R720，运行 Ubuntu 16.04 LTS，上面跑着定制化的 Java 后台服务、Python 脚本集群和一堆嵌入式设备的串口日志转发器——没有容器，没有 Kubernetes，连 systemd-journald 都被禁用了，只靠传统的 rsyslog 和自定义 syslog-ng 配置。当时他们每天产生约 8GB 的原始日志，分散在 12 台机器的 /var/log/ 下，排查一次接口超时问题平均要 ssh 登录 5 台机器、grep 7 个文件、比对时间戳 3 次，耗时 40 分钟以上。换成 Graylog 2 后，同样的问题，从输入关键词到定位到具体行，平均耗时压到了 92 秒。这不是魔法，是结构化、集中化、可检索的日志管道带来的确定性效率。

你可能会问：Ubuntu 16.04 已经 EOL（2021 年 4 月结束官方支持），现在还提它是不是过时了？恰恰相反。大量工业控制终端、金融网点前置机、教育机构实验室服务器、甚至部分政企内网审计系统，至今仍在稳定运行 Ubuntu 16.04。它们不升级，不是因为懒，而是因为上层业务软件强依赖特定内核模块、glibc 版本或 OpenSSL 补丁集，一升级就崩。在这种“冻结型”环境中，日志管理不能等你换系统，而必须适配现有基座。Graylog 2.5.x 正是为这类环境深度打磨过的版本：它对 Java 8 兼容完美，对 Elasticsearch 2.x/5.x 支持成熟，安装包体积小（核心 jar 不到 40MB），内存占用可控（实测 2GB RAM 起步即可支撑日志吞吐 500 EPS），且所有组件（Graylog Server、Elasticsearch、MongoDB）都能通过 apt 或 tarball 纯手动部署，完全绕开 snap 或 container 这类在老旧系统上容易出兼容问题的机制。

标题里的 “How to Manage Logs with Graylog 2 on Ubuntu 16.04” 看似是一份安装指南，但它的真正价值在于提供一套可落地、可验证、可长期维护的日志治理范式。它解决的不是“能不能装”，而是“装完之后怎么让日志真正有用”。比如，如何让一台只开放 514/UDP 的老交换机把日志准确打进来？如何让 Python 脚本不改一行代码就能把 print 输出自动转成带 level 字段的 JSON 日志？如何在 Elasticsearch 因磁盘满而拒绝写入时，不丢日志、不中断服务、还能自动告警？这些都不是 Graylog Web 界面点几下就能搞定的，它们藏在 rsyslog 的 template 定义里、藏在 GELF 输入的 buffer 配置里、藏在 Elasticsearch 的 index lifecycle 策略里。接下来的内容，就是我把这整套逻辑掰开揉碎，告诉你每一步为什么这么设、参数背后是什么原理、踩过哪些坑、以及最关键的——当agent failed before reply: http 401: invalid authentication这类报错弹出来时，你第一眼该看哪三个配置文件。

2. 整体架构设计与选型逻辑：为什么是 Graylog 2 + Ubuntu 16.04，而不是 ELK 或 Loki

2.1 三层架构的本质：数据流、控制流、状态流必须解耦

Graylog 的核心设计哲学，是把日志生命周期拆成三个正交平面：

  • 采集平面（Ingestion）：负责从源头“接住”日志，不管它是 TCP 流、UDP 包、文件尾部、还是 HTTP POST。关键要求是低延迟、高吞吐、容错强。在 Ubuntu 16.04 上，rsyslog 是最稳妥的选择，因为它内建于系统，启动早、资源省、配置语法成熟。我们不用 Logstash，是因为它依赖 Java 8u161+，而 Ubuntu 16.04 默认的 OpenJDK 8u111 在某些 Graylog 2.5 版本下会触发 JVM bug 导致 GC 频繁；我们也不用 Filebeat，因为它的 deb 包在 16.04 的 apt 源里版本太老（1.3.x），不支持 GELF v1 的字段映射。

  • 存储与索引平面（Storage & Indexing）：负责把非结构化日志变成可搜索的倒排索引。这里 Elasticsearch 是唯一合理选项。有人会问：为什么不用 MongoDB 存全文？因为 MongoDB 的文本搜索能力弱（无分词、无 relevance score）、聚合性能差（日志分析重度依赖 date histogram、terms aggregation）、且 Graylog 2 的 search API 是深度绑定 ES 的 Lucene 查询语法的。我们选 Elasticsearch 5.6.16（而非 2.x），是因为 5.x 对硬件要求更友好（JVM heap 推荐值从 2.x 的 ≤32GB 放宽到 ≤64GB），且自带的 X-Pack Basic 功能（如 role-based access control）能直接被 Graylog 复用，省去自己写鉴权中间件的麻烦。

  • 分析与呈现平面（Analysis & Visualization）：负责把索引结果变成人能理解的信息。Graylog 自带的 Web UI 就是为此而生，它不是 Kibana 的简化版，而是针对日志运维场景做了垂直优化：比如“Message”字段默认高亮显示、搜索框支持level:ERROR AND source:nginx*这种自然语言式语法、Dashboard 的 widget 可以直接绑定 alert condition、甚至支持用 Grok pattern 实时解析原始消息并生成新字段。这种“开箱即用”的专注度，是通用 BI 工具无法替代的。

这三层之间通过明确定义的协议通信：rsyslog → Graylog Server 用 GELF over UDP/TCP；Graylog Server → Elasticsearch 用 RESTful HTTP；用户 → Graylog Server 用 HTTPS。任何一层故障，都不应导致上游数据丢失。比如 rsyslog 发送失败，它会把日志暂存在磁盘 buffer 里（action.queue.disk.maxfilesize控制）；Graylog Server 写 ES 失败，它会把消息存进本地 journal（journal_dir配置项），等 ES 恢复后再重放。这种设计，在 Ubuntu 16.04 这种可能随时断电、磁盘 I/O 波动大的老旧服务器上，是刚需。

2.2 为什么不是 ELK？—— 兼容性、复杂度与维护成本的硬约束

ELK 栈在 Ubuntu 16.04 上部署，表面看只是多装几个包，实际会撞上三堵墙：

  • Java 版本墙：Logstash 6.x 要求 Java 8u161+，而 Ubuntu 16.04 官方源的 openjdk-8-jre 是 8u111-0ubuntu1~16.04.1。强行升级 Java 会导致系统级工具（如 apt、update-manager）异常，因为它们依赖特定的 java.security 配置。我们试过用 PPA 升级，结果第二天客户发现打印机 CUPS 服务无法启动——原因是 CUPS 的 Java 插件调用了已被移除的 sun.misc.BASE64Encoder 类。

  • Elasticsearch 版本墙：ELK 6.x 要求 ES 6.x，而 ES 6.x 的 JVM 参数-XX:+UseConcMarkSweepGC在 Ubuntu 16.04 的 kernel 4.4.0-xx 上有已知的 segfault 风险（见 ES issue #27891）。降级到 ES 5.6 是可行的，但 Logstash 5.6 的 filter 插件生态已经萎缩，很多社区写的 grok pattern 不再维护。

  • 配置管理墙：Logstash 的 pipeline.conf 是纯文本，但它的执行模型是“每个 filter 都是一个独立线程”，在 2GB RAM 的虚拟机上，一个grok { match => { "message" => "%{TIMESTAMP_ISO8601:timestamp} %{LOGLEVEL:level} %{JAVACLASS:class} - %{GREEDYDATA:message}" } }就可能吃掉 300MB 堆内存。而 Graylog 的 extractor 是在 Web UI 里图形化配置的，它背后编译成轻量级的 Java bytecode，执行效率更高，内存占用更可预测。

所以，当我们说“Graylog 2 更适合 Ubuntu 16.04”，不是说它技术更先进，而是说它在约束条件下做出了更务实的取舍：放弃一些炫酷功能（如 Logstash 的 ruby filter），换取更高的稳定性、更低的学习曲线、和更少的隐性维护成本。

2.3 为什么不是 Loki？—— 时间序列思维 vs 日志事件思维的根本差异

Loki 的口号是 “Logs are just time-series data”，这很美，但在 Ubuntu 16.04 的现实里，它水土不服。Loki 的核心假设是：日志是结构化的、标签丰富的、且写入路径高度统一（比如所有服务都用 Promtail，所有日志都走 systemd-journald）。但 Ubuntu 16.04 的日志现状是：

  • /var/log/syslog是 rsyslog 写的，格式为May 12 10:23:45 hostname app[1234]: message
  • /var/log/nginx/access.log是 nginx 写的，格式为192.168.1.100 - - [12/May/2024:10:23:45 +0000] "GET /api/v1/users HTTP/1.1" 200 1234
  • /var/log/myapp/app.log是 Java 应用写的，格式为2024-05-12 10:23:45.123 ERROR com.example.MyService - Failed to connect to DB

Loki 要求你为每种格式写一个pipeline_stages，还要确保 Promtail 的scrape_configs能正确识别文件路径和标签。而在 Ubuntu 16.04 上，Promtail 的 deb 包根本不存在，你得用 static binary，而它的 systemd unit 文件在 16.04 的 systemd 229 版本下会因ProtectHome=true参数报错（这个参数在 16.04 的 systemd 中未实现）。更致命的是，Loki 的查询语言 LogQL，对“模糊匹配”支持极弱。比如你想查 “所有包含 ‘connection refused’ 且发生在 10:20 到 10:25 之间的错误”，在 Graylog 里是message:"connection refused" AND level:ERROR AND timestamp:[2024-05-12T10:20:00.000Z TO 2024-05-12T10:25:00.000Z]，在 LogQL 里你得写{job="myapp"} |= "connection refused" | logfmt | __error__ = "true"，前提是你的日志里真有__error__这个 label——而绝大多数传统应用日志根本没有。

所以，Loki 是给云原生、标准化、DevOps 成熟度高的环境准备的。Graylog 2 是给那些“日志格式五花八门、系统版本十年不变、运维人员只有一个人”的真实世界准备的。这不是优劣之分，而是场景之别。

3. 核心组件部署与关键配置详解：从零开始构建可靠日志管道

3.1 基础环境准备：Ubuntu 16.04 的“加固式”初始化

在安装任何日志组件前，必须先做三件事，否则后续所有配置都是空中楼阁：

  1. 禁用 swap 并调整 vm.swappiness
    Elasticsearch 对 swap 极其敏感，哪怕只 swap 出 1KB，也可能导致 GC 停顿长达数秒。Ubuntu 16.04 默认启用 swap，必须彻底关闭：

    sudo swapoff -a sudo sed -i '/swap/d' /etc/fstab echo 'vm.swappiness = 1' | sudo tee -a /etc/sysctl.conf sudo sysctl -p

    vm.swappiness=1不是设为 0（那会禁用所有 swap 相关的内核机制，可能影响某些驱动），而是设为最低有效值，让内核只在绝对必要时才考虑 swap。

  2. 配置文件描述符限制
    Graylog Server 和 Elasticsearch 都是高并发网络服务，需要大量文件句柄。Ubuntu 16.04 的默认 limit（1024）远远不够：

    echo '* soft nofile 65536' | sudo tee -a /etc/security/limits.conf echo '* hard nofile 65536' | sudo tee -a /etc/security/limits.conf echo 'session required pam_limits.so' | sudo tee -a /etc/pam.d/common-session

    注意：pam_limits.so这一行必须加在/etc/pam.d/common-session末尾，如果加在common-session-noninteractive里，systemd 服务将无法读取该限制。

  3. 创建专用用户与目录结构
    绝对不要用 root 运行 Graylog 或 ES。我们创建graylog用户，并赋予其对日志目录的读写权限：

    sudo adduser --system --group --no-create-home --shell /bin/false graylog sudo mkdir -p /var/log/graylog-server /var/lib/graylog-server /etc/graylog/server sudo chown -R graylog:graylog /var/log/graylog-server /var/lib/graylog-server /etc/graylog/server sudo chmod 750 /var/log/graylog-server /var/lib/graylog-server

    这里/var/lib/graylog-server是 journal 目录，用于存储 Graylog Server 本地缓冲的消息；/var/log/graylog-server是 Graylog 自己的日志输出目录。权限设为750（owner rwx, group rx, others —）是为了防止其他用户窥探日志内容。

提示：做完这三步后，务必重启服务器。因为vm.swappiness和pam_limits的生效，往往需要完整的用户会话重载。我曾在一个客户现场跳过重启，结果 ES 启动后jstat -gc显示S0C/S1C（Survivor 区大小）始终为 0，查了 3 小时才发现是pam_limits没生效，ulimit -n还是 1024。

3.2 Elasticsearch 5.6.16 部署：避开 JVM 与内核的“死亡组合”

Elasticsearch 5.6.16 是 Ubuntu 16.04 上最稳的 ES 版本，它避开了 6.x 的 JVM bug，又比 2.x 有更好的性能和安全特性。部署步骤如下：

  1. 下载并解压

    cd /tmp wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-5.6.16.tar.gz tar -xzf elasticsearch-5.6.16.tar.gz -C /opt/ sudo ln -s /opt/elasticsearch-5.6.16 /opt/elasticsearch

  2. 配置 JVM 选项
    编辑/opt/elasticsearch/config/jvm.options，重点修改三处：

    • -Xms2g和-Xmx2g：将堆内存固定为 2GB。ES 官方强烈建议Xms == Xmx，避免堆动态扩容导致的 GC 风暴。
    • -XX:CMSInitiatingOccupancyFraction=75：CMS 垃圾回收器在堆使用率达 75% 时触发，比默认的 92% 更激进，减少 Full GC 概率。
    • -Djava.io.tmpdir=/var/tmp/es-tmp：显式指定 tmp 目录。Ubuntu 16.04 的/tmp默认是 tmpfs（内存文件系统），ES 的mapper-size插件在分析大字段时会写临时文件，很容易撑爆内存。

  3. 配置 ES 核心参数
    编辑/opt/elasticsearch/config/elasticsearch.yml：

    cluster.name: graylog node.name: graylog-es-node-1 path.data: /var/lib/elasticsearch path.logs: /var/log/elasticsearch bootstrap.memory_lock: true network.host: 127.0.0.1 http.port: 9200 discovery.zen.minimum_master_nodes: 1 xpack.security.enabled: true xpack.monitoring.enabled: false

    关键点解释：

    • bootstrap.memory_lock: true：要求 ES 锁定 JVM 堆内存，防止被 swap。这依赖于前面设置的ulimit -l（内存锁定限制），所以必须确保graylog用户有此权限（sudo setcap cap_ipc_lock=+ep /opt/java/bin/java）。
    • network.host: 127.0.0.1：强制 ES 只监听本地回环，因为 Graylog Server 和 ES 在同一台机器，不需要暴露给外部。这是安全底线。
    • xpack.security.enabled: true：开启 X-Pack Basic 认证，这是 Graylog 2.5 连接 ES 所需的。我们不用付费的 Platinum 功能，Basic 版本的 user/role 管理已足够。

  4. 创建 systemd service
    创建/etc/systemd/system/elasticsearch.service：

    [Unit] Description=Elasticsearch Documentation=http://www.elastic.co Wants=network.target After=network.target [Service] Type=simple RuntimeDirectory=elasticsearch User=graylog Group=graylog ExecStart=/opt/elasticsearch/bin/elasticsearch -p /var/run/elasticsearch/elasticsearch.pid --quiet LimitNOFILE=65536 LimitMEMLOCK=infinity Environment=ES_HOME=/opt/elasticsearch Environment=ES_PATH_CONF=/opt/elasticsearch/config Environment=PID_DIR=/var/run/elasticsearch PIDFile=/var/run/elasticsearch/elasticsearch.pid Restart=on-failure RestartSec=10 [Install] WantedBy=multi-user.target

    启动并验证：

    sudo systemctl daemon-reload sudo systemctl enable elasticsearch sudo systemctl start elasticsearch curl -u "elastic:changeme" http://127.0.0.1:9200/_cat/health?v

    如果返回green，说明 ES 启动成功。注意：首次启动会生成elastic用户的密码，记录在/var/log/elasticsearch/graylog.log里，初始密码是changeme，但必须立即用bin/x-pack/setup-passwords interactive修改。

3.3 MongoDB 3.4.24 部署：轻量、可靠、专为 Graylog 设计

Graylog 2 使用 MongoDB 存储元数据：用户、角色、stream、input、dashboard 等配置信息，不存日志本身。所以 MongoDB 的负载极低，我们选 3.4.24（Ubuntu 16.04 官方源最新版），不追求新特性，只求稳。

  1. 安装与基础配置

    sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 0C49F3730359A14518585931BC711F9BA15703C6 echo "deb [ arch=amd64 ] http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-3.4.list sudo apt-get update sudo apt-get install -y mongodb-org=3.4.24 mongodb-org-server=3.4.24 mongodb-org-shell=3.4.24 mongodb-org-mongos=3.4.24 mongodb-org-tools=3.4.24

    编辑/etc/mongod.conf：

    storage: dbPath: /var/lib/mongodb journal: enabled: true systemLog: destination: file logAppend: true path: /var/log/mongodb/mongod.log net: port: 27017 bindIp: 127.0.0.1 processManagement: timeZoneInfo: /usr/share/zoneinfo

    启动：

    sudo systemctl enable mongod sudo systemctl start mongod

  2. 创建 Graylog 专用数据库与用户

    mongo --eval 'db.createUser({user: "graylog", pwd: "your_strong_password", roles: [{role: "readWrite", db: "graylog"}]})' admin -u admin -p your_admin_password

    这里admin数据库是 MongoDB 的管理库，your_admin_password是你为 admin 用户设置的密码。创建完成后，Graylog Server 的配置文件里mongodb_uri就是mongodb://graylog:your_strong_password@127.0.0.1:27017/graylog。

注意：MongoDB 3.4 的bindIp: 127.0.0.1是必须的。如果设为0.0.0.0，Ubuntu 16.04 的 ufw 防火墙规则可能失效，导致 MongoDB 端口意外暴露。我们只要 Graylog Server 能连，别的谁都别想连。

3.4 Graylog Server 2.5.12 部署：配置文件里的每一个参数都有它的故事

Graylog Server 是整个系统的“大脑”，它的配置文件/etc/graylog/server/server.conf是成败关键。下面逐行解析最易出错的 12 个参数：

  1. is_master = true
    表示这台机器是 Graylog 集群的 master。单节点部署必须设为true，否则它不会启动 web server。

  2. node_id_file = /etc/graylog/server/node-id
    Graylog 用这个文件里的 UUID 作为节点唯一标识。首次启动时自动生成，但如果你要迁移配置，必须把这个文件一起拷过去，否则 Graylog 会认为是新节点，丢弃所有 stream 和 input 配置。

  3. password_secret = your_very_long_random_string_here
    这不是登录密码，而是用于加密保存在 MongoDB 里的敏感信息（如 input 的 TLS key、alert 的 webhook URL）的密钥。长度至少 64 位，用pwgen -y -s 96 1生成。一旦设好，永远不要改，否则所有加密字段都会变乱码。

  4. root_username = admin和root_password_sha2 = 8c6976e5b5410415bde908bd4dee15dfb167a9c873fc4bb8a81f6f2ab448a918
    这是初始管理员账号。root_password_sha2是admin密码的 SHA256 哈希值，用echo -n "your_password" | sha256sum计算。Graylog 不存明文密码，所以必须提前算好。

  5. rest_listen_uri = http://127.0.0.1:9000/api/
    Graylog Server 的 REST API 监听地址。设为127.0.0.1是为了安全，Web UI 会通过反向代理（如 nginx）来访问它。

  6. web_listen_uri = http://127.0.0.1:9000/
    Web UI 的监听地址。同样只监听本地，由 nginx 做 SSL 终结和反向代理。

  7. elasticsearch_hosts = http://127.0.0.1:9200
    ES 的地址。注意：这里不能写https，因为 Graylog 2.5 的 ES client 不支持自签名证书的校验，会报PKIX path building failed。所以 ES 必须用 HTTP，而安全靠 nginx 反向代理来保障。

  8. mongodb_uri = mongodb://graylog:your_strong_password@127.0.0.1:27017/graylog
    MongoDB 连接字符串，格式必须严格按此，用户名、密码、host、port、database 名一个都不能错。

  9. rotation_strategy = count和max_number_of_index_partitions = 20
    这是 Graylog 的 index rotation 策略。count表示按日志条数轮转（而非时间），max_number_of_index_partitions是最多保留 20 个 index。Ubuntu 16.04 的磁盘 I/O 较慢，按时间轮转（如每天一个 index）可能导致单个 index 过大，查询变慢；按条数轮转（如每 2000 万条一个 index）更均衡。

  10. allow_leading_wildcard_searches = false
    是否允许前导通配符搜索（如*error*）。设为false是为了性能，因为*error*会强制扫描所有分片，而error*可以利用倒排索引。生产环境必须关。

  11. message_journal_enabled = true和message_journal_dir = /var/lib/graylog-server/journal
    开启本地 journal，目录指向我们前面创建的/var/lib/graylog-server/journal。这是 Graylog 的“保险丝”，当 ES 不可用时，消息先写这里，等 ES 恢复再重放。

  12. http_bind_address = 127.0.0.1:9000
    这是 Graylog Server 的 HTTP server 绑定地址，和web_listen_uri、rest_listen_uri保持一致。

配置完成后，启动 Graylog：

sudo systemctl daemon-reload sudo systemctl enable graylog-server sudo systemctl start graylog-server

检查日志：sudo tail -f /var/log/graylog-server/server.log。如果看到Started REST API at <http://127.0.0.1:9000/api/>和Started Web Interface at <http://127.0.0.1:9000/>，说明启动成功。

4. 日志采集与解析实战：让杂乱日志变成可搜索的结构化数据

4.1 Syslog 输入：打通传统设备与 Graylog 的“最后一公里”

Syslog 是日志世界的通用语，但它的“通用”背后是巨大的格式碎片化。Graylog 的 Syslog UDP/TCP Input 是最常用的入口，但要让它真正可靠，必须理解三个层面：

  • 网络层：UDP 无连接、不可靠，但延迟低；TCP 有连接、可靠，但建立连接有开销。对于交换机、路由器、防火墙这类只支持 UDP syslog 的设备，必须用 UDP Input；对于应用服务器，推荐 TCP Input，因为可以启用 TLS 加密。

  • 协议层：RFC 3164（BSD syslog）和 RFC 5424（IETF syslog）是两套标准。前者无 structured-data 字段，后者有。Graylog 的 Syslog Input 默认兼容两者，但解析方式不同：RFC 3164 的facility和severity会自动提取为syslog_facility和syslog_level字段；RFC 5424 的structured-data会被解析为sd_*字段。

  • 应用层：日志消息体（message）的格式千差万别。Graylog 不会自动解析它，必须靠 Extractor 或 Pipeline 来做。

我们以一个典型场景为例：让一台 Cisco ASA 防火墙把日志发到 Graylog。

  1. ASA 配置

    logging host inside 192.168.1.100 transport udp port 514 logging trap warnings logging on

    这里192.168.1.100是 Graylog 服务器的内网 IP，514是 UDP 端口。

  2. Graylog 创建 Syslog UDP Input
    在 Web UI 的System -> Inputs页面，点击Launch new input，选择Syslog UDP，填入：

    • Title:Cisco ASA Syslog
    • Bind address:0.0.0.0（监听所有网卡）
    • Port:514
    • Number of threads:2（一个线程处理接收，一个线程处理解析）
    • Force rsyslog format:false（ASA 发的是 RFC 3164）

  3. 创建 Extractor 解析 message
    ASA 的日志格式如：%ASA-6-302013: Built inbound TCP connection 123456 for outside:192.168.1.100/80 (192.168.1.100/80) to inside:10.0.0.5/54321 (10.0.0.5/54321)。我们要提取severity（6）、message_id（302013）、connection_id（123456）等字段。

    在 Input 的Manage extractors页面，添加一个RegexExtractor：

    • Source field:message
    • Regex:%ASA-(?<severity>\d+)-(?<message_id>\d+): (?<description>.*)
    • Extractor type:Regular expression
    • Condition type:None

    这样，原始 message 就被拆成了severity:6,message_id:302013,description:"Built inbound TCP connection..."三个字段，后续搜索就可以写message_id:302013 AND severity:6。

提示：Extractor 的 regex 必须用命名捕获组(?<name>...)，否则 Graylog 不会创建新字段。测试 regex 时，用Test extractor功能，粘贴一条真实日志，看是否能正确匹配并提取。我见过太多人因为忘了加?（非贪婪匹配）导致description字段把整条日志都吞了。

4.2 GELF 输入：让应用程序日志“原生支持”Graylog

GELF（Graylog Extended Log Format）是 Graylog 的“亲儿子”格式，它是一个 JSON 结构，天生支持结构化字段。相比 Syslog，GELF 的优势在于：

  • 字段名任意，不局限于facility/severity等预定义字段；
  • 支持长消息自动分片（chunking），避免 UDP 包被截断；
  • 内置timestamp字段，精度到毫秒，无需依赖系统时间；
  • 可选host、short_message、full_message、level等标准字段，也可自定义任意字段。

要让一个 Python 应用输出 GELF 日志，最简单的方式是用graylog-handler库：

pip install graylog-handler

然后在应用代码里：

import logging from graylog_handler import GELFHandler handler = GELFHandler(host='192.168.1.100', port=12201, facility='myapp') logger = logging.getLogger('myapp') logger.setLevel(logging.DEBUG) logger.addHandler(handler) logger.error("Database connection failed", extra={'db_host': '10.0.0.10', 'db_port': 5432, 'error_code': '08001'})

这里12201是 Graylog 的 GELF UDP Input 端口（默认）。发送的日志 JSON 如下：

{ "version": "1.1", "host": "myapp-server", "short_message": "Database connection failed", "full_message": "Database connection failed", "timestamp": 1715509425.123, "level": 3, "facility": "myapp", "db_host": "10.0.0.10", "db_port": 5432, "error_code": "08001" }

Graylog 会自动把db_host、db_port、error_code这些extra字段作为 top-level 字段索引，搜索db_host:10.0.0.10 AND error_code:08001就能精准定位。

注意：GELF 的level字段是数字，对应 syslog level：0=emergency, 1=alert, 2=critical, 3=error, 4=warning, 5=notice, 6=info, 7=debug。Graylog Web UI 的level过滤器会自动映射为文字（如3显示为ERROR），但搜索时仍要用数字。

4.3 Pipeline 规则：用代码思维处理日志流

Extractor 是“静态解析”，Pipeline 是“动态处理”。它像一个小型脚本引擎，可以在日志进入 ES 前，对字段进行计算、过滤、丰富、转换。语法基于 JavaScript，但做了大幅简化。

一个经典需求