Intelligent Remediation: Action generation with AI

概要とメリット

• Intelligent Remediationは、AIを活用してアラートやインシデントに対する修復アクションを自動生成する機能です。問題発生時に人間が手動で対応方法を考える代わりに、AIが過去のデータやベストプラクティスに基づいて適切な対応策を提案します。
• 問題の根本原因分析から修復手順の提案まで、AIが自動的に実行することで、MTTR（平均復旧時間）を大幅に短縮できます。
• 経験の浅いオペレーターでも、AIの提案に従うことで適切な対応が可能になり、チーム全体の対応品質が向上します。

公式ドキュメントのリンク

• https://www.ibm.com/docs/ja/instana-observability/current?topic=remediation-action-generation-ai

公式ドキュメントで不足している情報

AIモデルの学習データと精度向上

公式ドキュメントではAIの仕組みについて詳しく触れられていませんが、実運用では以下の点を理解しておく必要があります。

AIが学習するデータソース:

1. 過去のインシデント履歴
2. 過去に発生した問題とその解決方法

3. 対応にかかった時間と効果

4. 環境固有のパターン

5. 自社環境でのアプリケーション構成
6. よく発生する問題のパターン

7. 効果的だった対応策

8. ベストプラクティス

9. 一般的な問題に対する推奨対応
10. 業界標準の修復手順

精度を向上させるための運用:

# インシデント対応後、必ずフィードバックを記録
# Instana UIで対応結果を記録することで、AIの学習データが蓄積される

# 良い例:
# - 提案された対応策を実施
# - 結果を記録（成功/失敗、所要時間）
# - 追加で実施した手順があれば記録

# 悪い例:
# - AIの提案を無視して独自に対応
# - 結果を記録しない
# - フィードバックを提供しない

初期セットアップ時の注意点

公式ドキュメントでは設定方法が中心ですが、実際には以下の準備が重要です。

1. 十分なデータ蓄積期間

Intelligent Remediationを有効にする前に、最低でも2週間以上のデータを蓄積することを推奨します：

# configuration.yaml
com.instana.plugin.ai:
  intelligent_remediation:
    enabled: false  # 初期は無効にしてデータを蓄積
    data_collection:
      enabled: true  # データ収集のみ有効

2週間後に有効化：

com.instana.plugin.ai:
  intelligent_remediation:
    enabled: true
    confidence_threshold: 0.7  # 信頼度70%以上の提案のみ表示

2. アラートチャネルとの統合設定

AIが生成したアクションを通知に含めるための設定：

# アラート通知にAI提案を含める
com.instana.plugin.ai:
  intelligent_remediation:
    include_in_alerts: true
    max_actions: 3  # 最大3つのアクションを提案
    action_types:
      - "diagnostic"  # 診断コマンド
      - "remediation"  # 修復コマンド
      - "rollback"    # ロールバック手順

3. 権限とセキュリティ設定

AIが提案するアクションには、システムに影響を与えるコマンドが含まれる場合があります：

# 実行可能なアクションの制限
com.instana.plugin.ai:
  intelligent_remediation:
    allowed_actions:
      - "kubectl restart"
      - "systemctl restart"
      - "docker restart"
    forbidden_actions:
      - "rm -rf"
      - "DROP DATABASE"
      - "shutdown"
    require_approval: true  # 実行前に承認を必須にする

Kubernetes環境での統合

公式ドキュメントでは一般的な設定が中心ですが、Kubernetes環境では追加の設定が必要です。

ServiceAccountとRBACの設定:

# instana-ai-remediation-sa.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: instana-ai-remediation
  namespace: instana-agent
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: instana-ai-remediation
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "delete"]
  - apiGroups: ["apps"]
    resources: ["deployments", "statefulsets"]
    verbs: ["get", "list", "patch"]
  - apiGroups: [""]
    resources: ["pods/log"]
    verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: instana-ai-remediation
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: instana-ai-remediation
subjects:
  - kind: ServiceAccount
    name: instana-ai-remediation
    namespace: instana-agent

適用：

kubectl apply -f instana-ai-remediation-sa.yaml

# Instana AgentのDaemonSetに追加
kubectl patch daemonset instana-agent -n instana-agent --patch '
spec:
  template:
    spec:
      serviceAccountName: instana-ai-remediation
'

具体的なユースケース

ユースケース1: Podのクラッシュループに対する自動診断と修復

背景・課題: Kubernetes環境でPodが頻繁にクラッシュし、手動で原因調査と再起動を繰り返している。夜間や休日の対応が負担になっている。

解決方法: Intelligent RemediationがPodクラッシュを検知し、自動的に診断と修復アクションを提案。

手順:

1. アラート発生
2. Pod payment-service-7d8f9c-xyz がCrashLoopBackOffに

3. Instanaが自動的にアラートを生成

4. AIによる診断アクション生成

Instana UIのアラート詳細に以下が表示される：

AI提案: 診断アクション
信頼度: 85%

1. ログの確認
   kubectl logs payment-service-7d8f9c-xyz --tail=100

2. 前回のログ確認（クラッシュ前）
   kubectl logs payment-service-7d8f9c-xyz --previous

3. イベントの確認
   kubectl describe pod payment-service-7d8f9c-xyz

1. 診断結果の分析

ログから以下のエラーを発見：

Error: Unable to connect to database: Connection timeout
FATAL: password authentication failed for user "payment_user"

1. AIによる修復アクション生成

AI提案: 修復アクション
信頼度: 78%
根本原因: データベース認証情報の不一致

推奨アクション:
1. Secretの確認
   kubectl get secret payment-db-secret -o yaml

2. データベース接続のテスト
   kubectl run -it --rm debug --image=postgres:14 --restart=Never -- \
     psql -h payment-db -U payment_user -d payment_db

3. Secretの更新（必要な場合）
   kubectl create secret generic payment-db-secret \
     --from-literal=username=payment_user \
     --from-literal=password=<new-password> \
     --dry-run=client -o yaml | kubectl apply -f -

4. Podの再起動
   kubectl rollout restart deployment payment-service

1. 対応の実施

オペレーターがAIの提案に従って対応： - Secretを確認し、パスワードが古いことを発見 - 正しいパスワードでSecretを更新 - Deploymentを再起動 - Podが正常に起動することを確認

1. フィードバックの記録

Instana UIで対応結果を記録： - 提案されたアクションの有効性: 有効 - 所要時間: 5分 - 追加で実施した手順: なし

期待される効果: - MTTR: 30分 → 5分（83%削減） - 夜間対応の負担軽減 - AIの学習データ蓄積により、次回以降の精度向上

ユースケース2: メモリリークに対する段階的な対応提案

背景・課題: アプリケーションのメモリ使用量が徐々に増加し、最終的にOOMで停止する。原因特定と対応に時間がかかる。

解決方法: AIがメモリ使用量の異常なパターンを検知し、段階的な診断と対応を提案。

手順:

1. 早期警告アラート

メモリ使用量が通常の1.5倍に達した時点でアラート：

AI提案: 予防的診断
信頼度: 72%

メモリ使用量が異常に増加しています。
OOMが発生する前に以下の診断を実施することを推奨します。

1. ヒープダンプの取得
   kubectl exec api-server-abc123 -- \
     jcmd 1 GC.heap_dump /tmp/heap_dump.hprof

2. ヒープダンプのダウンロード
   kubectl cp api-server-abc123:/tmp/heap_dump.hprof ./heap_dump.hprof

3. スレッドダンプの取得
   kubectl exec api-server-abc123 -- jstack 1 > thread_dump.txt

1. 診断結果に基づく分析

AIがプロファイルデータと組み合わせて分析：

AI分析結果:
- 大量のStringオブジェクトがヒープに蓄積
- CacheManagerクラスでメモリリークの可能性
- 過去の類似ケース: 3件（すべてキャッシュ関連）

1. 段階的な修復アクション提案

AI提案: 段階的修復

【即時対応】信頼度: 90%
1. 手動でGCを実行
   kubectl exec api-server-abc123 -- jcmd 1 GC.run

2. 効果を確認（メモリ使用量が減少するか）
   # Instana UIでメモリメトリクスを監視

【短期対応】信頼度: 85%
3. キャッシュをクリア（アプリケーション固有）
   kubectl exec api-server-abc123 -- \
     curl -X POST http://localhost:8080/admin/cache/clear

4. Podを再起動
   kubectl delete pod api-server-abc123

【中期対応】信頼度: 75%
5. キャッシュサイズの制限を設定
   # ConfigMapを更新
   cache.max-size=1000
   cache.eviction-policy=LRU

6. アプリケーションを再デプロイ
   kubectl rollout restart deployment api-server

1. 対応の実施と効果確認

2. 即時対応: GC実行でメモリが20%削減（一時的）

3. 短期対応: Pod再起動で正常化
4. 中期対応: ConfigMap更新でメモリ使用量が安定

期待される効果: - OOM発生前に予防的対応が可能 - 段階的なアプローチで影響を最小化 - 根本原因の修正により再発防止

ユースケース3: データベース接続プールの枯渇対応

背景・課題: 突然アプリケーションが応答しなくなり、「Connection pool exhausted」エラーが発生。原因と対応方法が不明。

解決方法: AIが接続プール枯渇を検知し、原因特定と対応策を提案。

手順:

1. アラート発生とAI分析

AI提案: 緊急診断
信頼度: 88%

データベース接続プールが枯渇しています。
以下の診断を実施してください。

1. 現在のアクティブ接続数を確認
   kubectl exec app-server-xyz -- \
     curl http://localhost:8080/actuator/metrics/hikaricp.connections.active

2. 待機中のスレッドを確認
   kubectl exec app-server-xyz -- jstack 1 | grep -A 5 "waiting for connection"

3. データベース側の接続数を確認
   # Instana UIのDatabase viewで確認

1. 原因の特定

AIが過去のトレースデータを分析：

AI分析結果:
- 特定のAPIエンドポイント (/api/reports/generate) が長時間接続を保持
- 平均実行時間: 45秒（通常は2秒）
- 同時実行数: 20（接続プールサイズ: 20）
- 結論: 長時間実行クエリが接続プールを占有

1. 修復アクション提案

AI提案: 修復アクション

【即時対応】信頼度: 92%
1. 長時間実行中のクエリをキャンセル
   # データベースで実行
   SELECT pg_cancel_backend(pid) 
   FROM pg_stat_activity 
   WHERE state = 'active' AND query_start < NOW() - INTERVAL '30 seconds';

2. 接続プールサイズを一時的に増やす
   kubectl set env deployment/app-server \
     SPRING_DATASOURCE_HIKARI_MAXIMUM_POOL_SIZE=40

【恒久対応】信頼度: 80%
3. 長時間実行クエリにタイムアウトを設定
   # application.propertiesに追加
   spring.datasource.hikari.connection-timeout=30000
   spring.jpa.properties.hibernate.query.timeout=30000

4. レポート生成を非同期処理に変更
   # コード修正が必要
   @Async
   public CompletableFuture<Report> generateReport(...)

1. 対応の実施

2. 即時対応で接続プールを解放

3. アプリケーションが正常に応答開始
4. 恒久対応として非同期処理を実装

期待される効果: - サービス停止時間: 15分 → 3分 - 再発防止策の実装 - 同様の問題に対する対応パターンの確立

実運用での注意点・ベストプラクティス

AIの提案を盲目的に信頼しない

AIの提案は参考情報として扱い、必ず内容を確認してから実行してください：

# 良い例: 提案内容を理解してから実行
# 1. 提案されたコマンドを確認
# 2. 影響範囲を理解
# 3. 必要に応じてdry-runで確認
kubectl delete pod xxx --dry-run=client

# 悪い例: 提案をそのままコピー&ペーストで実行

フィードバックループの確立

AIの精度を向上させるため、必ず対応結果をフィードバック：

1. 対応後の記録
2. 提案されたアクションの有効性
3. 実際に実施した手順

4. 所要時間と効果

5. 定期的なレビュー

6. 月次でAIの提案精度をレビュー
7. 効果的だった提案パターンを共有
8. 改善が必要な領域を特定

段階的な権限付与

初期は診断アクションのみを許可し、徐々に修復アクションを追加：

# フェーズ1: 診断のみ（最初の1ヶ月）
com.instana.plugin.ai:
  intelligent_remediation:
    allowed_action_types:
      - "diagnostic"

# フェーズ2: 安全な修復アクションを追加（2-3ヶ月目）
com.instana.plugin.ai:
  intelligent_remediation:
    allowed_action_types:
      - "diagnostic"
      - "restart"
      - "scale"

# フェーズ3: 完全な自動化（4ヶ月目以降）
com.instana.plugin.ai:
  intelligent_remediation:
    allowed_action_types:
      - "diagnostic"
      - "restart"
      - "scale"
      - "rollback"
      - "configuration_change"

よくあるトラブルと解決方法

AIの提案が表示されない

症状: アラートは発生するが、AIによる修復アクションの提案が表示されない。

原因: データ不足、または信頼度閾値が高すぎる。

解決方法:

# 1. データ収集状況を確認
# Instana UIで Settings → AI Configuration → Data Collection Status

# 2. 信頼度閾値を一時的に下げる
kubectl edit configmap instana-agent-config -n instana-agent

# confidence_threshold: 0.7 → 0.5 に変更

# 3. Agentを再起動
kubectl rollout restart daemonset/instana-agent -n instana-agent

# 4. ログで提案生成を確認
kubectl logs -n instana-agent -l app=instana-agent | grep "AI remediation"

提案されたコマンドが実行できない

症状: AIが提案したコマンドを実行しようとすると、権限エラーが発生する。

原因: ServiceAccountの権限不足。

解決方法:

# 1. 必要な権限を確認
kubectl auth can-i delete pods --as=system:serviceaccount:instana-agent:instana-ai-remediation

# 2. 不足している権限を追加
kubectl edit clusterrole instana-ai-remediation

# 必要なverbsを追加
# verbs: ["get", "list", "delete", "patch", "update"]

# 3. 権限の反映を確認
kubectl auth can-i delete pods --as=system:serviceaccount:instana-agent:instana-ai-remediation
# 結果: yes

AIの提案が環境に合わない

症状: AIが提案するコマンドが自社環境の構成と合わず、実行できない。

原因: 環境固有の設定がAIに学習されていない。

解決方法:

# カスタムアクションテンプレートを定義
# instana-custom-actions.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: instana-custom-actions
  namespace: instana-agent
data:
  pod-restart: |
    # 自社環境用のPod再起動手順
    kubectl drain <node> --ignore-daemonsets
    kubectl delete pod <pod-name>
    kubectl uncordon <node>

  database-connection-reset: |
    # 自社環境用のDB接続リセット
    kubectl exec <pod> -- /opt/app/scripts/reset-db-pool.sh

適用：

kubectl apply -f instana-custom-actions.yaml

# Instana Agentの設定に追加
kubectl edit configmap instana-agent-config -n instana-agent

# custom_actions_configmap: instana-custom-actions を追加

これにより、AIは標準的な提案に加えて、カスタムアクションも提案するようになります。