从零开始入门 K8s | 可观测性：监控与日志

一、为什么K8s可观测性至关重要？

Kubernetes（K8s）作为容器编排领域的标准，其动态性、分布式特性对运维提出了全新挑战。当集群规模从几个节点扩展到数百节点时，仅依赖传统运维手段已无法满足需求。可观测性（Observability）通过监控（Monitoring）、日志（Logging）、追踪（Tracing）三大支柱，帮助开发者快速定位问题、优化资源使用并保障系统稳定性。

1.1 监控的核心价值

• 实时性：通过指标（Metrics）实时反映集群健康状态（如CPU、内存、网络延迟）。
• 趋势分析：基于历史数据预测容量需求，避免资源过载或闲置。
• 告警机制：在异常发生时主动通知，减少MTTR（平均修复时间）。

1.2 日志的关键作用

• 问题复现：记录容器、Pod、节点的详细运行日志，辅助排查错误。
• 审计追踪：跟踪用户操作、API调用等安全相关事件。
• 业务分析：提取业务指标（如订单量、响应时间）支持决策。

二、K8s监控体系构建

2.1 核心监控对象

• 集群级指标：Node资源使用率、API Server延迟、etcd存储状态。
• Pod级指标：容器CPU/内存限制、重启次数、就绪状态。
• 应用级指标：自定义业务指标（如QPS、错误率）。

2.2 主流监控工具对比

工具	类型	特点
Prometheus	开源时序数据库	支持多维度查询、Alertmanager告警、Grafana可视化，K8s生态首选方案。
Heapster	已弃用	早期K8s内置监控，功能有限，逐步被Metrics Server替代。
Metrics Server	核心组件	采集资源指标（如CPU/内存），供HPA等组件使用，不存储历史数据。
第三方SaaS	如Datadog	提供全托管服务，但成本较高，适合中大型企业。

2.3 Prometheus实战配置

2.3.1 部署Prometheus Operator

# 使用Helm快速部署
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install prometheus prometheus-community/kube-prometheus-stack

2.3.2 自定义监控指标

通过ServiceMonitor捕获应用指标：

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: example-app
spec:
  selector:
    matchLabels:
      app: example
  endpoints:
  - port: web
    path: /metrics
    interval: 30s

2.3.3 告警规则示例

groups:
- name: cpu-alerts
  rules:
  - alert: HighCPUUsage
    expr: sum(rate(container_cpu_usage_seconds_total{namespace="prod"}[1m])) > 0.8
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "Pod {{ $labels.pod }} CPU使用率过高"

三、K8s日志管理方案

3.1 日志收集架构

• 节点级日志：通过kubelet的--container-runtime=remote配置，将容器日志写入/var/log/containers/。
• Sidecar模式：在Pod中部署日志代理（如Fluent Bit）实时收集日志。
• DaemonSet模式：每个节点运行一个日志收集器，统一处理节点上所有Pod的日志。

3.2 主流日志工具对比

工具	类型	优势
Fluentd	开源收集器	支持多种输出（Elasticsearch、S3等），插件生态丰富。
Fluent Bit	轻量级替代	内存占用低（仅需几MB），适合边缘设备。
Loki	日志聚合系统	基于标签查询，与Prometheus集成，成本低于ELK。
EFK栈	企业级方案	Elasticsearch存储+Fluentd收集+Kibana可视化，功能全面但资源消耗高。

3.3 Fluent Bit配置示例

3.3.1 收集容器日志并输出到标准输出

# ConfigMap配置
apiVersion: v1
kind: ConfigMap
metadata:
  name: fluent-bit-config
data:
  fluent-bit.conf: |
    [SERVICE]
        Flush 1
        Log_Level info
        Parsers_File parsers.conf
    [INPUT]
        Name tail
        Path /var/log/containers/*.log
        Parser docker
        Tag kube.*
        Mem_Buf_Limit 5MB
        Skip_Long_Lines On
    [OUTPUT]
        Name stdout
        Match *

3.3.2 部署Fluent Bit DaemonSet

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit
spec:
  template:
    spec:
      containers:
      - name: fluent-bit
        image: fluent/fluent-bit:1.9
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: varlibdockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true
        - name: config
          mountPath: /fluent-bit/etc/
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: varlibdockercontainers
        hostPath:
          path: /var/lib/docker/containers
      - name: config
        configMap:
          name: fluent-bit-config

四、进阶优化策略

4.1 监控数据持久化

• 长期存储：将Prometheus数据远程写入Thanos或Cortex，避免单机存储瓶颈。
• 降采样：对历史数据按时间粒度聚合（如1分钟→5分钟），减少存储开销。

4.2 日志上下文增强

• 结构化日志：应用层输出JSON格式日志，便于后续分析。

  {"level": "error", "timestamp": "2023-01-01T12:00:00Z", "message": "Database connection failed"}

• 关联追踪ID：在日志中加入唯一请求ID，实现跨服务日志关联。

4.3 成本优化

• 采样率调整：对高频日志（如访问日志）按比例采样，平衡信息量与存储成本。
• 冷热数据分离：将30天前的日志归档至低成本存储（如S3 Glacier）。

五、常见问题解决方案

5.1 监控数据丢失

• 原因：Prometheus磁盘空间不足或节点宕机。
• 解决：配置--storage.tsdb.retention.time=30d，并启用持久化存储。

5.2 日志重复收集

• 原因：多个收集器同时抓取同一日志文件。
• 解决：通过fluent-bit的Multiline插件合并多行日志，或使用exclude_path过滤重复路径。

5.3 告警风暴

• 原因：阈值设置过低或依赖链触发连锁告警。
• 解决：引入告警抑制（Inhibition）和分组（Grouping）规则，例如：

  inhibit_rules:
  - source_match:
      severity: "critical"
    target_match:
      severity: "warning"
    equal: ["alertname", "namespace"]

六、总结与行动建议

1. 从Prometheus+Grafana入手：快速搭建可视化监控面板，优先覆盖核心指标。
2. 采用Fluent Bit轻量级方案：中小规模集群推荐DaemonSet部署，大规模可结合Loki。
3. 逐步完善告警策略：从关键业务指标开始，避免“告警疲劳”。
4. 定期复盘可观测性效果：通过事后分析（Post-Mortem）优化监控粒度与日志字段。

通过系统化的可观测性建设，开发者能够显著提升K8s集群的运维效率，将故障定位时间从小时级缩短至分钟级，为业务稳定运行保驾护航。