[{"data":1,"prerenderedAt":755},["ShallowReactive",2],{"blog-ja-kubernetes-servicemonitor-silent-metrics-failure":3,"blog-related-ja-kubernetes-servicemonitor-silent-metrics-failure":704,"blog-ja-kubernetes-servicemonitor-silent-metrics-failure-alt":693},{"id":4,"title":5,"author":6,"body":7,"date":687,"description":688,"extension":689,"image":690,"locale":691,"meta":692,"navigation":693,"path":694,"seo":695,"stem":696,"tags":697,"__hash__":703},"blog\u002Fblog\u002Fja\u002Fkubernetes-servicemonitor-silent-metrics-failure.md","Prometheusは動いている。なのにメトリクスが無い。ServiceMonitorが『静かに』失敗する3つの理由","Kubo Team",{"type":8,"value":9,"toc":672},"minimark",[10,15,19,35,44,51,55,72,81,104,115,119,149,155,159,166,181,184,187,368,378,384,388,391,412,433,440,443,496,508,514,518,521,575,578,592,599,605,608,617,625,629,632,652,659,668],[11,12,14],"h2",{"id":13},"prometheusは起動しているダッシュボードも開けるでもグラフが空白のままだ","Prometheusは起動している。ダッシュボードも開ける。でもグラフが空白のままだ",[16,17,18],"p",{},"Helmでkube-prometheus-stackを入れ、Grafanaのログインにも成功した。だがアプリケーションのカスタムメトリクスを表示しようとすると、パネルは空白のままになる。エラーログもない。アラートも鳴らない。ただ、データが存在しないだけだ。",[16,20,21,22,26,27,34],{},"これは Kubernetes の監視構築でよく起きる「サイレント障害」だ。",[23,24,25],"strong",{},"kubernetes service monitor"," の仕組みは、Podのアノテーションベースの発見よりも柔軟な設定を提供する反面、",[28,29,33],"a",{"href":30,"rel":31},"https:\u002F\u002Fprometheus-operator.dev\u002Fdocs\u002Fapi-reference\u002Fapi\u002F",[32],"nofollow","Prometheus Operator の公式ドキュメント","が示す通り、複数のレイヤーで条件が一致して初めて動く設計になっている。どこか1箇所でも噛み合わなければ、メトリクスは静かに消える。",[16,36,37,38,43],{},"監視というシステムの本質的な皮肉がここにある。アプリケーションの障害は監視が検知してくれる。しかし、監視自体が壊れていることは、監視では検知できない。この記事では、ServiceMonitorがメトリクスを取りこぼす3つの典型的な原因と、その切り分け手順を順番に見ていく。ちなみに、こうした監視スタックの初期設定自体を引き受けてくれる選択肢として",[28,39,42],{"href":40,"rel":41},"https:\u002F\u002Fkubo.hexabase.io\u002F",[32],"Kubo","のようなマネージドK3s環境もあるが、まずは仕組みそのものを理解しておこう。",[16,45,46],{},[47,48],"img",{"alt":49,"src":50},"監視ダッシュボードにメトリクスが表示されないブラックボックス状態を示す図","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-servicemonitor-silent-metrics-failure\u002Fsection01.webp",[11,52,54],{"id":53},"原因1-serviceservicemonitorprometheus-crの三重のラベル一致が崩れている","原因1: Service・ServiceMonitor・Prometheus CRの「三重のラベル一致」が崩れている",[16,56,57,58,62,63,67,68,71],{},"ServiceMonitorの",[59,60,61],"code",{},"selector","フィールドは、",[28,64,66],{"href":30,"rel":65},[32],"公式ドキュメント","によれば「ラベルセレクターを用いてメトリクスをスクレイプするKubernetes Podオブジェクトを選択する」ためのものだ。つまりServiceMonitor自体にラベルを書けばよいわけではなく、",[23,69,70],{},"監視対象のServiceが持つラベルと完全に一致していなければならない","。",[16,73,74,75,80],{},"さらに、",[28,76,79],{"href":77,"rel":78},"https:\u002F\u002Fgithub.com\u002Fprometheus-community\u002Fhelm-charts\u002Fblob\u002Fmain\u002Fcharts\u002Fkube-prometheus-stack\u002FREADME.md",[32],"kube-prometheus-stackのHelmチャート","を使っている場合、話はもう一段階複雑になる。デフォルトでは、Prometheus本体は「自分と同じnamespace内にあり、かつprometheus-operatorのreleaseラベルと同じラベルタグが付与されたServiceMonitor」だけを検出する仕様になっている。つまり:",[82,83,84,94],"ol",{},[85,86,57,87,90,91],"li",{},[59,88,89],{},"selector.matchLabels"," ↔ Serviceの",[59,92,93],{},"labels",[85,95,96,97,100,101,103],{},"Prometheus CRの",[59,98,99],{},"serviceMonitorSelector"," ↔ ServiceMonitorの",[59,102,93],{},"（release ラベル)",[16,105,106,107,110,111,114],{},"この2つのラベル一致が両方成立しなければ、ServiceMonitorは存在してもPrometheusから「見えない」ことになる。Helmチャート側では",[59,108,109],{},"serviceMonitorSelectorNilUsesHelmValues","を",[59,112,113],{},"false","に設定することで、release固有のラベルによる絞り込みを無効化し、namespace内の全ServiceMonitorを対象にすることも可能だが、これは意図せず無関係なServiceMonitorまで拾ってしまうリスクとのトレードオフになる。",[116,117,118],"h3",{"id":118},"チェックすべきポイント",[120,121,122,132,139],"ul",{},[85,123,57,124,127,128,131],{},[59,125,126],{},"spec.selector.matchLabels","とServiceの",[59,129,130],{},"metadata.labels","が完全一致しているか",[85,133,134,135,138],{},"kube-prometheus-stack環境では、ServiceMonitor自体に正しい",[59,136,137],{},"release: {リリース名}","ラベルが付いているか",[85,140,96,141,144,145,148],{},[59,142,143],{},"spec.serviceMonitorSelector","がどのラベルを要求しているか、",[59,146,147],{},"kubectl get prometheus -o yaml","で確認したか",[16,150,151],{},[47,152],{"alt":153,"src":154},"Service・ServiceMonitor・Prometheus CRの3層のラベル一致関係を示す図","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-servicemonitor-silent-metrics-failure\u002Fsection02.webp",[11,156,158],{"id":157},"原因2-namespaceselectorを設定しないと自分のnamespaceしか見えない","原因2: namespaceSelectorを設定しないと「自分のnamespaceしか見えない」",[16,160,161,162,165],{},"アプリケーションはproductionネームスペース、監視スタックはmonitoringネームスペースに分離しているのはよくある構成だ。しかしこの構成で",[59,163,164],{},"namespaceSelector","を設定し忘れると、メトリクスは永遠に収集されない。",[16,167,168,169,173,174,176,177,180],{},"公式ドキュメントの仕様は明確だ。",[28,170,172],{"href":30,"rel":171},[32],"ServiceMonitorのAPIリファレンス","によれば、",[59,175,164],{},"が空のラベルセレクターなら全namespaceのPodを検出するが、",[23,178,179],{},"nullラベルセレクター(未設定)の場合はServiceMonitorオブジェクトと同じnamespaceのPodのみが検出対象になる","。これがデフォルト挙動であり、明示的な設定なしにクロスnamespace監視は成立しない。",[16,182,183],{},"この仕様を知らないと、「ServiceMonitorをmonitoring namespaceに作ったのに、production namespaceのServiceが拾われない」という現象にそのままハマる。原因1のラベル一致がすべて正しくても、このnamespaceの壁を越えていなければ意味がない。",[116,185,186],{"id":186},"対処法",[188,189,194],"pre",{"className":190,"code":191,"language":192,"meta":193,"style":193},"language-yaml shiki shiki-themes tokyo-night","apiVersion: monitoring.coreos.com\u002Fv1\nkind: ServiceMonitor\nmetadata:\n  name: my-app-monitor\n  namespace: monitoring\n  labels:\n    release: kube-prometheus-stack\nspec:\n  namespaceSelector:\n    matchNames:\n      - production\n  selector:\n    matchLabels:\n      app: my-app\n  endpoints:\n    - port: metrics\n      interval: 30s\n","yaml","",[59,195,196,213,224,233,244,255,263,274,282,290,298,308,316,324,335,343,357],{"__ignoreMap":193},[197,198,201,205,209],"span",{"class":199,"line":200},"line",1,[197,202,204],{"class":203},"s0U2E","apiVersion",[197,206,208],{"class":207},"sAklC",":",[197,210,212],{"class":211},"sPY7s"," monitoring.coreos.com\u002Fv1\n",[197,214,216,219,221],{"class":199,"line":215},2,[197,217,218],{"class":203},"kind",[197,220,208],{"class":207},[197,222,223],{"class":211}," ServiceMonitor\n",[197,225,227,230],{"class":199,"line":226},3,[197,228,229],{"class":203},"metadata",[197,231,232],{"class":207},":\n",[197,234,236,239,241],{"class":199,"line":235},4,[197,237,238],{"class":203},"  name",[197,240,208],{"class":207},[197,242,243],{"class":211}," my-app-monitor\n",[197,245,247,250,252],{"class":199,"line":246},5,[197,248,249],{"class":203},"  namespace",[197,251,208],{"class":207},[197,253,254],{"class":211}," monitoring\n",[197,256,258,261],{"class":199,"line":257},6,[197,259,260],{"class":203},"  labels",[197,262,232],{"class":207},[197,264,266,269,271],{"class":199,"line":265},7,[197,267,268],{"class":203},"    release",[197,270,208],{"class":207},[197,272,273],{"class":211}," kube-prometheus-stack\n",[197,275,277,280],{"class":199,"line":276},8,[197,278,279],{"class":203},"spec",[197,281,232],{"class":207},[197,283,285,288],{"class":199,"line":284},9,[197,286,287],{"class":203},"  namespaceSelector",[197,289,232],{"class":207},[197,291,293,296],{"class":199,"line":292},10,[197,294,295],{"class":203},"    matchNames",[197,297,232],{"class":207},[197,299,301,305],{"class":199,"line":300},11,[197,302,304],{"class":303},"sgJMe","      -",[197,306,307],{"class":211}," production\n",[197,309,311,314],{"class":199,"line":310},12,[197,312,313],{"class":203},"  selector",[197,315,232],{"class":207},[197,317,319,322],{"class":199,"line":318},13,[197,320,321],{"class":203},"    matchLabels",[197,323,232],{"class":207},[197,325,327,330,332],{"class":199,"line":326},14,[197,328,329],{"class":203},"      app",[197,331,208],{"class":207},[197,333,334],{"class":211}," my-app\n",[197,336,338,341],{"class":199,"line":337},15,[197,339,340],{"class":203},"  endpoints",[197,342,232],{"class":207},[197,344,346,349,352,354],{"class":199,"line":345},16,[197,347,348],{"class":303},"    -",[197,350,351],{"class":203}," port",[197,353,208],{"class":207},[197,355,356],{"class":211}," metrics\n",[197,358,360,363,365],{"class":199,"line":359},17,[197,361,362],{"class":203},"      interval",[197,364,208],{"class":207},[197,366,367],{"class":211}," 30s\n",[16,369,370,373,374,377],{},[59,371,372],{},"matchNames","で対象namespaceを明示するか、複数namespaceを横断する場合は",[59,375,376],{},"any: true","で全namespace対象に切り替える。",[16,379,380],{},[47,381],{"alt":382,"src":383},"namespaceSelector未設定時と設定後のnamespace間可視範囲の違いを示す図","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-servicemonitor-silent-metrics-failure\u002Fsection03.webp",[11,385,387],{"id":386},"原因3-ラベルは正しいのにrbac権限がなくて見えているのに見えない","原因3: ラベルは正しいのに、RBAC権限がなくて「見えているのに見えない」",[16,389,390],{},"ここまでの2つはYAMLの記述ミスで気づきやすいが、3つ目は最も見落とされやすい。ラベルもnamespaceSelectorも完璧なのに、それでもメトリクスが取れないケースだ。",[16,392,393,394,399,400,403,404,407,408,411],{},"原因はPrometheusのServiceAccountに紐づくRBAC権限の不足にある。",[28,395,398],{"href":396,"rel":397},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fsecurity\u002Fservice-accounts\u002F",[32],"KubernetesのServiceAccount公式ドキュメント","が明記する通り、自動作成される",[59,401,402],{},"default"," ServiceAccountは「デフォルトAPI Discovery権限」以外にはほぼ権限を持たない。Prometheusが対象namespaceのService・Endpoints・Podを",[59,405,406],{},"list","\u002F",[59,409,410],{},"watch","できる権限を明示的に付与しなければ、スクレイピング対象として認識されることすらない。",[16,413,414,419,420,423,424,427,428,427,430,432],{},[28,415,418],{"href":416,"rel":417},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Freference\u002Faccess-authn-authz\u002Frbac\u002F",[32],"KubernetesのRBAC公式ドキュメント","によれば、権限はRoleで定義した",[59,421,422],{},"verbs","（",[59,425,426],{},"get",", ",[59,429,406],{},[59,431,410],{},"など）を、RoleBindingを通じてServiceAccountに紐づける形で付与する。RoleBindingはnamespaceスコープ、ClusterRoleBindingはクラスタ全体スコープという違いも重要だ。マルチnamespace監視をする場合、必要な数だけRoleBindingを増やすか、ClusterRoleとClusterRoleBindingで一括付与するかの設計判断が発生する。",[16,434,435,436,439],{},"この問題が厄介なのは、",[23,437,438],{},"エラーとして表面化しないこと","だ。権限不足でリソースが一覧できなくても、Prometheus自体はクラッシュしない。ただターゲットリストに現れないだけで、ログを注意深く見ない限り気づかない。",[116,441,442],{"id":442},"確認コマンド",[188,444,448],{"className":445,"code":446,"language":447,"meta":193,"style":193},"language-bash shiki shiki-themes tokyo-night","kubectl auth can-i list services --as=system:serviceaccount:monitoring:prometheus-kube-prometheus-prometheus -n production\nkubectl auth can-i list endpoints --as=system:serviceaccount:monitoring:prometheus-kube-prometheus-prometheus -n production\n","bash",[59,449,450,477],{"__ignoreMap":193},[197,451,452,456,459,462,465,468,472,475],{"class":199,"line":200},[197,453,455],{"class":454},"sE3pS","kubectl",[197,457,458],{"class":211}," auth",[197,460,461],{"class":211}," can-i",[197,463,464],{"class":211}," list",[197,466,467],{"class":211}," services",[197,469,471],{"class":470},"sT800"," --as=system:serviceaccount:monitoring:prometheus-kube-prometheus-prometheus",[197,473,474],{"class":470}," -n",[197,476,307],{"class":211},[197,478,479,481,483,485,487,490,492,494],{"class":199,"line":215},[197,480,455],{"class":454},[197,482,458],{"class":211},[197,484,461],{"class":211},[197,486,464],{"class":211},[197,488,489],{"class":211}," endpoints",[197,491,471],{"class":470},[197,493,474],{"class":470},[197,495,307],{"class":211},[16,497,498,501,502,507],{},[59,499,500],{},"no","が返ってきた場合は、対象namespaceに向けたRole\u002FRoleBindingの追加が必要になる。",[28,503,506],{"href":504,"rel":505},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fsecurity\u002Frbac-good-practices\u002F",[32],"Kubernetes公式のRBACベストプラクティス","にもある通り、最小権限の原則を守りながら、監視に必要な範囲だけを明示的に許可するのが正しい設計だ。",[16,509,510],{},[47,511],{"alt":512,"src":513},"ServiceAccountからRBAC権限チェックまでの診断フローを示す図","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-servicemonitor-silent-metrics-failure\u002Fsection04.webp",[11,515,517],{"id":516},"実際に切り分ける手順-targetsページからkubectlコマンドまでのc4ステップ","実際に切り分ける手順 — TargetsページからkubectlコマンドまでのC4ステップ",[16,519,520],{},"原因が3つあると分かっても、実際の障害でどこから手をつけるべきかは別の問題だ。以下の順序で切り分けると迷いがない。",[82,522,523,536,554,565],{},[85,524,525,423,528,531,532,535],{},[23,526,527],{},"Prometheus UIのTargetsページを開く",[59,529,530],{},"\u002Ftargets","）。対象のジョブが一覧に出ているかを確認する。出ていなければ原因1か2、出ているのに",[59,533,534],{},"DOWN","状態ならエンドポイント自体の問題を疑う",[85,537,538,541,542,545,546,549,550,553],{},[23,539,540],{},"ServiceMonitorのselectorを確認","する。",[59,543,544],{},"kubectl get servicemonitor \u003Cname> -o yaml","で",[59,547,548],{},"spec.selector","と",[59,551,552],{},"spec.namespaceSelector","を出力し、対象のServiceのラベルと突き合わせる",[85,555,556,541,559,545,562,564],{},[23,557,558],{},"Prometheus CRのselectorを確認",[59,560,561],{},"kubectl get prometheus -n monitoring -o yaml",[59,563,143],{},"を確認し、ServiceMonitor自体のラベルと一致しているか見る",[85,566,567,574],{},[23,568,569,570,573],{},"RBAC権限を",[59,571,572],{},"kubectl auth can-i","で確認","する。ここまで一致していてもTargetsに出ない場合は、ほぼ確実にRBACが原因になる",[16,576,577],{},"このステップを踏めば、原因1・2・3のどこで詰まっているかが機械的に切り分けられる。逆に言えば、この4ステップを最初から手順化しておかない限り、毎回同じ原因を場当たり的に探し直すことになる。",[16,579,580,585,586,591],{},[28,581,584],{"href":582,"rel":583},"https:\u002F\u002Fwww.cncf.io\u002Fannouncements\u002F2018\u002F08\u002F09\u002Fprometheus-graduates\u002F",[32],"Prometheus はCNCFの2番目の卒業プロジェクト","として、Kubernetesエコシステムのデファクトスタンダードになっているからこそ、この設定の複雑さは多くのチームが一度は通る道でもある。",[28,587,590],{"href":588,"rel":589},"https:\u002F\u002Fwww.cncf.io\u002Fblog\u002F2022\u002F08\u002F01\u002Fkubernetes-monitoring-leveraging-4-open-source-toolsets\u002F",[32],"CNCFのKubernetes監視解説","でも、複数のOSSツールセットを組み合わせる際の設定整合性の重要性が指摘されている。",[16,593,594,595,598],{},"序盤の切り分けを毎回自前でやるのが負担なら、",[28,596,42],{"href":40,"rel":597},[32],"はPrometheus + Grafanaを標準搭載しており、ServiceMonitorのラベル整合やRBAC設定を含めて事前に動作確認済みの構成で提供される。K3sベースの軽量な構成の上に、監視スタックの初期設定をゼロから組む工程そのものを引き受ける形だ。",[16,600,601],{},[47,602],{"alt":603,"src":604},"Targets確認からRBAC確認までの4ステップ診断プロセスを示す図","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-servicemonitor-silent-metrics-failure\u002Fsection05.webp",[11,606,607],{"id":607},"モニタリングとオブザーバビリティの違いを踏まえた設計を",[16,609,610,611,616],{},"そもそも",[28,612,615],{"href":613,"rel":614},"https:\u002F\u002Fwww.infoq.com\u002Fjp\u002Fnews\u002F2018\u002F01\u002Fobservability-monitoring",[32],"監視とオブザーバビリティの違い","を踏まえると、監視は「明確に定義された障害」の検出に特化したものであり、オブザーバビリティはログ・メトリクス・トレースを含むより広い可観測性の実現を指す。ServiceMonitorの設定ミスは、この監視という土台そのものが機能していない状態であり、その上に積むはずのオブザーバビリティ全体が崩れることを意味する。",[16,618,619,624],{},[28,620,623],{"href":621,"rel":622},"https:\u002F\u002Fdocs.aws.amazon.com\u002Fja_jp\u002Fwellarchitected\u002Flatest\u002Foperational-excellence-pillar\u002Fimplement-observability.html",[32],"AWSのオペレーショナルエクセレンスに関するドキュメント","でも、オブザーバビリティの実装は運用の柱の一つとして位置づけられている。監視基盤の設定不備は、単なる技術的なミスではなく、運用全体の信頼性に関わる問題だ。",[11,626,628],{"id":627},"まとめ-3つの原因を順に潰せば監視の静かな失敗は防げる","まとめ — 3つの原因を順に潰せば、監視の「静かな失敗」は防げる",[16,630,631],{},"Prometheus + ServiceMonitorでメトリクスが取れない場合、原因はほぼ以下の3点に集約される。",[120,633,634,640,646],{},[85,635,636,639],{},[23,637,638],{},"ラベルセレクタの不一致",": Service ↔ ServiceMonitor ↔ Prometheus CRの三重整合が崩れていないか",[85,641,642,645],{},[23,643,644],{},"namespaceSelectorの設定漏れ",": デフォルトでは自namespaceしか見えない仕様を理解しているか",[85,647,648,651],{},[23,649,650],{},"RBAC権限の不足",": ServiceAccountがlist\u002Fwatchできる権限を明示的に持っているか",[16,653,654,655,658],{},"これらはいずれも公式ドキュメントに仕様として明記されているが、複数のCRDとRBACをまたぐ設定であるがゆえに、実際の障害では見落とされやすい。毎回この3点を手動でチェックする運用から抜け出したいなら、",[28,656,42],{"href":40,"rel":657},[32],"のようにPrometheus + Grafanaが標準搭載され、初期設定済みの状態で始められるマネージドK3s環境を検討する価値がある。EKSやAKSでゼロから監視スタックを組む場合と比べても、コスト効率よく本格的なKubernetes運用を実現できる。",[16,660,661,662,667],{},"監視基盤の構築・運用でこうした落とし穴に頭を悩ませているなら、",[28,663,666],{"href":664,"rel":665},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[32],"お問い合わせ","から相談してみてほしい。",[669,670,671],"style",{},"html pre.shiki code .s0U2E, html code.shiki .s0U2E{--shiki-default:#F7768E}html pre.shiki code .sAklC, html code.shiki .sAklC{--shiki-default:#89DDFF}html pre.shiki code .sPY7s, html code.shiki .sPY7s{--shiki-default:#9ECE6A}html pre.shiki code .sgJMe, html code.shiki .sgJMe{--shiki-default:#9ABDF5}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html pre.shiki code .sE3pS, html code.shiki .sE3pS{--shiki-default:#C0CAF5}html pre.shiki code .sT800, html code.shiki .sT800{--shiki-default:#E0AF68}",{"title":193,"searchDepth":215,"depth":215,"links":673},[674,675,678,681,684,685,686],{"id":13,"depth":215,"text":14},{"id":53,"depth":215,"text":54,"children":676},[677],{"id":118,"depth":226,"text":118},{"id":157,"depth":215,"text":158,"children":679},[680],{"id":186,"depth":226,"text":186},{"id":386,"depth":215,"text":387,"children":682},[683],{"id":442,"depth":226,"text":442},{"id":516,"depth":215,"text":517},{"id":607,"depth":215,"text":607},{"id":627,"depth":215,"text":628},"2026-08-14","Kubernetesのkubernetes service monitorが原因不明にスクレイプされない——ラベル不一致・namespaceSelector・RBACという3つの落とし穴を、公式ドキュメントを元に切り分け手順つきで解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-servicemonitor-silent-metrics-failure\u002Feyecatch.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fkubernetes-servicemonitor-silent-metrics-failure",{"title":5,"description":688},"blog\u002Fja\u002Fkubernetes-servicemonitor-silent-metrics-failure",[698,699,700,701,702],"k3s","kubernetes","prometheus","observability","servicemonitor","_W9u-v6mZHkEW4j_1LhfmbB-dCtABnMaisERDx9Ro9Q",[705,713,721,728,737,747],{"path":706,"title":707,"description":708,"date":709,"tags":710},"\u002Fblog\u002Fja\u002Fk3s-opentelemetry-observability-correlation","3つのダッシュボードを往復する障害対応はもう終わり。K3sの可観測性をOpenTelemetryで『相関』させる設計","PrometheusとLokiとJaegerを個別に確認して原因究明に時間を溶かしていないか。K3sクラスタの可観測性をOpenTelemetryで相関させ、障害調査時間を短縮する設計とOpenTelemetry Collectorの導入パターンを、K3s\u002FKubernetes運用の現場目線で解説する。","2026-08-20",[698,699,711,701,712],"opentelemetry","distributed-tracing",{"path":714,"title":715,"description":716,"date":717,"tags":718},"\u002Fblog\u002Fja\u002Fkubernetes-ebpf-inspektor-gadget-observability","strace禁止、sidecar禁止、それでも診断できる。KubernetesをeBPFで透視するInspektor Gadgetという回答","特権コンテナもsidecarも追加できない本番Kubernetesで、Podの通信とシステムコールをどう診断するか。eBPFツール「Inspektor Gadget」の仕組みと2026年の最新動向を解説する。","2026-08-15",[698,699,719,701,720],"ebpf","cncf",{"path":722,"title":723,"description":724,"date":725,"tags":726},"\u002Fblog\u002Fja\u002Fkubernetes-aiops-incident-response-distributed-tracing","AIに『直して』と頼んでも直らない。Kubernetes本番障害調査は分散トレーシングから始まる","Kubernetes本番環境の障害対応をAIに任せても、分散システムの因果関係が見えなければ的外れな対処になる。AIOpsを機能させる分散トレーシング設計とOpenTelemetry導入の実践ステップを解説する。","2026-07-27",[699,698,701,712,711,727],"aiops",{"path":729,"title":730,"description":731,"date":732,"tags":733},"\u002Fblog\u002Fja\u002Fedge-k3s-observability-homelab-dashboard","壁に貼っただけで「安心」に変わる。ホームラボの壁掛けダッシュボードが教えてくれた、エッジK3sクラスタの観測性設計","自宅の壁掛けダッシュボード作りで起きた総当たりのトラブルシューティングは、工場や店舗に分散したエッジKubernetesクラスタの運用でも同じ罠になる。K3s・Prometheus・Grafanaの公式ドキュメントを引きながら、観測性を後回しにしないための設計原則を解説する。","2026-07-26",[698,699,734,701,735,736],"edge-computing","monitoring","managed-kubernetes",{"path":738,"title":739,"description":740,"date":741,"tags":742},"\u002Fblog\u002Fja\u002Fgrafana-dashboard-kubernetes-observability","Grafana ダッシュボード設計: Kubernetes オブザーバビリティ実践","Grafana で Kubernetes のオブザーバビリティを実現するダッシュボード設計手法。RED メソッド、Four Golden Signals、パネル構成のベストプラクティスを解説。","2026-05-27",[743,699,701,744,720,700,745,746],"grafana","ダッシュボード","監視","可視化",{"path":748,"title":749,"description":750,"date":741,"tags":751},"\u002Fblog\u002Fja\u002Fprometheus-monitoring-kubernetes-guide","Prometheus で Kubernetes を監視する完全ガイド","Prometheus を使った Kubernetes 監視の導入から運用まで。PromQL、Alertmanager、サービスディスカバリなど本番環境で必要な設定を体系的に解説します。",[700,699,745,752,720,701,753,754],"モニタリング","promql","alertmanager",1787649513377]