Skip to content

Amazon EKS 监控和日志记录 ​

最后更新: July 3, 2026

有效的监控和日志记录对于维护 Amazon EKS clusters 的可靠性、可用性和性能至关重要。本文档介绍在 EKS clusters 中实施监控和日志记录的各种工具、技术和最佳实践。

目录 ​

  1. 监控和日志记录概述
  2. EKS Control Plane 日志记录
  3. Container 日志记录
  4. Cluster 监控
  5. 告警和事件管理
  6. 日志分析和可视化
  7. 监控和日志记录最佳实践
  8. 故障排查和调试

监控和日志记录概述 ​

监控和日志记录的重要性 ​

Amazon EKS clusters 中的监控和日志记录非常重要,原因如下:

  1. 可见性: 提供对 cluster 状态、性能和行为的可见性
  2. 问题检测: 在问题变得严重之前及早检测
  3. 趋势分析: 识别一段时间内的性能和资源使用趋势
  4. 容量规划: 预测并规划资源需求
  5. 安全和审计: 检测安全事件并满足合规要求
  6. 故障排查: 在问题发生时实现快速诊断和解决

监控和日志记录架构 ​

EKS cluster 的全面监控和日志记录架构由以下组件组成:

监控和日志记录策略 ​

按照以下步骤制定有效的监控和日志记录策略:

  1. 定义目标: 定义监控和日志记录目标与需求
  2. 识别 Metrics 和 Logs: 识别要收集的关键 metrics 和 logs
  3. 选择工具: 选择满足需求的监控和日志记录工具
  4. 建立基线: 为正常行为建立基线
  5. 配置 Alerts: 为重要事件和阈值配置 alerts
  6. 自动化: 尽可能自动化监控和日志记录流程
  7. 定期审查: 定期审查并改进监控和日志记录策略

EKS Control Plane 日志记录 ​

Amazon EKS 提供将 cluster Control Plane logs 发送到 Amazon CloudWatch Logs 的能力。这提供了对 cluster control components 的可见性。

Control Plane Log 类型 ​

EKS 支持以下 Control Plane log 类型:

  1. API Server (api): Kubernetes API server logs
  2. Audit (audit): Kubernetes audit logs
  3. Authenticator (authenticator): AWS IAM authenticator logs
  4. Controller Manager (controllerManager): Controller manager logs
  5. Scheduler (scheduler): Kubernetes scheduler logs

启用 Control Plane Logging ​

你可以使用 AWS Management Console、AWS CLI 或 eksctl 启用 Control Plane logging:

使用 AWS CLI ​

bash
aws eks update-cluster-config \
  --region us-west-2 \
  --name my-cluster \
  --logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}'

使用 eksctl ​

bash
eksctl utils update-cluster-logging \
  --region us-west-2 \
  --cluster my-cluster \
  --enable-types api,audit,authenticator,controllerManager,scheduler

查询 Control Plane Logs ​

你可以使用 CloudWatch Logs Insights 查询 Control Plane logs:

API Server 错误查询 ​

fields @timestamp, @message
| filter @message like /Error/
| sort @timestamp desc
| limit 20

身份验证失败查询 ​

fields @timestamp, @message
| filter @message like /authentication failed/
| sort @timestamp desc
| limit 20

Audit Log 查询 ​

fields @timestamp, @message
| filter @message like /responseStatus.code="403"/
| sort @timestamp desc
| limit 20

Control Plane Log 保留和成本管理 ​

你可以在 CloudWatch Logs 中配置 log 保留周期以管理成本:

bash
aws logs put-retention-policy \
  --log-group-name /aws/eks/my-cluster/cluster \
  --retention-in-days 30

EKS Capabilities Logging (GitOps, ACK, kro) ​

EKS Capabilities 在 EKS Control Plane 上将 Argo CD、AWS Controllers for Kubernetes (ACK) 和 kro 作为托管 controllers 运行。它们的 controller logs 现在可以直接传送到 CloudWatch Logs、S3 或 Kinesis Data Firehose,使用与 Control Plane logging 相同的传送选项,而无需在 cluster 中运行单独的 log collector 来抓取 controller pods。

这弥补了过去需要直接检查 controller pods 的可见性缺口:

  • GitOps sync 错误 from Argo CD
  • 失败的 resource reconciliation from ACK
  • Workflow state transitions from kro

为你运行的 capabilities 启用 log delivery,并同时启用标准 Control Plane logging,然后用 CloudWatch Logs Insights 以查询 API server 或 audit logs 相同的方式查询结果。有关当前支持的 capability log types 列表,请参阅 公告(June 4, 2026)。

Container 日志记录 ​

Container logs 为诊断和解决 application 问题提供重要信息。在 EKS 中,你可以通过多种方式收集和管理 container logs。

日志记录架构 ​

EKS 中典型的 container logging 架构如下:

使用 Fluent Bit 收集 Logs ​

Fluent Bit 是一种轻量级 log collector,广泛用于在 EKS clusters 中收集 container logs:

Fluent Bit 安装 ​

使用 Helm 安装 Fluent Bit:

bash
helm repo add aws-for-fluent-bit https://aws.github.io/eks-charts
helm repo update
helm install aws-for-fluent-bit aws-for-fluent-bit/aws-for-fluent-bit \
  --namespace kube-system \
  --set cloudWatch.region=us-west-2 \
  --set cloudWatch.logGroupName=/aws/eks/my-cluster/fluentbit

Fluent Bit 配置 ​

用于自定义配置的 ConfigMap:

yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: fluent-bit-config
  namespace: kube-system
data:
  fluent-bit.conf: |
    [SERVICE]
        Flush         5
        Log_Level     info
        Daemon        off
        Parsers_File  parsers.conf

    [INPUT]
        Name              tail
        Tag               kube.*
        Path              /var/log/containers/*.log
        Parser            docker
        DB                /var/log/flb_kube.db
        Mem_Buf_Limit     5MB
        Skip_Long_Lines   On
        Refresh_Interval  10

    [FILTER]
        Name                kubernetes
        Match               kube.*
        Kube_URL            https://kubernetes.default.svc:443
        Kube_CA_File        /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
        Kube_Token_File     /var/run/secrets/kubernetes.io/serviceaccount/token
        Merge_Log           On
        K8S-Logging.Parser  On
        K8S-Logging.Exclude Off

    [OUTPUT]
        Name              cloudwatch
        Match             kube.*
        region            us-west-2
        log_group_name    /aws/eks/my-cluster/fluentbit
        log_stream_prefix container-
        auto_create_group true

    [OUTPUT]
        Name              es
        Match             kube.*
        Host              search-my-es-domain.us-west-2.es.amazonaws.com
        Port              443
        TLS               On
        AWS_Auth          On
        AWS_Region        us-west-2
        Index             eks-logs
        Suppress_Type_Name On

CloudWatch Container Insights ​

CloudWatch Container Insights 收集、聚合并汇总来自 containerized applications 和 microservices 的 metrics 和 logs:

安装 Container Insights ​

bash
ClusterName=my-cluster
RegionName=us-west-2
FluentBitHttpPort='2020'
FluentBitReadFromHead='Off'
[[ ${FluentBitReadFromHead} = 'On' ]] && FluentBitReadFromTail='Off'|| FluentBitReadFromTail='On'
[[ -z ${FluentBitHttpPort} ]] && FluentBitHttpServer='Off' || FluentBitHttpServer='On'

kubectl apply -f https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/quickstart/cwagent-fluent-bit-quickstart.yaml

Container Insights Dashboard ​

在 CloudWatch console 中访问 Container Insights dashboard,以监控:

  • Node、pod 和 container 级别的 CPU 与内存使用量
  • 网络和磁盘 I/O
  • Pod 和 container 状态
  • Cluster 故障和事件

自定义日志记录方案 ​

你可以针对特定需求实施自定义日志记录方案:

EFK (Elasticsearch, Fluentd, Kibana) Stack ​

bash
# Install Elasticsearch
helm repo add elastic https://helm.elastic.co
helm repo update
helm install elasticsearch elastic/elasticsearch \
  --namespace logging \
  --create-namespace \
  --set replicas=3

# Install Fluentd
helm install fluentd stable/fluentd \
  --namespace logging \
  --set output.host=elasticsearch-master.logging.svc.cluster.local

# Install Kibana
helm install kibana elastic/kibana \
  --namespace logging \
  --set service.type=LoadBalancer

PLG (Promtail, Loki, Grafana) Stack ​

bash
# Install Loki and Promtail
helm repo add grafana https://grafana.github.io/helm-charts
helm repo update
helm install loki grafana/loki-stack \
  --namespace logging \
  --create-namespace \
  --set grafana.enabled=true \
  --set promtail.enabled=true \
  --set loki.persistence.enabled=true \
  --set loki.persistence.size=10Gi

Log 结构化和解析 ​

建议使用结构化 log 格式以实现有效的 log 分析:

JSON Log 格式 ​

从你的 application 以 JSON 格式输出 logs:

json
{
  "timestamp": "2025-07-11T13:00:00Z",
  "level": "INFO",
  "message": "Request processed successfully",
  "request_id": "12345",
  "user_id": "user-789",
  "duration_ms": 45,
  "status_code": 200
}

Log Parser 配置 ​

Fluent Bit 中的 log parsing 配置:

[PARSER]
    Name        json
    Format      json
    Time_Key    timestamp
    Time_Format %Y-%m-%dT%H:%M:%S%z

Cluster 监控 ​

有效的 cluster 监控对于跟踪 EKS cluster 的状态、性能和资源使用情况至关重要。本节探讨用于监控 EKS clusters 的各种工具和技术。

CloudWatch Container Insights ​

Amazon CloudWatch Container Insights 收集、聚合并汇总来自 containerized applications 和 microservices 的 metrics、logs 和 events:

启用 Container Insights ​

使用 CloudWatch agent 启用 Container Insights:

bash
ClusterName=my-cluster
RegionName=us-west-2
FluentBitHttpPort='2020'
FluentBitReadFromHead='Off'
[[ ${FluentBitReadFromHead} = 'On' ]] && FluentBitReadFromTail='Off'|| FluentBitReadFromTail='On'
[[ -z ${FluentBitHttpPort} ]] && FluentBitHttpServer='Off' || FluentBitHttpServer='On'

curl https://raw.githubusercontent.com/aws-samples/amazon-cloudwatch-container-insights/latest/k8s-deployment-manifest-templates/deployment-mode/daemonset/container-insights-monitoring/quickstart/cwagent-fluent-bit-quickstart.yaml | sed 's/{{cluster_name}}/'${ClusterName}'/;s/{{region_name}}/'${RegionName}'/;s/{{http_server_toggle}}/"'${FluentBitHttpServer}'"/;s/{{http_server_port}}/"'${FluentBitHttpPort}'"/;s/{{read_from_head}}/"'${FluentBitReadFromHead}'"/;s/{{read_from_tail}}/"'${FluentBitReadFromTail}'"/' | kubectl apply -f -

Container Insights Metrics ​

Container Insights 收集以下 metrics:

  • Cluster level: Node count、pod count、failed pod count
  • Node level: CPU usage、memory usage、network I/O、disk I/O
  • Pod level: CPU usage、memory usage、network I/O
  • Service level: Pod count、CPU usage、memory usage

Container Insights Dashboard ​

在 CloudWatch console 中访问 Container Insights dashboard,以可视化 cluster performance:

  1. 登录 AWS Management Console
  2. 导航到 CloudWatch service
  3. 从左侧导航窗格选择 "Insights" > "Container Insights"
  4. 选择 cluster、node、pod 或 service 视图

Container Insights Alerts ​

设置 CloudWatch alarms,以便在 metrics 超过特定阈值时接收通知:

bash
aws cloudwatch put-metric-alarm \
  --alarm-name "High-CPU-Cluster" \
  --alarm-description "Alarm when cluster CPU exceeds 80%" \
  --metric-name pod_cpu_utilization \
  --namespace ContainerInsights \
  --statistic Average \
  --period 300 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --dimensions Name=ClusterName,Value=my-cluster \
  --evaluation-periods 2 \
  --alarm-actions arn:aws:sns:us-west-2:123456789012:my-topic

CloudWatch Observability Add-on 5.0.0 ​

从 amazon-cloudwatch-observability EKS add-on 的 5.0.0 版本(February 2026)开始,Application Signals (APM) 默认处于 enabled by default 状态,而不再需要手动 opt-in。该 add-on 现在将 Enhanced Container Insights、Container Logs 和 Application Signals 打包为一个单一 package,并且无需 pod annotations 即可为 workloads 检测 traces、metrics 和 logs:

bash
aws eks update-addon \
  --cluster-name my-cluster \
  --addon-name amazon-cloudwatch-observability \
  --addon-version v5.0.0-eksbuild.1

如果你正在从 Application Signals 仍为 opt-in 的 add-on 版本升级,请参阅 release notes(February 26, 2026)获取升级指导。有关基于 OTel 的新版 Container Insights metric collection 演进,请参阅 CloudWatch Metrics (English)。

EKS Node Monitoring Agent ​

EKS Node Monitoring Agent 会监视 worker nodes 的 system、storage、network 和 accelerator (GPU) 问题,并将它们发布为 Kubernetes Node Conditions,EKS auto node repair 功能可以自动对这些 Conditions 采取操作。截至 February 2026,该 agent 的源代码已在 GitHub 上公开,因此可以在内置检查之外进行自定义或扩展。

该 agent 默认包含在 EKS Auto Mode 中,也可以作为标准 managed node groups 的独立 add-on 使用:

bash
aws eks create-addon \
  --cluster-name my-cluster \
  --addon-name eks-node-monitoring-agent

使用以下命令检查它报告的 conditions:

bash
kubectl get nodes -o custom-columns='NAME:.metadata.name,CONDITIONS:.status.conditions[*].type'
kubectl describe node <node-name>

有关 GitHub repository 和支持的 condition types,请参阅 公告(February 24, 2026)。

Prometheus 和 Grafana ​

Prometheus 是一个 time-series database 和监控系统,Grafana 是用于可视化 metrics 的 dashboard 工具。你可以将这两个工具结合使用,对 EKS cluster 进行全面监控。

Amazon Managed Service for Prometheus 和 Grafana ​

AWS 为 Prometheus 和 Grafana 提供 managed services:

  1. Amazon Managed Service for Prometheus (AMP) 设置:
bash
# Create AMP workspace
aws amp create-workspace --alias my-amp-workspace

# Install Prometheus server and configure remote write to AMP
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm install prometheus prometheus-community/prometheus \
  --namespace prometheus \
  --create-namespace \
  --set server.remoteWrite[0].url=https://aps-workspaces.us-west-2.amazonaws.com/workspaces/ws-12345678-1234-1234-1234-123456789012/api/v1/remote_write \
  --set server.remoteWrite[0].sigv4.region=us-west-2
  1. Amazon Managed Grafana (AMG) 设置:
bash
# Create AMG workspace
aws grafana create-workspace \
  --name my-grafana-workspace \
  --authentication-providers AWS_SSO \
  --permission-type SERVICE_MANAGED

# Add AMP data source
aws grafana create-workspace-service-account \
  --workspace-id g-12345678 \
  --name amp-datasource \
  --service-account-role ADMIN

Self-Managed Prometheus 和 Grafana ​

你也可以将 self-managed Prometheus 和 Grafana 部署到你的 EKS cluster:

  1. 安装 kube-prometheus-stack:
bash
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm install monitoring prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --create-namespace \
  --set grafana.service.type=LoadBalancer
  1. 访问 Grafana:
bash
# Get Grafana service URL
kubectl get svc -n monitoring monitoring-grafana -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'

# Get default username and password
kubectl get secret -n monitoring monitoring-grafana -o jsonpath='{.data.admin-user}' | base64 --decode
kubectl get secret -n monitoring monitoring-grafana -o jsonpath='{.data.admin-password}' | base64 --decode

关键 Prometheus Metrics ​

Prometheus 收集以下重要 Kubernetes metrics:

  • Node metrics: CPU、memory、disk、network usage
  • Pod metrics: CPU、memory usage、restart count
  • Container metrics: CPU、memory usage、filesystem usage
  • API server metrics: Request latency、request count、error rate
  • etcd metrics: Latency、disk I/O、leader changes

有用的 Grafana Dashboards ​

你可以在 Grafana 中导入以下有用 dashboards:

  1. Kubernetes Cluster Monitoring (ID: 15661)
  2. Node Exporter Full (ID: 1860)
  3. Kubernetes Pod Monitoring (ID: 6417)
  4. Kubernetes API Server (ID: 12006)
  5. Kubernetes Resource Requests/Limits (ID: 13770)

PromQL 查询示例 ​

你可以使用 Prometheus Query Language (PromQL) 编写有用的查询:

# CPU usage by node
sum(rate(node_cpu_seconds_total{mode!="idle"}[5m])) by (instance) / count(node_cpu_seconds_total{mode="idle"}) by (instance) * 100

# Memory usage by pod (top 10)
topk(10, sum(container_memory_usage_bytes{container!=""}) by (pod))

# Container restart count
sum(kube_pod_container_status_restarts_total) by (pod)

# Disk usage percentage by node
100 - ((node_filesystem_avail_bytes{mountpoint="/"} * 100) / node_filesystem_size_bytes{mountpoint="/"})

使用 AWS X-Ray 进行分布式追踪 ​

AWS X-Ray 收集有关 application 处理的 requests 的数据,并使用这些数据识别 application 问题和优化机会。

X-Ray 设置 ​

  1. 安装 X-Ray daemon:
yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: xray-daemon
  namespace: default
spec:
  selector:
    matchLabels:
      app: xray-daemon
  template:
    metadata:
      labels:
        app: xray-daemon
    spec:
      containers:
      - name: xray-daemon
        image: amazon/aws-xray-daemon:latest
        ports:
        - containerPort: 2000
          hostPort: 2000
          protocol: UDP
        resources:
          limits:
            memory: 256Mi
          requests:
            memory: 256Mi
        env:
        - name: AWS_REGION
          value: us-west-2
      serviceAccountName: xray-daemon
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: xray-daemon
  namespace: default
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: xray-daemon
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: xray-daemon
  namespace: default
  1. 将 X-Ray SDK 集成到你的 application 中:

Java application 示例:

java
import com.amazonaws.xray.AWSXRay;
import com.amazonaws.xray.AWSXRayRecorderBuilder;
import com.amazonaws.xray.plugins.EKSPlugin;

public class Application {
    static {
        AWSXRayRecorderBuilder builder = AWSXRayRecorderBuilder.standard().withPlugin(new EKSPlugin());
        AWSXRay.setGlobalRecorder(builder.build());
    }

    // Application code
}

X-Ray Service Map ​

使用 X-Ray service map 可视化 microservices 架构中组件之间的关系和通信:

  1. 登录 AWS Management Console
  2. 导航到 X-Ray service
  3. 从左侧导航窗格选择 "Service Map"
  4. 检查 services 之间的 latency、errors 和 fault points

X-Ray Analysis and Insights ​

使用 X-Ray Analytics 分析 trace data 并识别性能瓶颈:

  1. 在 AWS Management Console 中导航到 X-Ray service
  2. 从左侧导航窗格选择 "Analytics"
  3. 分析 response time distribution、error rate 和 fault points

Kubernetes Dashboard ​

Kubernetes Dashboard 提供用于管理 cluster resources 和排查问题的 web-based UI:

安装 Kubernetes Dashboard ​

bash
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.7.0/aio/deploy/recommended.yaml

# Create service account and cluster role binding for dashboard access
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  name: admin-user
  namespace: kubernetes-dashboard
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: admin-user
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: admin-user
  namespace: kubernetes-dashboard
EOF

# Generate access token
kubectl -n kubernetes-dashboard create token admin-user

访问 Dashboard ​

bash
# Start dashboard proxy
kubectl proxy

# Access the following URL in browser
# http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/

Custom Metrics 和监控 ​

你可以实现自定义方案来收集和监控 application-specific metrics:

Prometheus Client Library 集成 ​

将 Prometheus client libraries 集成到你的 application 中以暴露 custom metrics:

Java application 示例:

java
import io.prometheus.client.Counter;
import io.prometheus.client.Histogram;
import io.prometheus.client.exporter.HTTPServer;

public class Application {
    static final Counter requests = Counter.build()
        .name("app_requests_total")
        .help("Total requests.")
        .register();

    static final Histogram requestLatency = Histogram.build()
        .name("app_request_latency_seconds")
        .help("Request latency in seconds.")
        .register();

    public static void main(String[] args) throws IOException {
        HTTPServer server = new HTTPServer(8080);
        // Application code
    }

    public void processRequest() {
        requests.inc();
        Histogram.Timer timer = requestLatency.startTimer();
        try {
            // Process request
        } finally {
            timer.observeDuration();
        }
    }
}

收集 Custom Metrics ​

使用 Prometheus ServiceMonitor 收集 custom metrics:

yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: app-monitor
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: my-app
  endpoints:
  - port: metrics
    interval: 15s
    path: /metrics

Custom Dashboards ​

在 Grafana 中创建 custom dashboards 以可视化 application metrics:

  1. 登录 Grafana
  2. 点击 "+" 图标并选择 "Dashboard"
  3. 点击 "Add panel"
  4. 选择 "Prometheus" 作为 data source
  5. 编写 PromQL query(例如 rate(app_requests_total[5m]))
  6. 配置 panel title、description 和 visualization type
  7. 点击 "Save"

告警和事件管理 ​

有效的告警和事件管理对于快速检测并响应 EKS cluster 中的问题至关重要。本节探讨用于在 EKS clusters 中管理 alerts 和 events 的各种工具与技术。

CloudWatch Alarms ​

使用 Amazon CloudWatch alarms,在 metrics 超过特定阈值时接收通知:

Cluster CPU Usage Alarm ​

bash
aws cloudwatch put-metric-alarm \
  --alarm-name "EKS-Cluster-High-CPU" \
  --alarm-description "Alarm when cluster CPU exceeds 80%" \
  --metric-name pod_cpu_utilization \
  --namespace ContainerInsights \
  --statistic Average \
  --period 300 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --dimensions Name=ClusterName,Value=my-cluster \
  --evaluation-periods 2 \
  --alarm-actions arn:aws:sns:us-west-2:123456789012:my-topic

Memory Usage Alarm ​

bash
aws cloudwatch put-metric-alarm \
  --alarm-name "EKS-Cluster-High-Memory" \
  --alarm-description "Alarm when cluster memory exceeds 80%" \
  --metric-name pod_memory_utilization \
  --namespace ContainerInsights \
  --statistic Average \
  --period 300 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --dimensions Name=ClusterName,Value=my-cluster \
  --evaluation-periods 2 \
  --alarm-actions arn:aws:sns:us-west-2:123456789012:my-topic

Disk Usage Alarm ​

bash
aws cloudwatch put-metric-alarm \
  --alarm-name "EKS-Node-High-Disk" \
  --alarm-description "Alarm when node disk usage exceeds 85%" \
  --metric-name node_filesystem_utilization \
  --namespace ContainerInsights \
  --statistic Maximum \
  --period 300 \
  --threshold 85 \
  --comparison-operator GreaterThanThreshold \
  --dimensions Name=ClusterName,Value=my-cluster \
  --evaluation-periods 2 \
  --alarm-actions arn:aws:sns:us-west-2:123456789012:my-topic

Prometheus Alertmanager ​

Prometheus Alertmanager 处理 Prometheus 生成的 alerts,并将它们路由到适当的 notification channels:

Alertmanager 配置 ​

yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: alertmanager-config
  namespace: monitoring
data:
  alertmanager.yml: |
    global:
      resolve_timeout: 5m
      slack_api_url: 'https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX'

    route:
      group_by: ['alertname', 'job']
      group_wait: 30s
      group_interval: 5m
      repeat_interval: 12h
      receiver: 'slack-notifications'
      routes:
      - match:
          severity: critical
        receiver: 'slack-notifications'
        continue: true

    receivers:
    - name: 'slack-notifications'
      slack_configs:
      - channel: '#eks-alerts'
        send_resolved: true
        title: '[{{ .Status | toUpper }}] {{ .CommonLabels.alertname }}'
        text: >-
          {{ range .Alerts }}
            *Alert:* {{ .Annotations.summary }}
            *Description:* {{ .Annotations.description }}
            *Severity:* {{ .Labels.severity }}
            *Details:*
            {{ range .Labels.SortedPairs }} • *{{ .Name }}:* `{{ .Value }}`
            {{ end }}
          {{ end }}

Alert Rules 配置 ​

yaml
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: kubernetes-alerts
  namespace: monitoring
spec:
  groups:
  - name: kubernetes
    rules:
    - alert: KubernetesPodCrashLooping
      expr: rate(kube_pod_container_status_restarts_total[5m]) * 60 * 5 > 5
      for: 5m
      labels:
        severity: critical
      annotations:
        summary: "Pod {{ $labels.namespace }}/{{ $labels.pod }} is crash looping"
        description: "Pod {{ $labels.namespace }}/{{ $labels.pod }} is restarting {{ $value }} times / 5 minutes"

    - alert: KubernetesNodeMemoryPressure
      expr: kube_node_status_condition{condition="MemoryPressure", status="true"} == 1
      for: 5m
      labels:
        severity: warning
      annotations:
        summary: "Node {{ $labels.node }} is under memory pressure"
        description: "Node {{ $labels.node }} has been under memory pressure for more than 5 minutes"

    - alert: KubernetesNodeDiskPressure
      expr: kube_node_status_condition{condition="DiskPressure", status="true"} == 1
      for: 5m
      labels:
        severity: warning
      annotations:
        summary: "Node {{ $labels.node }} is under disk pressure"
        description: "Node {{ $labels.node }} has been under disk pressure for more than 5 minutes"

EventBridge Event Rules ​

使用 Amazon EventBridge 创建 rules,以响应 EKS cluster 中的 events:

EKS Cluster State Change Event Rule ​

bash
aws events put-rule \
  --name "EKS-Cluster-State-Change" \
  --event-pattern '{
    "source": ["aws.eks"],
    "detail-type": ["EKS Cluster State Change"],
    "detail": {
      "clusterName": ["my-cluster"]
    }
  }'

aws events put-targets \
  --rule "EKS-Cluster-State-Change" \
  --targets '[
    {
      "Id": "1",
      "Arn": "arn:aws:sns:us-west-2:123456789012:my-topic"
    }
  ]'

EKS Node Group Event Rule ​

bash
aws events put-rule \
  --name "EKS-NodeGroup-Events" \
  --event-pattern '{
    "source": ["aws.eks"],
    "detail-type": ["EKS Node Group State Change"],
    "detail": {
      "clusterName": ["my-cluster"]
    }
  }'

aws events put-targets \
  --rule "EKS-NodeGroup-Events" \
  --targets '[
    {
      "Id": "1",
      "Arn": "arn:aws:sns:us-west-2:123456789012:my-topic"
    }
  ]'

Kubernetes Event 监控 ​

Kubernetes events 提供有关 cluster 中发生的重要活动的信息:

安装 Event Monitoring Tools ​

bash
# Install event-exporter
kubectl apply -f https://raw.githubusercontent.com/opsgenie/kubernetes-event-exporter/master/deploy/01-cluster-role.yaml
kubectl apply -f https://raw.githubusercontent.com/opsgenie/kubernetes-event-exporter/master/deploy/02-service-account.yaml
kubectl apply -f https://raw.githubusercontent.com/opsgenie/kubernetes-event-exporter/master/deploy/03-cluster-role-binding.yaml

Event Exporter 配置 ​

yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: event-exporter-config
  namespace: default
data:
  config.yaml: |
    logLevel: info
    logFormat: json
    route:
      routes:
        - match:
            - type: "Warning"
          receivers:
            - webhook:
                endpoint: "http://alertmanager:9093/api/v1/alerts"
                headers:
                  Content-Type: application/json
        - match:
            - type: "Normal"
              reason: "Created|Started|Killing|Scheduled|Pulled"
          receivers:
            - file:
                path: "/tmp/normal-events.log"
    receivers:
      - name: "dump"
        file:
          path: "/tmp/all-events.log"
      - name: "slack"
        slack:
          channel: "#kubernetes-events"
          token: "xoxb-1234-1234-1234"

Event Exporter Deployment ​

yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: event-exporter
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: event-exporter
  template:
    metadata:
      labels:
        app: event-exporter
    spec:
      serviceAccountName: event-exporter
      containers:
      - name: event-exporter
        image: opsgenie/kubernetes-event-exporter:latest
        args:
        - -conf=/etc/config/config.yaml
        volumeMounts:
        - name: config
          mountPath: /etc/config
      volumes:
      - name: config
        configMap:
          name: event-exporter-config

Notification Channel 集成 ​

你可以集成各种 notification channels,将 alerts 传递给你的团队:

Slack 集成 ​

yaml
apiVersion: v1
kind: Secret
metadata:
  name: slack-webhook
  namespace: monitoring
type: Opaque
stringData:
  url: https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX
---
apiVersion: notification.toolkit.fluxcd.io/v1beta1
kind: Provider
metadata:
  name: slack
  namespace: monitoring
spec:
  type: slack
  channel: eks-alerts
  secretRef:
    name: slack-webhook

PagerDuty 集成 ​

yaml
apiVersion: v1
kind: Secret
metadata:
  name: pagerduty-api-key
  namespace: monitoring
type: Opaque
stringData:
  token: your-pagerduty-api-key
---
apiVersion: notification.toolkit.fluxcd.io/v1beta1
kind: Provider
metadata:
  name: pagerduty
  namespace: monitoring
spec:
  type: pagerduty
  serviceKey: your-pagerduty-service-key
  secretRef:
    name: pagerduty-api-key

Email 集成 ​

yaml
apiVersion: v1
kind: Secret
metadata:
  name: smtp-credentials
  namespace: monitoring
type: Opaque
stringData:
  username: your-smtp-username
  password: your-smtp-password
---
apiVersion: notification.toolkit.fluxcd.io/v1beta1
kind: Provider
metadata:
  name: email
  namespace: monitoring
spec:
  type: smtp
  server: smtp.example.com
  port: "587"
  from: eks-alerts@example.com
  to:
  - team@example.com
  secretRef:
    name: smtp-credentials

Alert 管理和升级 ​

实施策略以有效管理和升级 alerts:

Alert 严重性级别 ​

将 alerts 分类为以下严重性级别:

  • Critical: 需要立即采取行动的严重问题
  • Warning: 需要关注但不需要立即行动的问题
  • Info: 信息性 alerts

Alert 升级策略 ​

使用 PagerDuty 等工具实施 alert escalation policies:

  1. First Response: 通知 on-call engineer
  2. Escalation 1: 如果 15 分钟后无响应,则通知 backup engineer
  3. Escalation 2: 如果 30 分钟后无响应,则通知 team lead
  4. Escalation 3: 如果 45 分钟后无响应,则通知 manager

减少 Alert Fatigue ​

实施减少 alert fatigue 的策略:

  1. Alert Grouping: 将相关 alerts 分组以减少重复通知
  2. Alert Filtering: 过滤以仅传递重要 alerts
  3. Alert Throttling: 限制重复 alerts 的频率
  4. Alert Time Windows: 仅在工作时间传递非业务关键 alerts

日志分析和可视化 ​

日志分析和可视化在诊断并解决 EKS cluster 中发生的问题方面发挥重要作用。本节探讨用于在 EKS clusters 中分析和可视化 logs 的各种工具与技术。

CloudWatch Logs Insights ​

使用 CloudWatch Logs Insights 查询并分析来自 EKS cluster 的 logs:

Container Log Query ​

fields @timestamp, kubernetes.pod_name, log
| filter kubernetes.namespace_name = "default"
| filter kubernetes.container_name = "app"
| filter log like /ERROR/
| sort @timestamp desc
| limit 20

API Server Error Query ​

fields @timestamp, @message
| filter @logStream like /kube-apiserver/
| filter @message like /Error/
| sort @timestamp desc
| limit 20

Authentication Failure Query ​

fields @timestamp, @message
| filter @logStream like /authenticator/
| filter @message like /authentication failed/
| sort @timestamp desc
| limit 20

Log Pattern Analysis ​

fields @timestamp, @message
| parse @message "* * * [*] *" as date, time, level, component, message
| stats count(*) as count by level, component
| sort count desc

Amazon OpenSearch Service ​

使用 Amazon OpenSearch Service(以前称为 Amazon Elasticsearch Service)存储、分析并可视化来自 EKS cluster 的 logs:

创建 OpenSearch Domain ​

bash
aws opensearch create-domain \
  --domain-name eks-logs \
  --engine-version OpenSearch_1.3 \
  --cluster-config InstanceType=r6g.large.search,InstanceCount=2 \
  --ebs-options EBSEnabled=true,VolumeType=gp3,VolumeSize=100 \
  --node-to-node-encryption-options Enabled=true \
  --encryption-at-rest-options Enabled=true \
  --domain-endpoint-options EnforceHTTPS=true \
  --advanced-security-options Enabled=true,InternalUserDatabaseEnabled=true,MasterUserOptions='{MasterUserName=admin,MasterUserPassword=Admin123!}' \
  --access-policies '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"AWS":"*"},"Action":"es:*","Resource":"arn:aws:es:us-west-2:123456789012:domain/eks-logs/*"}]}'

使用 Fluent Bit 将 Logs 发送到 OpenSearch ​

yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: fluent-bit-config
  namespace: kube-system
data:
  fluent-bit.conf: |
    [SERVICE]
        Flush         5
        Log_Level     info
        Daemon        off
        Parsers_File  parsers.conf

    [INPUT]
        Name              tail
        Tag               kube.*
        Path              /var/log/containers/*.log
        Parser            docker
        DB                /var/log/flb_kube.db
        Mem_Buf_Limit     5MB
        Skip_Long_Lines   On
        Refresh_Interval  10

    [FILTER]
        Name                kubernetes
        Match               kube.*
        Kube_URL            https://kubernetes.default.svc:443
        Kube_CA_File        /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
        Kube_Token_File     /var/run/secrets/kubernetes.io/serviceaccount/token
        Merge_Log           On
        K8S-Logging.Parser  On
        K8S-Logging.Exclude Off

    [OUTPUT]
        Name            es
        Match           kube.*
        Host            search-eks-logs-abcdefghijklmnopqrstuvwxyz.us-west-2.es.amazonaws.com
        Port            443
        TLS             On
        AWS_Auth        On
        AWS_Region      us-west-2
        Index           eks-logs
        Suppress_Type_Name On

使用 OpenSearch Dashboards 进行 Log 可视化 ​

在 OpenSearch Dashboards 中创建以下 visualizations:

  1. Log Explorer: Log search 和 filtering
  2. Dashboards: 基于 log data 创建 dashboards
  3. Visualizations: 基于 log data 创建 charts 和 graphs
  4. Alerts: 基于 log patterns 配置 alerts

Grafana Loki ​

Grafana Loki 是一个 log aggregation system,使用类似 Prometheus 的 label-based 方法:

安装 Loki ​

bash
helm repo add grafana https://grafana.github.io/helm-charts
helm repo update
helm install loki grafana/loki-stack \
  --namespace logging \
  --create-namespace \
  --set grafana.enabled=true \
  --set promtail.enabled=true \
  --set loki.persistence.enabled=true \
  --set loki.persistence.size=10Gi

LogQL 查询示例 ​

# Search error logs in a specific namespace
{namespace="default"} |= "ERROR"

# Search logs for a specific pod
{namespace="default", pod=~"app-.*"} | json

# Count logs by log level
sum by (level) (count_over_time({namespace="default"} | json | level=~"info|warn|error" [5m]))

创建 Grafana Dashboards ​

使用 Loki data source 在 Grafana 中创建 log dashboards:

  1. 登录 Grafana
  2. 点击 "+" 图标并选择 "Dashboard"
  3. 点击 "Add panel"
  4. 选择 "Loki" 作为 data source
  5. 编写 LogQL query
  6. 配置 panel title、description 和 visualization type
  7. 点击 "Save"

AWS CloudTrail ​

使用 AWS CloudTrail 记录并分析与你的 EKS cluster 相关的 AWS API calls:

创建 CloudTrail Trail ​

bash
aws cloudtrail create-trail \
  --name eks-api-trail \
  --s3-bucket-name my-cloudtrail-bucket \
  --is-multi-region-trail \
  --include-global-service-events

aws cloudtrail start-logging --name eks-api-trail

过滤 CloudTrail Events ​

bash
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventSource,AttributeValue=eks.amazonaws.com

CloudTrail Lake Query ​

sql
SELECT eventTime, eventName, userIdentity.arn, requestParameters
FROM eks_events
WHERE eventSource = 'eks.amazonaws.com'
  AND eventName LIKE '%Cluster%'
  AND eventTime >= '2025-07-01T00:00:00Z'
  AND eventTime <= '2025-07-11T23:59:59Z'
ORDER BY eventTime DESC

Log 分析最佳实践 ​

有效分析来自 EKS cluster 的 logs 的最佳实践:

结构化 Logging ​

在你的 applications 中使用结构化 log 格式(例如 JSON):

json
{
  "timestamp": "2025-07-11T13:00:00Z",
  "level": "INFO",
  "message": "Request processed successfully",
  "request_id": "12345",
  "user_id": "user-789",
  "duration_ms": 45,
  "status_code": 200
}

Correlation IDs ​

使用 correlation IDs 跟踪 distributed systems 中的 requests:

java
import org.slf4j.MDC;

public class RequestHandler {
    public void handleRequest(Request request) {
        String correlationId = request.getHeader("X-Correlation-ID");
        if (correlationId == null) {
            correlationId = UUID.randomUUID().toString();
        }

        MDC.put("correlation_id", correlationId);

        try {
            // Process request
        } finally {
            MDC.remove("correlation_id");
        }
    }
}

使用 Log Levels ​

使用适当的 log levels 表示 logs 的重要性:

  • ERROR: Application errors 和 exceptions
  • WARN: 潜在问题或意外情况
  • INFO: 一般 application events
  • DEBUG: 对 debugging 有用的详细信息
  • TRACE: 非常详细的 debugging 信息

Log Retention Policy ​

根据成本和合规要求设置 log retention policies:

bash
# Set CloudWatch Logs log group retention period
aws logs put-retention-policy \
  --log-group-name /aws/eks/my-cluster/cluster \
  --retention-in-days 30

# Set S3 bucket lifecycle policy
aws s3api put-bucket-lifecycle-configuration \
  --bucket my-logs-bucket \
  --lifecycle-configuration file://lifecycle-config.json

lifecycle-config.json:

json
{
  "Rules": [
    {
      "ID": "Delete old logs",
      "Status": "Enabled",
      "Prefix": "logs/",
      "Expiration": {
        "Days": 90
      }
    },
    {
      "ID": "Archive old logs",
      "Status": "Enabled",
      "Prefix": "logs/",
      "Transitions": [
        {
          "Days": 30,
          "StorageClass": "STANDARD_IA"
        },
        {
          "Days": 60,
          "StorageClass": "GLACIER"
        }
      ]
    }
  ]
}

监控和日志记录最佳实践 ​

让我们探讨在 EKS clusters 中有效实施监控和日志记录的最佳实践。

监控最佳实践 ​

多层监控 ​

监控 EKS cluster 的所有层:

  1. Infrastructure Layer: EC2 instances、VPC、subnets、security groups
  2. Cluster Layer: Control plane、nodes、pods、services
  3. Application Layer: Application performance、user experience

Golden Signals 监控 ​

重点关注 Google SRE 书中建议的 “4 Golden Signals”:

  1. Latency: 处理 requests 所需的时间
  2. Traffic: 到系统的 requests 数量
  3. Errors: 失败 requests 的比例
  4. Saturation: 系统“有多满”(例如 memory usage)

主动监控 ​

实施主动监控,以在问题发生前检测它们:

  1. Trend Analysis: 分析一段时间内的资源使用趋势
  2. Anomaly Detection: 检测异常 patterns
  3. Predictive Analysis: 预测未来资源需求

Automated Scaling ​

基于 monitoring data 实施 automated scaling:

yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80

Business Metrics 监控 ​

除了 technical metrics 之外,还监控 business metrics:

  1. User Activity: 活跃用户数量、session length
  2. Transactions: Transaction count、transaction value
  3. Conversion Rate: User conversion rate、churn rate
  4. SLA Compliance: Service Level Objectives (SLOs) 是否得到满足

Logging 最佳实践 ​

Centralized Logging ​

将所有 logs 聚合到一个中心位置:

  1. Consistent Format: 在所有 applications 中使用一致的 log format
  2. Central Repository: 使用 CloudWatch Logs、OpenSearch 或 Loki 等 central log repository
  3. Log Forwarding: 使用 Fluent Bit 或 Fluentd 等 log forwarding agents

包含上下文信息 ​

在 logs 中包含足够的上下文信息:

  1. Timestamp: 准确的 timestamp(推荐 ISO 8601 格式)
  2. Request ID: 用于 distributed systems 中 request tracking 的唯一 ID
  3. User Information: User ID 或 session ID(不包括 personally identifiable information)
  4. Service Information: Service name、version、instance ID
  5. Error Details: Error code、error message、stack trace

Log Level Filtering ​

根据环境设置适当的 log levels:

  1. Development Environment: DEBUG 或 TRACE level
  2. Staging Environment: INFO level
  3. Production Environment: INFO 或 WARN level(可按需启用 DEBUG)

保护敏感信息 ​

保护 logs 中的敏感信息:

  1. PII Masking: 屏蔽 personally identifiable information (PII)
  2. Exclude Credentials: 排除 passwords、tokens、API keys 等 credentials
  3. Encryption: 对静态和传输中的 logs 进行加密

Alerting 最佳实践 ​

Alert 优先级 ​

对 alerts 进行优先级排序以减少 alert fatigue:

  1. P1 (Critical): 需要立即采取行动的严重问题
  2. P2 (High): 需要在工作时间内采取行动的重要问题
  3. P3 (Medium): 需要在计划维护期间采取行动的问题
  4. P4 (Low): 信息性 alerts

Alert Grouping ​

将相关 alerts 分组以减少重复通知:

yaml
route:
  group_by: ['alertname', 'job', 'instance']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h

可操作的 Alerts ​

在 alerts 中包含足够的信息用于故障排查:

  1. Clear Title: 清晰描述问题的标题
  2. Detailed Description: 对原因和影响的详细描述
  3. Troubleshooting Steps: 用于 troubleshooting 的步骤或链接
  4. Related Metrics and Logs: 对诊断有用的 metrics 和 logs 链接

Alert Testing ​

定期测试你的 alerting system:

  1. Alert Simulation: 生成 test alerts
  2. Escalation Testing: 测试 escalation paths
  3. Fault Injection: 在受控环境中注入 faults

成本优化最佳实践 ​

Log Volume Optimization ​

优化 log volume 以降低成本:

  1. Sampling: 对高容量 logs 进行 sampling
  2. Filtering: 过滤不必要的 logs
  3. Compression: 压缩 logs

Metric Cardinality Management ​

管理 metric cardinality 以降低成本:

  1. Label Limits: 限制 metrics 中使用的 labels 数量
  2. Aggregation: 将详细 metrics 聚合到更高层级
  3. Sampling: 对高分辨率 metrics 进行 sampling

Storage Tiering ​

实施成本效益高的 storage tiering:

  1. Hot Storage: 最近的 logs 和频繁访问的 logs
  2. Warm Storage: 较少访问的 logs
  3. Cold Storage: Archived logs

故障排查和调试 ​

让我们探讨在 EKS clusters 中排查和调试问题的各种技术。

Cluster 故障排查 ​

检查 Cluster 状态 ​

bash
# Check cluster status
aws eks describe-cluster --name my-cluster --query "cluster.status"

# Check cluster endpoint
aws eks describe-cluster --name my-cluster --query "cluster.endpoint"

# Check cluster logs
aws eks update-cluster-config \
  --name my-cluster \
  --logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}'

# Check cluster logs in CloudWatch Logs
aws logs get-log-events \
  --log-group-name /aws/eks/my-cluster/cluster \
  --log-stream-name kube-apiserver-12345abcde \
  --limit 10

Node 故障排查 ​

bash
# Check node status
kubectl get nodes
kubectl describe node <node-name>

# Check node group status
aws eks describe-nodegroup \
  --cluster-name my-cluster \
  --nodegroup-name my-nodegroup

# Check node logs
aws ec2 get-console-output \
  --instance-id i-1234567890abcdef0

# Access node via SSH
ssh -i ~/.ssh/my-key.pem ec2-user@<node-ip>

Pod 故障排查 ​

bash
# Check pod status
kubectl get pods -A
kubectl describe pod <pod-name> -n <namespace>

# Check pod logs
kubectl logs <pod-name> -n <namespace>
kubectl logs <pod-name> -n <namespace> --previous  # Logs from previous container

# Check pod events
kubectl get events -n <namespace> --sort-by='.lastTimestamp'

# Access pod shell
kubectl exec -it <pod-name> -n <namespace> -- /bin/bash

Networking 故障排查 ​

Service 故障排查 ​

bash
# Check service status
kubectl get svc -A
kubectl describe svc <service-name> -n <namespace>

# Check endpoints
kubectl get endpoints <service-name> -n <namespace>

# DNS check
kubectl run -it --rm --restart=Never busybox --image=busybox:1.28 -- nslookup <service-name>.<namespace>.svc.cluster.local

# Port forwarding
kubectl port-forward svc/<service-name> 8080:80 -n <namespace>

Network Policy 故障排查 ​

bash
# Check network policies
kubectl get networkpolicies -A
kubectl describe networkpolicy <policy-name> -n <namespace>

# Test network connectivity
kubectl run -it --rm --restart=Never busybox --image=busybox:1.28 -- wget -O- <service-name>.<namespace>.svc.cluster.local

# Packet capture
kubectl debug node/<node-name> -it --image=nicolaka/netshoot -- tcpdump -i any port 80

Logging 和 Monitoring 故障排查 ​

Fluent Bit 故障排查 ​

bash
# Check Fluent Bit pod status
kubectl get pods -n kube-system -l app=aws-for-fluent-bit

# Check Fluent Bit logs
kubectl logs -n kube-system -l app=aws-for-fluent-bit

# Check Fluent Bit configuration
kubectl get cm -n kube-system fluent-bit-config -o yaml

Prometheus 故障排查 ​

bash
# Check Prometheus pod status
kubectl get pods -n monitoring -l app=prometheus

# Check Prometheus logs
kubectl logs -n monitoring -l app=prometheus-server

# Check Prometheus targets
kubectl port-forward -n monitoring svc/prometheus-server 9090:80
# Access http://localhost:9090/targets in browser

Grafana 故障排查 ​

bash
# Check Grafana pod status
kubectl get pods -n monitoring -l app=grafana

# Check Grafana logs
kubectl logs -n monitoring -l app=grafana

# Check Grafana data sources
kubectl port-forward -n monitoring svc/grafana 3000:80
# Access http://localhost:3000/datasources in browser

常见问题和解决方案 ​

ImagePullBackOff Error ​

问题:Pod stuck in ImagePullBackOff state

解决方案:

  1. 验证 image name 和 tag 是否正确
  2. 检查 private registries 的 image pull secret
  3. 验证 node 是否具有 internet access
bash
# Create image pull secret
kubectl create secret docker-registry regcred \
  --docker-server=<registry-server> \
  --docker-username=<username> \
  --docker-password=<password> \
  --docker-email=<email>

# Apply secret to pod
kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "regcred"}]}'

CrashLoopBackOff Error ​

问题:Pod 在 CrashLoopBackOff state 中反复重启

解决方案:

  1. 检查 pod logs
  2. 检查 resource limits
  3. 检查 application configuration
bash
# Check pod logs
kubectl logs <pod-name> -n <namespace>

# Check pod events
kubectl describe pod <pod-name> -n <namespace>

# Add debug container
kubectl debug <pod-name> -n <namespace> --image=busybox:1.28 --target=<container-name>

Node NotReady State ​

问题:Node 显示为 NotReady state

解决方案:

  1. 检查 node status 和 events
  2. 检查 kubelet logs
  3. 检查 node resource usage
bash
# Check node status
kubectl describe node <node-name>

# Access node via SSH
ssh -i ~/.ssh/my-key.pem ec2-user@<node-ip>

# Check kubelet logs
sudo journalctl -u kubelet

# Check node resource usage
top
df -h

Service Connection Issues ​

问题:无法连接到 service

解决方案:

  1. 检查 service 和 endpoints
  2. 检查 pod labels 和 selectors
  3. 检查 network policies
bash
# Check service and endpoints
kubectl get svc <service-name> -n <namespace>
kubectl get endpoints <service-name> -n <namespace>

# Check pod labels
kubectl get pods -n <namespace> --show-labels

# Check service selector
kubectl get svc <service-name> -n <namespace> -o jsonpath='{.spec.selector}'

# Check network policies
kubectl get networkpolicies -n <namespace>

Debugging Tools ​

kubectl Debugging Tools ​

bash
# Pod debugging
kubectl debug <pod-name> -n <namespace> --image=busybox:1.28 --target=<container-name>

# Node debugging
kubectl debug node/<node-name> -it --image=busybox:1.28

# Create temporary debugging pod
kubectl run debug --rm -it --image=nicolaka/netshoot -- /bin/bash

AWS CLI Debugging Tools ​

bash
# Describe EKS cluster
aws eks describe-cluster --name my-cluster

# Describe EKS node group
aws eks describe-nodegroup --cluster-name my-cluster --nodegroup-name my-nodegroup

# CloudWatch Logs query
aws logs start-query \
  --log-group-name /aws/eks/my-cluster/cluster \
  --start-time $(date -u -v-1H +%s) \
  --end-time $(date -u +%s) \
  --query-string 'fields @timestamp, @message | filter @message like /Error/'

Network Debugging Tools ​

bash
# Create network debugging pod
kubectl run netshoot --rm -it --image=nicolaka/netshoot -- /bin/bash

# Test network connectivity
nc -zv <service-name> <port>
curl -v <service-name>:<port>

# DNS check
dig <service-name>.<namespace>.svc.cluster.local

# Packet capture
tcpdump -i any port <port> -w capture.pcap

结论 ​

在本文档中,我们探讨了用于 Amazon EKS clusters 监控和日志记录的各种工具、技术和最佳实践。实施有效的监控和日志记录策略,可以让你持续了解 cluster 的状态,及早发现问题,并在问题发生时快速响应。

涵盖的关键主题:

  1. Monitoring and Logging Overview: 监控和日志记录的重要性与架构
  2. EKS Control Plane Logging: Control Plane log 类型以及启用方法
  3. Container Logging: 使用 Fluent Bit 和 CloudWatch Container Insights 进行 container log collection
  4. Cluster Monitoring: 使用 CloudWatch、Prometheus 和 Grafana 进行 cluster monitoring
  5. Alerting and Event Management: 使用 CloudWatch alarms 和 Prometheus Alertmanager 进行 alert configuration
  6. Log Analysis and Visualization: 使用 CloudWatch Logs Insights、OpenSearch 和 Grafana Loki 进行 log analysis
  7. Monitoring and Logging Best Practices: 有效监控和日志记录的最佳实践
  8. Troubleshooting and Debugging: 常见问题和解决方案

EKS clusters 中的监控和日志记录是一个持续过程,应不断改进,以满足你的 cluster 和 applications 的要求。

参考资料 ​

测验 ​

要测试你在本章学到的内容,请尝试 topic quiz。

向文档提问

按 Enter 发送,按 Shift+Enter 换行。