eks-app-log-analysis

EKS 应用日志分析

在 FIS 故障注入实验期间分析 EKS 应用日志，了解应用如何应对基础设施故障。支持实时监控和 事后分析模式。

输出语言规则

检测用户对话所用的语言，并在所有输出中使用相同的语言。

• 输入为中文 -> 输出为中文
• 输入为英文 -> 输出为英文

前提条件

所需工具：

• kubectl — 已配置为可访问目标 EKS 集群
• AWS CLI — 用于查询 FIS 实验状态
• 已准备/执行的 FIS 实验目录（来自 aws-fis-experiment-prepare 或 aws-fis-experiment-execute）

工作流

digraph log_analysis_flow {
    "Receive input path" [shape=box];
    "Detect mode" [shape=diamond];
    "Real-time mode" [shape=box];
    "Post-hoc mode" [shape=box];
    "Read service list" [shape=box];
    "Auto-discover + confirm app dependencies" [shape=box];
    "Start background log collection" [shape=box];
    "Batch fetch historical logs" [shape=box];
    "Frontend polling + insight display" [shape=box];
    "Experiment complete?" [shape=diamond];
    "Generate analysis report" [shape=box];

    "Receive input path" -> "Detect mode";
    "Detect mode" -> "Real-time mode" [label="directory with README"];
    "Detect mode" -> "Post-hoc mode" [label="*-experiment-results.md"];
    "Real-time mode" -> "Read service list";
    "Post-hoc mode" -> "Read service list";
    "Read service list" -> "Auto-discover + confirm app dependencies";
    "Auto-discover + confirm app dependencies" -> "Start background log collection" [label="real-time"];
    "Auto-discover + confirm app dependencies" -> "Batch fetch historical logs" [label="post-hoc"];
    "Start background log collection" -> "Frontend polling + insight display";
    "Frontend polling + insight display" -> "Experiment complete?";
    "Experiment complete?" -> "Frontend polling + insight display" [label="No, continue"];
    "Experiment complete?" -> "Generate analysis report" [label="Yes"];
    "Batch fetch historical logs" -> "Generate analysis report";
}

步骤 1：检测模式并加载上下文

用户提供以下任一内容：

• 目录路径（例如，./2026-03-31-14-30-22-az-power-interruption-my-cluster/）→ 实时模式
• 报告文件路径（例如，./2026-03-31-...-experiment-results.md）→ 事后分析模式

实时模式： 目录中包含来自 prepare 技能的 README.md。 从中提取实验模板 ID 和区域。

事后分析模式： 文件是实验结果报告（包含 "FIS Experiment Results"）。从中提取实验 ID、开始时间、结束时间和区域。

步骤 2：读取服务列表

从以下位置提取受影响的 AWS 服务：

• 实验目录中的 expected-behavior.md（实时模式），或
• 实验结果报告（事后分析模式）

查找服务名称标题（例如，“### RDS (cluster-xxx)”）以建立列表。 向用户展示检测到的服务列表。

步骤 3：收集应用依赖项

3a. 自动发现潜在依赖项

对于每个受影响的 AWS 服务，自动发现可能依赖它的 EKS 应用：

1. 通过 AWS CLI 获取服务端点（例如，RDS 集群端点、ElastiCache 主端点、EC2 私有 IP/DNS）
2. 在所有命名空间的 Pod 环境变量中搜索对该端点的引用
3. 在所有命名空间的 ConfigMap 中搜索对该端点的引用
4. 向用户展示发现的 namespace/deployment 候选项，并注明匹配位置（环境变量名称、ConfigMap 名称）

3b. 用户确认和手动补充

请用户确认自动发现的依赖项，并补充任何遗漏项。将最终映射保存为 SERVICE_APP_MAP（服务 → namespace/deployment 对列表）。

步骤 4：日志收集

Shell 脚本规则： 使用多行脚本。不要在单行中使用 && 链接命令 — 后台 & 进程启动后，变量会丢失。

所有日志都应保存到临时目录：/tmp/{timestamp}-fis-app-logs/， 并按服务名称创建子目录。

实时模式：后台收集

对于 SERVICE_APP_MAP 中的每个应用，为常规容器（不包括 FIS 注入的临时容器）启动后台 kubectl logs -f 进程：

1. 从 .spec.selector.matchLabels 解析 Deployment 的 Pod 标签选择器
2. 从 Deployment 规格中获取常规容器名称列表：

   kubectl get deployment {DEPLOYMENT} -n {NAMESPACE} \
     -o jsonpath='{.spec.template.spec.containers[*].name}'
   

   不要使用 --all-containers=true — FIS Pod 级故障注入（例如， pod-network-latency、pod-cpu-stress）会向目标 Pod 注入临时容器。使用 --all-containers 会在应用日志之外收集到 FIS Agent 日志（噪声）。始终使用 --container={name}，仅收集常规容器的日志。
3. 对每个常规容器，启动后台日志流：

   kubectl logs -f --selector={labels} -n {NAMESPACE} \
     --container={CONTAINER_NAME} --timestamps --prefix=true \
     --max-log-requests=20 \
     >> {LOG_DIR}/{service-name}/{deployment}.log &
   

   使用 --selector={labels}（不要使用 deployment/xxx）— 这样可以捕获所有匹配 Pod 的日志，包括实验期间重新创建的 Pod。
4. 将每个后台进程 PID 记录到 {LOG_DIR}/.pids，以便清理

事后模式：批量获取

在事后模式下，实验期间 Pod 可能已终止。请先检测 Container Insights 是否可用，然后据此选择日志来源。

步骤 4a：检测 Container Insights

检查 EKS 集群是否已启用 Container Insights：

• 查找 amazon-cloudwatch-observability EKS 插件（使用 aws eks describe-addon）
• 或检查 amazon-cloudwatch 命名空间中是否存在 CloudWatch agent / Fluent Bit daemonset

步骤 4b：CloudWatch Logs（已启用 Container Insights 时优先使用）

针对日志组 /aws/containerinsights/{CLUSTER_NAME}/application，查询实验时间范围 （START_TIME 至 END_TIME）内的 CloudWatch Logs Insights。按每个部署的 kubernetes.namespace_name 和 kubernetes.labels.app（或 Pod 名称模式）筛选。这样可以获取 完整日志，包括来自已不存在的 Pod 的日志。

步骤 4c：kubectl logs（回退方案，未启用 Container Insights 时使用）

对每个常规容器（容器发现方式与实时模式步骤 2 相同），使用 kubectl logs --selector={labels} --since-time={START_TIME}，并添加 --container={CONTAINER_NAME} --timestamps --prefix=true。不要使用 --all-containers。 注意：这只能获取当前正在运行的 Pod 的日志；实验期间已终止的 Pod 的日志将会丢失。

步骤 5：实时监控显示

实验运行期间每 30 秒轮询一次。对于每个服务组和每个应用：

1. 从日志文件中读取最近 30 秒收集的日志
2. 统计错误级别条目（匹配：error、exception、fail、refused、timeout）和警告级别条目（匹配：warn、retry）
3. 显示每个应用的摘要：错误数量、警告数量、最近 5 条错误日志
4. 检测近期日志中的恢复信号（connected、restored、success、recovered），如有发现则报告

步骤 6：检查实验状态（实时模式）

使用 aws fis list-experiments 检查具有匹配模板 ID 的实验是否仍处于 running 状态。实验完成（或未找到）后，继续生成报告。

步骤 7：生成分析报告

实验完成后（或在事后模式下立即），生成报告：

TIMESTAMP=$(date +%Y-%m-%d-%H-%M-%S)
# Save the report in the experiment directory (EXPERIMENT_DIR)
REPORT_FILE="${EXPERIMENT_DIR}/${TIMESTAMP}-app-log-analysis.md"

报告结构：

# Application Log Analysis Report

**Experiment ID:** {EXPERIMENT_ID}
**Analysis Time:** {TIMESTAMP}
**Time Range:** {START_TIME} - {END_TIME}
**Duration:** {DURATION}

## Summary

| Service | Application | Total Errors | Peak Error Rate | Recovery Time |
|---------|-------------|--------------|-----------------|---------------|
| {service} | {app} | {count} | {rate}/min | {time} |

## Per-Service Application Analysis

### {Service Name} ({resource_id})

#### {Application Name} ({namespace}/{deployment})

**Error Timeline:**

| Time (UTC) | Level | Message |
|------------|-------|---------|
| {HH:MM:SS} | ERROR | {truncated message} |
| ... | ... | ... |

**Key Error Patterns:**

| Pattern | Count | First Occurrence | Last Occurrence |
|---------|-------|------------------|-----------------|
| Connection refused | {n} | {time} | {time} |
| Timeout | {n} | {time} | {time} |

**Log Sample (Critical Errors):**

{5-10 lines of actual error logs}

**Insights:**
- {insight_1}: Error spike at {time}, correlates with {service} failover
- {insight_2}: Recovery detected at {time}, {duration} after fault injection ended
- {insight_3}: Application retry mechanism worked/failed because...

(Repeat for each application)

## Cross-Service Correlation

| Time | Event | RDS Impact | ElastiCache Impact | Application Response |
|------|-------|------------|--------------------|--------------------|
| {time} | Fault injection start | - | - | First errors appear |
| {time} | {service} failover | Connection errors | - | Retrying... |
| {time} | Recovery | Connections restored | - | Normal operation |

## Recommendations

1. **{Issue}:** {description}
   - **Impact:** {what happened}
   - **Recommendation:** {what to improve}

## Appendix: Log File Locations

**Raw log directory:** `{LOG_DIR}`

To view raw logs after the analysis, navigate to the temp directory shown above.
These files will persist until the system clears `/tmp`.

| Application | Log File |
|-------------|----------|
| {app} | `{LOG_DIR}/{service}/{app}.log` |

步骤 8：清理（实时模式）

终止 {LOG_DIR}/.pids 中记录的所有后台 kubectl logs 进程。 清理后删除 PID 文件。

错误处理

错误	原因	解决方法
/.pids: Permission denied	&& 链导致 LOG_DIR 变量为空 — 路径解析为 /.pids	使用多行脚本和 export LOG_DIR=...，不要使用 && 链。参见步骤 4 的说明。
kubectl: command not found	未安装 kubectl	安装 kubectl 并配置 kubeconfig
error: You must be logged in	未配置 kubeconfig	运行 aws eks update-kubeconfig --name {cluster}
No resources found	部署/Pod 不存在	验证部署名称和命名空间
Unable to retrieve logs	Pod 未运行或已重启	检查 Pod 状态，可能需要从 CloudWatch Logs 获取日志
未找到模板 ID	README 格式已更改	手动提供模板 ID

输出文件

{EXPERIMENT_DIR}/                                 # Experiment directory
└── {timestamp}-app-log-analysis.md               # Analysis report

/tmp/{timestamp}-fis-app-logs/                    # Temp directory for raw logs
├── rds-cluster-xxx/
│   ├── app-backend.log
│   └── api-server.log
├── elasticache-redis-xxx/
│   └── cache-layer.log
└── .pids (temporary, cleaned up)

使用示例

# Real-time monitoring (during experiment)
"Analyze app logs for ./2026-03-31-14-30-22-az-power-interruption-my-cluster/"
"Monitor application behavior in the experiment directory"
"实时监控应用日志"

# Post-hoc analysis (after experiment)
"Analyze app logs using ./2026-03-31-14-35-00-az-power-interruption-my-cluster-experiment-results.md"
"分析实验报告中的应用表现"
"Check what happened to applications during the experiment"

与其他技能集成

• aws-fis-experiment-prepare — 读取 README.md 和 expected-behavior.md 以了解上下文
• aws-fis-experiment-execute — 读取 *-experiment-results.md 获取时间范围和服务列表
• 不会修改其他技能中的任何文件