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

一、K8s可观测性体系概述

Kubernetes（K8s）作为容器编排领域的标杆技术，其可观测性体系由监控（Metrics）、日志（Logging）和追踪（Tracing）三大支柱构成。对于从零开始的开发者而言，理解这三者的协同机制至关重要：监控解决系统运行状态感知问题，日志提供事件级详细记录，追踪则用于分析请求全链路。

1.1 监控的核心价值

K8s集群的监控数据分为资源指标（CPU/内存使用率）和自定义指标（业务请求量）。通过Prometheus等工具采集的指标数据，可实现：

• 资源使用率可视化（如通过Grafana展示Node资源负载）
• 自动扩缩容决策（HPA基于CPU/内存指标触发）
• 异常检测（如Pod频繁重启时的告警）

1.2 日志的必要性

K8s环境下日志呈现多层次特征：

• 应用日志：开发者通过标准输出（stdout/stderr）打印的业务日志
• 系统日志：Kubelet、API Server等组件生成的运维日志
• 审计日志：记录集群操作的安全日志

典型日志处理流程：Sidecar模式采集 → 集中存储 → 检索分析。例如，一个Java应用可通过log4j2配置输出JSON格式日志，便于后续解析。

二、监控体系搭建实战

2.1 Prometheus监控方案

2.1.1 核心组件部署

# prometheus-deployment.yaml示例
apiVersion: apps/v1
kind: Deployment
metadata:
  name: prometheus
spec:
  template:
    spec:
      containers:
      - name: prometheus
        image: prom/prometheus:v2.47.0
        args:
        - "--config.file=/etc/prometheus/prometheus.yml"
        ports:
        - containerPort: 9090

关键配置要点：

• ServiceMonitor：通过Prometheus Operator自动发现服务
• Relabeling规则：过滤无效目标（如排除job="kube-scheduler"的本地实例）
• 存储策略：建议配置TSDB存储保留期（--storage.tsdb.retention.time=30d）

2.1.2 指标采集实践

• Node Exporter：采集主机级指标（CPU/磁盘/网络）
• cAdvisor：内置于Kubelet，提供容器级资源指标
• 自定义Exporter：如通过blackbox_exporter监控HTTP服务可用性

2.2 Grafana可视化配置

推荐仪表盘模板：

• K8s集群概览：整合Node、Pod、Deployment状态
• 资源利用率热力图：按Namespace分组展示CPU使用趋势
• 自定义告警面板：关联Prometheus Alertmanager规则

三、日志系统构建方案

3.1 EFK日志栈部署

3.1.1 Elasticsearch集群配置

# es-statefulset.yaml关键配置
spec:
  template:
    spec:
      initContainers:
      - name: increase-vm-max-map-count
        image: busybox
        command: ["sysctl", "-w", "vm.max_map_count=262144"]
      containers:
      - name: elasticsearch
        env:
        - name: discovery.type
          value: single-node  # 测试环境简化配置

存储优化建议：

• 使用SSD磁盘并配置index.buffer_size: 512mb
• 索引生命周期管理（ILM）策略：按时间滚动索引（如logs-*-{now/d-1d}）

3.1.2 Fluentd采集配置

关键配置片段：

<match **>
  @type elasticsearch
  host "#{ENV['FLUENT_ELASTICSEARCH_HOST']}"
  port "#{ENV['FLUENT_ELASTICSEARCH_PORT']}"
  logstash_format true
  <buffer>
    @type file
    path /var/log/fluentd-buffers
    timekey 1d
    timekey_wait 10m
  </buffer>
</match>

采集策略优化：

• 多行日志合并：针对Java堆栈日志配置<parse>模块
• 标签增强：添加kubernetes.namespace_name等元数据

3.2 Loki轻量级方案

对于资源受限环境，Loki提供高效替代方案：

• 日志压缩：基于LogQL的标签过滤减少数据量
• 低成本存储：可对接S3/MinIO对象存储
• 与Prometheus集成：共享告警规则引擎

四、生产环境最佳实践

4.1 监控告警策略设计

• 分级告警：

  • P0（集群级故障）：Node NotReady持续5分钟
  • P1（服务降级）：Pod CrashLoopBackOff
  • P2（资源预警）：内存使用率>85%持续10分钟

• 抑制规则：避免告警风暴（如节点故障时抑制其上所有Pod告警）

4.2 日志管理规范

• 日志格式标准化：推荐JSON格式，包含traceID、timestamp等字段
• 存储周期：根据合规要求设置（如金融行业保留3年）
• 敏感信息脱敏：通过Fluentd的<filter>模块过滤信用卡号等数据

4.3 性能优化技巧

• 监控数据采样：对高频指标（如请求延迟）设置[5m]的采样间隔
• 日志分级存储：热数据存SSD，冷数据转存对象存储
• Prometheus联邦：分片采集大规模集群数据

五、故障排查案例

案例1：监控数据缺失

现象：Grafana中部分Pod指标显示为N/A
排查步骤：

1. 检查Prometheus Targets页面，确认目标状态为UP
2. 执行kubectl logs prometheus-xxx查看采集错误
3. 发现是ServiceMonitor的namespaceSelector配置错误

案例2：日志检索超时

现象：Kibana查询30天前日志时响应缓慢
解决方案：

1. 检查Elasticsearch集群状态（GET _cluster/health）
2. 发现分片数量过多（>5000个），执行curl -XPOST "localhost:9200/_flush"强制刷新
3. 调整index.number_of_shards为更合理的值（如按日期索引分片）

六、工具链选型建议

场景	推荐方案	替代方案
中小规模集群	Prometheus+Grafana+EFK	Prometheus+Loki
多云环境	Thanos+Cortex	商业APM方案
安全合规场景	ELK Stack（FIPS认证版）	Graylog

七、进阶学习路径

1. 深度监控：学习eBPF技术实现无侵入式指标采集
2. 日志分析：掌握ELK Stack的机器学习异常检测
3. 可观测性平台：研究OpenTelemetry的统一采集标准

通过系统构建监控与日志体系，开发者不仅能快速定位K8s环境问题，更能基于数据驱动进行容量规划、性能调优等高级运维操作。建议从Prometheus+Grafana基础监控入手，逐步扩展至全链路可观测性建设。