一、K8s可观测性基础：为什么需要监控与日志？

Kubernetes（K8s）作为容器编排领域的标准，其动态、弹性的特性给运维带来了巨大挑战。当集群规模从几个节点扩展到上百节点，应用实例数以千计时，仅依赖传统运维方式已无法满足需求。此时，可观测性（Observability）成为保障集群稳定运行的核心能力，它通过监控（Monitoring）、日志（Logging）和追踪（Tracing）三大支柱，帮助开发者快速定位问题、优化性能并预防故障。

1.1 可观测性的三要素

• 监控：实时采集集群和应用的指标数据（如CPU、内存、网络流量），通过可视化面板展示状态，触发告警。
• 日志：集中存储和分析应用、系统及K8s组件的日志，用于故障排查和审计。
• 追踪：跟踪请求在微服务架构中的完整路径，分析延迟和错误根源（本文暂不深入讨论）。

1.2 初学者的常见痛点

• 不知道如何选择监控工具（Prometheus vs. InfluxDB？）
• 日志分散在多个节点，难以集中查询。
• 告警规则配置不合理，导致“告警风暴”或漏报。

本文将围绕监控与日志，从零开始构建完整的可观测性方案。

二、监控体系搭建：从指标采集到可视化

2.1 核心监控指标分类

指标类型	示例	用途
集群资源指标	CPU使用率、内存剩余量	资源调度与扩容决策
应用性能指标	请求延迟、QPS、错误率	性能优化与SLA保障
自定义业务指标	订单数、用户活跃度	业务健康度评估

2.2 Prometheus：K8s监控事实标准

2.2.1 为什么选择Prometheus？

• 原生支持K8s：通过ServiceMonitor CRD自动发现服务。
• 时序数据库：高效存储和查询指标数据。
• 灵活的告警：通过Alertmanager实现路由、抑制和分组。

2.2.2 快速部署Prometheus

# 使用Prometheus Operator简化部署（推荐）
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  name: prometheus
spec:
  serviceAccountName: prometheus
  resources:
    requests:
      memory: 400Mi
  scrapeInterval: 30s
  serviceMonitorSelector:
    matchLabels:
      team: frontend

2.2.3 关键组件协作流程

1. Exporters：Node Exporter（节点指标）、cAdvisor（容器指标）、自定义Exporter（业务指标）。
2. ServiceMonitor：定义哪些服务需要被监控。
3. Prometheus Server：存储和查询指标。
4. Alertmanager：处理告警并通知（邮件、Slack等）。
5. Grafana：可视化仪表盘。

2.3 监控实践建议

• 标签设计：为指标添加team、env、service等标签，便于多维度筛选。
• 告警阈值：根据历史数据动态调整，避免固定阈值导致的误报。
• 保留策略：设置合理的retention.time（如30天），平衡存储成本与历史分析需求。

三、日志管理：从分散到集中

3.1 K8s日志的挑战

• 多源日志：容器日志、K8s事件、系统日志。
• 动态性：Pod可能频繁重启或迁移，日志位置不固定。
• 海量数据：高并发应用可能每秒产生GB级日志。

3.2 EFK栈：日志集中化解决方案

3.2.1 组件说明

• Elasticsearch：存储和索引日志。
• Fluentd：作为DaemonSet运行在每个节点，收集日志并转发到ES。
• Kibana：日志查询和可视化界面。

3.2.2 部署Fluentd（示例配置）

# fluentd-daemonset.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd
spec:
  template:
    spec:
      containers:
      - name: fluentd
        image: fluent/fluentd-kubernetes-daemonset:v1-debian-elasticsearch
        env:
        - name: FLUENT_ELASTICSEARCH_HOST
          value: "elasticsearch.logging.svc.cluster.local"
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: varlibdockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: varlibdockercontainers
        hostPath:
          path: /var/lib/docker/containers

3.2.3 日志查询技巧

• 结构化日志：在应用中输出JSON格式日志，便于ES索引和查询。

  {"level": "error", "message": "Database connection failed", "trace_id": "abc123"}

• Kibana查询语法：

  level:error AND message:*connection*

• 上下文查看：通过Kibana的“周围日志”功能快速定位问题上下文。

3.3 日志优化建议

• 日志级别控制：生产环境避免输出DEBUG日志，减少存储压力。
• 采样策略：对高频日志（如访问日志）进行随机采样。
• 冷热分离：将历史日志归档到低成本存储（如S3）。

四、进阶实践：统一可观测性平台

4.1 Loki+Prometheus+Tempo组合

• Loki：轻量级日志系统，按标签存储，成本低于EFK。
• Tempo：分布式追踪系统，与Prometheus共享标签模型。
• 优势：统一的标签系统，实现指标、日志、追踪的关联查询。

4.2 开源方案对比

方案	监控	日志	追踪	适用场景
Prometheus+EFK	优秀	优秀	不支持	传统监控+日志需求
Prometheus+Loki+Tempo	优秀	良好	优秀	云原生微服务架构
Datadog	商业SaaS	商业SaaS	商业SaaS	快速上手，预算充足

4.3 自动化告警策略

• 基于SLO的告警：将错误预算（Error Budget）与告警阈值联动。
• 依赖分析：通过服务拓扑图识别关键路径，优先告警核心服务故障。
• 降噪处理：对已知频繁告警（如磁盘空间预警）进行抑制或自动处理。

五、总结与行动建议

1. 从Prometheus+Grafana开始：快速搭建监控仪表盘，覆盖基础资源指标。
2. 逐步完善日志：先实现核心应用的日志集中，再扩展到全量日志。
3. 参与社区：关注K8s SIG Instrumentation动态，使用最新工具（如OpenTelemetry）。
4. 模拟故障：定期进行混沌工程实验，验证可观测性体系的完整性。

下一步行动：

• 部署Prometheus Operator和Grafana，创建第一个自定义仪表盘。
• 在应用中集成结构化日志，通过Fluentd或Loki收集。
• 加入K8s Slack频道#sig-instrumentation，学习最佳实践。

通过系统化的监控与日志管理，即使是K8s初学者也能快速掌握集群状态，从“救火队员”转变为“预防专家”。