[{"data":1,"prerenderedAt":298},["ShallowReactive",2],{"blog-ja-k3s-opentelemetry-observability-correlation":3,"blog-related-ja-k3s-opentelemetry-observability-correlation":245,"blog-ja-k3s-opentelemetry-observability-correlation-alt":234},{"id":4,"title":5,"author":6,"body":7,"date":228,"description":229,"extension":230,"image":231,"locale":232,"meta":233,"navigation":234,"path":235,"seo":236,"stem":237,"tags":238,"__hash__":244},"blog\u002Fblog\u002Fja\u002Fk3s-opentelemetry-observability-correlation.md","3つのダッシュボードを往復する障害対応はもう終わり。K3sの可観測性をOpenTelemetryで『相関』させる設計","Kubo Team",{"type":8,"value":9,"toc":213},"minimark",[10,15,19,30,38,41,44,57,66,73,77,92,99,103,112,120,129,134,138,146,151,154,158,161,165,168,171,176,180,186,193,198,201,204],[11,12,14],"h2",{"id":13},"深夜のアラート3つの画面を往復する30分","深夜のアラート、3つの画面を往復する30分",[16,17,18],"p",{},"深夜、K3sクラスタでレイテンシ悪化のアラートが鳴る。まずPrometheusでどのサービスのP99レイテンシが跳ねているかを確認し、次にLokiで該当時間帯のエラーログを検索し、最後にJaegerでどのリクエストが遅かったかを突き合わせる。",[16,20,21,22,29],{},"この「3つのダッシュボードを往復する」作業は、多くのチームにとって当たり前の光景になっている。Grafana Labsが2025年に実施した調査では、企業は平均8種類の可観測性ツールを併用し、合計101種類もの異なる可観測性技術が挙げられたという（",[23,24,28],"a",{"href":25,"rel":26},"https:\u002F\u002Fgrafana.com\u002Fobservability-survey\u002F2025\u002F",[27],"nofollow","Grafana Observability Survey 2025","）。ツールが増えるほど、障害調査は「推測とタイムスタンプの突き合わせ」に頼るしかなくなる。",[16,31,32,33,37],{},"本記事では、この「サイロ化した可観測性」がなぜ生まれるのか、そしてメトリクス・ログ・トレースを",[34,35,36],"strong",{},"相関","（＝バラバラの手がかりを1つの原因につなぎ合わせること）させる設計にどう移行すべきかを解説する。",[11,39,40],{"id":40},"ツールを増やすほど障害対応が遅くなるという逆説",[16,42,43],{},"可観測性の「三本柱」と呼ばれるメトリクス・ログ・トレースは、それぞれ別のツールで扱われることが多い。Prometheusでメトリクスを、Lokiでログを、Jaegerでトレースを、という構成は一見合理的だが、別々のデータストアに保存され共通の識別子で紐付いていない場合、障害対応の現場では致命的な非効率が生まれる。",[16,45,46,47,52,53,56],{},"Network Worldが報じた調査によれば、企業は依然として平均4.4個の可観測性ツールを運用しており、ネットワーク運用チームの87%が「意味のある統合のないまま複数ツールに依存している」と回答している（",[23,48,51],{"href":49,"rel":50},"https:\u002F\u002Fwww.networkworld.com\u002Farticle\u002F4067370\u002Ftool-sprawl-hampers-enterprise-observability-efforts.html",[27],"Network World","）。影響度の高い障害1件あたりのコストは中央値で1時間200万ドルにのぼるが、フルスタックの可観測性を実現した組織では半減するという。ツールの数ではなく、",[34,54,55],{},"シグナル間の相関","が取れているかが障害対応コストを左右する。",[16,58,59,60,65],{},"Grafanaの調査でも、アラート疲れが「ほぼ全ての職位で障害対応を遅らせる最大の要因」として挙げられ、複雑性そのものが39%の回答者にとって最大の障壁になっている。ツールを個別最適で増やした結果、全体では障害対応が遅くなるという逆説がここにある。",[23,61,64],{"href":62,"rel":63},"https:\u002F\u002Fkubo.hexabase.io\u002F",[27],"Kubo","のようなマネージドK3sサービスには、可観測性スタックを最初から統合設計で提供するものもある。",[16,67,68],{},[69,70],"img",{"alt":71,"src":72},"","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fk3s-opentelemetry-observability-correlation\u002Fsection01.webp",[11,74,76],{"id":75},"opentelemetryがkubernetesに次ぐ規模のプロジェクトに成長した理由","OpenTelemetryがKubernetesに次ぐ規模のプロジェクトに成長した理由",[16,78,79,80,85,86,91],{},"この「サイロ化した可観測性」への回答として急速に普及しているのがOpenTelemetry(OTel)だ。CNCFは2026年5月、OpenTelemetryを最上位ステータスである「Graduated（卒業)」プロジェクトに認定したと発表した（",[23,81,84],{"href":82,"rel":83},"https:\u002F\u002Fwww.cncf.io\u002Fannouncements\u002F2026\u002F05\u002F21\u002Fcloud-native-computing-foundation-announces-opentelemetrys-graduation-solidifying-status-as-the-de-facto-observability-standard\u002F",[27],"CNCF公式発表","）。プロジェクトページによれば参加企業は5,136社、総貢献者数は26,846名にのぼり（",[23,87,90],{"href":88,"rel":89},"https:\u002F\u002Fwww.cncf.io\u002Fprojects\u002Fopentelemetry\u002F",[27],"CNCF Projects: OpenTelemetry","）、CNCF傘下240以上のプロジェクトの中でもKubernetesに次ぐ第2位のプロジェクト速度という分析もある。",[16,93,94,95,98],{},"この成長の背景には、単なる人気ではなく設計思想の転換がある。OpenTelemetryは「メトリクス・ログ・トレースを別々のツールで個別に集める」のではなく、",[34,96,97],{},"単一の計装標準","でこれら3つのシグナルを収集し、共通のコンテキスト（トレースID等）で紐付ける前提で設計されている。ベンダー固有の計装ライブラリに縛られず、バックエンドを乗り換えても計装コードを書き直す必要がなく、ベンダーロックインを避けたいインフラチームの導入動機になっている。",[11,100,102],{"id":101},"メトリクスとトレースをクリック1つでつなぐexemplarsという仕組み","メトリクスとトレースを「クリック1つ」でつなぐExemplarsという仕組み",[16,104,105,106,111],{},"この相関を技術的に支えるのが「Exemplars」という仕組みだ。メトリクスのサンプルにトレース情報（trace_id・span_id・timestamp）を直接紐付けるデータ構造で、アクティブなスパンのコンテキスト内で記録されたメトリクスに自動でトレース識別情報が付与される（",[23,107,110],{"href":108,"rel":109},"https:\u002F\u002Fopentelemetry.io\u002Fdocs\u002Flanguages\u002Fdotnet\u002Fmetrics\u002Fexemplars\u002F",[27],"OpenTelemetry公式ドキュメント: Exemplars","）。",[16,113,114,115,111],{},"Exemplarsがない状態でレイテンシスパイクを検知しても「何かが遅い」ことしか分からず、ログを手動で検索し30分以上かかることも珍しくない。Exemplarsを使えば、グラフ上の異常値をクリックするだけで実際のトレースへ直接ジャンプできる。ある実装ガイドでは、根本原因の特定が2分程度まで短縮された事例が紹介されている（",[23,116,119],{"href":117,"rel":118},"https:\u002F\u002Foneuptime.com\u002Fblog\u002Fpost\u002F2026-01-30-metric-trace-correlation\u002Fview",[27],"metric-trace correlationの実装ガイド",[16,121,122,123,128],{},"Google CloudのManaged Service for Prometheusでも「Trace Exemplars」として提供され、テール・レイテンシから直接トレースへ遷移できる（",[23,124,127],{"href":125,"rel":126},"https:\u002F\u002Fcloud.google.com\u002Fblog\u002Fproducts\u002Fdevops-sre\u002Ftrace-exemplars-now-available-in-managed-service-for-prometheus",[27],"Google Cloud Blog","）。K3s上の自前Prometheusでも、OpenTelemetry Collector経由で同様の相関機能を組み込める。",[16,130,131],{},[69,132],{"alt":71,"src":133},"https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fk3s-opentelemetry-observability-correlation\u002Fsection02.webp",[11,135,137],{"id":136},"k3sクラスタにopentelemetry-collectorを組み込む3つの配置パターン","K3sクラスタにOpenTelemetry Collectorを組み込む3つの配置パターン",[16,139,140,141,111],{},"K3s\u002FKubernetesクラスタへの導入では、OpenTelemetry Collectorをどこに配置するかが設計の肝になる。代表的なパターンは以下の3つに整理される（",[23,142,145],{"href":143,"rel":144},"https:\u002F\u002Fwww.groundcover.com\u002Flearn\u002Fkubernetes\u002Fopentelemetry-collector-kubernetes",[27],"OpenTelemetry CollectorのKubernetesアーキテクチャ解説",[147,148,150],"h3",{"id":149},"agentパターンdaemonset","Agentパターン（DaemonSet）",[16,152,153],{},"各ノードに1つずつCollectorを配置し、ノードローカルのメトリクス・ログ・kubeletの統計情報を収集する。ノード固有のファイルシステムアクセスが必要な収集に向く。",[147,155,157],{"id":156},"gatewayパターンdeployment","Gatewayパターン（Deployment）",[16,159,160],{},"安定したテレメトリ受信エンドポイントを提供する中央集約型パターン。複数のAgentから送られたデータを一箇所に集め、バックエンドへの振り分けやサンプリングを一元管理できる。",[147,162,164],{"id":163},"sidecarパターン","Sidecarパターン",[16,166,167],{},"アプリケーションPodに専用のCollectorコンテナを同居させる方式。個別設定ができる反面、Pod数に比例してリソース消費も増える。",[16,169,170],{},"多くの本番環境では、ノードレベルの収集をAgentで行い中央のGatewayに集約する「Agent-to-Gateway」の2段構成が推奨される。K3sでもこの構成なら、既存のPrometheus Operator\u002FServiceMonitor構成を壊さず段階的にOTelを導入できる。",[16,172,173],{},[69,174],{"alt":71,"src":175},"https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fk3s-opentelemetry-observability-correlation\u002Fsection03.webp",[11,177,179],{"id":178},"サイロ化した可観測性から相関する可観測性へ","サイロ化した可観測性から、相関する可観測性へ",[16,181,182,183,185],{},"可観測性の課題は「ツールを増やすこと」では解決しない。むしろツールが増えるほどダッシュボード間を往復するコストが膨らむ。重要なのは、メトリクス・ログ・トレースという3つのシグナルを共通のコンテキストで",[34,184,36],{},"させる設計だ。ある求人市場の分析でも、企業が求めているのは個別ツールの操作知識ではなく「システム思考」だと指摘されている。可観測性基盤の設計もこの視点が問われる。",[16,187,188,189,192],{},"K3sでゼロから可観測性スタックを構築する場合、Prometheus・Grafana・Loki・Tempo(またはJaeger)・OpenTelemetry Collectorを個別にセットアップし、連携設定まで自前で行う必要がある。",[23,190,64],{"href":62,"rel":191},[27],"のようなマネージドK3sサービスなら、Prometheus + Grafanaが標準搭載された状態からスタートでき、OpenTelemetry Collectorを追加するだけで相関分析基盤を構築できる。",[16,194,195],{},[69,196],{"alt":71,"src":197},"https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fk3s-opentelemetry-observability-correlation\u002Fsection04.webp",[11,199,200],{"id":200},"まとめ",[16,202,203],{},"メトリクス・ログ・トレースを別々のツールで個別に眺めている限り、障害の「本当の原因」には辿り着けない。OpenTelemetryがCNCFで2番目の規模まで成長した背景には、ベンダー中立の標準化と、Exemplarsに代表される「相関させる」設計思想がある。重要なのは闇雲にツールを追加することではなく、既存のPrometheus\u002FServiceMonitor構成を活かしOpenTelemetry Collectorを段階的に組み込み、メトリクスからトレースへワンクリックで遷移できる基盤を作ることだ。",[16,205,206,207,212],{},"可観測性スタックの再設計を検討しているなら、Prometheus + Grafanaが標準搭載されたKuboから始めるのも一つの選択肢だ。OpenTelemetry Collectorを追加するだけでサイロ化しない可観測性基盤を構築できる。相談は",[23,208,211],{"href":209,"rel":210},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[27],"お問い合わせ","からいつでも可能だ。",{"title":71,"searchDepth":214,"depth":214,"links":215},2,[216,217,218,219,220,226,227],{"id":13,"depth":214,"text":14},{"id":40,"depth":214,"text":40},{"id":75,"depth":214,"text":76},{"id":101,"depth":214,"text":102},{"id":136,"depth":214,"text":137,"children":221},[222,224,225],{"id":149,"depth":223,"text":150},3,{"id":156,"depth":223,"text":157},{"id":163,"depth":223,"text":164},{"id":178,"depth":214,"text":179},{"id":200,"depth":214,"text":200},"2026-08-20","PrometheusとLokiとJaegerを個別に確認して原因究明に時間を溶かしていないか。K3sクラスタの可観測性をOpenTelemetryで相関させ、障害調査時間を短縮する設計とOpenTelemetry Collectorの導入パターンを、K3s\u002FKubernetes運用の現場目線で解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fk3s-opentelemetry-observability-correlation\u002Feyecatch.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fk3s-opentelemetry-observability-correlation",{"title":5,"description":229},"blog\u002Fja\u002Fk3s-opentelemetry-observability-correlation",[239,240,241,242,243],"k3s","kubernetes","opentelemetry","observability","distributed-tracing","CpBzP9SzKmYyLuBMhHPnAOlvFIIz7BDg9wlqQ70-ebE",[246,253,261,269,278,288],{"path":247,"title":248,"description":249,"date":250,"tags":251},"\u002Fblog\u002Fja\u002Fkubernetes-aiops-incident-response-distributed-tracing","AIに『直して』と頼んでも直らない。Kubernetes本番障害調査は分散トレーシングから始まる","Kubernetes本番環境の障害対応をAIに任せても、分散システムの因果関係が見えなければ的外れな対処になる。AIOpsを機能させる分散トレーシング設計とOpenTelemetry導入の実践ステップを解説する。","2026-07-27",[240,239,242,243,241,252],"aiops",{"path":254,"title":255,"description":256,"date":257,"tags":258},"\u002Fblog\u002Fja\u002Fkubernetes-ebpf-inspektor-gadget-observability","strace禁止、sidecar禁止、それでも診断できる。KubernetesをeBPFで透視するInspektor Gadgetという回答","特権コンテナもsidecarも追加できない本番Kubernetesで、Podの通信とシステムコールをどう診断するか。eBPFツール「Inspektor Gadget」の仕組みと2026年の最新動向を解説する。","2026-08-15",[239,240,259,242,260],"ebpf","cncf",{"path":262,"title":263,"description":264,"date":265,"tags":266},"\u002Fblog\u002Fja\u002Fkubernetes-servicemonitor-silent-metrics-failure","Prometheusは動いている。なのにメトリクスが無い。ServiceMonitorが『静かに』失敗する3つの理由","Kubernetesのkubernetes service monitorが原因不明にスクレイプされない——ラベル不一致・namespaceSelector・RBACという3つの落とし穴を、公式ドキュメントを元に切り分け手順つきで解説する。","2026-08-14",[239,240,267,242,268],"prometheus","servicemonitor",{"path":270,"title":271,"description":272,"date":273,"tags":274},"\u002Fblog\u002Fja\u002Fedge-k3s-observability-homelab-dashboard","壁に貼っただけで「安心」に変わる。ホームラボの壁掛けダッシュボードが教えてくれた、エッジK3sクラスタの観測性設計","自宅の壁掛けダッシュボード作りで起きた総当たりのトラブルシューティングは、工場や店舗に分散したエッジKubernetesクラスタの運用でも同じ罠になる。K3s・Prometheus・Grafanaの公式ドキュメントを引きながら、観測性を後回しにしないための設計原則を解説する。","2026-07-26",[239,240,275,242,276,277],"edge-computing","monitoring","managed-kubernetes",{"path":279,"title":280,"description":281,"date":282,"tags":283},"\u002Fblog\u002Fja\u002Fopentelemetry-distributed-tracing","OpenTelemetry で分散トレーシングを実装する: 入門から実践まで","OpenTelemetry を使った分散トレーシングの実装方法を解説。Collector の構成、自動計装、Jaeger\u002FTempo との連携、Kubernetes 環境でのベストプラクティス。","2026-05-27",[241,284,240,260,242,285,286,287],"分散トレーシング","jaeger","tempo","マイクロサービス",{"path":289,"title":290,"description":291,"date":292,"tags":293},"\u002Fblog\u002Fja\u002Fk3s-container-image-security-supply-chain-checklist","「スキャン済み」は本番投入の許可証にならない。K3sコンテナイメージセキュリティ、署名からアドミッション制御まで","コンテナ セキュリティ ガイドラインというと『スキャンしてるから大丈夫』で止まりがちだ。K3s環境でベースイメージの最小化から脆弱性スキャン、SBOM生成、署名、アドミッション制御まで、本番投入前に通すべき工程を実務チェックリストとして具体的に解説する。","2026-08-24",[239,240,294,295,296,297],"container-security","image-scanning","sbom","supply-chain-security",1787649512181]