稼働時間チェックは、リソースが応答するかどうかを確認するためにそのリソースに送信されたリクエストです。稼働時間チェックを使用して、VM インスタンス、App Engine サービス、URL、または AWS ロードバランサの稼働率を確認できます。
稼働時間チェックが失敗した場合にインシデントを作成するアラート ポリシーを作成することで、リソースが使用できるかをモニタリングできます。アラート ポリシーは、メールまたは別のチャネルで通知するように構成できます。その通知には、応答に失敗したリソースに関する詳細が含まれます。 Monitoring の稼働時間チェック ダッシュボードで稼働時間チェックの結果を確認するオプションもあります。
このページでは、次の方法について説明します。
- 新しい稼働時間チェックの作成
- ダッシュボードでの稼働時間チェックの確認
- 稼働時間チェックの編集
- 稼働時間チェックの削除
料金ページと稼働時間チェックのモニタリングを説明するページへのリンクについては、次のステップ セクションをご覧ください。
始める前に
稼働時間チェックの使用は、サービスを保護するファイアウォールの影響を受けます。
- チェックするリソースが公開されていない場合は、稼働時間チェック サーバーからの着信トラフィックを許可するようにリソースのファイアウォールを構成する必要があります。IP アドレスのリストをダウンロードするには、IP アドレスの取得をご覧ください。
- チェックするリソースが外部 IP アドレスを持たない場合、稼働時間チェックはそのリソースにアクセスできません。
稼働時間チェックではページアセットの読み込みや JavaScript の実行は行われません。また稼働時間チェックのデフォルト構成には認証が含まれません。
HTTP と HTTPS については、レスポンスが別の URL へのリダイレクトである場合、チェックはその URL からデータを取得します。最後にデータを評価し、チェックが成功したかどうかを判断します。
成功となるには、これらの条件が必要です。
- HTTP ステータスが
Success
。 - データに必要とされるコンテンツは指定されていない、もしくは必要なコンテンツが存在する。
- HTTP ステータスが
稼働時間チェックの作成
ここでは、稼働時間チェックを作成して構成する方法について説明します。
Console
Google Cloud Console を使用して稼働時間チェックを作成するには、次の手順に従います。
Cloud Console で、[Monitoring] を選択します。
[稼働時間チェック] をクリックします。
[稼働時間チェックの作成] をクリックします。
稼働時間チェックを説明するタイトルを入力し、[次へ] をクリックします。
稼働時間チェックのターゲットを指定します。
[プロトコル] でプロトコルを選択します。HTTP、HTTPS、TCP のオプションがあります。
次のリソースタイプのいずれか 1 つを選択します。
- URL: 任意の IPv4 アドレスまたはホスト名。パスとポートは別々に入力します。
- [App Engine]: App Engine アプリケーション(モジュール)
- [Instance]: Compute Engine または AWS EC2 インスタンス
- [Elastic Load Balancer]: AWS ロードバランサ
プロトコル固有のフィールドを入力します。
TCP チェックでは、ポートを入力します。
HTTP チェックと HTTPS チェックでは、ホストまたはリソース内のパスを入力するオプションがあります。これらのプロトコルを使用するすべての稼働時間チェックは、
http://target/path
にリクエストを送信します。この式において、URL リソースでは、target
はホスト名または IP アドレスです。 App Engine リソースでは、target
はサービス名に由来するホスト名です。インスタンスとロードバランサのリソースでは、target
はリソースまたはリソースのグループに指定した名前に由来する IP アドレスです。path
フィールドを空白のままにするか、値を/
に設定すると、リクエストはhttp://target/
に発行されます。URL リソース
example.com/tester
に稼働時間チェックを発行するには、ホスト名フィールドをexample.com
に、パスフィールドを/tester
に設定します。/
と/hello
をサポートするコーディネーターによってサーバーを App Engine にデプロイしたとします。パスフィールドを空白のままにした場合、稼働時間チェックが/
ハンドラに送信されます。稼働時間チェックを/hello
ハンドラに発行するには、パスフィールドの値を/hello
に設定します。
リソース固有のフィールドを入力します。
URL リソースでは、ホスト名フィールドにホスト名を入力します。たとえば、「
example.com
」と入力します。App Engine リソースでは、[サービス] フィールドにサービス名を入力します。
エラスティック ロードバランサとインスタンスのリソースの場合は、次のフィールドに入力します。
- 単一のインスタンスまたはロードバランサに稼働時間チェックを発行するには、[適用先] フィールドで [Single] を選択し、メニューを使用して特定のインスタンスまたはロードバランサを選択します。
- モニタリング グループに稼働時間チェックを発行するには、[適用先] フィールドで [Group] を選択し、メニューを使用してグループ名を選択します。
[チェックの頻度] フィールドでは、稼働時間チェックの実行頻度を制御します。デフォルト値のままにする、またはオプション メニューから値を選択することができます。
チェッカー リージョンを構成するか、SSL 証明書、認証、ヘッダー、および HTTP チェックと HTTPS チェックのポートを構成するには、[その他のターゲット オプション] をクリックします。
- リージョン: 稼働時間チェックがリクエストを受信するリージョンを選択します。稼働時間チェックには、少なくとも 3 つのチェッカーが必要です。3 つのチェッカーがある米国を除くすべてのリージョンには、1 つのチェッカーがあります。デフォルト設定の [グローバル] にはすべてのリージョンが含まれています。
- General: 仮想ホストをチェックする場合に入力します。このフィールドは TCP チェックには使用できません。
- Port: ポート番号を指定します。
Custom Headers: カスタム ヘッダーを追加し、必要に応じて暗号化します。暗号化すると、ヘッダーの値はフォームに表示されません。 認証に関連するヘッダーを他のユーザーに表示しないように暗号化を使用します。
[Authentication]: 単一のユーザー名とパスワードを指定します。これらの値は Authorization ヘッダーとして送信されます。ここで値を設定する場合、これとは別に Authorization ヘッダーを設定しないでください。Authorization ヘッダーを設定する場合は、ここに値を設定しないでください。フォームではパスワードは常に非表示です。このフィールドは TCP チェックには使用できません。
SSL 証明書の検証: URL リソースに対して HTTPS を選択した場合、デフォルトでは HTTPS 経由での接続を試行し、SSL 証明書を検証します。URL に無効な証明書がある場合、稼働時間チェックは失敗します。無効な証明書の例として、期限切れの証明書、自己署名証明書、ドメイン名が一致しない証明書、AIA 拡張機能を使用している証明書などが挙げられます。
HTTPS 稼働時間チェックによって SSL 証明書を検証させるには、[SSL 証明書を検証する] が選択されていることを確認します。
SSL 証明書の検証を無効にするには、[SSL 証明書を検証する] がクリアされていることを確認します。
Authority Information Access(AIA)拡張機能を使用した SSL 証明書がある場合は、SSL 証明書の検証を無効にする必要があります。これらのタイプの証明書はサポートされておらず、検証シーケンスは失敗します。 通常、エラーメッセージは「10000 ミリ秒の SSL ハンドシェイク エラーで応答」です。
指標
monitoring.googleapis.com/uptime_check/time_until_ssl_cert_expires
では、証明書が期限切れになる前に通知するアラートを作成できます。詳細については、サンプル ポリシー: 稼働時間チェック ポリシーをご覧ください。[SSL 証明書を検証する] チェックボックスを選択オンにします。
[次へ] をクリックします。
レスポンス要件を構成します。
オプションのメニューから [レスポンスのタイムアウト] を選択します。
1
〜60
秒の範囲から任意の値を選択できます。このタイムアウト時間内に複数のロケーションからレスポンスを受け取らなかった場合、稼働時間チェックは失敗となります。コンテンツ マッチングでは、トグルラベルが [コンテンツ マッチングが有効] になっていることを確認します。
- オプションのメニューから [レスポンスのコンテンツのマッチタイプ] を選択します。
このフィールドは、レスポンスのコンテンツと返されたデータをどのように比較するかを指定します。たとえば、レスポンスのコンテンツが
abcd
で、コンテンツのマッチタイプが [含む] の場合、レスポンスのデータにabcd
が含まれていれば、稼働時間チェックは成功となります。レスポンスにabcd
が含まれていない場合、稼働時間チェックは失敗します。 - [レスポンスのコンテンツ] を入力します。1024 バイト以下の文字列を指定する必要があります。API では、これは
ContentMatcher
オブジェクトです。
- オプションのメニューから [レスポンスのコンテンツのマッチタイプ] を選択します。
このフィールドは、レスポンスのコンテンツと返されたデータをどのように比較するかを指定します。たとえば、レスポンスのコンテンツが
稼働時間チェックを Cloud Logging に送信しない場合は、[チェックの失敗をログする] をオフにします。
[次へ] をクリックします。
アラート ポリシーを作成します。稼働時間チェックがアラート ポリシーによってモニタリングされると、稼働時間チェックが失敗した場合、インシデントが作成され、ポリシーに接続されたすべての通知チャネルに通知が送信されます。たとえば、ポリシーにメールアドレスを追加すると、そのアドレスにメールが送信されます。このステップでアラート ポリシーを作成することも、チェックの作成後にアラート ポリシーを作成することもできます。
このフローでアラート ポリシーを作成したくない場合は、切り替えボタンのテキストが [アラートを作成しない] になっていることを確認します。ボタンをクリックして切り替えの状態を変更します。
このフローの一環としてアラート ポリシーを作成するには、次のとおりにします。
切り替えボタンのテキストが [アラートを作成する] になっていることを確認します。必要に応じてボタンをクリックします。
名前フィールドに、アラート ポリシーの名前を入力するか、デフォルトの名前を使用します。
アラート ポリシーに 1 つ以上の通知チャネルを追加するには、[通知チャネル] というラベルのテキスト ボックスでメニュー arrow_drop_down をクリックします。追加するチャネルを選択し、[OK] をクリックします。通知は、チャネルタイプごとにアルファベット順にグループ化されます。
アラート ポリシーに追加する通知チャネルがリストにない場合は、[通知チャネルを管理する] をクリックします。
新しいブラウザタブの [通知チャネル] ウィンドウに移動します。通知チャネルを追加し、このタブに戻って [更新] refreshをクリックし、アラート ポリシーに追加する通知チャネルを選択します。
期間フィールドで、稼働時間チェックの失敗のインシデントが作成されるまでの時間を選択します。デフォルトでは、少なくとも 2 つのリージョンで 1 分間の稼働時間チェックの失敗が報告された場合に、アラート ポリシーが構成されます。
アラート ポリシーの無効化、編集、削除については、ポリシーの管理をご覧ください。
稼働時間チェックの構成を確認するには、[TEST] をクリックします。結果が期待どおりでない場合は、下記のチェックの失敗セクションを参照して構成を修正し、検証ステップを繰り返します。
[作成] をクリックします。必要なデータがない場合、保存操作が失敗し、ダイアログ ボタンの横にデータが不足しているフィールドの一覧が表示されます。変更を保存すると、[Uptime check created] ダイアログが表示されます。
API
projects.uptimeCheckConfigs.create
メソッドを呼び出します。メソッドのパラメータを次のように設定します。
parent: 必須。稼働時間チェックを作成するプロジェクトの名前を指定する必要があります。
PROJECT_ID
を実際の Google Cloud プロジェクト ID に置き換えます。書式は次のとおりです。projects/PROJECT_ID
リクエスト本文には、新しい稼働時間チェックの
UptimeCheckConfig
オブジェクトを含める必要があります。このページでは、いくつかのフィールドについてのみ説明します。このオブジェクトとそのフィールドの詳細については、UptimeCheckConfig
のドキュメントをご覧ください。構成オブジェクトの
name
フィールドは空白のままにします。このフィールドは、システムがレスポンス構成オブジェクトを作成するときに設定します。HTTP または HTTPS チェックを構成する場合は、
UptimeCheckConfig
オブジェクトのHttpCheck
フィールドに入力する必要があります。このオブジェクトでは、requestMethod
フィールドをGET
またはPOST
に設定します。このフィールドを省略するかMETHOD_UNSPECIFIED
に設定すると、GET
リクエストが発行されます。POST
リクエストを構成する場合は、contentType
フィールドとbody
フィールドに入力します。
create
メソッドは、新しい構成に応じた UptimeCheckConfig
オブジェクトを返します。
作成された稼働時間チェックの構成が想定どおりに機能しない場合は、このページのチェックの失敗セクションをご覧ください。
C#
Java
Go
Node.js
PHP
Python
Ruby
稼働時間チェックの結果が Monitoring に送信され始めるまでに、最大 5 分の遅延が発生する可能性があります。その間、稼働時間チェック ダッシュボードには「データがありません」というステータスが表示されます。
稼働時間チェックで使用する識別子
稼働時間チェックが作成されると、Monitoring によって識別子が割り当てられます。この識別子は稼働時間チェック ID と呼ばれています。稼働時間チェック ID は次のように、新しく作成された稼働時間チェックのリソース名に埋め込まれます。
projects/PROJECT_ID/uptimeCheckConfigs/UPTIME_CHECK_ID
メソッド呼び出しのレスポンスで返された稼働時間チェック ID を使用して、稼働時間チェックの作成や一覧表示を行えます。稼働時間チェック ID は、[構成] セクションの下の [稼働時間の詳細] ウィンドウから確認することもできます。
稼働時間チェックの確認
Cloud Console で稼働時間チェックを作成する際、保存前にその構成をテストできます。
チェックの成功
次の 2 つの条件に当てはまる場合、稼働時間チェックが成功します。
- HTTP ステータスが
Success
。 - レスポンスに必要なコンテンツが指定されていない、もしくは、レスポンスを検索して必要なコンテンツが見つかった。
チェックの失敗
以下に、稼働時間チェックが失敗する原因の一部を示します。
- Connection Error - Refused: デフォルトの HTTP 接続タイプを使用している場合、HTTP リクエストに応答しているウェブサーバーがインストールされていることを確認します。これは、新しいインスタンスにウェブサーバーがインストールされていない場合に発生する可能性があります。Compute Engine のクイックスタートをご覧ください。HTTPS 接続タイプを使用する場合は、追加の構成手順を実行しなければならないことがあります。ファイアウォールの問題については、IP アドレスの取得をご覧ください。
- 名前またはサービスが見つかりません: ホスト名が正しくない可能性があります。
- 403 Forbidden: サービスが稼働時間チェッカーにエラーコードを返しています。たとえば、Apache ウェブサーバーのデフォルト構成は、Amazon Linux ではこのコードを返しますが、他のいくつかの Linux バージョンではコード 200 (Success) を返します。Amazon Linux の LAMP チュートリアルまたはご使用のウェブサーバーのドキュメントをご覧ください。
- 404 Not found: パスが正しくない可能性があります。
- 408 Request timeout、またはレスポンスなし: ポート番号が正しくない、サービスが稼働していない、サービスがアクセスできない状態になっている、あるいはタイムアウト値が小さすぎる可能性があります。ファイアウォールが稼働時間サーバーからのトラフィックを許可していることを確認してください。詳しくは IP アドレスの取得をご覧ください。タイムアウト時間は、[Advanced Options] の [Healthcheck] で指定します。
稼働時間チェックを表示する
稼働時間チェックを表示するには、次の手順に従います。
Console
単一の稼働時間チェックの詳細ステータスを表示する方法は次のとおりです。
Cloud Console で、[Monitoring] を選択します。
[稼働時間チェック] をクリックします。
[稼働時間の詳細] ウィンドウを表示するには、表示する稼働時間チェックを見つけて、稼働時間チェックの名前をクリックします。
次のスクリーンショットは、「My Uptime Check」という名前の稼働時間チェックの稼働時間の詳細を示しています。
[稼働時間の詳細] ウィンドウには以下の情報が含まれます。
- 選択した時間間隔。デフォルトの間隔は 1 時間です。
- 稼働時間チェックの名前。この例では、チェックの名前は My Uptime Check です。
稼働率と平均レイテンシ。[Percent uptime] の値は、
(S/T)*100
として計算されるパーセンテージです。ここで、S
は成功したチェック レスポンスの数で、T
は、すべてのロケーションからのチェック レスポンスの合計数です。グループ チェックの場合、S
およびT
の値は、現在のすべてのグループ メンバーにわたって合計されます。たとえば、すべてのリージョンで 1 分間の稼働時間チェックを 25 分間にわたって実行すると、6 つのロケーションそれぞれから 25 件のリクエストが取得されるため、合計で 150 件のリクエストになります。また、ダッシュボードで 83.3% の稼働時間がレポートされた場合、150 件のリクエストのうち 125 件が成功したことを意味します。
[Passed checks] と [Uptime check latency] ペインには、渡されたチェックの数と各チェックのレイテンシを時間の関数としてグラフで表示します。
[Current status] ペインには、最新のチェックのステータスが表示されます。リージョンの隣にあるチェックマークのついた緑色の丸は、そのリージョンで最後に実行されたチェックが成功したことを示します。バツ印のついた赤い丸は失敗を示します。
[Configuration] ペインに、稼働時間チェックの構成が表示されます。このデータは、稼働時間チェックの作成時に割り当てられます。[Check Id] の値は、API 呼び出しの
UPTIME_CHECK_ID
値に対応しています。[Alert Policy] ペインには、関連するアラート ポリシーの情報が表示されます。このサンプル ダッシュボードでは、1 つのアラート ポリシーが構成されています。
C#
Java
Go
Node.js
PHP
Python
Ruby
稼働時間チェックを編集する
稼働時間チェック プロトコル、リソースタイプ、モニタリング対象のリソースは変更できません。これらのフィールドを変更する場合は、適切な構成の稼働時間チェックを作成する必要があります。ただし、稼働時間チェック内の他のすべてのフィールドは、チェックの作成後に変更できます。
稼働時間チェックに関連付けられたアラート ポリシーを編集するには、[Monitoring] ナビゲーションペインでnotifications [Alerting] をクリックし、編集するポリシーを選択して [Edit] をクリックします。
稼働時間チェックを編集するには、次の手順に従います。
Console
Cloud Console で、[Monitoring] を選択します。
[稼働時間チェック] をクリックします。
編集する稼働時間チェックを見つけ、次のいずれかの操作を行います。
- クリック[その他] をクリックしてmore_vert、[編集] を選択します。
- 稼働時間チェックの詳細を表示し、[Edit] をクリックします。
必要に応じてフィールドの値を変更します。一部のフィールドは変更できません。チェックのカスタム ヘッダーの値が非表示になっている場合は、表示できません。
チェックが動作するかどうかを確認するには、[TEST] をクリックします。テストが失敗した場合は、チェックの失敗を参照して考えられる原因を特定します。
[SAVE] をクリックします。
API
projects.uptimeCheckConfigs.patch
メソッドを呼び出します。メソッドのパラメータを次のように設定します。
uptimeCheckConfig.name: 必須。これは REST URL の一部で、編集する稼働時間チェックのリソース名です。
projects/PROJECT_ID/uptimeCheckConfigs/UPTIME_CHECK_ID
UPTIME_CHECK_ID は、
create
メソッドまたはlist
メソッドのレスポンスから取得できます。この ID は Cloud Console には表示されません。updateMask: 任意。これは次のようなクエリ パラメータになります。
?updateMask=[FIELD_LIST]
[FIELD_LIST]
には、変更するUptimeCheckConfig
オブジェクト内のフィールドをカンマ区切りのリストとして指定します。例:"resource.type,httpCheck.path"
リクエスト本文には、新しいフィールド値を指定した
UptimeCheckConfig
を含める必要があります。
updateMask
が設定されている場合は、updateMask
にリストされたフィールドについてのみ、既存構成の対応するフィールドが置換されます。サブフィールドが存在するフィールドについては、フィールド マスクのリストにフィールドだけ含まれ、サブフィールドが含まれていない場合でも、そのフィールド値に応じてサブフィールドの値が適宜置き換えられます。
updateMask
が設定されていない場合、リクエスト本文中の構成が既存の構成全体と置き換わります。
patch
メソッドは、変更後の構成が反映された UptimeCheckConfig
オブジェクトを返します。
C#
Java
Go
Node.js
PHP
Python
Ruby
新しい稼働時間チェックの結果が表示されるまでに最大 5 分の遅延が発生する可能性があります。その間は、変更前の稼働時間チェックの結果がダッシュボードに表示され、アラート ポリシーで使用されます。
稼働時間チェックを削除する
Cloud Console を使用して稼働時間チェックを削除しようとして、稼働時間チェックに依存するアラート ポリシーが存在する場合、削除オペレーションは失敗します。チェックを使用するすべてのアラート ポリシーから稼働時間チェックを削除してから、再び削除を試みてください。
Cloud Monitoring API を使用して稼働時間チェックを削除しようとすると、稼働時間チェックに依存するアラート ポリシーが存在する場合でも、稼働時間チェックは削除されます。エラーは発生しません。存在しないチェックに対し、インシデントは作成されません。 稼働時間チェックを削除する前に、このチェックに依存するアラート ポリシーがないことを確認してください。
稼働時間チェックを削除するには、次の手順に従います。
Console
Cloud Console で、[Monitoring] を選択します。
[稼働時間チェック] をクリックします。
編集する稼働時間チェックを見つけ、次のいずれかの操作を行います。
- [その他] をクリックしてmore_vert、[削除] を選択します。
- 稼働時間チェックの詳細を表示して、[Delete] deleteをクリックします。
API
projects.uptimeCheckConfigs.delete
メソッドを呼び出します。パラメータを次のように設定します。
name: 必須。削除する稼働時間チェック構成のリソース名を次の書式で指定します。
projects/PROJECT_ID/uptimeCheckConfigs/UPTIME_CHECK_ID
UPTIME_CHECK_ID は、
create
メソッドまたはlist
メソッドのレスポンスから取得できます。この ID は Cloud Console には表示されません。
C#
Java
Go
Node.js
PHP
Python
Ruby
次のステップ
- 稼働時間チェックの料金と上限を確認するには、料金と上限をご覧ください。
- すべての稼働時間チェックを一覧表示するには、稼働時間チェックの確認をご覧ください。
- 稼働時間チェックで使用される IP アドレスの一覧を取得するには、IP アドレスの取得をご覧ください。
- API を使用して稼働時間チェックのステータスを確認するには、指標
monitoring.googleapis.com/uptime_check/check_passed
をモニタリングします。詳細については、Google Cloud 指標の一覧をご覧ください。