サービスチェック
サービスチェック (Service Check) とは、Datadog Agent のチェックが監視対象の稼働状態を OK / WARNING / CRITICAL / UNKNOWN の 4 つの状態で報告する仕組みのこと。値の推移を見るメトリクスとは別の系統で、サービスが応答しているかどうかを表す。
概要
サービスチェックは、Datadog Agent のインテグレーションやカスタムチェックが監視対象の状態を報告するデータの種類です。数値ではなく OK (0) / WARNING (1) / CRITICAL (2) / UNKNOWN (3) の 4 状態を実行のたびに送り、Check Summary の画面、ダッシュボードの Check status ウィジェット、サービスチェックモニターで使います。メトリクスのように時系列グラフには描けませんが、指定した回数だけ連続して CRITICAL になったら鳴らす、クラスターの何 % が落ちたら鳴らす、という判定に向きます。気にするのは、メトリクスもログも無いのに OK / CRITICAL という結果だけが並ぶ画面を見たときと、稼働監視の鳴らし方を決めるときです。
値ではなく状態を運ぶデータ
サービスチェック (Service Check) は、Datadog Agent のチェックが監視対象の稼働状態を報告するデータの種類です。公式ドキュメントは、サービスチェックはサービスの状態を特徴付けて Datadog で監視できるようにするもの、と説明しています。サービスの up / down を見張り、Agent が指定回数連続でそのサービスに接続できないとアラートされる、というのが公式の説明です (2026 年 9 月時点・出典: Service Check)。メトリクス が「CPU 使用率 73%」のような値を運ぶのに対し、サービスチェックは「この DB に接続できたか」を 4 つの状態で運びます。状態はチェック実行のたびに 1 件送られ、時系列の値としては積み上がりません。この違いが、後述する「グラフには描けないがモニターにはできる」という性質につながります。
4 つの状態と数字の対応
カスタム Agent チェックからは self.service_check(name, status, tags, hostname, message) で送り、status は 0 から 3 の整数です。message には状態の理由を添えられます (2026 年 9 月時点・出典: Service Check Submission: Agent Check)。
| 状態 | status の値 | サービスチェックモニターでの扱い |
|---|---|---|
| OK | 0 | 連続 N 回の OK でアラートを回復する |
| WARNING | 1 | クラスタアラートの警告しきい値の対象になる |
| CRITICAL | 2 | 連続 N 回の CRITICAL でアラートになる |
| UNKNOWN | 3 | 通知するかしないかを選べる。通知時は状態バーが No Data と同じ灰色になり、モニター全体は OK のまま |
送る手段はカスタム Agent チェックのほかに DogStatsD と API があり、送信手段そのものは DogStatsD の項に委ねます。多くのインテグレーションは自前のサービスチェックを持つので、自分で書くのはインテグレーションに無いときと、社内サービスの稼働を見たいときです。
グラフには描けない、でもモニターにはできる
サービスチェックが現れる場所は 3 つです。Check Summary の画面には過去 1 日にインフラ全体から報告された全チェックが並び、選ぶと状態とタグが見えます。ダッシュボードでは Check status ウィジェットに、集計する期間と、1 つのチェックかタグでまとめたクラスターかの範囲を指定して置けます。3 つ目がサービスチェックモニターです。公式は、メトリクスのように時間軸のグラフには描けないが、モニターにはできる、と明記しています (2026 年 9 月時点・出典: Service Check)。「状態の履歴を折れ線で見たい」という要望にはサービスチェックは向かず、応答時間のようなメトリクスを併せて集める設計になります。インテグレーション の多くはメトリクスとサービスチェックの両方を出すので、値の推移と稼働の可否を組み合わせて読みます。
連続 N 回で鳴らす - チェックアラートとクラスタアラート
モニターの条件は 2 種類です。チェックアラートは、チェックのグループごとに連続した状態を追い、しきい値と比べます。
- チェックを報告するグループごとに別のアラートを立てる (サービスチェックモニターではグループを自分で指定する)
- CRITICAL が連続 N 回続いたらアラートにする (1 にすれば最初の失敗で鳴る)
- UNKNOWN を通知するか、しないかを選ぶ
- OK が連続 N 回続いたら回復させる (例: 4 回で直ったと見なす)
クラスタアラートは、タグの組み合わせごとを 1 つのチェックと数え、その最後の状態だけを使って、特定の状態にあるチェックの割合をしきい値と比べます (2026 年 9 月時点・出典: Service Check Monitor)。公式の例は、環境ごとにグループ化し、いずれかの環境で 70% を超えるチェックが CRITICAL ならアラート、70% を超えて WARN なら警告、というものです。1 台に複数のサービスが載り一部の障害には耐える構成では、クラスタアラートの方がホストの生死よりも早くサービスの劣化を捉えられる、というのが公式の勧めです。
UNKNOWN と No Data を混同しない
読み違えやすいのは UNKNOWN と No Data の関係です。UNKNOWN はチェックが実行され「判定できない」と報告した状態で、モニターでは通知するかしないかを選べます。通知を選ぶと UNKNOWN への遷移で通知が飛び、状態バーには No Data と同じ灰色が使われますが、モニター全体の状態は OK のままです (2026 年 9 月時点・出典: Service Check Monitor)。一方の No Data は、チェックの結果そのものが届かなかったときにモニターが取る状態で、Agent が止まった、ホストが消えたという沈黙を表します。同じ灰色でも「判定不能と報告された」のと「報告が来ない」のとでは、原因の探し方が違います。サービスチェックを意識するのは、モニター の種類を選ぶときに「稼働しているか」だけを見たい場面と、インテグレーションの画面に並ぶ OK / CRITICAL が何かを知りたいときです。数値ではなく状態、という意味を先に覚えておくと迷いません。