HTTPS
ウェブサイトとAPIのモニタリング
ページまたはエンドポイントを4つの大陸から取得します。
今すぐ試してください
1回のチェックを1か所から今すぐ実行しますが、何も保存されません。モニターはすべての拠点からチェックを行い、2つの他の大陸からも障害を確認してから通知します。単一のチェックではそれを確認できません。
用途
誰もが最初に始めるチェックであり、多くの製品がそこで止まります。URLをリクエストし、リダイレクトを指示通りに追従または拒否し、ステータスコードを読み取ります。
ステータスコードだけでは弱い保証です。サイトはエラーページ、ログイン画面、先週火曜日のキャッシュコピー、またはレンダリングに失敗した空のシェルを返しながら200を返すことがあります。そのため、チェックでは特定のフレーズの存在、リダイレクト先の指定、JSONフィールドの特定値、設定した時間内の応答到着を要求することもできます。これらはステータスコードでは検出できない障害です。
ここにあるすべてのチェックと同様に、Amsterdam, New York, Sydney and Singaporeから実行され、障害が発生した場合、他の2つの大陸から確認されてから通知されます。その仕組み。
設定できる内容
以下のすべては、どのプランでも追加時のフォームに含まれています。
- メソッド
- GET、HEAD、POST、PUT、PATCH、DELETE。HEADは、存在確認だけで十分なページに対する丁寧なデフォルトです。
- 期待されるステータス
- どのコードが正常と見なされるか。401は拒否すべきエンドポイントにとって正しいコードであり、これを指定することで認証が正常に機能しているのに障害として報告されるのを防ぎます。
- キーワード
- 存在すべきまたは存在してはいけないフレーズ。本当はエラーページである200を検出する最も簡単な方法です。
- JSONアサーション
- 200を返しながらボディで異なる内容を返すAPIに対して、パスと期待される値を指定します。
- リダイレクト
- チェーンを追従するか、リダイレクトを回答として扱います。期待される場所を指定することで、不適切な場所に静かにリダイレクトされたサイトを検出します。
- 遅い場合は失敗
- 応答時間がこの値を超えると、稼働中ではなく劣化と見なされます。また、それを何回連続で検出したらそう判断するかを設定します。
- 認証
- BasicまたはBearer。暗号化されて保存され、コントロールプレーンで復号化され、すべてのキーを貸与されたマシンに渡すのではなく、プローブに割り当てとともに渡されます。
- ヘッダーとボディ
- リクエストに必要なもの。ヘッダーは1行ごとに記載し、ボディが必要なメソッドにはボディを指定します。
- タイムアウト
- 失敗と見なすまでの待機時間。
- 確認
- 誰かを起こす前に、他の大陸が何回同意する必要があるか。ゼロも選べますが、通常は望ましくありません。
質問
502や503は何を意味し、それに対してアラートを出しますか?
502はフロントのサーバーがバックエンドのサーバーから使えない応答を受け取ったことを示し、503はサーバーがリクエストを受け付けていないことを示します。これは多くのフレームワークが再起動中に返すものです。デフォルトではどちらもチェックに失敗します。デフォルトでは2xxと3xxを期待しているためです。そのエンドポイントにとって正しいコードであれば、期待されるステータスリストに追加することで障害ではなくなります。
SSL/TLS証明書チェーンを検証しますか?
はい。このチェックはブラウザと同じ方法で接続し、パブリックトラストストアに対して行います。そのため、中間証明書の欠如、自己署名証明書、ホスト名の不一致、または期限切れの証明書は、ステータスコードではなくTLSエラーとしてチェックに失敗します。ただし、残り日数をカウントすることはしません。それはSSL/TLS証明書モニターの役割です。内部ホストについて知っている場合、モニターごとに検証をオフにすることができます。
ページではなくAPIエンドポイントをモニタリングできますか?
それがリクエストオプションの目的であり、これが専用のAPIモニタータイプが存在しない理由です。POST、PUT、PATCH、またはDELETEを選択し、ヘッダーとボディを追加し、BasicまたはBearer認証を使用して認証し、正しいステータスコードを受け入れ、返ってくるJSON内のパスをアサートします。
タイムアウトと遅い応答の違いは何ですか?
タイムアウトは、許可された秒数内に応答が得られなかったチェックであり、ステータスコードなしで失敗として報告されます。ただし、接続が完全に拒否された場合は別です。遅いとは、応答が届いたものの時間がかかりすぎた場合を指します。応答時間の閾値を設定し、それを超えた場合にチェックが劣化と見なされるようにします。また、通知されるまでの連続回数も設定します。
リダイレクトを追従しますか?
そうするように設定しない限りは違います。これは多くの人が驚くポイントなので説明する価値があります。駐車ページに302で応答し始めるサイトは壊れていますが、それを静かに追跡して200を見つけたチェッカーは正常と報告してしまいます。リダイレクトが目的の場合は追跡を有効にし、終了地点として期待する場所を指定してください。
チェックはJavaScriptを実行したりページをレンダリングしたりしますか?
いいえ、そうではありません。それを暗示するのではなく、明確にお伝えします。このチェックはサーバーが送信するドキュメントを取得して読み取るため、キーワードチェックはフレームワークが後で描画するものではなく、HTML内の何かに一致する必要があります。ブラウザでレンダリングされるページの場合、ステータスコード、応答時間、および応答内に実際に含まれるフレーズをアサートしてください。
応答時間は訪問者が体験するものと同じですか?
これは、リクエストから応答まで、コールドキャッシュやブラウザを介さずにプローブが待機した時間です。これにより、サーバーが遅くなっていることを検出する優れたトリップワイヤーとなりますが、スマートフォンを使用する1人のユーザーのモデルとしては不十分です。リアルユーザーモニタリングとCore Web Vitalsは別の質問に答えるものであり、このチェックはそれを装うものではありません。
なぜcronジョブでcurlするだけではいけないのですか?
1台のマシンから1つのURLを監視する場合、cronジョブは確かにこれの大部分をカバーします。それ以外を主張する人は何かを売ろうとしているだけです。ただし、cronジョブでは静かに停止する可能性のある実行環境を提供することはできません。ネットワークを失ったマシン上のチェックは何も報告せず、すべてが正常であるかのように見えます。また、サイトとあなたの間のリンク切れが原因なのか、サイト自体が壊れているのかを区別することもできません。これを解決するために、他の2つの大陸から再チェックする必要がありますが、それでも誰かを起こす仕組みを構築する必要があります。
ブラウザベースのシンセティックチェックとはどう違うのですか?
シンセティックチェックは実際のブラウザを駆動するため、スクリプトがエラーを起こして空白になるページ、動作しなくなったボタン、読み込まれなかったフォントなど、私たちには見えないものを確認できます。このチェックはリクエストを送信し、応答を読み取るだけなので、それらを確認することはできません。その代わりに、3つの大陸から30秒ごとにすべてのURLを監視できるほど安価なチェックを提供します。これにより、1時間に数回のシナリオを監視するのではなく、すべてのURLをカバーできます。これらは異なる質問に答えるものであり、多くの人が両方を求めています。