容器日志收集器断开连接本质是采集链路中断，需重点排查三处：采集器进程是否存活且无报错、是否正确定位并有权限读取日志源路径（如/var/log/containers/）、是否能连通后端存储服务。
容器日志收集器断开连接，本质是采集链路中断，不是容器不输出日志，而是采集器“没看到”或“读不到”。重点查三处：采集器是否在运行、是否能访问日志源路径、是否有权限或配置错位。
确认采集器进程是否存活且无报错
采集器（如 Fluent Bit、Filebeat）本身宕了或启动失败，日志自然停采。不能只看 Pod 或容器状态为 Running，要进日志里看真实运行情况。
- 查采集器自身日志：
kubectl logs -n logging fluent-bit-xxxx（K8s）或docker logs fluent-bit（Docker），留意tail: cannot open、permission denied、connection refused等关键词 - 检查采集器配置加载是否成功：Fluent Bit 日志中应有
[config] configuration loaded successfully；Filebeat 启动时应显示Successfully loaded config from … - 验证采集器健康端点（如有）：比如 Fluent Bit 默认暴露
http://localhost:2020/api/v1/metrics，返回 200 且input_tail_files_active数值 > 0 才算真正接入
核对采集器是否正确定位到日志文件路径
多数采集器不读 Docker 的 /var/lib/docker/containers/xxx/xxx-json.log，而是依赖宿主机上由 Docker 日志驱动生成的符号链接路径（如 /var/log/containers/*.log）。路径错、目录空、软链断，采集器就无从下手。
- 登录宿主机，执行
ls -l /var/log/containers/，确认该目录下有对应容器的日志文件（命名通常含 Pod 名、容器名、UID） - 检查 Docker 日志驱动是否为
json-file：docker info | grep "Logging Driver"，非此驱动（如none或syslog）会导致无文件生成 - 对比采集器配置中的
Path是否与实际路径一致。例如 Fluent Bit 配置写的是Path /var/log/pods/*.log，但实际日志在/var/log/containers/，就会完全漏采
验证采集器是否有权限读取日志文件
容器化采集器常以非 root 用户运行，而 Docker 生成的日志文件默认属主为 root:root，权限为 640。若采集器用户不在 root 组，或未显式提权，会静默跳过。
- 在宿主机上运行
ls -l /var/log/containers/*.log | head -3，查看文件权限和属组 - 进入采集器容器：
docker exec -it fluent-bit sh，尝试手动读取一个日志文件：cat /var/log/containers/nginx-xxx.log | head -5，看是否报 permission denied - 修复方式包括：在 DaemonSet 或 docker run 中添加
securityContext.runAsUser: 0（临时提权），或更安全地将采集器用户加入root组，并确保宿主机上日志组可读（如chmod g+r /var/log/containers/*.log或配置 Dockerlog-opts指定mode）
检查采集器与后端服务的连通性是否正常
即使前段采集成功，若无法把日志发到 Elasticsearch、Loki 或 Log Analytics，也会表现为“日志消失”。此时容器日志在本地存在，但监控界面上看不到。
- 在采集器容器内测试目标地址连通性：
curl -v http://loki:3100/ready或telnet es-cluster 9200 - 查看采集器日志中是否有
failed to flush chunk、connection reset by peer、timeout类错误 - 确认后端服务是否限流或拒绝新连接（如 Loki 的
max_streams_per_user超限、ES 的 circuit breaker 触发）
