rsyslog tls转发收不到日志因证书验证失败静默丢弃，需检查$defaultnetstreamdrivercafile路径权限及必配$actionqueue参数；filebeat匹配容器日志需确认docker log-driver及真实路径；logstash timestamp偏差8小时因date插件未设timezone；es写入慢应优先调大bulk队列而非仅改refresh_interval。
rsyslog 配置远程转发时收不到日志？检查 $ActionQueue 和 $DefaultNetstreamDriverCAFile
默认配置下，rsyslog 启用 TLS 转发时会因证书验证失败静默丢弃日志，而不是报错。现象是客户端没报错、服务端收不到任何日志，journalctl -u rsyslog 里也看不到明显提示。
- 确认是否启用了
$DefaultNetstreamDriverCAFile：如果指定了 CA 文件但路径错误或权限不对（比如非 root 可读），连接直接失败且不重试 - TLS 模式下必须配
$ActionQueue系列参数，否则高并发日志会阻塞主线程并丢弃——常见漏配项：$ActionQueueFileName、$ActionQueueMaxDiskSpace、$ActionQueueSaveOnShutdown - 测试连通性别只用
telnet：它不走 TLS；改用openssl s_client -connect <code>server:6514-CAfile /path/to/ca.pem
用 filebeat 收集容器日志，paths 匹配不到 /var/lib/docker/containers/*/*.log？
容器日志路径在不同宿主机上可能被挂载到别处，或被 systemd-journald 接管后根本不在文件系统暴露。硬写绝对路径大概率失效。
- 先查真实日志位置：
docker inspect <code>container_id| grep LogPath，或看/etc/docker/daemon.json中的log-driver设置 - 若用
journald驱动，filebeat 无法直接读文件——得换systemd输入插件，或让 docker 切回json-file -
paths中的通配符不支持递归匹配（**），/var/lib/docker/containers/*/是对的，/var/lib/docker/containers/**/*.log会忽略
elk 中 timestamp 字段总是比实际晚 8 小时？重点看 date 过滤器的 timezone
Logstash 的 date 插件默认按 UTC 解析时间字符串，但日志里常带本地时区偏移（如 "2024-04-10T14:23:01+0800"）。如果配置里没显式指定 timezone，它可能误判为 UTC 时间再转成 @timestamp，结果就差 8 小时。
- 确保
date插件中match对应的格式串和日志时间字符串完全一致，包括毫秒、时区符号（Z或+0800） - 显式加
timezone => "Asia/Shanghai"，而不是依赖系统时区——Logstash 进程的TZ环境变量不影响该字段解析逻辑 - 验证方式：在 Filter 中临时加
ruby { code => 'puts Event.get("@timestamp")' }，看输出是否符合预期
日志量大时 elasticsearch 写入变慢甚至超时？别只调 refresh_interval
单纯把 refresh_interval 从 1s 改成 30s，对吞吐提升有限，还可能让搜索延迟不可控。真正卡点常在 bulk 请求队列和 segment 合并压力上。
- 检查
_nodes/stats/thread_pool中bulk队列长度和拒绝数，若频繁 reject，优先调大thread_pool.bulk.queue_size（默认 200） - 避免单次 bulk 太大（如 >10MB）或文档数太多（如 >1000 条）：filebeat 的
bulk_max_size和bulk_queue_size得配合 ES 的http.max_content_length（默认 100MB） - segment 合并不是瓶颈？关掉
index.merge.scheduler.max_thread_count（设为 1）反而可能更稳——尤其在机械盘或低配节点上
实际部署时，最常被跳过的一步是验证日志端到端时间戳一致性：从应用写入、采集器读取、传输解码、到 ES 存储，每个环节都可能悄悄做一次时区转换或截断。不逐层打日志比对，光看最终结果很容易以为“已经好了”。