容器日志管理需分层设计：采集（Fluent Bit/Filebeat）、传输（Kafka/Redis）、存储（Loki/Elasticsearch/S3）、查询（Grafana+上下文注入），禁用容器内文件落盘，统一输出到stdout/stderr，并打标、缓冲、分级存储与智能告警。
容器日志不能只靠 docker logs 查看，更不能直接写到宿主机磁盘上任其疯长。真正的日志管理需要分层设计：采集、传输、存储、查询，每层都要适配容器的短生命周期和多实例特性。
容器日志源头：规范输出与禁用文件落盘
应用必须将日志输出到 stdout/stderr，这是 Docker 和 Kubernetes 原生支持的日志捕获方式。禁止在容器内写日志文件（如 /var/log/app.log），否则会面临几个问题：
- 容器重启后日志丢失（除非挂载 volume，但增加运维复杂度）
- 多个副本日志路径冲突，难以区分来源
- 日志轮转需额外配置，且无法被平台统一收集
若必须保留文件日志（如某些 Java 应用强依赖 log4j 配置），可使用符号链接将日志文件指向 /dev/stdout，或改用支持 stdout 的日志框架（如 Logback 的 ConsoleAppender）。
日志采集层：选择轻量、可靠、标签丰富的 Agent
推荐使用 Fluent Bit（Kubernetes 官方推荐）或 Filebeat，它们专为容器环境优化：
- 以 DaemonSet 方式部署，每个节点一个实例，低资源占用
- 自动识别容器元数据（pod name、namespace、container ID、labels），打标后便于后续过滤
- 支持 JSON 解析（当应用输出结构化日志时）、字段过滤、采样、限速
- 内置重试与缓冲机制，网络抖动时不丢日志
避免直接用 Logstash：JVM 开销大，启动慢，不适合边缘采集角色。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
传输与存储：解耦采集与后端，按需选型
采集端（Fluent Bit）不应直连 Elasticsearch 或对象存储，中间建议加一层缓冲：
- 短期缓冲：Kafka（高吞吐、多消费者、支持重放）或 Redis（轻量，适合中小规模）
- 长期存储：Elasticsearch（适合检索分析）、Loki（轻量、索引小、与 Prometheus 生态融合好）、或 S3 + Athena（低成本归档+按需查询）
例如：Fluent Bit → Kafka → Fluentd（做富化/路由）→ Loki + Grafana，这套组合兼顾可观测性统一和资源效率。
查询与告警：从“查得到”升级到“看得懂”
原始日志堆砌无意义。关键动作包括：
- 在采集阶段注入业务上下文（如 trace_id、user_id、env=prod），让日志可关联链路追踪
- 用 Grafana + Loki 查询时，善用
logfmt或json解析语法提取字段，避免正则硬编码 - 对高频错误（如 HTTP 5xx、DB connection timeout）配置日志级告警，而非等监控指标异常才响应
- 保留日志时间窗口要合理：热数据（7 天）存 SSD，冷数据（90 天）自动归档至对象存储
不复杂但容易忽略：给所有日志流配置 label 或 tenant 字段，隔离测试/生产、不同业务线的日志权限与存储策略。
