ログベースの指標のトラブルシューティング

このページには、Cloud Logging でログベースの指標を使用する際の一般的なシナリオのトラブルシューティング情報を掲載しています。

指標を表示または作成できない

ログベースの指標は、単一の Google Cloud プロジェクトまたは Google Cloud プロジェクト内の Logging バケットにのみ適用されます。請求先アカウントや組織などの他の Google Cloud リソースには、ログベースの指標を作成できません。ログベースの指標は、指標が受信された Google Cloud プロジェクトまたはバケットのログに対してのみ計算されます。

指標を作成するには、適切な Identity and Access Management 権限が必要です。詳細については、IAM によるアクセス制御: ログベースの指標をご覧ください。

指標のログデータがない

ログベースの指標のデータが欠落している理由として、いくつかの可能性が考えられます。

  • 新しいログエントリが指標のフィルタと一致していない。ログベースの指標は、指標が作成された後に受信した、一致するログエントリからデータを取得します。Logging では、以前のログエントリからの指標はバックフィルされません。

  • 新しいログエントリに正しいフィールドが含まれていないか、データが適切な形式で分布指標から抽出されないことがあります。フィールド名と正規表現が正しいことを確認してください。

  • 指標のカウントが遅れている。カウントできるログエントリがログ エクスプローラに表示されている場合でも、Cloud Monitoring でログベースの指標が更新されるまでに最大 10 分を要する場合があります。

  • タイムスタンプの時間との差が大きすぎるため、表示されているカウントが遅れているか、まったくカウントされていない可能性があります。ログエントリが過去 24 時間を超える期間または未来に 10 分を超える期間ずれて Cloud Logging に受信された場合、ログエントリはログベースの指標にカウントされません。

    システムログ ベースの指標 logging.googleapis.com/logs_based_metrics_error_count の各ログに対して、遅れて到着するエントリの数が記録されます。

    例: ログベースの指標に一致するログエントリが遅れて到着したとします。それは、timestamp が 2020 年 2 月 20 日午後 2 時 30 分で、receivedTimestamp が 2020 年 2 月 21 日午後 2 時 45 分です。このエントリはログベースの指標にカウントされません。

  • ログベースの指標が、指標がカウントする可能性があるログエントリの到着後に作成されました。ログベースの指標は、ログバケットに保存されているログエントリを評価します。これらの指標は Logging に保存されているログエントリを評価しません。

Cloud Monitoring でリソースタイプが「未定義」です

一部の Cloud Logging モニタリング対象リソースのタイプは、Cloud Monitoring モニタリング対象リソースのタイプに直接マッピングされません。たとえば、ログベースの指標からアラート ポリシーまたはグラフのいずれかを初めて作成する際、リソースタイプが「未定義」になる場合があります。

リソースタイプが未定義です。

モニタリング対象リソースのタイプは、global または Cloud Monitoring の別のモニタリング対象リソースのタイプのいずれかにマッピングされます。Logging 専用のリソースのマッピングを参照して、どのモニタリング対象リソースのタイプを選択すべきか判断します。

インシデントが作成されていない、または誤検出である

アラート ポリシーの配置期間が短すぎるため、誤検出のインシデントまたは、Monitoring がログベースの指標からインシデントを作成しない状況が発生する可能性があります。次のようなシナリオでは、誤検出が発生する場合があります。

  • アラート ポリシーで未満ロジックを使用する場合。
  • アラート ポリシーが分布指標のパーセンタイル条件に基づく場合。

ログエントリが Logging に遅れて送信される可能性があるため、誤検出のインシデントが発生します。たとえば、ログフィールド timestamp と receiveTimestamp には分単位の差分を指定できます。また、Logging がログバケットにログを保存する場合、ログエントリが生成されてから Logging が受信するまでに、固有の遅延があります。つまり、ログエントリが生成されてから少し後の時点まで、Logging は特定のログエントリの合計数を持たないことがあります。これが、未満ロジックを使用する、または配布指標のパーセンタイル条件に基づくアラート ポリシーが「まだすべてのログエントリは考慮されていません」の誤検出アラートを生成する理由です。

ただし、ログベースの指標は常に結果整合性を保持しています。ログベースの指標と一致するログエントリは、ログの receiveTimestamp よりも大幅に古い、または新しい timestamp で Logging に送信できるため、ログベースの指標は結果整合性を保持します。

つまり、同じタイムスタンプを持つ既存のログエントリが Logging で受信された後、ログベースの指標で古いタイムスタンプを持つログエントリを受信できます。したがって、指標値を更新する必要があります。

オンタイムのデータであっても通知を正確なままにするには、ログベースの指標のアラート ポリシーで、配置期間を 2 分以上にした条件を使用する必要があります。Logging に送信されるログエントリの遅延時間を分単位で指定する場合、適時制と精度を調整するため、配置期間は 10 分が推奨されます。

指標の時系列が多すぎる

指標の時系列の数は、ラベル値の異なる組み合わせの数によって異なります。時系列の数は、指標のカーディナリティと呼ばれ、30,000 以下にする必要があります。

ラベル値のすべての組み合わせに対して時系列を生成できるため、値の数が多い 1 つ以上のラベルがある場合は、30,000 時系列を超えることは珍しくありません。高いカーディナリティの指標は避けます。

指標のカーディナリティが増加すると、指標が抑制され、指標にデータポイントが書き込まれない場合があります。グラフが処理する必要がある時系列が多数あるため、指標が表示されるグラフの読み込みが遅くなることがあります。また、時系列データを照会する API 呼び出しの費用が発生することもあります。詳細については、Cloud Monitoring の費用をご覧ください。

カーディナリティの高い指標を作成しないようにするには、次のことを行います。

  • ラベル フィールドとエクストラクタの正規表現が、限定されたカーディナリティを持つ値と一致することを確認します。

  • 無制限に変更可能なテキスト メッセージをラベル値として抽出しないようにします。

  • 無制限のカーディナリティを持つ数値を抽出しないようにします。

  • カーディナリティがわかっているラベルからのみ値を抽出します（たとえば、値の範囲が決まっているステータス コードなど）。

次のシステムログ ベースの指標は、ラベルの追加や削除が指標のカーディナリティに及ぼす影響を測定する際に有用です。

これらの指標を確認すると、指標名で結果を絞り込むことができます。詳細については、指標の選択: フィルタリングをご覧ください。

指標名が無効

カウンタ指標または分布指標を作成するときは、Google Cloud プロジェクトのログベースの指標で一意の指標名を選択します。

指標名の文字列は 100 文字を超えてはならず、次の文字のみを含めることができます。

  • A～Z
  • a～z
  • 0～9

  • 特殊文字 _-.,+!*',()%\/.

    スラッシュ文字（/）は指標名の部分の階層を示し、名前の先頭の文字にすることはできません。

ラベル値が切り捨てられる

ユーザー定義のラベルの値は、1,024 バイトを超えることはできません。

カスタムログ指標を削除できない

Google Cloud コンソールを使用してカスタム ログベースの指標を削除しようとしました。削除リクエストが失敗し、削除ダイアログにエラー メッセージ There is an unknown error while executing this operation が表示されます。

この問題を解決するには、次のことを試してください。

  • Google Cloud コンソールで [ログベースの指標] ページを更新します。内部のタイミングの問題が原因で、エラー メッセージが表示される場合があります。

  • ログベースの指標をモニタリングするアラート ポリシーを特定して削除します。 ログベースの指標がアラート ポリシーによってモニタリングされていないことを確認したら、ログベースの指標を削除します。アラート ポリシーによってモニタリングされるログベースの指標は削除できません。