このドキュメントでは、内部アプリケーション ロードバランサのロギングとモニタリングの指標について説明します。リージョン内部アプリケーション ロードバランサとクロスリージョン内部アプリケーション ロードバランサの両方のロギングとモニタリングの指標は同じです。
ロギング
ロギングは、バックエンド サービス単位で有効にできます。1 つの内部アプリケーション ロードバランサの URL マップで複数のバックエンド サービスを参照できます。このため、構成に応じて複数のバックエンド サービスでロギングを有効にする必要がある場合があります。
ログのサンプリングと収集
Google Cloud は、ロードバランサのバックエンド仮想マシン（VM）インスタンスから送信されたパケットをサンプリングします。サンプリングされたパケットは、ログを生成するために処理されます。
すべてのパケットがサンプリングされるわけではありません。Google Cloud は、物理ホスト上のトラフィック量に応じてパケットのサブセットをサンプリングします。最も低いサンプリング レートは、1,024 パケット中 1 パケットです。サンプリング レートは Google Cloud によって動的に制御されます。サンプリング レートは調整できません。
パケット サンプリングは、ファイアウォール ルールと次のように相互作用します。
- 下り（外向き）ファイアウォール ルールが適用される前にパケットがサンプリングされます。
- 上り（内向き）ファイアウォール ルールが適用された後にパケットがサンプリングされます。
パケット サンプリングの後、Google Cloud はサンプリングされたパケットを次のように処理します。
集計: サンプリングされたパケットは 5 秒間隔で集計され、単一のフローエントリが生成されます。
構成可能な（セカンダリ）ログ サンプリング: 2 番目のサンプリング プロセスで、フローをサンプリングします。logConfig.sampleRate パラメータに従って、ログエントリとして出力されるフロー部分の割合を制御します。
logConfig.sampleRateが1.0（100%）の場合、サンプリングされたパケットがすべて処理されます。Logging への書き込み: ログエントリが Cloud Logging に書き込まれます。
オプション フィールド
ログレコードには必須フィールドとオプション フィールドがあります。ログの内容に、オプション フィールドと必須フィールドの一覧を示します。すべての必須フィールドは常に含まれます。保持するオプション フィールドはカスタマイズできます。
[すべてのオプションのフィールドを含める] を選択すると、ログレコード形式のすべてのオプションのフィールドがフローログに含まれます。新しいオプション フィールドがレコード形式に追加されると、フローログに新しいフィールドが自動的に含まれます。
[すべてのオプションのフィールドを除外する] を選択した場合、オプション フィールドはすべて省略されます。
[カスタム] を選択した場合は、含めるオプション フィールド（
tls.protocol,tls.cipherなど）を指定できます。
オプション フィールドをカスタマイズする手順については、既存のバックエンド サービスでロギングを有効にするをご覧ください。
既存のバックエンド サービスでロギングを有効にする
リージョン内部アプリケーション ロードバランサの場合は、次の操作を行います。
コンソール
Google Cloud コンソールの [ロード バランシング] ページに移動します。
ロードバランサの名前をクリックします。
[編集] をクリックします。
[バックエンドの構成] をクリックします。
バックエンド サービスの横にある [編集] をクリックします。
[高度な構成（セッション アフィニティ、コネクション ドレインのタイムアウト）] をクリックします。
[ロギングを有効にする] をクリックします。
[サンプルレート] の値を選択します。
0.0から1.0までの数値を設定できます。0.0はリクエストがログに記録されていないことを意味し、1.0はリクエストの 100% がログに記録されることを意味します。デフォルト値は1.0です。省略可: ログにすべてのオプション フィールドをすべて含めるには、[任意項目] セクションで [すべてのオプションのフィールドを含める] をクリックします。
バックエンド サービスの編集を終了するには、[更新] をクリックします。
ロードバランサの編集を終了するには、[更新] をクリックします。
gcloud
バックエンド サービスを更新してロギングを有効にするには、gcloud compute
backend-services update コマンドを使用します。
gcloud compute backend-services update BACKEND_SERVICE \
--enable-logging \
--logging-sample-rate=RATE \
--region=REGION \
--logging-optional=LOGGING_OPTIONAL_MODE \
--logging-optional-fields=OPTIONAL_FIELDS
ここで
--enable-loggingは、バックエンド サービスのロギングを有効にします。--logging-sample-rateには、0.0から1.0までの値を指定できます。0.0を設定すると、リクエストはまったくロギングされません。1.0を設定すると、すべてのリクエストがロギングされます。--enable-loggingパラメータの場合のみ有意です。ロギングを有効にしても、サンプリング レートが0.0であれば、ロギングが無効の場合と同じ結果になります。デフォルト値は1.0です。--logging-optionalを使用すると、ログに含めるオプション フィールドを指定できます。INCLUDE_ALL_OPTIONAL: すべてのオプション フィールドを含めます。EXCLUDE_ALL_OPTIONAL（デフォルト）: すべてのオプション フィールドを除外します。CUSTOM:OPTIONAL_FIELDSで指定するオプション フィールドのカスタムリストを含めます。
--logging-optional-fieldsを使用すると、ログに含めるオプション フィールドのカンマ区切りのリストを指定できます。たとえば、
tls.protocol,tls.cipherは、LOGGING_OPTIONAL_MODEがCUSTOMに設定されている場合にのみ設定できます。
クロスリージョン内部アプリケーション ロードバランサの場合は、次の操作を行います。
コンソール
Google Cloud コンソールの [ロード バランシング] ページに移動します。
ロードバランサの名前をクリックします。
[編集] をクリックします。
[バックエンドの構成] をクリックします。
バックエンド サービスの横にある [編集] をクリックします。
[高度な構成（セッション アフィニティ、コネクション ドレインのタイムアウト）] をクリックします。
[ロギングを有効にする] をクリックします。
[サンプルレート] の値を選択します。
0.0から1.0までの数値を設定できます。0.0はリクエストがログに記録されていないことを意味し、1.0はリクエストの 100% がログに記録されることを意味します。デフォルト値は1.0です。省略可: ログにすべてのオプション フィールドをすべて含めるには、[任意項目] セクションで [すべてのオプションのフィールドを含める] をクリックします。
バックエンド サービスの編集を終了するには、[更新] をクリックします。
ロードバランサの編集を終了するには、[更新] をクリックします。
gcloud
バックエンド サービスを更新してロギングを有効にするには、gcloud compute
backend-services update コマンドを使用します。
gcloud compute backend-services update BACKEND_SERVICE \
--enable-logging \
--logging-sample-rate=RATE \
--global \
--logging-optional=LOGGING_OPTIONAL_MODE \
--logging-optional-fields=OPTIONAL_FIELDS
ここで
--enable-loggingは、バックエンド サービスのロギングを有効にします。--logging-sample-rateには、0.0から1.0までの値を指定できます。0.0を設定すると、リクエストはまったくロギングされません。1.0を設定すると、すべてのリクエストがロギングされます。--enable-loggingパラメータの場合のみ有意です。ロギングを有効にしても、サンプリング レートが0.0であれば、ロギングが無効の場合と同じ結果になります。デフォルト値は1.0です。--logging-optionalを使用すると、ログに含めるオプション フィールドを指定できます。INCLUDE_ALL_OPTIONAL: すべてのオプション フィールドを含めます。EXCLUDE_ALL_OPTIONAL（デフォルト）: すべてのオプション フィールドを除外します。CUSTOM:OPTIONAL_FIELDSで指定するオプション フィールドのカスタムリストを含めます。
--logging-optional-fieldsを使用すると、ログに含めるオプション フィールドのカンマ区切りのリストを指定できます。たとえば、
tls.protocol,tls.cipherは、LOGGING_OPTIONAL_MODEがCUSTOMに設定されている場合にのみ設定できます。
バックエンド サービスでロギングを有効にすると、Cloud Logging を使用して各 HTTP(S) リクエストがロギングされます。
ログの表示方法
ログを表示するには、Google Cloud コンソールで [ログ エクスプローラ] ページに移動します。
内部アプリケーション ロードバランサのログは、最初はネットワーク別に、次にリージョン別にインデックス化されます。
- すべての内部アプリケーション ロードバランサのログを表示するには、最初のプルダウン メニューで [内部アプリケーション ロードバランサ ルール] を選択します。
- 1 つのネットワークのログのみを表示するには、[内部アプリケーション ロードバランサのルール] を選択して、ネットワークの名前を選択します。
- ネットワークの 1 つのリージョンのみのログを表示するには、[内部アプリケーション ロードバランサのルール] > [
NETWORK] > [REGION] を選択します。
通常、ブール型のログフィールドは、フィールドの値が true の場合にのみ表示されます。ブール フィールドの値が false の場合、そのフィールドはログから省略されます。
ログフィールドには UTF-8 エンコードが適用されます。UTF-8 以外の文字列は、疑問符に置き換えられます。
リソースログ（resource.type="internal_http_lb_rule"）のログベースの指標のエクスポートを構成できます。作成される指標は、内部アプリケーション ロードバランサ ルールのリソースに基づいています。このリソースは Cloud Monitoring ダッシュボードで使用できます。
ログの内容
内部アプリケーション ロードバランサ ログエントリには、HTTP(S) トラフィックのモニタリングとデバッグに役立つ情報が含まれています。ログレコードには、すべてのログレコードのデフォルト フィールドである必須フィールドと、HTTP(S) トラフィックに関する追加情報を追加するオプション フィールドが含まれます。オプションのフィールドは、ストレージ コストを節約するために省略できます。ログエントリには次のタイプの情報が含まれています。
- 重大度、プロジェクト ID、プロジェクト番号、タイムスタンプなど、ほとんどの Google Cloud ログで表示される一般情報（LogEntry の説明を参照）。
- HttpRequest ログフィールド
一部のログフィールドはマルチ フィールド形式であり、所定のフィールドに複数のデータが含まれます。たとえば、tls フィールドは TlsDetails 形式で、TLS プロトコルと TLS 暗号が 1 つのフィールドに含まれています。これらのマルチ フィールドのフィールドについては、次のレコード形式の表で説明します。
| フィールド | 型 | フィールドのタイプ: 必須または省略可 | 説明 |
|---|---|---|---|
logName
|
文字列 | 必須 |
このログエントリが属するログのリソース名。"projects/PROJECT_ID/logs/requests" の形式です。 |
timestamp
|
文字列 | 必須 | リクエストが開始された時刻。 |
severity
|
LogSeverity 形式 | 必須 |
ログエントリの重大度。デフォルトは LogSeverity.DEFAULT です。 |
httpRequest
|
HttpRequest オブジェクト | 必須 | ログに記録される HTTP(S) リクエストを記述する HttpRequest プロトコル。 |
trace
|
文字列 | 必須 |
ログエントリに関連付けられているトレースのリソース名。相対リソース名が含まれている場合、https://tracing.googleapis.com を基準とした相対的な名前になります。例: projects/PROJECT_ID/traces/06796866738c859f2f19b7cfb3214824。内部アプリケーション ロードバランサは、このフィールドをサポートしていません。 |
spanId
|
文字列 | 必須 |
ログエントリに関連付けられているトレース内のスパン ID。トレーススパンの場合、この文字列は Trace API v2 と同じ形式で、8 バイトの配列を 16 文字の 16 進数にエンコードした値（例: 000000000000004a）になります。内部アプリケーション ロードバランサは、このフィールドをサポートしていません。 |
resource
|
MonitoredResource オブジェクト | 必須 |
このログエントリを生成したモニタリング対象リソース。
たとえば、内部アプリケーション ロードバランサのモニタリング対象リソースの記述子は、リソースタイプが |
| jsonPayload | オブジェクト（Struct 形式） | 必須 | JSON オブジェクトとして表されるログエントリ ペイロード。JSON オブジェクトには、次のフィールドが含まれています。
|
| 文字列 | 必須 |
値が空の文字列の場合、このフィールドはログに記録されません。詳細については、proxyStatus メッセージをご覧ください。 |
|
| 文字列 | 必須 | backendTargetProjectNumber フィールドには、バックエンド サービスまたはバックエンド バケットのオーナーを識別するプロジェクト番号が保持されます。 |
|
| 文字列 | 必須 | serviceDirectoryService フィールドには、Cloud FIT 障害が構成された Service Directory サービスの名前が保持されます。 |
|
| 文字列 | 必須 | cloudFitExperiment フィールドには、Cloud FIT テストの名前が保持されます。 |
|
| 文字列 | 必須 | cloudFitFault フィールドには、このリクエストパスに Cloud FIT 障害テストによって挿入された障害の名前が保持されます。 |
|
| ServiceExtensionInfo | 必須 | serviceExtensionInfo フィールドには、ロードバランサから Service 拡張機能への gRPC ストリームに関する情報が格納されます。詳しくは、コールアウト拡張機能でログに記録される内容をご覧ください。 |
|
| TlsDetails | 省略可 | tls フィールドには、クライアントと内部アプリケーション ロードバランサ間の接続の TLS メタデータを指定する TlsDetails が保持されます。このフィールドは、クライアントが TLS / SSL 暗号化を使用している場合にのみ使用できます。 |
|
| MtlsDetails | 省略可 | mtls フィールドには、クライアントと内部アプリケーション ロードバランサ間の接続の mTLS メタデータを指定する MtlsDetails 値が保持されます。このフィールドは、ロードバランサがフロントエンド相互 TLS（mTLS）を使用している場合にのみ使用できます。 |
TlsDetails フィールドの形式
| フィールド | フィールドの形式 | フィールドのタイプ: 必須または省略可 | 説明 |
|---|---|---|---|
| protocol | 文字列 | 省略可 | クライアントがロードバランサとの接続を確立するために使用する TLS プロトコル。有効な値は、TLS 1.0, 1.1, 1.2,
1.3 または QUIC です。クライアントが TLS / SSL 暗号化を使用していない場合、この値は NULL に設定されます。 |
| cipher | 文字列 | 省略可 | クライアントがロードバランサとの接続を確立するために使用する TLS 暗号。クライアントが HTTP(S) を使用していない場合、またはクライアントが TLS / SSL 暗号化を使用していない場合、この値は NULL に設定されます。 |
MtlsDetails フィールドの形式
| フィールド | フィールドの形式 | フィールドのタイプ: 必須または省略可 | 説明 |
|---|---|---|---|
| clientCertPresent | ブール値 | 省略可 | TLS handshake 中にクライアントが証明書を提供した場合は |
| clientCertChainVerified | ブール値 | 省略可 | 構成された |
| clientCertError | 文字列 | 省略可 | エラー条件を表す事前定義の文字列。エラー文字列の詳細については、mTLS クライアント検証モードをご覧ください。 |
| clientCertSha256Fingerprint | 文字列 | 省略可 | クライアント証明書の Base64 でエンコードされた SHA-256 フィンガープリント。 |
| clientCertSerialNumber | 文字列 | 省略可 | クライアント証明書のシリアル番号。シリアル番号が 50 バイトを超える場合、文字列 |
| clientCertValidStartTime | 文字列 | 省略可 | クライアント証明書が無効になる前のタイムスタンプ（RFC 3339 日付文字列形式）。例: |
| clientCertValidEndTime | 文字列 | 省略可 | クライアント証明書が有効でなくなった後のタイムスタンプ（RFC 3339 日付文字列形式）。例: |
| clientCertSpiffeId | 文字列 | 省略可 | サブジェクト代替名（SAN）フィールドの SPIFFE ID。値が無効であるか、2,048 バイトを超える場合、SPIFFE ID は空の文字列に設定されます。 SPIFFE ID が 2,048 バイトを超える場合、文字列 |
| clientCertUriSans | 文字列 | 省略可 | URI 型の SAN 拡張機能のカンマ区切り Base64 エンコード リスト。SAN 拡張機能はクライアント証明書から抽出されます。
|
| clientCertDnsnameSans | 文字列 | 省略可 | DNSName タイプの SAN 拡張機能のカンマ区切り Base64 エンコード リスト。SAN 拡張機能はクライアント証明書から抽出されます。
|
| clientCertIssuerDn | 文字列 | 省略可 | Base64 でエンコードされた証明書の完全な発行者フィールド。
|
| clientCertSubjectDn | 文字列 | 省略可 | Base64 でエンコードされた証明書の完全なサブジェクト フィールド。
|
| clientCertLeaf | 文字列 | 省略可 | 証明書が検証に合格している確立済みの mTLS 接続のクライアント リーフ証明書。証明書のエンコードは RFC 9440 に準拠しています。バイナリ DER 証明書は Base64 を使用してエンコードされ、両側がコロンで区切られています（改行、スペース、Base64 以外の文字は使用されません）。
|
| clientCertChain | 文字列 | 省略可 | クライアント証明書が検証に合格している確立済みの mTLS 接続のクライアント証明書チェーンの証明書のリスト。このリストはカンマ区切りで、標準の TLS 順序になっています（リーフ証明書は含みません）。証明書のエンコードは RFC 9440 に準拠しています。 Base64 エンコード前の |
リソースラベル
次の表に、resource.type="internal_http_lb_rule" のリソースラベルを示します。
| フィールド | 型 | 説明 |
|---|---|---|
network_name |
文字列 | ロードバランサの VPC ネットワークの名前。 |
project_id | 文字列 | このリソースに関連付けられた Google Cloud プロジェクトの ID。 |
region |
文字列 | ロードバランサが定義されているリージョン。 |
url_map_name | 文字列 | バックエンド サービスを選択するように構成された URL マップ オブジェクトの名前。 |
forwarding_rule_name |
文字列 | 転送ルール オブジェクトの名前。 |
target_proxy_name | 文字列 | 転送ルールで参照されるターゲット プロキシ オブジェクトの名前。 |
matched_url_path_rule |
文字列 |
URL マップキーの一部として構成された URL マップ パスルールまたはルートルール。フォールバックとして UNMATCHED または UNKNOWN の場合もあります。
|
backend_target_name |
文字列 | リクエストを処理するために選択されたバックエンドの名前。リクエストと一致する URL マップのパスルールまたはルートルールに基づいて選択されます。 |
backend_target_type | 文字列 | バックエンド ターゲットのタイプ（BACKEND_SERVICE / UNKNOWN）。 |
backend_name |
文字列 | バックエンド インスタンス グループまたは NEG の名前。 |
backend_type |
文字列 | インスタンス グループ、NEG、不明のいずれかのバックエンドのタイプ。 Cloud Logging では、ロギングが無効になっている場合でも、 |
backend_scope |
文字列 |
バックエンドの範囲。ゾーン名またはリージョン名です。backend_name が不明な場合はいつでも、UNKNOWN である可能性があります。 |
backend_scope_type |
文字列 |
バックエンドの範囲（REGION/ZONE）。backend_name が不明な場合はいつでも、UNKNOWN である可能性があります。 |
proxyStatus メッセージ
proxyStatus フィールドにログに記録される文字列は次のとおりです。
| proxyStatus | 意味 | 一般的に記録されるレスポンス コード |
|---|---|---|
destination_unavailable
|
ロードバランサが、バックエンドが使用不可であるとみなしています。たとえば、バックエンドとの通信が最近失敗したか、ヘルスチェックの失敗を示している場合などです。 | 500、503 |
connection_timeout
|
ロードバランサがバックエンドへの接続を開始しようとしてタイムアウトしました。 | 504 |
connection_terminated
|
完全なレスポンスを受信する前に、ロードバランサとバックエンドの接続が終了しました。 | 502、503 |
connection_refused
|
ロードバランサからバックエンドへの接続が拒否されました。 | 502、503 |
connection_limit_reached
|
ロードバランサはバックエンドに対する接続数を制限するように構成されており、この上限を超えています。 | 502、503 |
destination_not_found
|
ロードバランサは、このリクエストに使用する適切なバックエンドを決定できません。たとえば、構成されていない可能性があります。 | 500、404 |
dns_error
|
バックエンド ホスト名の IP アドレスを検出しようとしたときに、ロードバランサで DNS エラーが発生しました。 | 502、503 |
http_response_timeout
|
ロードバランサは、バックエンドからの完全なレスポンスの待機する時間の上限に達しました。 | 504、408 |
http_request_error
|
ロードバランサは、クライアントに代わってクライアント（4xx）レスポンスを生成しています。 | 400、403、405、406、408、411、413、414、415、416、417、または 429 |
proxy_configuration_error
|
ロードバランサの構成に関するエラーが発生しました。 | 500 |
http_protocol_error
|
ロードバランサが、バックエンドとの通信中に HTTP プロトコル エラーを検出しました。 | 502 |
proxy_internal_error
|
ロードバランサで内部エラーが発生しました。 | 500、502 |
proxy_internal_response
|
ロードバランサがバックエンドへの接続を試行せずにレスポンスを生成しました。 | 問題の種類に応じて HTTP ステータス コードが表示されます。たとえば、HTTP ステータス コード 410 は、支払いの滞納が原因でバックエンドが利用できないことを意味します。 |
mTLS クライアント証明書検証のログを表示する
相互 TLS クライアント証明書の検証中に、閉じられた接続についてログに記録されたエラーを表示するには、次の操作を行います。
コンソール
Google Cloud コンソールで、[ログ エクスプローラ] ページに移動します。
[クエリを表示] をクリックして、クエリエディタを有効にします。
または、[クエリ] フィールドに次の内容を貼り付けます。
FORWARDING_RULE_NAMEは、転送ルールの名前に置き換えます。jsonPayload.statusDetails=~"client_cert" jsonPayload.@type="type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry" resource.labels.forwarding_rule_name=FORWARDING_RULE_NAME
[クエリを実行] をクリックします。
モニタリング
内部アプリケーション ロードバランサは、モニタリング データを Monitoring にエクスポートします。
モニタリング指標は次の目的で使用します。
- ロードバランサの構成、使用状況、パフォーマンスの評価
- 問題のトラブルシューティング
- リソースの使用率とユーザー エクスペリエンスの改善
Monitoring の事前定義されたダッシュボードに加えて、カスタム ダッシュボードを作成して、アラートをセットアップし、Monitoring API を使用して指標をクエリできます。
Cloud Monitoring の指標の表示
コンソール
Metrics Explorer を使用してモニタリング対象リソースの指標を表示するには、次の操作を行います。
-
Google Cloud コンソールのナビゲーション パネルで [Monitoring] を選択し、次に [leaderboard Metrics Explorer] を選択します。
- [指標] 要素の [指標を選択] メニューを開いてフィルタバーに「
Internal Application Load Balancer Rule」と入力し、サブメニューを使用して特定のリソースタイプと指標を選択します。- [有効なリソース] メニューで、[Internal Application Load Balancer Rule] を選択します。
- 指標を選択するには、[Active metric categories] メニューと [Active metrics] メニューを使用します。
- [適用] をクリックします。
表示から時系列を削除するには、[フィルタ] 要素を使用します。
時系列を結合するには、[集計] 要素のメニューを使用します。たとえば、ゾーンに基づいて VM の CPU 使用率を表示するには、最初のメニューを [平均] に設定し、2 番目のメニューを [ゾーン] に設定します。
[集計] 要素の最初のメニューが [未集計] に設定されている場合は、すべての時系列が表示されます。[集計] 要素のデフォルト設定は、選択した指標タイプによって決まります。
- 割り当てと、1 日に 1 つのサンプルを報告するその他の指標については、次の操作を行います。
- [表示] ペインで、[ウィジェット タイプ] を [積み上げ棒グラフ] に設定します。
- 期間は少なくとも 1 週間に設定します。
アラート ポリシーを定義する
コンソール
アラート ポリシーを作成して指標の値をモニタリングすると、指標が条件に違反した場合に通知できます。
-
Google Cloud コンソールのナビゲーション パネルで、[Monitoring] を選択してから、[notificationsアラート] を選択します。
- 通知チャンネルを作成せずに通知を受け取る場合は、[EDIT NOTIFICATION CHANNELS] をクリックして、通知チャンネルを追加します。チャンネルを追加したら、[アラート] ページに戻ります。
- [アラート] ページで、[CREATE POLICY] をクリックします。
- 指標を選択するには、[指標を選択] メニューを開き、次の操作を行います。
- メニューを関連するエントリに限定するには、フィルタバーに「
Internal Application Load Balancer Rule」と入力します。結果が表示されない場合は、[Show only active resources & metrics] をオフに切り替えます。 - [リソースの種類] で、[内部アプリケーション ロードバランサのルール] を選択します。
- 指標カテゴリと指標を選択して、[適用] を選択します。
- メニューを関連するエントリに限定するには、フィルタバーに「
- [次へ] をクリックします。
- [Configure alert trigger] ページの設定によって、アラートがトリガーされるタイミングが決まります。条件タイプを選択し、必要に応じてしきい値を指定します。詳細については、指標しきい値のアラート ポリシーを作成するをご覧ください。
- [次へ] をクリックします。
- （省略可）アラート ポリシーに通知を追加するには、[通知チャネル] をクリックします。ダイアログで、メニューから 1 つ以上の通知チャンネルを選択し、[OK] をクリックします。
- （省略可）インシデントの自動クローズ期間を更新します。このフィールドは、指標データがない場合に Monitoring がインシデントを閉じるタイミングを決定します。
- （省略可）[Documentation] をクリックして、通知メッセージに追加する情報を入力します。
- [アラート名] をクリックして、アラート ポリシーの名前を入力します。
- [Create Policy] をクリックします。
Monitoring カスタム ダッシュボードの定義
コンソール
内部アプリケーション ロードバランサの指標の上にカスタム Monitoring ダッシュボードを作成できます。
Google Cloud コンソールで [Monitoring] ページに移動します。
[ダッシュボード] > [CREATE DASHBOARD] を選択します。
[Add Chart] をクリックします。
グラフにタイトルを付けます。
指標とフィルタを選択します。指標のリソースタイプは、Internal HTTP/S Load Balancer です。
[保存] をクリックします。
指標報告の頻度と保持
ロードバランサの指標は、1 分単位のバッチで Monitoring にエクスポートされます。モニタリング データは 6 週間保持されます。ダッシュボードでは、1H（1 時間）、6H（6 時間）、1D（1 日）、1W（1 週間）、6W（6 週間）のデフォルト間隔でデータ分析の結果を確認できます。また、6 週間から 1 分までの間隔を任意に指定して手動で分析を行うこともできます。
内部アプリケーション ロードバランサのモニタリング指標
内部アプリケーション ロードバランサの次の指標は Monitoring に報告されます。
| 指標 | FQDN | 説明 |
|---|---|---|
| リクエスト数 | loadbalancing.googleapis.com/https/internal/request_count |
内部アプリケーション ロードバランサによって処理されるリクエストの数。 |
| リクエスト バイト数 | loadbalancing.googleapis.com/https/internal/request_bytes |
クライアントから内部アプリケーション ロードバランサへのリクエストとして送信されたバイト数。 |
| レスポンス バイト数 | loadbalancing.googleapis.com/https/internal/response_bytes |
内部 HTTP(S) ロードバランサからクライアントへのレスポンスとして送信されたバイト数。 |
| 総レイテンシ | loadbalancing.googleapis.com/https/internal/total_latencies |
レイテンシの分布（ミリ秒単位）。リクエストの最初のバイトがプロキシで受信された時点からレスポンスの最後のバイトがプロキシから送信された時点までのレイテンシ。 |
| バックエンド レイテンシ | loadbalancing.googleapis.com/https/internal/backend_latencies |
レイテンシの分布（ミリ秒単位）。プロキシからバックエンドにリクエストの最初のバイトが送信された時点から、バックエンドからのレスポンスの最後のバイトがプロキシで受信された時点までのレイテンシ。 |
内部アプリケーション ロードバランサ指標のディメンションのフィルタ
内部アプリケーション ロードバランサごとに指標が集計されます。集計された指標は、次のディメンション（*）でフィルタできます。
| プロパティ | 説明 |
|---|---|
| BACKEND_SCOPE | クライアント リクエストを処理したバックエンド グループの Google Cloud ゾーンまたはリージョン。バックエンド グループが割り当てられていない場合は、特殊文字列が返されます。例: us-central1-a、europe-west1-b、asia-east1、UNKNOWN。 |
| PROXY_REGION | 内部アプリケーション ロードバランサ、クライアント、バックエンドのリージョン。例: us-central1、europe-west1、asia-east1。 |
| バックエンド | クライアント リクエストを処理したバックエンド インスタンス グループまたは NEG の名前。 |
| BACKEND_TARGET | クライアント リクエストを処理したバックエンド サービスの名前。 |
| MATCHED_URL_RULE | クライアント HTTP(S) リクエストのプレフィックスに一致する URL マップ パスルールまたはルートルール（最大 50 文字）。 |
Response code class fraction 指標はロードバランサ全体でサポートされています。これ以上の粒度はサポートされません。
次のステップ
- 内部アプリケーション ロードバランサのコンセプトについて理解する。
- 内部アプリケーション ロードバランサを作成する。
- ロードバランサで使用できる DNS 名オプションについては、内部ロード バランシングと DNS 名をご覧ください。