概要

このラボでは、Google Cloud Pub/Sub 経由で取り込み可能なトラフィック センサーのシミュレーション データから、Dataflow を使用してトラフィック イベントを収集し、実際に利用できる平均値を生成します。また、後で分析するために未加工データを BigQuery に保存します。この過程で、Dataflow パイプラインを起動、モニタリング、最適化する方法について学習します。

注: このドキュメントの作成時点では、Dataflow Python SDK でストリーミング パイプラインを使用することはできません。そのため、ストリーミングのラボでは Java を使用しています。

目標

このラボでは、次のタスクを行います。

• Dataflow を起動して Dataflow ジョブを実行する
• データ要素が Dataflow パイプラインの変換でどのように処理されるかを理解する
• Dataflow を Pub/Sub と BigQuery に接続する
• Dataflow の自動スケーリングによってコンピューティング リソースが調整され、入力データが最適に処理される仕組みを確認して理解する
• Dataflow によって作成されるログ情報の保存場所を確認する
• Cloud Monitoring で各種指標を確認し、アラートとダッシュボードを作成する

設定

各ラボでは、新しい Google Cloud プロジェクトとリソースセットを一定時間無料で利用できます。

1. Qwiklabs にシークレット ウィンドウでログインします。

2. ラボのアクセス時間（例: 1:15:00）に注意し、時間内に完了できるようにしてください。
   一時停止機能はありません。必要な場合はやり直せますが、最初からになります。

3. 準備ができたら、[ラボを開始] をクリックします。

4. ラボの認証情報（ユーザー名とパスワード）をメモしておきます。この情報は、Google Cloud Console にログインする際に使用します。

5. [Google Console を開く] をクリックします。

6. [別のアカウントを使用] をクリックし、このラボの認証情報をコピーしてプロンプトに貼り付けます。
   他の認証情報を使用すると、エラーが発生したり、料金の請求が発生したりします。

7. 利用規約に同意し、再設定用のリソースページをスキップします。

プロジェクトの権限を確認する

Google Cloud で作業を開始する前に、Identity and Access Management（IAM）内で適切な権限がプロジェクトに付与されていることを確認する必要があります。

1. Google Cloud コンソールのナビゲーション メニュー（）で、[IAM と管理] > [IAM] を選択します。

2. Compute Engine のデフォルトのサービス アカウント {project-number}-compute@developer.gserviceaccount.com が存在し、編集者のロールが割り当てられていることを確認します。アカウントの接頭辞はプロジェクト番号で、ナビゲーション メニュー > [Cloud の概要] > [ダッシュボード] から確認できます。

注: アカウントが IAM に存在しない場合やアカウントに編集者のロールがない場合は、以下の手順に沿って必要なロールを割り当てます。

1. Google Cloud コンソールのナビゲーション メニューで、[Cloud の概要] > [ダッシュボード] をクリックします。
2. プロジェクト番号（例: 729328892908）をコピーします。
3. ナビゲーション メニューで、[IAM と管理] > [IAM] を選択します。
4. ロールの表の上部で、[プリンシパル別に表示] の下にある [アクセス権を付与] をクリックします。
5. [新しいプリンシパル] に次のように入力します。

{project-number}-compute@developer.gserviceaccount.com

6. {project-number} はプロジェクト番号に置き換えてください。
7. [ロール] で、[Project]（または [基本]）> [編集者] を選択します。
8. [保存] をクリックします。

タスク 1. 準備

トレーニング用 VM からセンサー シミュレータを実行します。ラボ 1 では、Pub/Sub コンポーネントを手動でセットアップしました。このラボでは、それらのプロセスの一部が自動化されています。

SSH ターミナルを開いてトレーニング用 VM に接続する

1. コンソールのナビゲーション メニュー（）で、[Compute Engine] > [VM インスタンス] をクリックします。

2. training-vm という名前のインスタンスがある行を確認します。

3. 右端の [接続] の下にある [SSH] をクリックしてターミナル ウィンドウを開きます。

4. このラボでは、training-vm 上で CLI コマンドを入力します。

初期化が完了していることを確認する

training-vm によってバックグラウンドでソフトウェアのインストールが行われます。

• 新しいディレクトリの内容を調べて設定が完了していることを確認します。

ls /training

list（ls）コマンドの出力結果が次の画像のように表示された場合、設定は完了しています。完全なリストが表示されない場合は、数分待ってからもう一度実行してください。

注: バックグラウンドのすべての処理が完了するまで、2～3 分かかることがあります。

コード リポジトリをダウンロードする

• このラボで使用するコード リポジトリを更新します。

git clone https://github.com/GoogleCloudPlatform/training-data-analyst

環境変数を設定する

• training-vm の SSH ターミナルで次のように入力します。

source /training/project_env.sh

このスクリプトにより、DEVSHELL_PROJECT_ID 環境変数と BUCKET 環境変数が設定されます。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 コード リポジトリをダウンロードする

タスク 2. BigQuery データセットと Cloud Storage バケットの作成

後で作成される Dataflow パイプラインによって、BigQuery データセットのテーブルに書き込みが行われます。

BigQuery コンソールを開く

1. Google Cloud Console で、ナビゲーション メニュー > [BigQuery] を選択します。

[Cloud Console の BigQuery へようこそ] メッセージ ボックスが開きます。このメッセージ ボックスにはクイックスタート ガイドへのリンクと、UI の更新情報が表示されます。

2. [完了] をクリックします。

BigQuery データセットを作成する

1. データセットを作成するには、プロジェクト ID の横にある [アクションを表示] アイコンをクリックし、[データセットを作成] を選択します。

2. 次に、[データセット ID] の名前を「demos」にします。他のオプションはすべてデフォルト値のままにして [データセットを作成] をクリックします。

Cloud Storage バケットを確認する

プロジェクト ID と同じ名前のバケットがすでに存在します。

1. コンソールのナビゲーション メニュー（）で、[Cloud Storage] > [バケット] をクリックします。

2. 次の値を確認します。

プロパティ	値 （値を入力、または指定されたオプションを選択）
名前
Default storage class	Regional
場所

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 BigQuery データセットを作成する

タスク 3. Pub/Sub へのトラフィック センサーデータのシミュレート

• training-vm の SSH ターミナルでセンサー シミュレータを起動します。次のスクリプトは、CSV ファイルからサンプルデータを読み取って Pub/Sub にパブリッシュします。

/training/sensor_magic.sh

このコマンドを実行すると、1 時間分のデータが 1 分で送信されます。現在のターミナルでスクリプトの実行を継続します。

SSH ターミナルをもう 1 つ開いてトレーニング用 VM に接続する

1. training-vm の SSH ターミナルの右上にある歯車アイコン（）をクリックし、プルダウン メニューから [training-vm への新しい接続] を選択します。新しいターミナル ウィンドウが開きます。

2. 新しいターミナル セッションには、必要な環境変数が設定されていません。そこで、次のコマンドを実行して環境変数を設定します。

3. training-vm の新しい SSH ターミナルで次のように入力します。

source /training/project_env.sh

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 Pub/Sub へのトラフィック センサーデータのシミュレート

タスク 4. Dataflow パイプラインの起動

このプロジェクトで Google Cloud Dataflow API が有効になっていることを確認する

1. 適切な API と権限を設定するために、Cloud Shell で以下のコードブロックを実行します。

gcloud services disable dataflow.googleapis.com --force gcloud services enable dataflow.googleapis.com

2. training-vm の 2 つ目の SSH ターミナルに戻り、このラボのディレクトリに移動します。

cd ~/training-data-analyst/courses/streaming/process/sandiego

3. Dataflow パイプラインを作成および実行するスクリプトの内容を確認します。

cat run_oncloud.sh

4. 次の URL をコピーしてブラウザの新しいタブに貼り付けると、GitHub にあるソースコードが表示されます。

https://github.com/GoogleCloudPlatform/training-data-analyst/blob/master/courses/streaming/process/sandiego/run_oncloud.sh

5. このスクリプトでは、project id、bucket name、classname の 3 つの引数は必須です。

4 つ目の options はオプションの引数です。options 引数については、このラボで後述します。

project id
bucket name
classname	<集計を実行する Java ファイル>
options	<オプション>

classname は、4 つの Java ファイルから選択できます。それぞれが Pub/Sub からトラフィック データを読み取り、異なる集計と計算を実行します。

6. Java のディレクトリに移動し、AverageSpeeds.java というソースファイルの内容を確認します。

cd ~/training-data-analyst/courses/streaming/process/sandiego/src/main/java/com/google/cloud/training/dataanalyst/sandiego cat AverageSpeeds.java

このスクリプトは何を実行するのでしょうか。

ファイルを閉じて続行します。アプリケーションの実行中にこのソースコードを簡単に参照できるように、ブラウザの新しいタブを開いて、GitHub の AverageSpeeds.java を表示します。

7. 次の URL をコピーしてブラウザタブに貼り付けると、GitHub にあるソースコードが表示されます。

https://github.com/GoogleCloudPlatform/training-data-analyst/blob/master/courses/streaming/process/sandiego/src/main/java/com/google/cloud/training/dataanalyst/sandiego/AverageSpeeds.java

ブラウザでこのタブを開いたままにしておきます。このラボの後のステップでソースコードを参照します。

8. training-vm の SSH ターミナルに戻ります。次のコマンドを実行して、Dataflow パイプラインによって Pub/Sub から読み取り、BigQuery に書き込みます。

cd ~/training-data-analyst/courses/streaming/process/sandiego export REGION={{{project_0.startup_script.gcp_region|Lab GCP Region}}} ./run_oncloud.sh $DEVSHELL_PROJECT_ID $BUCKET AverageSpeeds

このスクリプトでは、Maven を使用して Java で Dataflow ストリーミング パイプラインを構築しています。

正常に完了した例:

[INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 45.542 s [INFO] Finished at: 2018-06-08T16:51:30+00:00 [INFO] Final Memory: 56M/216M [INFO] ------------------------------------------------------------------------

タスク 5. パイプラインの使用

この Dataflow パイプラインは、Pub/Sub トピックからメッセージを読み取り、入力メッセージの JSON を解析し、1 つの主出力を生成して BigQuery に書き込みます。

1. コンソールのブラウザタブに戻り、ナビゲーション メニュー（）で [Dataflow] をクリックし、進行状況をモニタリングするジョブをクリックします。

例:

注: Dataflow ジョブが失敗した場合は、コマンド ./run_oncloud.sh $DEVSHELL_PROJECT_ID $BUCKET AverageSpeeds を再度実行します。

2. パイプラインを実行したら、ナビゲーション メニュー（）で [Pub/Sub] > [トピック] をクリックします。

3. [トピックの名前] の行で sandiego というトピックを探します。

4. ナビゲーション メニュー（）に戻って [Dataflow] をクリックし、ジョブをクリックします。

5. ブラウザの GitHub を表示しているタブのコード（AverageSpeeds.java）と、Dataflow ジョブのページに表示されているパイプラインのグラフを比較します。

6. グラフで [GetMessages] のパイプライン ステップを見つけ、AverageSpeeds.java ファイルでそれに対応するコードを特定します。これは、Pub/Sub トピックから読み取りを行うパイプライン ステップで、読み取られた Pub/Sub メッセージに対応する文字列のコレクションを作成します。

• 作成されたサブスクリプションは表示されていますか。
• コードでは、どのように Pub/Sub からメッセージを pull していますか。

7. グラフとコードで [Time Window] のパイプライン ステップを確認します。このパイプライン ステップでは、パイプライン パラメータで指定された期間のウィンドウ（この場合はスライディング ウィンドウ）を作成します。このウィンドウは、前のステップからウィンドウ終了までのトラフィック データを蓄積し、以降のステップにそれを渡します。そこでデータがさらに変換されます。

• ウィンドウの間隔はどれくらいですか。
• 新しいウィンドウはどれくらいの頻度で作成されていますか。

8. グラフで [BySensor] と [AvgBySensor] のパイプライン ステップを見つけ、AverageSpeeds.java ファイルでそれに対応するコード スニペットを特定します。この [BySensor] ではウィンドウ内のすべてのイベントがセンサー ID ごとにグループ化され、[AvgBySensor] ではそれらの各グループの平均速度が計算されます。

9. グラフとコードで [ToBQRow] のパイプライン ステップを確認します。このステップでは、前のステップで計算された平均とレーン情報を含む「行」の作成のみを行います。

注: [ToBQRow] のステップでは、その他のアクションを行うこともできます。たとえば、算出された平均と事前定義済みのしきい値を比べて、比較結果を Cloud Logging に記録することができます。

10. パイプライン グラフとソースコードの両方で [BigQueryIO.Write] を確認します。このステップでは、パイプラインの行を BigQuery テーブルに書き込みます。書き込み処理として [WriteDisposition.WRITE_APPEND] を選択しているため、新しいレコードがテーブルの末尾に追加されます。

11. BigQuery ウェブ UI のタブに戻り、ブラウザの画面を更新します。

12. プロジェクト名と作成した demos データセットを確認します。データセット名 demos の左側にある小さい矢印が有効になり、それをクリックすると average_speeds テーブルが表示されます。

13. average_speeds テーブルが BigQuery に表示されるまでには数分かかります。

例:

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 Dataflow パイプラインの起動

タスク 6. スループット率の特定

Dataflow パイプラインをモニタリングして改善する際は、パイプラインで 1 秒あたりに処理される要素の数、システムラグ、その時点で処理済みのデータ要素数を特定するのが一般的です。このアクティビティでは、処理された要素と時間に関する情報を Cloud コンソールで確認していきます。

1. コンソールのブラウザタブに戻り、ナビゲーション メニュー（）で [Dataflow] をクリックし、進行状況をモニタリングするジョブをクリックします（パイプライン名に自分のユーザー名が表示されています）。

2. グラフで [GetMessages] パイプライン ノードを選択し、右側でステップの指標を確認します。

• [System Lag] はストリーミング パイプラインの重要な指標です。これは、データ要素が変換ステップの入力に「到着」した後、処理待ち状態になっている時間を表します。
• 出力コレクションの [Elements Added] 指標は、このステップで出力されたデータ要素の数を表しています（パイプラインの [Read PubSub Msg] のステップの場合は、Pub/Sub IO コネクタによってトピックから読み取られた Pub/Sub メッセージ数も表しています）。

3. グラフの [Time Window] ノードを選択します。[Time Window] ステップの入力コレクションの [Elements Added] 指標が、前のステップである [GetMessages] の出力コレクションの [Elements Added] 指標と一致することを確認します。

タスク 7. BigQuery 出力の確認

1. BigQuery ウェブ UI に戻ります。

注: ストリーミング データとテーブルは、すぐに表示されないことがあります。また、ストリーミング バッファ内にあるデータはプレビューできないことがあります。

[プレビュー] をクリックすると、「This table has records in the streaming buffer that may not be visible in the preview.」というメッセージが表示されますが、クエリを実行してデータを確認することは可能です。

2. [クエリエディタ] ウィンドウで、以下のクエリを入力します（またはコピーして貼り付けます）。このクエリを使用して、Dataflow ジョブからの出力を確認します。[実行] をクリックします。

SELECT * FROM `demos.average_speeds` ORDER BY timestamp DESC LIMIT 100

3. 次の SQL を実行して、テーブルに対して最後に行われた更新を確認します。

SELECT MAX(timestamp) FROM `demos.average_speeds`

4. 次に、BigQuery のタイムトラベル機能を使用して、過去のある時点でのテーブルの状態を参照します。

次のクエリは、10 分前に存在していた average_speeds テーブルから一部の行を返します。

クエリで行をリクエストしても、指定した過去の時点でテーブルが存在しなかった場合は、次のエラー メッセージが表示されます。

Invalid snapshot time 1633691170651 for Table PROJECT:DATASET.TABLE__

このエラーが表示された場合は、時間の値を小さくしてタイムトラベルの範囲を狭くしてください。

SELECT * FROM `demos.average_speeds` FOR SYSTEM_TIME AS OF TIMESTAMP_SUB(CURRENT_TIMESTAMP, INTERVAL 10 MINUTE) ORDER BY timestamp DESC LIMIT 100

タスク 8. 自動スケーリングの確認と理解

着信 Pub/Sub メッセージのバックログを処理するために、Dataflow でワーカー数がどのようにスケールされるかを確認します。

1. コンソールのブラウザタブに戻り、ナビゲーション メニュー（）で [Dataflow] をクリックし、パイプライン ジョブをクリックします。

2. 右側の [ジョブの指標] パネルにある [自動スケーリング] セクションで、Pub/Sub トピックのメッセージを処理するために使用されているワーカー数を確認します。

3. [その他の履歴] をクリックし、パイプライン実行中のさまざまな時点で使用されたワーカー数を確認します。

4. ラボの始めに開始されたトラフィック センサー シミュレータからのデータによって、1 秒あたり何百ものメッセージが Pub/Sub トピックに作成されます。そのため、Dataflow はパイプラインのシステムラグを最適なレベルに保つ目的でワーカー数を増やします。

5. [その他の履歴] をクリックします。[ワーカープール] で、Dataflow がワーカー数をどのように変更したかを確認できます。[ステータス] 列には変更の理由が示されています。

タスク 9. センサーデータのシミュレーション スクリプトの更新

注: トレーニング ラボ環境には、割り当て上限があります。センサーデータのシミュレーション スクリプトの実行時間が長すぎて割り当て上限を超過すると、セッションの認証が停止されます。

1. センサーデータのスクリプトを実行している training-vm の SSH ターミナルに戻ります。

2. [INFO: Publishing] というメッセージが表示される場合は、スクリプトがまだ実行されています。Ctrl+C キーを押してスクリプトを停止してから、スクリプトを再び開始するコマンドを実行します。

cd ~/training-data-analyst/courses/streaming/publish ./send_sensor_data.py --speedFactor=60 --project $DEVSHELL_PROJECT_ID 以下のステップ 3～8 は、Ctrl+C キーでスクリプトを停止できない場合にのみ必要となります。スクリプトが割り当て上限を超えている場合は、[Credentials could not be refreshed] というエラー メッセージが繰り返し表示され、Ctrl+C キーでスクリプトを停止できないことがあります。この場合は、SSH ターミナルを終了して、以下のステップ 3～8 を行ってください。

3. 新しい SSH ターミナルを開きます。新しいセッションでは割り当ては未使用の状態です。

4. Cloud コンソールのナビゲーション メニュー（）で、[Compute Engine] > [VM インスタンス] の順にクリックします。

5. training-vm という名前のインスタンスがある行を確認します。

6. 右端の [接続] の下で [SSH] をクリックして、新しいターミナル ウィンドウを開きます。

7. training-vm の SSH ターミナルで、次のコマンドを入力して環境変数を作成します。

source /training/project_env.sh

8. 次のコマンドを使用して、新しいセンサー シミュレータを開始します。

cd ~/training-data-analyst/courses/streaming/publish ./send_sensor_data.py --speedFactor=60 --project $DEVSHELL_PROJECT_ID

タスク 10. Cloud Monitoring のインテグレーション

Cloud Monitoring を Dataflow に統合すると、ユーザーは System Lag（ストリーミング ジョブの場合）、Job Status（失敗または成功）、Element Counts、User Counters などの Dataflow ジョブ指標に Cloud Monitoring 内からアクセスできるようになります。

統合により利用できる Cloud Monitoring の機能

• Dataflow 指標の確認: 利用可能な Dataflow パイプライン指標を閲覧して、グラフで可視化します。

下記は、一般的な Dataflow 指標の一部です。

指標	機能
Job status	ジョブ ステータス（失敗または成功）。30 秒ごと、および更新のたびに列挙型としてレポートされます。
Elapsed time	ジョブの経過時間（秒単位で計測）。30 秒ごとにレポートされます。
System lag	パイプライン全体での最大ラグ。数秒でレポートされます。
Current vCPU count	ジョブで現在使用されている仮想 CPU の数。値が変化すると更新されます。
Estimated byte count	PCollection ごとの処理バイト数。

• Monitoring ダッシュボードでの Dataflow 指標のグラフ化: ダッシュボードを作成し、Dataflow 指標を時系列グラフにします。
• アラートの構成: ジョブまたはリソース グループ レベルの指標のしきい値を定義し、これらの指標が指定値に達したときにアラートを発行します。Monitoring のアラートでは、長いストリーミングのシステムラグや失敗したジョブなど、さまざまな状態について通知を受け取ることができます。
• ユーザー定義指標のモニタリング: Dataflow 指標に加えて、Dataflow でユーザー定義指標（SDK アグリゲータ）が Monitoring カスタム カウンタとして Monitoring UI に表示され、グラフやアラート機能で使用できます。Dataflow パイプラインで定義されたアグリゲータはすべて、カスタム指標として Monitoring にレポートされます。Dataflow はユーザーに代わって新しいカスタム指標を定義し、約 30 秒ごとに増分更新を Monitoring にレポートします。

タスク 11. 指標の確認

Cloud Monitoring は、Google Cloud における別個のサービスです。そのため、ご使用のラボのアカウントでこのサービスを初期設定するために、いくつかのセットアップが必要になります。

Monitoring ワークスペースの作成

Qwiklabs の GCP プロジェクトに関連付けられた Monitoring ワークスペースをセットアップします。次の手順に沿って、Monitoring を無料でお試しいただける新しいアカウントを作成します。

1. Google Cloud Platform Console で、[ナビゲーション メニュー] > [Monitoring] の順にクリックします。

2. ワークスペースがプロビジョニングされるまで待ちます。

Monitoring ダッシュボードが開いたら、ワークスペースの準備は完了です。

3. 左側のパネルで [Metrics Explorer] をクリックします。

4. Metrics Explorer の [Resource & Metric] で [指標を選択] をクリックします。

5. [Dataflow Job] > [Job] を選択すると、使用可能な Dataflow 関連の指標が表示されます。[Data watermark lag] を選択して [適用] をクリックします。

6. Cloud Monitoring のページ右側にグラフが描画されます。

7. 指標にある [リセット] をクリックして [Data watermark lag] 指標を削除します。新しい Dataflow 指標 [System lag] を選択します。

注: Dataflow から Monitoring に提供される指標の一覧は、Google Cloud の指標に関するドキュメントで確認できます。ページ上で Dataflow を検索してください。上で確認した指標は、パイプラインのパフォーマンス インジケータとして役立ちます。

Data watermark lag: パイプラインで処理が完了した、直近のデータ項目の経過時間（イベント タイムスタンプ以降の時間）。

System lag: 処理待ち状態になっていたデータ項目の現時点での最長時間（秒単位）。

タスク 12. アラートを作成する

特定の指標が、指定されているしきい値を超えたとき（たとえばこのラボのストリーミング パイプラインのシステムラグが事前定義済みの値より大きくなったとき）に通知を受け取るには、Monitoring のアラート機能を利用します。

アラートの作成

1. Cloud Monitoring で、[アラート] をクリックします。

2. [+ CREATE POLICY] をクリックします。

3. [指標を選択] プルダウンをクリックします。[Show only active resources & metrics] を無効にします。

4. リソースと指標名のフィルタに「Dataflow Job」と入力し、[Dataflow Job] > [Job] をクリックします。[System lag] を選択して [適用] をクリックします。

5. [トリガーの構成] をクリックします。

6. [しきい値の位置] で [しきい値より上] を選択し、[しきい値] に「500」と入力します。[詳細オプション] > [再テスト ウィンドウ] で [1 分] を選択して [次へ] をクリックします。

通知を追加する

1. [通知チャンネル] の横にあるプルダウン矢印をクリックし、[通知チャンネルを管理] をクリックします。

[通知チャンネル] ページが新しいタブで開きます。

2. ページを下方向にスクロールし、[メール] で [新しく追加] をクリックします。

3. [Create Email Channel] ダイアログ ボックスで、[メールアドレス] にラボのユーザー名を入力し、[表示名] を入力します。

注: 自分のメールアドレスを入力すると、プロジェクトのリソースがすべて削除されるまでアラートが届くことがあります。

4. [保存] をクリックします。

5. [通知ポリシーの作成] タブに戻ります。

6. [通知チャンネル] をもう一度クリックし、更新アイコンをクリックして、前の手順で入力した表示名が表示されている状態にします。

7. 使用する表示名を選択し、[OK] をクリックします。

8. [アラート名] を「MyAlertPolicy」に設定します。

9. [次へ] をクリックします。

10. アラートを確認して [ポリシーを作成] をクリックします。

イベントを表示する

1. [Monitoring] タブで、[アラート] > [Policies] をクリックします。

2. 指標のしきい値の条件によってアラートがトリガーされるたびに、インシデントおよび対応するイベントが Monitoring で作成されます。また、アラートの通知メカニズム（メール、SMS など）を指定した場合は、通知を受け取ることができます。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 アラートの作成

タスク 13. ダッシュボードの設定

Cloud Monitoring ダッシュボードを使用すると、適切な Dataflow 関連のグラフを含むダッシュボードを簡単に作成できます。

1. 左側のペインで [ダッシュボード] をクリックします。

2. [+ CREATE DASHBOARD] をクリックします。

3. 新しいダッシュボード名の項目に「My Dashboard」と入力します。

4. [ウィジェットを追加] をクリックし、[折れ線] グラフをクリックします。

5. [Resource & Metric] の下にあるプルダウンをクリックします。

6. [Dataflow Job] > [Job] > [System lag] を選択して [適用] をクリックします。

7. [Filters] パネルで、[+ ADD FILTER] をクリックします。

8. [Label] で [project_id] を選択し、[Value] で を選択または入力します。

9. [適用] をクリックします。

例:

必要に応じて、トピックでの Pub/Sub パブリッシュ レートやサブスクリプション バックログ（Dataflow 自動スケーラーに対するシグナル）などのグラフをダッシュボードに追加できます。

ラボを終了する

ラボが完了したら、[ラボを終了] をクリックします。ラボで使用したリソースが Google Cloud Skills Boost から削除され、アカウントの情報も消去されます。

ラボの評価を求めるダイアログが表示されたら、星の数を選択してコメントを入力し、[送信] をクリックします。

星の数は、それぞれ次の評価を表します。

• 星 1 つ = 非常に不満
• 星 2 つ = 不満
• 星 3 つ = どちらともいえない
• 星 4 つ = 満足
• 星 5 つ = 非常に満足

フィードバックを送信しない場合は、ダイアログ ボックスを閉じてください。

フィードバックやご提案の送信、修正が必要な箇所をご報告いただく際は、[サポート] タブをご利用ください。

Copyright 2020 Google LLC All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。