journalctl 是 systemd 日志唯一完整入口，实时跟踪用 -u unit.service -f，精确过滤用 -o json 配合 jq，时间范围用 --since，日志指标需 mtail/promtail 中间层，journald 丢日志需调 ratelimit 和 systemmaxuse，logrotate 失效主因是 inode 变更。
怎么用 journalctl 实时看服务日志并过滤关键字段
journalctl 是 systemd 日志的入口，不是“看日志的备选方案”，而是唯一能拿到完整上下文（如 cgroup、unit 依赖、启动环境）的方式。直接 tail -f /var/log/syslog 会漏掉 early-boot 阶段和非 syslog 协议写入的日志。
- 实时跟踪某个服务：用
journalctl -u <code>nginx.service-f，不是nginx—— 必须带.service后缀，否则匹配不到 unit - 按字段精确过滤：比如只看含特定 HTTP 状态码的请求，用
journalctl -u <code>nginx.service| grep " 404 " 不可靠（可能跨行或被截断），应改用journalctl -u <code>nginx.service-o json | jq 'select(.MESSAGE | contains("404"))' - 时间范围要加
--since而非靠grep筛：因为 journal 本身支持纳秒级时间戳索引，journalctl -u <code>nginx.service--since "2024-05-20 14:30:00" 比管道进awk快一个数量级
prometheus-node-exporter 抓不到自定义日志指标怎么办
node_exporter 默认不解析日志内容，它只暴露系统级指标（CPU、磁盘、网络）。想把日志里的错误计数变成 Prometheus 指标，必须引入中间层——通常是 mtail 或 promtail，而不是改 node_exporter 配置。
-
mtail更轻量，适合单机部署：写一个nginx_error.mtail规则文件，匹配"[error]"并累加nginx_errors_total计数器，然后mtail -progs /etc/mtail/ -logs /var/log/nginx/error.log -
promtail适合集群场景，但注意它默认不开启指标暴露：必须在配置中显式设置scrape_configs和metrics_instance，否则/metrics端口返回 404 - 别把日志路径硬编码进 mtail 规则里：用
-logs参数传入，规则里只写匹配逻辑，否则日志轮转（logrotate）后 mtail 会丢失句柄
systemd-journald 写入性能差导致日志丢弃怎么调
当 journalctl -u <code>myapp.service 显示 “Dropped 1234 messages” 时，说明 journald 的内存/磁盘缓冲区已满，不是磁盘慢，而是默认配置太保守。
- 先确认丢弃源头：运行
journalctl --disk-usage，如果显示 “Archived and active journals take up ...”，说明是磁盘空间不足；若显示 “MaxFileSec=1month”，则是时间策略导致旧日志未及时归档 - 调整核心参数：编辑
/etc/systemd/journald.conf，把SystemMaxUse=512M（默认 10% 根分区）改成固定值，同时设RateLimitIntervalSec=30和RateLimitBurst=10000（默认是 10s/1000 条），避免突发日志被限流 - 禁用
Storage=volatile：这个选项会让日志全存在/run/log/journal（内存 tmpfs），机器重启就清空，监控告警依赖日志回溯时等于没日志
用 logrotate 切 nginx 日志后 promtail/mtail 失效的常见原因
logrotate 默认用 create 指令新建文件，但不会保留原 inode —— 这会导致正在 tail 的进程继续读旧文件（已重命名），新日志写入空文件却没人读。这不是配置问题，是 Linux 文件系统机制决定的。
- 必须在 logrotate 配置里加
copytruncate：它先复制再清空原文件，inode 不变，mtail/promtail 不会中断 - 或者用
sharedscripts+postrotate发信号：比如kill -USR1 `cat /var/run/nginx.pid`，让 nginx 自己 reopen 日志文件（更干净，但要求程序支持） - 检查
logrotate是否真执行了：加verbose参数跑一次，观察输出里有没有 “rotating log /var/log/nginx/access.log”，很多丢日志问题其实是因为 cron 没跑、权限不对、或配置文件没被 include 进主配置
日志和监控真正咬合住的地方，从来不在工具链多炫酷，而在每个环节是否清楚自己处理的是“流”还是“快照”、是否意识到 inode 和文件名是两回事、以及是否敢关掉默认的 rate limit。
