エンドポイント監視

「エンドポイント」とは？

エンドポイントとは、インターネット上でアドレス指定でき、利用可能性を検証するために問い合わせができるすべてのものを指します。典型的な例はウェブページのURLですが、現代のインフラストラクチャでは、管理すべき対象はさらに多様化しています：REST API、GraphQLエンドポイント、メールサーバー、データベースリスナー、メッセージキュー、コンテナのヘルスチェックポート、内部管理パネル、Webhookの受信先など。DiagnoSEO Uptime Monitoringは、これらを統一的に扱います。各エンドポイントにとって「正常」とは何かを定義し、チェックのスケジュールを設定し、障害発生時にはアラートを受け取れます。

このページでは、ツールが対応する各エンドポイントの種類、それぞれの用途、および監視によるシグナルについて説明します。

HTTP / HTTPSエンドポイント（ウェブページ）

デフォルトのケースです。https://example.comのようなURLを入力すると、モニターは指定した間隔ごとに（1分・5分・10分・30分・60分、プランによる）GETリクエストを送信します。成功とみなされる条件は、TCPコネクション確立、TLSハンドシェイクの完了（HTTPSの場合）、期待されるHTTPステータスコード（デフォルトで2xxまたは3xx）での応答受信、さらにオプションでボディ内に特定のキーワードが存在するか否か、となります。チェックでは、Time To First Byte、応答全体の時間、コンテンツサイズ、リダイレクトチェーン、レスポンスヘッダのフルセットも記録します。

HTTPエンドポイントは、マーケティングサイト、ブログ、ECサイト、SaaSダッシュボード、ドキュメントポータルなど、ブラウザで人がアクセスするあらゆる場所で最適な選択です。

APIエンドポイント（REST / GraphQL / JSON-RPC）

APIには単なる「応答したか」ではなく、「正しく応答したか」が重要です。HTTPメソッド（GET、POST、PUT、DELETE、PATCH）、カスタムヘッダー（認証トークン、Content-Type）、リクエストボディ（POST/PUT用JSONペイロード）、そしてJSONアサーション（data.statusが"ok"、result.countが0より大きい、errors[]が空など）をカスタマイズしてモニターを設定できます。HTTP 200を返してもペイロードが壊れているAPIは最悪の障害であり、単純なモニターには見抜けませんがすべてのクライアントには致命的です。JSONアサーションがこの問題を検出します。

設定方法とアサーション構文の詳細は、API監視の専用ガイドをご覧ください。

TCPポートのエンドポイント

非HTTPサービス用：SMTP（25 / 587 / 465番ポート）、POP3（110 / 995）、IMAP（143 / 993）、データベースリスナー（PostgreSQL 5432、MySQL 3306、Redis 6379、MongoDB 27017）、SSH（22）、FTP（21）、カスタムアプリケーションポートなど。host:portに対してTCP接続を試み、タイムアウトウィンドウ内で接続が受け入れられれば成功とみなします。プロトコルレベルのハンドシェイクは行いません — 単に「デーモンが待機しているかどうか」を確認します。

TCPベースの全サービスで、プロトコルに依存しない利用可能性確認をしたい時に最適なモニターです。SMTPバナー検証やデータベースクエリレベルのチェックが必要な場合は、ハートビートモニターを使ってください（サービスからこちらにpingを送信、cron-job/ハートビート監視を参照）。

Ping（ICMP）エンドポイント

OSI第3層の可用性チェックです。モニターはターゲットのホスト名またはIPにICMPエコーリクエストを送り、返答を待ちます。ルーター、スイッチ、IoTデバイスなど、Pingで反応があるがHTTPは動かない機器の監視に便利です。ただし、AWS/GCP/Azureなど多くのクラウドプロバイダーは、セキュリティグループ設定でICMPを標準でブロックするため、実際は問題なくてもPingは通りません。クラウドワークロードにはHTTPまたはTCPポートのチェックを推奨します。

ホスト名 / DNSエンドポイント

DNS解決の監視です。ツールが定期的に、指定ドメインのA、AAAA、MX、NS、TXT、CNAMEレコードを解決し、そのスナップショットを取得、いずれかに変更があればアラートを通知します。不正なDNS乗っ取り、DNSプロバイダー移行時の設定ミス、外部サービスの無告知なエンドポイント変更（例：CDNのIPブロック変更）、スペルミスでMXレコードが消える、といった事象の検知に役立ちます。

DNS監視は「利用可能性」のためでなく、変化の検出目的です。DNSプロバイダーは通常、オリジンより高い信頼性があるためです。 詳細はDNS変更監視のページをご覧ください。

SSL証明書エンドポイント

すべてのHTTPSエンドポイントは、自動的にSSL監視がアップタイムチェックに追加されます。ツールが証明書を読み取り、有効期間や発行者を解析し、有効期限の30日・14日・7日・3日・1日前に警告します。詳細はSSL証明書監視ページをご覧ください。

ドメイン有効期限エンドポイント

監視対象のURL毎に、ツールはWHOISを1日1回照会し、ドメイン登録の有効期限を追跡します。アラートはSSLと同じ基準値（30/14/7/3/1日）で発報されます。更新料未納は大きなリスク — ドメインが無主状態となり、グレース期間終了時に他者が登録できるためです。詳細はドメイン有効期限監視をご覧ください。

最適なエンドポイント種別の選び方

どのタイプのモニターを使えばいいかわからない場合は、WebインターフェースがあるものはHTTP/HTTPS、その他はTCPポート、ネットワークに公開されていないバッチ処理にはハートビートチェックから始めましょう。同じ対象に複数のタイプで監視も可能です— 例えば、TCPポート443のチェックで「サーバーは稼働しているがTLSハンドシェイクが失敗」の検出、同じURLでのHTTPチェックではそれも含めた全体の可用性確認、さらに内部エージェントからのハートビートでアプリのロジックが本当に動作しているかも確かめられます。

よくある質問

• エンドポイントとは？

  インターネット上でアドレス指定できる全て：HTTP/HTTPSのURL、REST API、TCPポート（SMTP、MySQL、カスタムなど）、Ping対象ホスト名、DNSレコード、SSL証明書、ドメイン登録情報を指します。各エンドポイント種別ごとにモニターを1つずつ設定しましょう。

• HTTPチェックとTCPポートのどちらを使うべきですか？

  HTTPは全てのウェブサービスに対する基本的な選択肢です。非HTTPサービス（データベース、メールサーバー、独自プロトコルなど）で接続可否のみを知りたい場合はTCPポートの監視が向いています。TCPは低レベルの可用性、HTTPは「アプリが正しく動作しているか」を判定するのに適しています。

• ハートビートモニター（cron-job）はどう違いますか？

  ハートビートは逆方向の仕組みで、こちらからサービスへ問い合わせるのではなく、サービス側が指定のURLへ定期的にpingを送信します。所定の時間内にpingが届かない場合にアラートが出ます。主にcronジョブやバッチ処理など、外部からネットワークアクセスできないタスクに使われます。

• 1つのURLに複数のモニターは設定できますか？

  はい、可能です。同じターゲットに対して異なる種類のチェックを行うことができます。たとえば、HTTPチェックで全体の稼働状況を、TCP 443ポートのチェックでTLSハンドシェイクの問題まで網羅することができます。各モニターは独立して動作し、異なるアラートが発報されます。

• SSLやドメインは個別にモニターが必要ですか？

  いいえ — HTTPSエンドポイントには自動的にSSL監視がアップタイムチェックに追加され、監視対象URLにはドメイン有効期限の毎日トラッキングも自動で付加されます。どちらも追加設定の必要はありません。ドメイン監視は1ドメインごとにまとめて管理され、同じドメインに複数モニターを設定した場合はWHOISデータが共有されます。