Dataflow のターンキー アラート

Cloud Monitoring でポリシーを手動で構成せずに、ストリーミング パイプラインの健全性とリソース消費量をモニタリングするには、Dataflow でターンキー アラートを有効にします。ターンキー アラートは、ジョブの起動時に有効にできる、推奨されるアラート ポリシーの事前構成済みスイートを提供します。

この機能を使用すると、次のことができます。

  • 即座に可視化: 手動設定なしで、バックログ処理時間や vCPU の増加など、重要なストリーミング指標を自動的に追跡できます。
  • モニタリングの標準化: 新しいワークロードと既存のワークロードの両方に、ベースライン アラート ポリシーを迅速に適用できます。
  • アラートのカスタマイズ: デフォルトのアラートしきい値を調整したり、個々のポリシーを無効にしたり、独自のカスタム アラート ポリシーをスイートに追加したりできます。

これらのデフォルト ポリシーは、Cloud Monitoring でいつでもカスタマイズできます。また、独自のカスタム アラート ポリシーをターンキー アラート スイートに統合することもできます。

前提条件

ターンキー アラートを使用するには、プロジェクトが次の要件を満たしている必要があります。

  1. 通知チャンネル: 少なくとも 1 つの通知チャンネル(メール、Slack、PagerDuty など)が構成されている必要があります。アラートが適切な関係者に届くように、エッセンシャル コンタクトを構成することをおすすめします。この要件は、Dataflow サービスによって適用されません。詳細については、通知チャンネルを作成して管理するをご覧ください。

  2. 権限: Dataflow サービス アカウント(P4SA)には、これらのポリシーを作成して管理するための特定の IAM 権限が必要です。

    • monitoring.alertPolicies.get
    • monitoring.alertPolicies.list
    • monitoring.alertPolicies.create
    • monitoring.alertPolicies.update
    • monitoring.alertPolicies.delete

    新しいプロジェクトの場合、これらの権限は自動的に追加されます。既存のプロジェクトの場合は、P4SA アカウントでこれらの権限を手動で設定する必要があります。

P4SA 権限を更新する

Dataflow サービス エージェント(P4SA、プロダクトごと、プロジェクトごとのサービス アカウントとも呼ばれます)は、Dataflow API を有効にすると自動的に作成されるマネージド サービス アカウントです。メールアドレスの形式は次のとおりです。

service-PROJECT_NUMBER@dataflow-service-producer-prod.

P4SA を更新するには、resourcemanager.projects.setIamPolicy 権限、またはプロジェクトの IAM 管理者(roles/resourcemanager.projectIamAdmin)など、この権限を含むロールが必要です。

コンソールを使用して必要なロールを付与する手順は次のとおりです。 Google Cloud

  1. コンソールで、[IAM] ページに移動します。 Google Cloud

    [IAM] に移動

  2. プロジェクトを選択します。

  3. [Google 提供のロール付与を含める] チェックボックスをオンにします。

  4. プリンシパルのリストで、Dataflow サービス エージェント(service-PROJECT_NUMBER@dataflow-service-producer-prod. または Cloud Dataflow Service Agent ロール)の行を見つけます。

  5. その行の [**プリンシパルを編集**] をクリックします。

  6. In the [**権限の編集**] ペインで、 [**別のロールを追加**] をクリックします。

  7. [ロールを選択] リストで、[モニタリング編集者](roles/monitoring.editor)を選択します。

  8. [保存] をクリックします。権限の更新が反映されるまでに数分かかることがあります。

ターンキー アラートを有効にする

gcloud CLI を使用して、ジョブをターンキー アラートに登録できます。

gcloud CLI を使用してアラートを有効にする

ジョブの送信時に次のいずれかのフラグを追加して、この機能を有効または無効にします。

  • --enable-turnkey-alerts
  • --no-enable-turnkey-alerts

サービス アカウントに必要な権限がない場合、CLI はリクエストを拒否し、不足している権限を表示します。詳しくは事前準備についての記事をご覧ください。

ターンキー アラートの設定は、ジョブの更新後も保持されます。ジョブを更新すると、以前のターンキー アラートの設定が保持されるため、設定を変更する場合を除き、--enable-turnkey-alerts フラグまたは --no-enable-turnkey-alerts フラグを再度指定する必要はありません。

デフォルト ポリシー スイート

ターンキー アラートには、一般的なストリーミング ワークロード向けに設計された 2 つの主要なポリシーが含まれています。これらのポリシーは、処理時間やリソース使用率などのリアルタイム KPI に重点を置いています。Google 提供のポリシーには、識別用に Default Policy: という接頭辞が付いています。ただし、サービスではラベルがプライマリ識別子として使用されます。

デフォルト ポリシー スイートのすべてのポリシーに自動的に登録されます。必要に応じて、Cloud Monitoring アラートで特定のデフォルト ポリシーを無効にできます。

ポリシー名 ベース指標 デフォルトのしきい値 根拠
デフォルト ポリシー: 推定バックログ job/estimated_backlog_processing_time 30 分 現在のバックログをクリアするために必要な時間を推定します。バックログが 30 分を超えている場合、ジョブの進行が困難であることを示します。
デフォルト ポリシー: vCPU 増加ポリシー job/current_num_vcpus 1 時間あたりの平均 vCPU 使用量が 7 日間の平均と比較して 5 倍以上増加 vCPU 数を相対的に変更して、予期しないジョブ費用を把握できるようにします。

ポリシーのライフサイクル

  • ベータ版ポリシー: これらのポリシーの名前には BETA という接頭辞が付いています。しきい値が調整されると、変更または削除される可能性があります。
  • GA ポリシー: ポリシーが安定していると判断されると、BETA 接頭辞が削除されます。

アラートをカスタマイズして管理する

ターンキー アラートは出発点として機能します。特定のビジネス要件に合わせてカスタマイズすることをおすすめします。

  1. コンソールで、[Cloud Monitoring] > [アラート] に移動します。 Google Cloud
  2. ポリシー(デフォルト ポリシー: 推定バックログ など)を見つけます。
  3. しきい値を希望の値に編集します。

カスタム ポリシーを作成する

goog-turnkey-alerts ラベルを追加することで、任意の Cloud Monitoring アラート ポリシーをターンキー アラート スイートに追加できます。これにより、デフォルト スイートとともに、ビジネス固有のカスタムルールを管理できます。

アラート ポリシーを無効または削除する

Monitoring を使用して、特定のデフォルト ポリシーを無効または削除できます。ポリシーを無効にすると、Monitoring はポリシー条件の評価を停止し、新しいインシデントは作成されませんが、ポリシー構成は保持されます。ポリシーを削除すると、プロジェクトから完全に削除されます。ポリシーのライフサイクルの管理の詳細については、アラート ポリシーを管理する無効なアラート ポリシーをご覧ください。

トラブルシューティング

問題 解決策
PERMISSION_DENIED Dataflow P4SA に、monitoring.alertPolicies.* 権限が 前提条件に記載されていることを確認します。P4SA にこれらのロールがない場合でも、パイプラインは正常に起動しますが、コマンドライン出力とジョブログに PERMISSION_DENIED エラーが表示され、デフォルトのアラートを作成できなかったことが示されます。
アラートを受信しない インシデントを確認して、アラート条件が満たされたかどうかを判断します。アラートの発生とインシデントのタイムラインは Monitoring で確認できます(インシデントとイベントを表示するをご覧ください)。
ポリシーの重複 通常、複数のポリシーが goog-turnkey-alerts ラベルと同じ指標構成を共有している場合に発生します。Dataflow は、名前が完全に一致するのではなく、ラベルと指標が重複しているかどうかを確認します。ポリシーを確認し、冗長な構成からラベルを削除します。