[{"data":1,"prerenderedAt":334},["ShallowReactive",2],{"blog-ja-kubernetes-aiops-incident-response-distributed-tracing":3,"blog-related-ja-kubernetes-aiops-incident-response-distributed-tracing":282,"blog-ja-kubernetes-aiops-incident-response-distributed-tracing-alt":270},{"id":4,"title":5,"author":6,"body":7,"date":264,"description":265,"extension":266,"image":267,"locale":268,"meta":269,"navigation":270,"path":271,"seo":272,"stem":273,"tags":274,"__hash__":281},"blog\u002Fblog\u002Fja\u002Fkubernetes-aiops-incident-response-distributed-tracing.md","AIに『直して』と頼んでも直らない。Kubernetes本番障害調査は分散トレーシングから始まる","Kubo Team",{"type":8,"value":9,"toc":249},"minimark",[10,15,19,22,33,40,44,47,50,73,82,88,92,95,104,107,113,117,126,135,143,149,153,156,161,184,188,195,199,214,217,223,227,230,233,236],[11,12,14],"h2",{"id":13},"aiに障害調査を丸投げしても直らないkubernetesの本番障害","AIに障害調査を丸投げしても直らないKubernetesの本番障害",[16,17,18],"p",{},"深夜のアラート対応で「AIエージェントに原因調査を任せれば早く終わる」と考えたことがある方は多いはずだ。実際、AIはPodのログを要約し、再起動コマンドを提案し、YAMLの修正案まで一瞬で出してくれる。だがKubernetes運用の現場では、それで根本原因が解決したケースより、「表面上は直ったように見えて数時間後に再発した」というケースの方が圧倒的に多い。",[16,20,21],{},"理由は単純だ。AIはユーザーが渡したコンテキストの外にある事実には気づけない。あるチェックアウト機能が遅いという相談に対してAIに最適化コードを書かせても、本当のボトルネックがデータベース設計や過剰なクエリ呼び出しにあった場合、コードをどれだけ書き直しても遅延は解消しない。Kubernetesの本番障害対応でも構造は同じだ。障害を起こしたPodを再起動して一見収まったように見えても、原因が別サービスのスロークエリやネットワークポリシーの誤設定にあれば、AIにその情報を渡さない限り正しい診断には到達しない。",[16,23,24,25,32],{},"この記事では、KubernetesでAIOps（AIによる運用自動化）を機能させるために不可欠な「分散トレーシング」という前提条件と、OpenTelemetryを使った導入ステップを整理する。観測性の土台部分をゼロから構築する余力がないチームも多いはずだが、",[26,27,31],"a",{"href":28,"rel":29},"https:\u002F\u002Fkubo.hexabase.io\u002F",[30],"nofollow","Kubo","のようにPrometheus + Grafanaが標準搭載されたクラスタであれば、少なくとも監視基盤の構築そのものに時間を溶かさずに済む。",[16,34,35],{},[36,37],"img",{"alt":38,"src":39},"title","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-aiops-incident-response-distributed-tracing\u002Ftitle.webp",[11,41,43],{"id":42},"aiに直させるが失敗する現場のパターン","「AIに直させる」が失敗する現場のパターン",[16,45,46],{},"Kubernetesクラスタで障害が起きたとき、多くのチームがまず頼るのはPodのログとメトリクスのダッシュボードだ。AIエージェントにこれらの情報を渡して「原因を教えて」と聞けば、それらしい仮説はすぐに返ってくる。しかし、その仮説はAIに渡された情報の範囲内でしか成立しない。",[16,48,49],{},"典型的な誤診断パターンは次のようなものだ。",[51,52,53,61,67],"ul",{},[54,55,56,60],"li",{},[57,58,59],"strong",{},"Pod再起動で\"解決\"したように見える",": メモリリークのように見えて、実は上流サービスからのリクエストが異常に多重化していたケース",[54,62,63,66],{},[57,64,65],{},"特定のマイクロサービスのログだけを見て結論を出す",": 実際の遅延の起点は3つ先のサービス呼び出しだったケース",[54,68,69,72],{},[57,70,71],{},"CPU使用率の急上昇だけを根拠に「スケールアップが必要」と誤診断",": 実際にはリトライの多重発生がCPUを圧迫していたケース",[16,74,75,76,81],{},"いずれのケースも、単一サービスのログやメトリクスだけを見ている限り、AIも人間と同じように誤った結論に至る。",[26,77,80],{"href":78,"rel":79},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fcluster-administration\u002Flogging\u002F",[30],"Kubernetes公式ドキュメント","が示す通り、標準のロギング機構はコンテナ単位の出力を集約するに留まり、サービス間の因果関係までは表現できない。",[16,83,84],{},[36,85],{"alt":86,"src":87},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-aiops-incident-response-distributed-tracing\u002Fsection01.webp",[11,89,91],{"id":90},"メトリクスとログだけでは因果が見えない","メトリクスとログだけでは\"因果\"が見えない",[16,93,94],{},"Prometheus + Grafanaによるメトリクス監視は、「いつ」「どのコンポーネントで」異常が起きたかを教えてくれる。だが「なぜ」「どこが起点か」という因果関係の特定には別のデータが必要になる。",[16,96,97,98,103],{},"分散システムの障害調査に詳しいCoralogixの解説によれば、",[26,99,102],{"href":100,"rel":101},"https:\u002F\u002Fcoralogix.com\u002Fguides\u002Fobservability\u002Fdistributed-tracing\u002F",[30],"分散トレーシングはマイクロサービス間を横断するリクエストの全経路を可視化する","技術であり、メトリクスやログだけでは把握できないサービス間の依存関係と遅延の伝播経路を明らかにする。メトリクスは「何が起きたか」の集計値、ログは「その瞬間に何が記録されたか」の断片情報にすぎず、どちらも単体では「どのサービスの、どの呼び出しが遅延の起点か」という問いに答えられない。",[16,105,106],{},"AIエージェントに障害対応を任せる場合も同様の限界にぶつかる。ネットワーク運用領域でのAI活用について調査した業界動向でも、AIによる診断はまだ初期段階にあり、深い文脈理解を要する複雑な診断領域では人間の補助的な役割にとどまっているという指摘がある。AIが本当に役立つ判断を下すには、サービス境界を横断した構造化データが不可欠であり、それを提供できるのが分散トレーシングだ。",[16,108,109],{},[36,110],{"alt":111,"src":112},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-aiops-incident-response-distributed-tracing\u002Fsection02.webp",[11,114,116],{"id":115},"分散トレーシングがaiopsの前提条件になる理由","分散トレーシングがAIOpsの前提条件になる理由",[16,118,119,120,125],{},"分散トレーシングを整備すると何が変わるのか。W3C Trace Context標準に基づいてトレースIDをサービス間で伝播させることで、",[26,121,124],{"href":122,"rel":123},"https:\u002F\u002Foneuptime.com\u002Fblog\u002Fpost\u002F2026-02-06-trace-correlation-root-cause-analysis\u002Fview",[30],"単一のリクエストが複数サービスをまたいで処理される様子を一つの視点で追跡できる","ようになる。さらにログレコードへトレースIDを自動的に注入しておけば、「あるログ行から、そのリクエストの完全なトレースへ」とたどることが可能になり、調査時間を数時間から数分規模へ短縮できるとされている。",[16,127,128,129,134],{},"こうした構造化されたトレースデータがあって初めて、AIエージェントによる自動診断も現実的になる。CNCFのSandboxプロジェクトとして開発が進む",[26,130,133],{"href":131,"rel":132},"https:\u002F\u002Fwww.cncf.io\u002Fblog\u002F2026\u002F04\u002F21\u002Fauto-diagnosing-kubernetes-alerts-with-holmesgpt-and-cncf-tools\u002F",[30],"HolmesGPT","は、Prometheusのアラートを起点にKubernetesクラスタのログ・メトリクス・イベントを横断的に取得し、LLMが「ReActパターン」で調査ツールを選択しながら段階的に根本原因を絞り込む仕組みを持つ。興味深いのは、こうしたAI SREエージェントの精度を決めるのはモデル性能そのものよりも、調査対象・利用可能なツール・注意事項を定義した「runbook」の有無だという点だ。適切なrunbookとトレースデータが揃っていれば数ステップで解決に至る一方、それらが欠けていると20ステップ以上を無駄にすることもあると報告されている。",[16,136,137,138,142],{},"つまり、AIOpsは「賢いAIを導入すれば解決する」話ではなく、AIが参照できる構造化された観測性データ、その中核である分散トレーシングが土台として存在して初めて機能する。本記事で述べた「因果が見えない」という問題は、そもそも監視基盤がどこまで整っているかで大きく左右される。",[26,139,141],{"href":28,"rel":140},[30],"Kubo Cloud","はPrometheus・Grafanaを標準搭載し、Captain UIによってクラスタの状態を可視化できるため、分散トレーシング導入前の土台部分をあらかじめ備えた状態でクラスタ運用を始められる。",[16,144,145],{},[36,146],{"alt":147,"src":148},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-aiops-incident-response-distributed-tracing\u002Fsection03.webp",[11,150,152],{"id":151},"kubernetesクラスタにopentelemetryを組み込む現実的なステップ","KubernetesクラスタにOpenTelemetryを組み込む現実的なステップ",[16,154,155],{},"分散トレーシングをゼロから導入する場合、以下の順序で進めるのが現実的だ。",[157,158,160],"h3",{"id":159},"ステップ1-opentelemetry-operatorの導入","ステップ1: OpenTelemetry Operatorの導入",[16,162,163,168,169,173,174,177,178,183],{},[26,164,167],{"href":165,"rel":166},"https:\u002F\u002Fopentelemetry.io\u002Fdocs\u002Fplatforms\u002Fkubernetes\u002Foperator\u002F",[30],"OpenTelemetry Operator","はKubernetes上でCollectorの管理と自動計装を担うOperatorで、",[170,171,172],"code",{},"OpenTelemetryCollector","と",[170,175,176],{},"Instrumentation","という2種類のCustom Resource Definitionを提供する。",[26,179,182],{"href":180,"rel":181},"https:\u002F\u002Fgithub.com\u002Fopen-telemetry\u002Fopentelemetry-operator",[30],"GitHubの公式リポジトリ","にHelmチャートやマニフェストが公開されており、既存のクラスタに追加でデプロイする形で導入できる。",[157,185,187],{"id":186},"ステップ2-自動計装auto-instrumentationの有効化","ステップ2: 自動計装(Auto-Instrumentation)の有効化",[16,189,190,191,194],{},"対象のワークロードに",[170,192,193],{},"instrumentation.opentelemetry.io\u002Finject-\u003C言語>","のようなアノテーションを付与するだけで、アプリケーションコードを変更せずにOperatorがトレース計装用のinit-containerを自動的に注入してくれる。まずは影響範囲を確認しやすい1〜2個のマイクロサービスから試すのが安全だ。",[157,196,198],{"id":197},"ステップ3-サンプリング戦略の設計","ステップ3: サンプリング戦略の設計",[16,200,201,202,207,208,213],{},"トレースデータを全件収集するとストレージコストが急増するため、サンプリング戦略の設計が欠かせない。",[26,203,206],{"href":204,"rel":205},"https:\u002F\u002Flogz.io\u002Flearn\u002Fsampling-in-distributed-tracing-guide\u002F",[30],"Logz.ioの解説","によれば、リクエスト開始時点で即座に記録可否を判定する「head-based sampling」は低コストだが情報が限定的であり、全スパンを収集してから判定する「tail-based sampling」はエラーやレイテンシー条件を使った精緻な判断ができる一方でリソース負荷が高い。",[26,209,212],{"href":210,"rel":211},"https:\u002F\u002Fwww.datadoghq.com\u002Farchitecture\u002Foptimizing-distributed-tracing-best-practices-for-remaining-within-budget-and-capturing-critical-traces\u002F",[30],"Datadogが提唱するアプローチ","では、決済APIのような収益に直結するエンドポイントは高いサンプリング率を維持しつつ、ヘルスチェックのような低優先度の呼び出しはサンプリング率を大きく下げることで、月次のトレーシング予算を超過させずに重要な障害だけを確実に捕捉できるとされている。",[16,215,216],{},"トレースの保持期間についても、直近の障害調査に使う「ホットストレージ」は数十日程度、長期トレンド分析用は安価な「コールドストレージ」に分けて設計することで、コストと調査性のバランスを取りやすくなる。",[16,218,219],{},[36,220],{"alt":221,"src":222},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-aiops-incident-response-distributed-tracing\u002Fsection04.webp",[11,224,226],{"id":225},"まとめ-aiopsは監視ツールの置き換えではなく観測性基盤の上に成立する","まとめ: AIOpsは監視ツールの置き換えではなく観測性基盤の上に成立する",[16,228,229],{},"AIエージェントに障害対応を任せることそのものは、決して間違った方向性ではない。しかし、AIに「原因を直して」と頼む前に、そのAIが根本原因にたどり着くための材料——サービス境界を横断した分散トレーシングデータ——が整っているかどうかが、成果を大きく左右する。",[16,231,232],{},"Kubernetesクラスタの観測性を、Prometheus・Grafanaによるメトリクス監視だけで止めてしまっているチームは少なくない。だが本番障害対応の質を一段引き上げるには、分散トレーシングという土台への投資が避けて通れない。",[16,234,235],{},"AI時代のインフラ運用で本当に問われるのは、AIエージェントをどう使うかだけでなく、AIエージェントに正しい判断材料を渡せる基盤をどう整えるかだ。モニタリングスタックをゼロから構築・運用するコストは決して小さくないからこそ、その土台部分をあらかじめ備えたインフラを選ぶかどうかが差になる。",[16,237,238,239,242,243,248],{},"分散トレーシングの整備からKubernetes運用を見直したい場合は、",[26,240,31],{"href":28,"rel":241},[30]," の",[26,244,247],{"href":245,"rel":246},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[30],"お問い合わせ","から気軽に相談してみてほしい。EKSやAKSで同等の構成を組む場合と比べても、K3sベースのKuboならコスト効率よく観測性基盤を含めた本格的なKubernetes環境を構築できる。",{"title":250,"searchDepth":251,"depth":251,"links":252},"",2,[253,254,255,256,257,263],{"id":13,"depth":251,"text":14},{"id":42,"depth":251,"text":43},{"id":90,"depth":251,"text":91},{"id":115,"depth":251,"text":116},{"id":151,"depth":251,"text":152,"children":258},[259,261,262],{"id":159,"depth":260,"text":160},3,{"id":186,"depth":260,"text":187},{"id":197,"depth":260,"text":198},{"id":225,"depth":251,"text":226},"2026-07-27","Kubernetes本番環境の障害対応をAIに任せても、分散システムの因果関係が見えなければ的外れな対処になる。AIOpsを機能させる分散トレーシング設計とOpenTelemetry導入の実践ステップを解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-aiops-incident-response-distributed-tracing\u002Feyecatch.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fkubernetes-aiops-incident-response-distributed-tracing",{"title":5,"description":265},"blog\u002Fja\u002Fkubernetes-aiops-incident-response-distributed-tracing",[275,276,277,278,279,280],"kubernetes","k3s","observability","distributed-tracing","opentelemetry","aiops","X1LdQ5hbxIrVsxPcARrtXQIKOI894rjtNtq4g-KrP2s",[283,289,297,305,314,324],{"path":284,"title":285,"description":286,"date":287,"tags":288},"\u002Fblog\u002Fja\u002Fk3s-opentelemetry-observability-correlation","3つのダッシュボードを往復する障害対応はもう終わり。K3sの可観測性をOpenTelemetryで『相関』させる設計","PrometheusとLokiとJaegerを個別に確認して原因究明に時間を溶かしていないか。K3sクラスタの可観測性をOpenTelemetryで相関させ、障害調査時間を短縮する設計とOpenTelemetry Collectorの導入パターンを、K3s\u002FKubernetes運用の現場目線で解説する。","2026-08-20",[276,275,279,277,278],{"path":290,"title":291,"description":292,"date":293,"tags":294},"\u002Fblog\u002Fja\u002Fkubernetes-ebpf-inspektor-gadget-observability","strace禁止、sidecar禁止、それでも診断できる。KubernetesをeBPFで透視するInspektor Gadgetという回答","特権コンテナもsidecarも追加できない本番Kubernetesで、Podの通信とシステムコールをどう診断するか。eBPFツール「Inspektor Gadget」の仕組みと2026年の最新動向を解説する。","2026-08-15",[276,275,295,277,296],"ebpf","cncf",{"path":298,"title":299,"description":300,"date":301,"tags":302},"\u002Fblog\u002Fja\u002Fkubernetes-servicemonitor-silent-metrics-failure","Prometheusは動いている。なのにメトリクスが無い。ServiceMonitorが『静かに』失敗する3つの理由","Kubernetesのkubernetes service monitorが原因不明にスクレイプされない——ラベル不一致・namespaceSelector・RBACという3つの落とし穴を、公式ドキュメントを元に切り分け手順つきで解説する。","2026-08-14",[276,275,303,277,304],"prometheus","servicemonitor",{"path":306,"title":307,"description":308,"date":309,"tags":310},"\u002Fblog\u002Fja\u002Fedge-k3s-observability-homelab-dashboard","壁に貼っただけで「安心」に変わる。ホームラボの壁掛けダッシュボードが教えてくれた、エッジK3sクラスタの観測性設計","自宅の壁掛けダッシュボード作りで起きた総当たりのトラブルシューティングは、工場や店舗に分散したエッジKubernetesクラスタの運用でも同じ罠になる。K3s・Prometheus・Grafanaの公式ドキュメントを引きながら、観測性を後回しにしないための設計原則を解説する。","2026-07-26",[276,275,311,277,312,313],"edge-computing","monitoring","managed-kubernetes",{"path":315,"title":316,"description":317,"date":318,"tags":319},"\u002Fblog\u002Fja\u002Fopentelemetry-distributed-tracing","OpenTelemetry で分散トレーシングを実装する: 入門から実践まで","OpenTelemetry を使った分散トレーシングの実装方法を解説。Collector の構成、自動計装、Jaeger\u002FTempo との連携、Kubernetes 環境でのベストプラクティス。","2026-05-27",[279,320,275,296,277,321,322,323],"分散トレーシング","jaeger","tempo","マイクロサービス",{"path":325,"title":326,"description":327,"date":328,"tags":329},"\u002Fblog\u002Fja\u002Fk3s-container-image-security-supply-chain-checklist","「スキャン済み」は本番投入の許可証にならない。K3sコンテナイメージセキュリティ、署名からアドミッション制御まで","コンテナ セキュリティ ガイドラインというと『スキャンしてるから大丈夫』で止まりがちだ。K3s環境でベースイメージの最小化から脆弱性スキャン、SBOM生成、署名、アドミッション制御まで、本番投入前に通すべき工程を実務チェックリストとして具体的に解説する。","2026-08-24",[276,275,330,331,332,333],"container-security","image-scanning","sbom","supply-chain-security",1787649512412]