容器日志为什么容易乱成一锅粥
想象一下，你家楼下开了个快餐店，一开始只有一个厨师，所有订单都记在小本子上。后来生意好了，雇了十个厨师，各自为战，订单写在不同地方，电话、微信、小程序都有。这时候想查昨天中午谁做了哪单，基本靠猜。
容器化系统也一样。一个应用拆成十几个服务，每个服务又跑在多个容器里，日志分散在不同节点上。开发查问题得登录每台机器翻文件，运维半夜被报警叫起来，连错误发生在哪个实例都不知道。
标准输出才是正道
很多人一上来就想把日志写到文件里，按天切割，压缩归档。这在单机时代没问题，但在Kubernetes这种动态环境里，Pod随时可能被销毁重建，日志文件跟着消失。
正确的做法是让容器把日志往标准输出（stdout）和标准错误（stderr）打。Kubernetes默认会捕获这些输出，通过kubelet转发出去。这样就算容器挂了，只要日志采集器配置得当，数据不会丢。
apiVersion: v1
kind: Pod
metadata:
name: nginx-demo
spec:
containers:
- name: nginx
image: nginx:alpine
ports:
- containerPort: 80
# 日志直接输出，不写文件
args:
- /bin/sh
- -c
- echo \"$(date): 请求进入\" >&1 && sleep 10别再手动grep了
以前在服务器上查日志，三板斧：tail、grep、less。现在面对上百个容器，这套方法完全失效。你需要一个集中式收集方案。
EFK（Elasticsearch + Fluentd + Kibana）是目前最主流的选择。Fluentd作为日志代理部署在每个节点，自动发现新启动的容器，抓取stdout内容，打上标签如namespace、pod_name、container_name，再发给Elasticsearch存储。
给日志加点“身份信息”
光看日志内容不够，得知道它来自谁、属于哪个请求链。比如用户下单失败，你要能从网关日志一路追踪到库存服务、支付服务。
可以在入口处生成一个trace_id，随着请求头传递下去，每个服务记录日志时把这个ID带上。排查时用这个ID一搜，整条调用链就出来了。
# 示例：Go服务中记录带trace_id的日志
func handler(w http.ResponseWriter, r *http.Request) {
traceID := r.Header.Get("X-Trace-ID")
if traceID == "" {
traceID = generateTraceID()
}
log.Printf("trace_id=%s method=%s path=%s status=200", traceID, r.Method, r.URL.Path)
}别让日志拖垮系统
有个团队上了日志采集后，发现Elasticsearch集群老是OOM。查下来是因为某个服务疯狂打印调试日志，每天产生几百GB数据。
要设置合理的日志级别，生产环境至少用INFO，关键服务用WARN或ERROR。可以在Deployment里通过环境变量控制：
env:
- name: LOG_LEVEL
value: "INFO"同时在Fluentd里做过滤，丢掉无用的日志行，或者对高频日志做采样，避免被刷屏。
快速定位问题的实际技巧
Kibana里查日志，别一上来就全文搜索。先用过滤器缩小范围：选中特定namespace、service名称、时间窗口。再结合HTTP状态码筛选，比如只看status:500的记录。
如果某个接口突然变慢，在日志里找对应的响应时间字段，用Kibana画出趋势图，很容易看出是不是数据库慢查询导致的。
真正的效率不是靠工具多高级，而是流程设计合理。日志不是用来“存”的，是用来“用”的。从第一天就规划好结构、字段、采集路径，后面省下的时间远超前期投入。