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

原创 于 2026-06-20 09:47:44 发布 · 256 阅读 · 6 ·
本内容遵循CC 4.0 BY-SA版权协议
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
GEO检测
标签
#Graylog 2 #Ubuntu 16.04 #日志管理

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 页面，添加一个 Regex Extractor：

    • 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，但做了大幅简化。

一个经典需求

linux 日志管理 pdf,Ubuntu 16.04上安装配置 Graylog 2 日志管理系统
weixin_32688155的博客
05-02 391
Graylog：强大的日志管理系统Graylog是一款开源的日志管理系统，可以从任何来源解析和丰富日志消息，有线和事件数据，从而为第三方收集器(如fluentd，beats和nxlog)提供集中式配置管理系统。 例如，使用Graylog可以丰富使用从IP地址转换的地理坐标的日志消息，或将用户ID映射到用户名。特征Graylog最著名的功能包括：中央日志管理系统，使您的团队可以访问运行时配置和日志数...
ubuntu20.04 部署graylog
chenpeiyanbing的博客
08-26 951
Graylog 是开源集中式日志管理解决方案，和ELK类似功能。
Ubuntu 16.04 Graylog2日志服务安装教程
DeMonnnnnn
10-19 2184
前言本文基于Ubuntu 16.04系统。 Graylog2 -具有报警选项的可插入日志和事件分析服务器。 Graylog2官网：https://www.graylog.org/ Graylog2及相关所需环境： 1. Java (>= 8) Ubuntu 16.04 配置JDK及环境变量 2. MongoDB (>= 2.4) 3. Elasticsearch (>= 2.x) Gr
Ubuntu 16.04下部署Graylog日志服务器
weixin_34413103的博客
11-01 749
Graylog 是一个开源的日志管理系统，集中式收集、索引、分析其它服务器发来的日志。它是由 Java 语言编写的，能够接收 TCP、UDP、AMQP 协议发送的日志信息，并且使用 Mongodb 做为后台数据库。它还有一个使用 Ruby 编写的 Web 管理接口，可以轻松管理 Graylog 和查询日志。 Graylog 可以收集监控多种不同应用的日志...
10W无线充PCB.pcb
06-23
10W无线充PCB
婴儿监视器测试用例#时长最标准#最详细的
06-23
婴儿监视器测试用例#时长最标准#最详细的
曹振全2647102155
最新发布
06-23
曹振全2647102155
2025-2026 第二学期数据库应用技术期末考查方案及评分标准.docx
06-23
2025-2026 第二学期数据库应用技术期末考查方案及评分标准.docx
直驱式永磁同步电机矢量控制仿真模型研究（Simulink仿真实现）
06-23
内容概要：本文围绕直驱式永磁同步电机（PMSM）的矢量控制策略开展系统性研究，基于Simulink平台构建了完整的闭环仿真模型，深入探讨了电机在矢量控制下的动态响应特性与控制性能。研究内容涵盖了矢量控制的核心理论与关键技术模块，包括Clarke与Park坐标变换、转子磁场定向控制（FOC）、SVPWM调制算法、双闭环PI控制器（电流环与速度环）的设计与参数整定。通过仿真验证了系统在启动、突加负载及变速工况下的稳定性、抗干扰能力与动态调节精度，有效实现了对电机转矩与转速的精确控制。该模型不仅有助于深化对PMSM控制机理的理解，也为高性能电机驱动系统的算法开发与工程化应用提供了可靠的仿真验证平台。; 适合人群：具备自动控制原理、电机学基础及Simulink仿真能力的电气工程、自动化、新能源等相关专业的高年级本科生、研究生以及从事电机驱动开发的初级科研人员与工程师。; 使用场景及目标：①作为高校课程设计、毕业设计或科研项目中PMSM控制系统的学习案例，用于掌握矢量控制算法的实现流程与模块化设计方法；②帮助研究人员理解各控制环节间的耦合关系，通过调整PI参数优化系统性能，并为进一步研究无传感器控制、弱磁扩速、先进非线性控制策略等高级课题奠定基础； 阅读建议：建议结合经典电机控制教材同步学习，重点剖析各功能模块的信号流向与数学原理，亲自动手搭建仿真模型，通过改变运行条件和控制器参数观察系统响应变化，从而深入掌握矢量控制系统的动态特性和调试技巧。
调整电脑微信小程序大小
06-23
调整电脑微信小程序大小，电脑打开小程序字体太大，通过调整模拟手机访问效果。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值