---
sourceDocument: Xanadu IT Operations Management
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/ja-JP/xanadu/it-operations-management

 Release :

    - xanadu

ft:locale :

    - ja-JP

ft:publication_title :

    - Xanadu IT Operations Management

ft:clusterId :

    - itom

bundleId :

    - itom

workflow :

    - Technology


---

# Azure 変更処理

# Azure 変更処理 {#ariaid-title1}

* リリースバージョン: Xanadu
* 
* 更新日 2024年08月01日
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 所要時間：7分

Azure 変更処理は、ライフサイクル状況の変更または構成の変更が行われた Microsoft Azure リソースに関する情報を収集します。次に、収集された情報を使用して 構成管理データベース (CMDB) を更新します。
図 : 1. Azure 変更処理の概要

\[Azure 変更処理 (Azure Process Changes)\] スケジュール済みジョブは、Azure のリソース変更 API を照会し、リソース変更情報を収集します。スケジュール済みジョブは、各実行サイクル中に、最後に成功したスケジュール実行から現在のスケジュール実行までの間に変更されたすべてのリソースに関する情報を収集します。変更情報を受信した後、Azure 変更処理は応答マッピングを使用して CMDB 内の変更情報を更新します。次回のディスカバリー中に、クラウドディスカバリー は適切なパターンをトリガーし (利用可能な場合)、CMDB に詳細なリソース情報を入力します。  
デフォルトでは、\[Azure 変更処理 (Azure Process Changes)\] スケジュール済みジョブは 10 分ごとに実行されます。必要に応じて、スケジュールの実行頻度を更新します。新しい実行頻度は、必ず次の範囲内で設定してください。

* 最小値：1 分
* 最大値：sn_cmp.azure.change_enquiry.max_frequency_in_hours プロパティで定義された値。

{#azure-change-processing__ul_tfn_sc3_5wb}\[Azure 変更処理 (Azure Process Changes)\] スケジュール済みジョブのデフォルトの実行頻度を減らすことで、CMDB の更新を高速化できます。

Azure 変更処理を初めて実行するときは、最大 4 時間かかる場合があります。デフォルトの最大スケジュール実行期間を変更するには、sn_cmp.azure.change_enquiry.max_frequency_in_hours プロパティを設定します。デフォルトのスケジュール実行期間を長くする場合は、スケジュールを実行するのに十分なワーカーノードが利用可能であることを確認してください。

イベント処理中、Cloud Event Scheduler はサービスアカウントのドメインを識別し、イベントにアサインします。処理前にドメインの識別中にエラーが発生した場合、イベントは未アサインのままになり、すべてのドメインに表示される可能性があります。失敗したイベントをすべてのドメインで表示しないようにするには、sn_cmp.error_events.default_domain プロパティをサービスプロバイダードメインの sys_id に設定して、失敗したイベントがサービスプロバイダードメインアドミニストレーターにのみ表示されるようにします。  
注:  
Azure 変更処理は、discovery_admin または sn_cmp.cloud_admin によって作成されたサービスアカウントからのみリソース変更情報をフェッチできます。

## API 記録とエラーログ {#azure-change-processing__section_o4d_td3_5wb}

Azure 変更処理では、MID サーバー を使用して Azure エンドポイントを呼び出し、リソース変更情報を収集します。API 呼び出しと応答を CAPI 記録 \[sn_capi_api_trail\] テーブルに記録します。  
リソース変更ペイロード情報 (Resource Changes Payload Info) \[sn_cmp_resource_changes_payload_info\] テーブルには、受信した変更に関する次の統計情報が含まれています。

* 合計数：変更ペイロードで受信した変更の数。
* 処理済み数：処理された変更の数。
* スキップ数：スキップされた変更の数。
* エラー数：エラーが原因で処理できなかった変更の数。リソース変更ペイロード情報 (Resource Changes Payload Info) レコードの \[イベント記録 (Event Trail)\] タブには、エラーが発生した変更に関する次の情報が表示されます。
  * 影響を受けるペイロード：Azure 変更処理が処理に失敗した変更。
  * 変更時間：失敗した変更のタイムスタンプ。
  * 変更タイプ：CMDB の変更をキャプチャするために必要な操作のタイプ。
  * エラーの理由：エラーログへのリンク。

  {#azure-change-processing__ul_tzl_b23_5wb}Azure 変更処理は、エラーが発生した変更をイベント記録 (Event Trail) \[sn_cmp_event_trail\] テーブルに記録します。
{#azure-change-processing__ul_k3h_yd3_5wb}  
注:  
リソース変更ペイロード情報 (Resource Changes Payload Info) \[sn_cmp_resource_changes_payload_info\] テーブルにアクセスできるのは、discovery_admin または sn_cmp.cloud_admin のみです。

## サポートされる Azure リソースタイプと変更 {#azure-change-processing__section_xrg_n23_5wb}

mid.cmp.azure.event.supported_resource_types プロパティには、変更処理がサポートされているすべての Azure リソースタイプのカンマ区切りリストが格納されます。  
{#azure-change-processing__table_w3g_w23_5wb__entry__2}

| リソース タイプ | サポートされるリソース変更 |
|-|-|
| Microsoft.Compute/virtualMachine | * computerName * osVersion * OsName * 電源ステータス {#azure-change-processing__ul_bg4_cf3_5wb} |
| Microsoft.Compute/disks | データディスク：既存の仮想マシン (VM) にディスクを追加します。 * diskSizeGB * キャッシュ * createOperation * deleteOperation * Lun * manageDisk.id {#azure-change-processing__ul_lqq_ff3_5wb} OS ディスク * 階層 * diskState {#azure-change-processing__ul_xm2_jf3_5wb} |
| Microsoft.Network/networkSecurityGroups | * ipConfigurations\[0\].etag * virtualMachine.id * プライマリ * macAddress * resourceGuid {#azure-change-processing__ul_ivp_lf3_5wb} |
| Microsoft.Network/networkinterfaces | networkInterfaces\[0\].id |
| Microsoft.Network/publicIPAddresses | * ipAddress * resourceGuid {#azure-change-processing__ul_fn1_pf3_5wb} |
[表 : 1. サポートされる Azure リソースタイプ]

{#azure-change-processing__table_w3g_w23_5wb}

Azure リソースタイプのサポートを追加する方法の詳細については、「[Azure リソースタイプの変更処理サポートの追加](https://servicenow-prod.fluidtopics.net/3BYrBMcmhEUZkeSAUipYfA "組織のニーズに応じて、Azure リソースタイプの Azure 変更処理サポートを追加します。")」を参照してください。

## Azure 変更処理の利点 {#azure-change-processing__section_jnh_zf3_5wb}

Azure 変更処理には、Microsoft Azure アラート駆動型ディスカバリーと比較して次の利点があります。

* パフォーマンスが向上し、Azure API スロットリングの可能性が低下
* セットアップが簡単
{#azure-change-processing__ul_xky_cg3_5wb}

パフォーマンスが向上し、Azure API スロットリングの可能性が低下
:   Microsoft Azure アラート駆動型ディスカバリーは、影響を受ける各リソースのターゲットディスカバリーをトリガーします。したがって、Now Platform が大量のアラートを受信すると、ターゲットディスカバリーによって Azure API が抑制される可能性があります。その結果、Now Platform のアラート処理パフォーマンスが低下する可能性があります。対照的に、Azure 変更処理では、影響を受ける各リソースのターゲットディスカバリーはトリガーされません。代わりに、応答マッピングを使用して、利用可能な変更情報に従って CMDB を更新します。次回のディスカバリー中に、クラウドディスカバリー は適切なパターンをトリガーし (利用可能な場合)、CMDB に詳細なリソース情報を入力します。したがって、Azure 変更処理は Now Platform の変更処理パフォーマンスを向上させ、Azure API スロットリングの可能性を減らします。

セットアップが簡単
:   Microsoft Azure アラート駆動型ディスカバリーでは、Webhook を使用してアラートを Now Platform に送信します。Azure クラウドはサブスクリプションレベルでアラートを生成するため、Microsoft Azure アラート駆動型ディスカバリーでは、監視するサブスクリプションごとに Webhook が必要です。対照的に、Azure 変更処理は CAPI と MID サーバー を使用して Azure リソース変更 API とやり取りします。API は、管理グループレベルで変更情報を提供できます。したがって、Azure 変更処理では Webhook が不要になり、セットアップが簡単になります。

Microsoft Azure クラウドからリソース変更情報を取得し、それを使用して CMDB を更新するように [Azure 変更処理](https://servicenow-prod.fluidtopics.net/67RNFSkEU6qEgpDCf8OjfA "Microsoft Azure クラウドからリソース変更情報を取得し、それを使用して 構成管理データベース (CMDB)を更新するように Azure 変更処理を構成します。")を構成できます。

Microsoft Azure アラート駆動型ディスカバリーを使用している場合、[Azure 変更処理に移行](https://servicenow-prod.fluidtopics.net/l5krzRHFJeV3mWIAZMFpBA "Azure 変更処理に移行すると、Now Platform の変更処理パフォーマンスが向上し、簡素化されたセットアップを利用できます。")すると、Now Platform の変更処理パフォーマンスが向上し、簡素化されたセットアップを利用できます。