K8s日志管理方案实战：高效排查线上问题

日志散落各处，查个错误像破案

你有没有过这种经历？线上服务突然报错，用户开始抱怨，你赶紧登录控制台，翻了半天发现日志分布在不同Pod、不同节点，甚至有些容器重启后日志直接没了。最后只能靠猜，哪个服务出的问题，什么时候发生的，参数传对了没……这哪是运维，简直是侦探破案。

为什么K8s的日志特别难管

Kubernetes的弹性伸缩和自动调度本是优点，但也带来了日志收集的麻烦。Pod随时创建销毁，IP动态变化，日志文件不持久化，传统直接上服务器tail -f的方式根本行不通。更别说微服务一多，几十个服务的日志混在一起，想定位一条关键信息，堪比大海捞针。

主流方案不是炫技，是真能省时间

现在大多数团队会选EFK（Elasticsearch + Fluentd/Fluent Bit + Kibana）这套组合。Fluent Bit轻量，适合跑在每个Node上作为DaemonSet收集容器标准输出；Elasticsearch存数据，支持快速检索；Kibana做可视化，查日志就像用搜索引擎。

比如你想查某个订单ID的处理流程，直接在Kibana里搜trace_id，所有相关服务的日志按时间线串出来，从网关到订单服务再到支付回调，一目了然。不用再一个一个服务去翻日志，效率提升不是一点半点。

实际部署配置示例

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit
  namespace: logging
spec:
  selector:
    matchLabels:
      k8s-app: fluent-bit-logging
  template:
    metadata:
      labels:
        k8s-app: fluent-bit-logging
    spec:
      containers:
      - name: fluent-bit
        image: fluent/fluent-bit:2.1.8
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: fluent-bit-config
          mountPath: /fluent-bit/etc/
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: fluent-bit-config
        configMap:
          name: fluent-bit-config

别等出事才想起日志

有些团队平时不重视日志结构，全是print打出来的杂乱文本，等到出问题再想去分析，发现字段没法提取，搜索效率极低。建议从开发阶段就规范日志格式，用JSON输出关键字段，比如request_id、user_id、耗时等，后续查询过滤都能直接用。

小团队也能低成本上手

如果你的业务规模不大，不想搭整套EFK，也可以先用Loki+Promtail+Grafana。Loki不索引日志内容，只存元数据，成本低很多。Promtail负责收集，Grafana查日志体验也不错，还能和监控图表联动。一个小VPS就能跑起来，适合初期投入有限的情况。

Loki采集配置片段

scrape_configs:
- job_name: kubernetes-pods
  pipeline_stages:
    - docker: {}
  kubernetes_sd_configs:
    - role: pod
  relabel_configs:
    - source_labels: [__meta_kubernetes_pod_label_app]
      target_label: app

日志分级管理，避免浪费资源

不是所有日志都得永久保存。调试级别的可以只留24小时，错误日志保留30天以上。通过Fluent Bit或Promtail的过滤规则，把不同级别、不同服务的日志打标分流，既能控制存储成本，又保证关键信息不丢失。

结合告警，让问题主动找你

光能查还不够，得让系统自己发现问题。比如用Prometheus配合Loki，设置规则监控ERROR日志频率，短时间内激增就触发告警。或者在Elasticsearch里配Watcher，检测特定异常关键词，自动通知值班人员。这样不用时刻盯着日志界面，也能第一时间响应故障。

K8s日志管理方案：让排查问题不再靠猜