VM のシャットダウンおよび再起動のトラブルシューティング

このドキュメントでは、仮想マシン（VM）インスタンスの予期しないシャットダウンおよび再起動について一般的な原因と防止方法を説明します。

VM のシャットダウンおよび再起動は、システム イベントまたは管理アクティビティによって発生する可能性があります。システム イベントによるシャットダウンおよび再起動は、Google システムまたは VM のオペレーティング システムによって引き起こされます。管理アクティビティによるシャットダウンおよび再起動は、ユーザーまたはサービス アカウントが生成した API 呼び出しによって引き起こされます。VM 内部で開始された再起動を除き、すべてのシャットダウンおよび再起動は、ログに記録されます。

始める前に

  • まだ設定していない場合は、認証を設定します。認証とは、Google Cloud サービスと API にアクセスするために ID を確認するプロセスです。ローカル開発環境からコードまたはサンプルを実行するには、次のように Compute Engine に対する認証を行います。

    Select the tab for how you plan to use the samples on this page:

    Console

    When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

    gcloud

    1. Install the Google Cloud CLI, then initialize it by running the following command: 

      gcloud init
    2. Set a default region and zone.

VM のシャットダウンおよび再起動の診断

VM のシャットダウンおよび再起動の原因を診断するには、VM のログに対してクエリを実行する必要があります。今後の VM のシャットダウンや再起動の原因をすばやく特定するには、ログを含むダッシュボードを構築します。ログをクエリした後、method フィールドと principalEmail フィールドを確認して、シャットダウンや再起動を引き起こしたイベントと、ユーザーやサービスを特定します。

Cloud Audit Logs のクエリ

Cloud Audit Logs に対してクエリを実行して、シャットダウンまたは再起動の原因となったシステム イベントと管理アクティビティのリストを表示します。

コンソール

  1. Google Cloud コンソールで、[ログ エクスプローラ] ページに移動します。

    [ログ エクスプローラ] に移動

  2. [クエリ] フィールドに次のクエリを入力します。

    resource.type="gce_instance"
"VM_NAME"
logName:("logs/cloudaudit.googleapis.com%2Fsystem_event" OR "logs/cloudaudit.googleapis.com%2Factivity")

    VM_NAME は、シャットダウンや再起動が発生した VM の名前に置き換えます。

  3. 探しているイベントが 1 時間以上前に発生している場合は、時計のアイコンをクリックしてカスタム期間を入力し、カスタムの期間を設定します。

    クエリの期間を設定します。

  4. [クエリを実行] をクリックします。結果は、[クエリ結果] セクションに表示されます。

  5. 各結果の横にある 展開矢印をクリックすると、詳細情報が表示されます。

  6. シャットダウンと再起動に関連する method と principalEmail フィールドの詳細と、それらを防ぐ方法については、Cloud Audit Logs の確認をご覧ください。

gcloud

  1. Cloud Audit Logs を表示するには、gcloud logging read コマンドを使用します。

    gcloud logging read --freshness=TIME 'resource.type="gce_instance" "VM_NAME" logName:("logs/cloudaudit.googleapis.com%2Fsystem_event" OR "logs/cloudaudit.googleapis.com%2Factivity")'

    次のように置き換えます。

    • TIME: クエリを実行する時間の長さ。たとえば、1h は、過去 1 時間のログエントリをクエリします。日付と時刻の形式については、gcloud topic datetimes をご覧ください。
    • VM_NAME: シャットダウンまたは再起動した VM の名前。

    結果が表示されます。

  2. シャットダウンと再起動に関連する method と principalEmail フィールドの詳細と、それらを防ぐ方法については、Cloud Audit Logs の確認をご覧ください。

Cloud Audit Logs の確認

VM がシャットダウンまたは再起動した原因を特定するには、Cloud Audit Logs の method フィールドと principalEmail フィールドを確認します。

  1. Cloud Audit Logs の method フィールドを確認し、次の表に示すメソッドと照合します。

    方法 シャットダウン タイプ 説明
    compute.instances.repair.recreateInstance システム イベント

    VM がマネージド インスタンス グループ（MIG）に属している場合、VM の状態が RUNNING から変化したが、MIG がその状態の変更を開始していない場合、MIG は VM を再作成します。

    MIG によって開始されないインスタンスの状態の変更は次のとおりです。
    compute.instances.hostError システム イベント

    ホストエラー（compute.instances.hostError）は、VM をホストしている物理マシンで、VM がクラッシュするようなハードウェアまたはソフトウェアの問題が発生したことを意味します。ハードウェア全体の障害やその他のハードウェアの問題でホストエラーが発生すると、VM のライブ マイグレーションが停止することがあります。VM が自動的に再起動するように設定されている場合（デフォルト設定）、Google は通常、エラーが検出されてから 3 分以内に VM を再起動します。問題によっては、再起動に最大 5.5 分かかります。

    ローカル SSD ディスク付きの VM

    1 つ以上のローカル SSD ディスクがアタッチされている VM でホストエラーが発生した場合、Compute Engine は可能な限り VM に再接続を試み、ローカル SSD を保持しようとします。Compute Engine が VM とローカル SSD ディスクを復元している間、ホストシステムと基盤となるディスクは応答不能になります。

    Compute Engine がローカル SSD の復元を試みる時間は、ローカル SSD の復元タイムアウトを設定して指定できます。

    ホストエラー発生時におけるローカル SSD ディスクの動作の詳細については、ローカル SSD データの永続性をご覧ください。

    応答しない VM

    ホストエラーが検出される前に、VM が応答しなくなる場合があります。ホストエラー回復タイムアウト（プレビュー）を設定することで、Compute Engine が VM の再起動または終了を待機する時間を短縮できます。詳細については、可用性ポリシーを設定するをご覧ください。

    物理的なハードウェアとソフトウェアの障害が発生する可能性はありますが、これはまれな現象です。起こりうる破壊的なシステム イベントからアプリケーションやサービスを保護するため、次の方策を確認してください。

    Google は、App Engine や App Engine フレキシブル環境などのマネージド サービスも提供しています。
    compute.instances.automaticRestart システム イベント

    このイベントは、VM の automaticRestart ホスト メンテナンス ポリシーが true に設定されている場合でも、hostError イベントまたは terminateOnHostMaintenance イベントの後に発生します。ログでは、このログの前に hostError または terminateOnHostMaintenance ログエントリがあります。

    VM のホスト メンテナンス ポリシーを変更する場合は、インスタンスのオプションの更新をご覧ください。

    compute.instances.guestTerminate システム イベント VM のオペレーティング システムがシャットダウンを開始しました。
    compute.instances.terminateOnHostMaintenance システム イベント

    VM の onHostMaintenance ホスト メンテナンス ポリシーを TERMINATE に設定している場合、Google が VM を別のホストに移動する必要があるメンテナンス イベントが発生すると、VM は Compute Engine により停止されます。

    VM の onHostMaintenance ポリシーを変更する場合は、インスタンスのオプションの更新をご覧ください。
    compute.instances.preempted システム イベント

    Compute Engine が、Spot VM または以前のプリエンプティブル VM をプリエンプトしました。

    • Compute Engine は、Spot VM をプリエンプトすると、その終了アクションに基づいて Spot VM を停止または削除します。Spot VM に最大実行時間はありません。
    • Compute Engine は、プリエンプティブル VM をプリエンプトすると、その VM を最大実行時間（24 時間）後に停止します。こうした制限を回避するには、代わりに Spot VM を使用します。

    Spot VM とプリエンプティブル VM は Compute Engine の余剰のキャパシティを利用する機能であるため、それ以外の場所で容量が必要になると、Compute Engine によってプリエンプトされる可能性があります。ベスト プラクティスに従うことで、プリエンプションの影響を軽減できます。ユーザー制御のランタイムを持つ VM が必要な場合は、代わりに標準 VM を作成します。
    compute.instances.stop 管理アクティビティ

    ユーザーまたはサービス アカウントによって VM が停止されました。

    次の手順に進んで、VM を停止したユーザーまたはサービス アカウントを特定します。VM の再起動については、停止したインスタンスの再起動をご覧ください。
    compute.instances.delete 管理アクティビティ

    ユーザーまたはサービス アカウントによって VM が削除されました。

    次のステップに進んで、VM を削除したユーザーまたはサービス アカウントを特定します。新しい VM の作成方法については、VM の作成と起動をご覧ください。
    compute.instances.insert 管理アクティビティ

    ユーザーまたはサービス アカウントによって VM が作成されました。

    次のステップに進んで、VM を作成したユーザーまたはサービス アカウントを特定します。新しい VM の作成方法については、VM の作成と起動をご覧ください。
    compute.instances.reset 管理アクティビティ

    ユーザーまたはサービス アカウントによって VM がリセットされました。

    次の手順に進んで、VM を停止したユーザーまたはサービス アカウントを特定します。

  2. Cloud Audit Logs の principalEmail フィールドを確認して、シャットダウンや再起動を開始したユーザーまたはサービスを特定します。次の表に、シャットダウンや再起動を開始する共通の Google マネージド サービスを示します。

    Email 説明
    system@google.com システム イベントによってシャットダウンまたは再起動が発生しました。
    project-number@cloudservices.gserviceaccount.com

    サービス エージェントによってシャットダウンが開始されました。

    サービスによってシャットダウンが開始されたプロジェクトを特定するには、サービス アカウントの project-number を確認します。

    リクエストを生成した Google サービスを特定するには、protoPayload.requestMetadata.callerSuppliedUserAgent フィールドを確認します。

    ユーザーがシャットダウンや再起動を開始した場合は、そのメールアドレスが principalEmail フィールドに表示されます。例: cloudysanfrancisco@gmail.com

    管理者は、ユーザー アカウントの Identity and Access Management 権限を変更することで、ユーザーがプロジェクト VM の状態を変更できないように設定できます。詳細については、リソースへのアクセス権の付与、変更、取り消しをご覧ください。

VM ライフサイクル イベントのモニタリング

Cloud Monitoring ダッシュボードを構築することで、VM のライフサイクル イベント（シャットダウン、再起動、ホストエラーなど）をモニタリングできます。

このダッシュボードでは、システム イベントと管理アクティビティを可視化できます。詳細については、このドキュメントの監査ログの確認のセクションをご覧ください。

VM ライフサイクル ダッシュボード: 停止イベントと開始イベント 図 1. インスタンスの可用性と、そのライフサイクル イベント（停止したインスタンスなど）を示すダッシュボードの例。

ログベースの指標の作成

VM のライフサイクル イベントをキャプチャするには、ユーザー定義のログベースの指標を作成します。この指標は、監査ログを使用して特定の VM ライフサイクル イベントが発生した回数を保持します。

指標の作成に必要な権限を取得するには、プロジェクトに対するログ書き込み（roles/logging.logWriter）IAM ロールを付与するよう管理者に依頼してください。ロールの付与の詳細については、アクセス権の管理をご覧ください。

必要な権限は、カスタムロールや他の事前定義ロールから取得することもできます。

次の手順で、ユーザー定義のログベースの指標を作成します。

  1. Google Cloud コンソールで、[ログベースの指標] ページに移動します。

    [ログベースの指標] に移動

  2. [指標を作成] をクリックします。

[指標タイプ] セクションで、次の操作を行います。

  • [Counter] を選択します。
  • [Distribution] は選択解除されたデフォルト設定のままにします。

[詳細] に次のように入力します。

  • ログベースの指標の名前: vm-lifecycle-events。ダッシュボードを正しく機能させるには、この正確な名前を使用する必要があります。
  • 説明: 省略可 - この指標の説明を入力します。
  • 単位: 1

  1. [フィルタの選択] セクションで、以下の内容を指定します。

    • [ログのスコープの選択] プルダウン メニューから [プロジェクト ログ] を選択します。
    • ビルドフィルタに、次のように入力します。 
      resource.type = "gce_instance" AND
log_id("cloudaudit.googleapis.com/activity") OR
log_id("cloudaudit.googleapis.com/system_event")
operation.first="true"

  2. [ラベル] セクションで [ラベルを追加] をクリックします。

  3. 以下を指定します。

    • ラベル名: method
    • ラベルのデータ型: STRING
    • フィールド名: protoPayload.methodName
    • 正規表現: 
      (recreateInstance|hostError|automaticRestart|guestTerminate|terminateOnHostMaintenance|preempted|insert|stop|delete|reset|start)

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

  5. [指標を作成] をクリックします。

ダッシュボードの使用

VM にシステム イベントまたは管理アクティビティが発生するまで、ダッシュボードにデータは表示されません。ダッシュボードが機能するかどうかをテストするには、stop オペレーションや start オペレーションなどの管理アクティビティを実行します。

  1. 既存の VM で stop と start のオペレーションを実行するか、テスト用に新しい VM を作成します。

ダッシュボードを使用するために必要な権限を取得するには、プロジェクトに対する Monitoring ダッシュボード閲覧者（roles/monitoring.dashboardViewer）IAM ロールを付与するよう管理者に依頼してください。ロールの付与の詳細については、アクセス権の管理をご覧ください。

必要な権限は、カスタムロールや他の事前定義ロールから取得することもできます。

  1. Google Cloud コンソールでダッシュボードを開きます。

    ダッシュボードに移動する

  2. [ダッシュボード リスト] タブで GCE VM Lifecycle Events Monitoring ダッシュボードを開きます。

  3. [名前] プルダウン メニューから VM を選択します。

  4. 時系列を該当する期間に絞り込みます。

    ダッシュボードをフィルタする別の方法については、一時的なフィルタを追加するをご覧ください。

ダッシュボードには、VM で発生するシステム イベントと管理アクティビティのタイムラインを表示する 2 つのグラフが含まれています。

  1. [VM ライフサイクル タイムライン] グラフには、次の情報が表示されます。

    • 特定の時点で VM が実行中であったかどうかを示す compute.googleapis.com/instance/uptime 指標（1 は稼働中、0 は停止中）。この指標は、ユーザー アクティビティとシステム イベントの結果としての可用性を反映するものであり、Compute Engine SLA を示すものではありません。
    • vm-lifecycle-events ログベースの指標。特定の時点で VM に対して実行されたライフサイクル アクション（stop、start など）の数をカウントします。

  2. イベントグラフには、同じログベースの指標 vm-lifecycle-events が表示されますが、読みやすくなるように拡大表示されます。X 軸は配置が調整されますが、2 つのグラフ間で色は同期されません。

複数のプロジェクトにまたがる大規模な VM シャットダウンの調査

共有 VPC ホスト プロジェクトの課金が無効になっている場合、Compute Engine は共有 VPC ホスト プロジェクトに接続されている複数の VM をシャットダウンすることがあります。

大量シャットダウン リクエストによって VM がシャットダウンされたかどうかを判断するには、cloud-cluster-manager@prod.google.com によって開始された停止オペレーションを探します。

影響を受けるインスタンスを起動すると、次のようなエラーが返されます。

Starting instance(s) INSTANCE_NAME...failed.
ERROR: (gcloud.compute.instances.start) The default network interface [nic0] is frozen.

この問題を解決するには、次の操作を行います。

  1. gcloud compute instances describe コマンドを使用して、VM が使用する共有 VPC を特定します。

    gcloud compute instances describe VM_NAME \
   --format="flattened(networkInterfaces[].network)"

    出力は次のようになります。

    networkInterfaces[0].network: https://www.googleapis.com/compute/v1/projects/SHARED_VPC_PROJECT/global/networks/FROZEN_NETWORK

  2. 課金が無効になっているかどうかを、共有 VPC のホスト プロジェクトで確認します。

    resource.type="project"
protoPayload.request.@type="type.googleapis.com/google.internal.cloudbilling.billingaccount.v1.DisableResourceBillingRequest"
protoPayload.response.resourceBillingInfo.billingAccountAssignmentType="DISABLED"

  3. 必要に応じて、ホスト プロジェクトで課金を有効にします。

この問題の再発を回避するには、プロジェクトと請求先アカウント間のリンクを保護するをご覧ください。