journalctl 本身不管理分布式日志，仅用于本地查询；真正实现分布式日志流转的是 systemd-journal-remote，它与 journalctl 共同构成原生、轻量、可信的日志协同体系，支持 tls 双向认证、结构化数据完整保留及中心化存储后的统一查询。
journalctl 本身不直接管理分布式日志，它只是本地查询工具；真正实现分布式日志流转的是 systemd-journal-remote —— 它和 journalctl 共同构成一套原生、轻量、可信的日志协同体系。关键不是“用 journalctl 看远程日志”，而是让 journalctl 能查到已集中存储的、结构完整的二进制日志。
journalctl 如何配合集中化日志使用
中心服务器接收并持久化所有客户端日志后，你仍用 journalctl 查看，只是数据源变了：
- 默认情况下 journalctl 只读本地 /var/log/journal/；要查集中日志，需指定 --directory 或挂载远程日志目录（如 /var/log/journal/central）
- 执行 journalctl --directory /var/log/journal/central -u nginx.service，就能看到所有上报节点中 nginx 的日志，按时间自动合并排序
- 支持完整过滤语法：--since "2 hours ago"、-p err、-o json-pretty 等全部可用，无需额外解析或转换
- 注意权限：/var/log/journal/central 目录需属 group systemd-journal，且用户需在该组内才能读取
systemd-journal-remote 是传输核心，不是可选插件
它不是辅助工具，而是 journald 分布式能力的唯一官方载体：
- 客户端用 systemd-journal-upload（非 curl 或 rsync），直接读 .journal 文件二进制流，零文本解析开销，吞吐稳定
- 服务端用 systemd-journal-remote 监听 HTTPS /upload 端点，原生支持 TLS 双向认证，拒绝未签名请求
- 传输失败时自动重试+本地暂存，网络恢复后补传，不丢日志
- 不依赖 Java、Docker 或中间件，纯 systemd 生态，升级兼容性高
为什么必须配 TLS 双向认证
没加密的日志管道等于裸奔：
- 单向 TLS（仅服务端证书）防不了伪造客户端——攻击者可伪造任意主机名上传垃圾日志，填满磁盘
- 双向认证要求每个客户端持有由同一 CA 签发的 client cert，服务端通过 CertificateVerify 验证身份，再按 CN 或 OU 字段做访问控制
- certbot 自动签发 + hook 续期，比自建 CA 少掉私钥泄露、CRL 同步、证书过期静默失效等运维黑洞
- Ubuntu 20.04 / Debian 10 均支持 systemd-journal-remote 的 ClientCertificate= 和 TrustedCert=/CA.pem 配置项，开箱即用
日志生命周期要闭环管理
集中之后，清理策略更要统一：
- 禁用各客户端的自动轮转（journald.conf 中设置 SystemMaxUse=0 或 MaxFileSec=0），避免本地删日志导致断档
- 只在中心服务器设 vacuum 策略：journalctl --vacuum-time=90d 或 --vacuum-size=50G，确保全量保留窗口一致
- 用 journalctl --disk-usage 实时监控中心存储，配合 systemd timer 触发告警，而非等磁盘写满才发觉
- 备份可直接 tar /var/log/journal/central/，因是标准 .journal 格式，恢复后 journalctl 仍可原样查询
