基本情報：
□ いつから問題が発生しているか？
□ どのサービス・機能が影響を受けているか？
□ エラーメッセージは何か？
□ 最近の変更はあったか？
影響範囲：
□ 全ユーザーに影響があるか？
□ 特定の機能のみか？
□ 地域・時間帯による違いはあるか？
□ 他のサービスへの影響はあるか？

サービス停止の場合：
1. Pod の異常終了
2. Service の設定ミス
3. Ingress の設定問題
4. ネットワーク接続問題
パフォーマンス低下の場合：
1. リソース不足（CPU・メモリ）
2. データベース接続問題
3. 外部API の応答遅延
4. ネットワーク帯域の問題

高確率・低コスト：
- ログの確認
- リソース使用状況の確認
- 基本的なコマンド実行
中確率・中コスト：
- 詳細な設定確認
- ネットワーク接続テスト
- パフォーマンス分析
低確率・高コスト：
- 深いシステム分析
- 外部システムとの連携確認
- 複雑な再現テスト

症状：
- ユーザーからのアクセスが全て500エラー
- 15分前から発生
- 最近のデプロイはなし
調査手順：
1. kubectl get pods → 全Pod正常稼働
2. kubectl get svc → Service設定正常
3. kubectl logs [pod-name] → データベース接続エラー発見
4. kubectl get pods -n database → データベースPod停止中
5. kubectl describe pod [db-pod] → ディスク容量不足が原因
解決：
- 不要ログファイルの削除
- ディスク容量監視の強化
- 復旧時間：25分

症状：
- 検索機能のみ応答が遅い（通常200ms → 5秒）
- 他の機能は正常
- 1時間前から発生
調査手順：
1. kubectl top pods → 検索API Podの CPU使用率が90%
2. kubectl logs [search-pod] → 大量のクエリログ
3. 外部監視ツール確認 → 特定ユーザーからの異常なリクエスト
4. アプリケーションログ分析 → ボット攻撃を確認
解決：
- レート制限の実装
- 異常なIPアドレスのブロック
- HPA設定の調整
- 復旧時間：15分

クラスターレベル：
- kube-apiserver ログ
- kube-scheduler ログ
- kube-controller-manager ログ
- etcd ログ
ノードレベル：
- kubelet ログ
- kube-proxy ログ
- コンテナランタイムログ
アプリケーションレベル：
- コンテナ標準出力・エラー出力
- アプリケーション固有ログ

# Pod の標準出力確認
kubectl logs [pod-name]
# 複数コンテナがある場合
kubectl logs [pod-name] -c [container-name]
# 前回起動時のログ確認
kubectl logs [pod-name] --previous
# リアルタイムログ監視
kubectl logs -f [pod-name]
# 複数Podのログを同時確認
kubectl logs -l app=myapp --tail=100

{
  "timestamp": "2025-07-13T12:00:00Z",
  "level": "ERROR",
  "service": "user-api",
  "pod": "user-api-abc123",
  "message": "Database connection failed",
  "error": "connection timeout",
  "duration_ms": 5000,
  "request_id": "req-456"
}

# エラーレベルのログのみ抽出
kubectl logs [pod-name] | jq 'select(.level=="ERROR")'
# 特定時間範囲のログ抽出
kubectl logs [pod-name] --since=1h | grep "ERROR"
# リクエストIDでの追跡
kubectl logs [pod-name] | grep "req-456"

ログ分析時間：
- 従来：複数Podのログを個別確認（30分）
- ELK導入後：統合検索・可視化（3分）
問題発見率：
- 従来：見落としが多い（60%）
- ELK導入後：包括的な分析（95%）
相関分析：
- 従来：手動での関連性分析（困難）
- ELK導入後：自動相関分析（容易）

障害パターン分析：
1. Kibanaでエラーログの時系列分析
2. 特定時間帯でのエラー急増を発見
3. 関連するサービスのログを横断検索
4. 根本原因（外部API障害）を特定
5. 対策（リトライ機能強化）を実装

ノード監視：
- CPU使用率（平均・最大）
- メモリ使用率・スワップ使用量
- ディスク使用率・I/O性能
- ネットワーク帯域・パケット損失
Kubernetesコンポーネント：
- API Server応答時間
- etcd性能・ストレージ使用量
- Scheduler待機時間
- Controller Manager処理時間

リソース使用量：
- CPU使用率（Request/Limit比較）
- メモリ使用量（RSS・キャッシュ）
- ネットワークI/O
- ファイルシステムI/O
アプリケーション：
- レスポンス時間・スループット
- エラー率・成功率
- アクティブ接続数
- キューの長さ

症状：
- レスポンス時間の増加
- CPU使用率が常に90%以上
- CPU Throttlingの発生
調査方法：
kubectl top pods --sort-by=cpu
kubectl describe pod [pod-name] # Limits確認
対策：
- CPU Limitの調整
- HPA（Horizontal Pod Autoscaler）設定
- アプリケーションの最適化

症状：
- OOMKilled（Out of Memory Killed）
- Pod の頻繁な再起動
- メモリ使用率が90%以上
調査方法：
kubectl describe pod [pod-name] # 終了理由確認
kubectl top pods --sort-by=memory
対策：
- Memory Limitの調整
- メモリリークの修正
- ガベージコレクション最適化

症状：
- 特定サービスへの接続タイムアウト
- 断続的な接続エラー
- レスポンス時間のばらつき
調査手順：
1. kubectl get svc # Service設定確認
2. kubectl get endpoints # エンドポイント確認
3. kubectl exec -it [pod] -- nslookup [service-name] # DNS確認
4. kubectl exec -it [pod] -- curl [service-url] # 接続テスト
よくある原因：
- Service Selectorの設定ミス
- Network Policyによる通信遮断
- DNS設定の問題
- ロードバランサーの設定問題

問題：
- API応答時間：通常200ms → 5秒
- エラー率：1% → 15%
- ユーザーからの苦情が急増
調査プロセス：
1. kubectl top pods → CPU・メモリ使用量は正常
2. アプリケーションログ → データベース接続タイムアウト多発
3. kubectl get pods -n database → データベースPod正常
4. データベース内部監視 → 接続プール枯渇を発見
5. アプリケーション設定確認 → 接続プール設定が不適切
根本原因：
- 接続プールサイズ：10（不足）
- 接続タイムアウト：30秒（長すぎ）
- 接続リークの発生
解決策：
- 接続プールサイズを50に増加
- 接続タイムアウトを5秒に短縮
- 接続リーク修正のコード改修
- 接続プール監視の追加
結果：
- API応答時間：200ms に回復
- エラー率：0.5% に改善
- 復旧時間：45分

外部 → Ingress → Service → Pod
↓       ↓        ↓       ↓
DNS   LoadBalancer  kube-proxy  Container

Ingress層：
- SSL証明書の問題
- ルーティング設定ミス
- ロードバランサーの障害
Service層：
- Selector設定ミス
- ポート設定の間違い
- エンドポイントの不整合
Pod層：
- コンテナポートの設定ミス
- アプリケーションの起動失敗
- ヘルスチェックの失敗

# 外部からのアクセステスト
curl -v https://myapp.example.com/health
# DNS解決確認
nslookup myapp.example.com
# SSL証明書確認
openssl s_client -connect myapp.example.com:443

# Service経由での接続テスト
kubectl exec -it [test-pod] -- curl http://myapp-service:8080/health
# Pod直接接続テスト
kubectl exec -it [test-pod] -- curl http://[pod-ip]:8080/health
# DNS解決テスト
kubectl exec -it [test-pod] -- nslookup myapp-service

# Network Policy一覧
kubectl get networkpolicy
# 特定ポリシーの詳細確認
kubectl describe networkpolicy [policy-name]
# ポリシー適用状況の確認
kubectl get pods --show-labels

問題：
- サービスA → サービスB の通信が断続的に失敗
- エラー率：約20%
- 特定の時間帯に集中
調査プロセス：
1. kubectl get svc service-b → Service設定正常
2. kubectl get endpoints service-b → エンドポイント数が変動
3. kubectl get pods -l app=service-b → Pod数が頻繁に変動
4. kubectl describe hpa service-b-hpa → HPA が頻繁にスケーリング
5. kubectl logs -l app=service-b → 起動時間が長い（30秒）
根本原因：
- HPA設定が敏感すぎる（CPU 50%でスケールアウト）
- Pod起動時間が長い
- Readiness Probeの設定が不適切
- 起動中のPodにトラフィックが流れる
解決策：
- HPA閾値を70%に調整
- Pod起動時間の最適化（イメージサイズ削減）
- Readiness Probeの適切な設定
- 起動時間を考慮したProbe設定
結果：
- エラー率：20% → 0.1%
- サービス安定性：大幅向上
- 復旧時間：2時間

人的対応の限界：
- 深夜・休日の対応困難
- 対応者のスキル差
- 手順の属人化
- 対応時間のばらつき
自動化の効果：
- 24時間365日の監視・対応
- 一貫した品質の対応
- 迅速な初期対応
- 人的リソースの効率活用

#!/bin/bash
# pod-health-check.sh
NAMESPACE=${1:-default}
APP_LABEL=${2:-app}
echo "=== Pod Health Check for $NAMESPACE ==="
# Pod状態確認
kubectl get pods -n $NAMESPACE -l $APP_LABEL --no-headers | while read line; do
    POD_NAME=$(echo $line | awk '{print $1}')
    STATUS=$(echo $line | awk '{print $3}')
    RESTARTS=$(echo $line | awk '{print $4}')
    if [ "$STATUS" != "Running" ]; then
        echo "⚠️  $POD_NAME: Status=$STATUS"
        kubectl describe pod $POD_NAME -n $NAMESPACE | grep -A 5 "Events:"
    fi
    if [ "$RESTARTS" -gt 3 ]; then
        echo "⚠️  $POD_NAME: High restart count=$RESTARTS"
        kubectl logs $POD_NAME -n $NAMESPACE --tail=10
    fi
done

#!/bin/bash
# resource-check.sh
echo "=== Resource Usage Check ==="
# CPU使用率上位Pod
echo "## High CPU Usage Pods:"
kubectl top pods --all-namespaces --sort-by=cpu | head -10
# メモリ使用率上位Pod
echo "## High Memory Usage Pods:"
kubectl top pods --all-namespaces --sort-by=memory | head -10
# ノードリソース状況
echo "## Node Resource Status:"
kubectl top nodes

# pod-restart-cronjob.yaml
apiVersion: batch/v1
kind: CronJob
metadata:
  name: pod-health-monitor
spec:
  schedule: "*/5 * * * *"  # 5分毎実行
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: health-monitor
            image: kubectl:latest
            command:
            - /bin/sh
            - -c
            - |
              # 異常なPodを検出・再起動
              kubectl get pods --all-namespaces --field-selector=status.phase!=Running | \
              grep -v "Completed\|Succeeded" | \
              while read namespace pod rest; do
                if [ "$namespace" != "NAMESPACE" ]; then
                  echo "Restarting unhealthy pod: $namespace/$pod"
                  kubectl delete pod $pod -n $namespace
                fi
              done
          restartPolicy: OnFailure

# emergency-hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: emergency-scaling
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: critical-service
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 70
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 60
      policies:
      - type: Percent
        value: 100
        periodSeconds: 60
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 10
        periodSeconds: 60

障害検知時間：
- 導入前：平均30分（人的監視）
- 導入後：平均2分（自動監視）
初期対応時間：
- 導入前：平均45分（担当者への連絡・対応）
- 導入後：平均5分（自動対応）
復旧成功率：
- 導入前：70%（人的対応のばらつき）
- 導入後：90%（一貫した自動対応）
運用工数：
- 導入前：週40時間（24時間監視体制）
- 導入後：週10時間（例外対応のみ）