Grafanaで「No data」と表示されたら、まずCollectorが受信しているか→拒否・失敗がないか→PromQLの名前が実在するか→ダッシュボードが保存されているかの順で確認します。パネルが空でも、監視データの配管まで止まっているとは限りません。
先にGrafanaのパネル設定を長時間見直すより、データ経路の上流から確認すると原因を絞りやすくなります。
「No data」で最初に分ける4つの原因
| 原因 | 確認するもの | 判断の目安 |
|---|---|---|
| 送信元から届いていない | acceptedの増加 | 増えなければ送信元からCollectorまでを確認する |
| Collectorで拒否・失敗している | refused / failedの増加 | 増えるなら受信設定や送信形式を疑う |
| PromQLの名前が違う | Prometheusにある実メトリクス名 | 推測せず、現在存在する系列と照合する |
| 表示用のダッシュボードがない | 保存済みダッシュボードとUID | 必要なパネル集合が保存・配備されているかを見る |
手順1:Collectorの受信カウンタを見る
最初に、送信元からCollectorまでメトリクスが届いているかを確認します。たとえば、受信量はrate(otelcol_receiver_accepted_metric_points[5m])、拒否の有無はrate(otelcol_receiver_refused_metric_points[5m])で確認できます。
acceptedが増え、refusedやfailedが増えていなければ、「そもそも送っていない」「Collectorが受け取れずに捨てている」という候補は後退します。この段階で、表示の問題なのか配管の問題なのかを大きく分けられます。
手順2:拒否・失敗の系列を空表示と混同しない
失敗数や拒否数は、発生していないことが正常なoptional系列です。Prometheusでは値が0の系列が常に存在するとは限らず、素のクエリでは空結果となってStatパネルが「No data」を出す場合があります。
正常時は0として見せたいなら、sum(increase(otelcol_receiver_failed_metric_points[24h])) or vector(0)のように空を0へ倒します。複数系列を足す場合も、各項を先にor vector(0)で包みます。
手順3:PromQLのメトリクス名を実在する系列と照合する
配管が正常でも、存在しないメトリクス名をPromQLで参照すればGrafanaは空になります。特に_totalの有無を慣れた名前から補完すると、Collectorのバージョンや公開スキーマとの差で外れることがあります。
Prometheus側で現在のメトリクス名を列挙し、パネルのクエリと照合してください。アプリ由来の値が古い疑いは、time() - timestamp(<app_metric>)の形で鮮度を分けて確認します。
手順4:データソースではなくダッシュボードの有無も確認する
Prometheus APIで値が返り、Grafanaだけが空なら、データソース、時間範囲、保存済みダッシュボードを確認します。データソースが設定済みでも、見るためのパネル集合が保存されていなければ「No data」のままです。
重要なダッシュボードはコード化し、同じUIDに上書きできる形で配備すると、再構築と旧ブックマークへの対応をしやすくなります。
根拠・実測
自宅ラボでの確認では、Collectorはmetric points 40,020件、span 20件を受信し、failedとrefusedはいずれも0でした。Prometheusのターゲットは2系統ともupで、最終サンプルは約15秒前でした。それでもGrafanaの収集ヘルス表示は「No data」であり、直接原因は保存済みダッシュボードが0件だったことでした。
よくある質問
Grafanaの「No data」は障害ですか?
必ずしも障害ではありません。送信停止、Collectorでの拒否・失敗、クエリ名の不一致、ダッシュボード未保存などを順に分けて確認します。
failedが表示されず「No data」になるのは正常ですか?
失敗がないと系列自体が存在しない場合があります。正常時に0を見せたいパネルではor vector(0)を使います。
Prometheusには値があるのにGrafanaだけ空です。
Grafanaのデータソース、時間範囲、PromQL、保存済みダッシュボードを確認してください。上流のPrometheus APIで先に値を確認すると、表示層の問題へ絞り込めます。
関連する確認手順として、GrafanaがNo dataになる時のOTel確認手順、Prometheusの古い値を検知する鮮度ゲートの作り方、OpenTelemetry Collectorで「流れないtelemetry」を作って観測するも参考になります。
この検証を回している環境
この検証は、自宅の常設ラボ(使い捨てVM/LXCを回す母艦+GPU+VLAN分離ネットワーク)で動かしています。使っている機材と選定理由、全体構成は1本にまとめています。
ラボ構成のまとめを見る →