Azure Automation State Configuration と Azure Monitor Logs を連携してDSC構成を可視化する方法

Azure Automation の State Configuration(DSC) で収集したノード状態やジョブ情報を、Azure Monitor Logs / Log Analytics ワークスペースに流し込んで一元監視したい、というニーズは非常に多くあります。本記事では、前提条件から Azure ポータル・PowerShell・IaC の具体的な手順、ログ活用のための Kusto クエリ例やコスト最適化の考え方まで、実運用を前提に詳しく解説します。

Azure Automation State Configuration と Azure Monitor Logs 連携の全体像

まずは、Azure Automation State Configuration(以下 DSC) と Azure Monitor Logs / Log Analytics の関係を整理します。

Azure Automation State Configuration (DSC)
サーバーや VM、ハイブリッドマシンに対して「あるべき状態」を宣言し、その構成が準拠しているか/していないかをレポートする構成管理サービスです。
ノードから送信される情報
構成適用結果(成功/失敗)、構成ドリフト情報、最新のチェックイン時刻、ジョブの開始/完了ステータス、ストリーム出力(Verbose / Error など)。
Azure Monitor Logs / Log Analytics
各種 Azure リソースやアプリケーションから集約されたログ/メトリックを保存・検索・可視化するための基盤。Kusto クエリ(KQL) により柔軟な集計・アラート設定が可能です。

今回のゴールは、Automation アカウントの診断設定(Diagnostic Settings)を利用して、DSC のノード状態やジョブログを Log Analytics ワークスペースに継続的に転送できるようにすることです。

前提条件と準備事項

連携を設定する前に、必要なリソース・権限・クライアント環境を確認しておきます。

必要な Azure リソース

種別	要件	補足
Automation アカウント	State Configuration が有効化されていること	少なくとも 1 台以上のノードが登録済みだと動作確認が容易です。
Log Analytics ワークスペース	Azure Monitor Logs の保存先として利用	既存ワークスペースでも新規でも可。テスト用途なら専用ワークスペースを推奨します。
Azure テナント / サブスクリプション	Automation と Log Analytics が同一テナント内であること	サブスクリプションは異なっていても、診断設定からクロスサブスクリプションで送信可能です。

必要な RBAC 権限

診断設定は Azure リソースに対する操作権限が必要です。少なくとも以下のいずれかを満たしてください。

対象リソース	推奨ロール	必要な理由
Automation アカウント	所有者 / 共同作成者 / Monitoring Contributor	診断設定(Microsoft.Insights/diagnosticSettings)リソースの作成・変更・削除に必要
Log Analytics ワークスペース	所有者 / 共同作成者 / Log Analytics Contributor	診断ログの送信先として指定するためのアクセス権が必要

特に、クロスサブスクリプションで連携する場合は、両方のサブスクリプションで最低限のロールが付与されているかを確認しておきましょう。

PowerShell / Az モジュールの準備

PowerShell から自動化したい場合は、ローカル環境または Azure Cloud Shell で Az PowerShell モジュールを利用できる状態にします。

# 必要に応じて最新の Az モジュールをインストール
Install-Module Az -Scope CurrentUser -Repository PSGallery -Force

# ロード確認
Import-Module Az
Get-Module Az* | Select-Object Name, Version

企業環境などでバージョン固定が必要な場合は、利用する Az モジュールのバージョンを事前に検証環境で確認してから、本番へ展開する運用ルールを決めておくと安心です。

Azure ポータルからの設定手順

まずは最も分かりやすい、Azure ポータルからの設定手順を確認します。GUI での設定は検証や PoC に向いており、最初に動作を理解するのにおすすめです。

Automation アカウントで診断設定を作成する

Azure ポータルで対象の Automation アカウント を開きます。
メニューから 診断設定 (Diagnostic settings) をクリックします。
＋追加(Add diagnostic setting) をクリックします。
任意の名前(例: Send-Automation-DSC-Logs)を入力します。
送信先 として Log Analytics ワークスペースに送信 を選択し、対象のワークスペースを指定します。
送信するログカテゴリにチェックを入れます。
[保存] をクリックして完了です。

数分後、対象 Automation アカウントに関連するイベントが Log Analytics 側に流れ始めます。

選択すべき主なログカテゴリ

Automation アカウントでは複数のログカテゴリが提供されており、DSC とジョブ監視に重要なカテゴリを中心に選択します。

カテゴリ名(例)	概要	主な用途
DscNodeStatus	DSC ノードのチェックイン情報や準拠状況	構成ドリフトの検出、サーバーごとの準拠状況レポート
JobLogs	ジョブの開始/終了、ステータス、実行時間など	DSC 構成適用ジョブの成功/失敗の追跡
JobStreams	ジョブ実行中の出力(Verbose / Error / Warning 等)	トラブルシューティング、より詳細なエラー内容の分析
AuditEvent	Automation アカウントに対する管理操作	誰がいつ設定変更/実行を行ったかの監査目的

コスト最適化の観点から、最初は DscNodeStatus + JobLogs に絞って開始し、必要に応じて JobStreams や AuditEvent を追加するのがおすすめです。JobStreams は出力量が多くなりやすく、保持期間が長いとワークスペースの料金に直接影響するためです。

Log Analytics 側でテーブルを確認する

診断ログをワークスペースへ送信すると、環境によって次のいずれかの形でログが保存されます。

AzureDiagnostics テーブルに集約されるパターン
リソース固有テーブル(例: Automation ジョブ用テーブルや DSC ノード状態用テーブル)に分かれて保存されるパターン

実際には、ワークスペースの設定や Azure 側の仕様により変わるため、最初にどのテーブルへ入っているかを確認することが重要です。Log Analytics のクエリエディターで、まずは以下のようなシンプルなクエリを実行してみましょう。

// 直近 1 時間に入ってきた Automation 関連ログを確認
AzureDiagnostics
| where TimeGenerated &gt; ago(1h)
| where ResourceProvider == "MICROSOFT.AUTOMATION"
| summarize count() by Category

リソース固有テーブルが有効な場合は、Automation 向けのテーブル名(例: ジョブ、ジョブストリーム、DSC ノード状態など)が登場します。その場合も、まず take 100 などで中身とスキーマを確認しておくと後続のクエリ設計がスムーズです。

PowerShell による診断設定の作成と管理

本番環境では、Automation アカウントが複数サブスクリプション・複数リージョンに分散しているケースが多く、Azure ポータルで一つずつ設定していくのは現実的ではありません。ここでは PowerShell を使って、診断設定をスクリプトで作成・変更・削除する方法を整理します。

基本的な診断設定の作成例

まずは、1 つの Automation アカウントから 1 つの Log Analytics ワークスペースに DSC ノード状態ログを送信する最小構成の例です。

# 1) Azure へサインイン
Connect-AzAccount
# 必要に応じてサブスクリプションを明示
# Select-AzSubscription -SubscriptionId "&lt;サブスクリプション ID&gt;"

# 2) 変数にリソース情報を設定
$automationAccount = "MyAutomationAccount"
$workspaceName     = "MyLogAnalytics"
$resourceGroup     = "MyResourceGroup"

# 3) リソース ID を取得
$autoId = (Get-AzAutomationAccount -ResourceGroupName $resourceGroup -Name $automationAccount).Id
$lawId  = (Get-AzOperationalInsightsWorkspace -ResourceGroupName $resourceGroup -Name $workspaceName).ResourceId

# 4) 診断設定を作成して DSC ノード状態ログを転送
Set-AzDiagnosticSetting `
    -Name "SendDSCLogs" `
    -ResourceId $autoId `
    -WorkspaceId $lawId `
    -Category "DscNodeStatus" `
    -Enabled $true

このスクリプトにより、ポータルで行った操作と同等の診断設定が自動で作成されます。既に同名の診断設定がある場合は上書きされるため、名称を運用ポリシーに合わせて統一しておくと管理しやすくなります。

複数カテゴリをまとめて有効化する例

DSC ノード状態だけでなく、ジョブログやストリームも同時に有効化したい場合は、-Category に複数のカテゴリを指定します。

$categories = @(
    "DscNodeStatus",
    "JobLogs",
    "JobStreams",
    "AuditEvent"
)

Set-AzDiagnosticSetting `
    -Name "SendAutomationLogs" `
    -ResourceId $autoId `
    -WorkspaceId $lawId `
    -Category $categories `
    -Enabled $true

カテゴリ名は環境によって若干の違いがある場合もあるため、一度 Get-AzDiagnosticSettingCategory コマンドレットで一覧を確認しておくと安全です。

Get-AzDiagnosticSettingCategory -ResourceId $autoId

複数 Automation アカウントへ一括適用するサンプル

同じサブスクリプション内で、複数の Automation アカウントに同一ポリシーの診断設定を適用したい場合の一例です。

$resourceGroup  = "MyResourceGroup"
$workspaceName  = "MyLogAnalytics"
$lawId          = (Get-AzOperationalInsightsWorkspace -ResourceGroupName $resourceGroup -Name $workspaceName).ResourceId

# RG 内の Automation アカウントを一括取得
$automationAccounts = Get-AzAutomationAccount -ResourceGroupName $resourceGroup

$categories = @(
    "DscNodeStatus",
    "JobLogs"
)

foreach ($account in $automationAccounts) {
    Write-Host "Configure diagnostic setting for:" $account.Name

    Set-AzDiagnosticSetting `
        -Name "SendAutomationLogs" `
        -ResourceId $account.Id `
        -WorkspaceId $lawId `
        -Category $categories `
        -Enabled $true
}

サブスクリプションをまたいで自動化したい場合は、Get-AzSubscription で一覧を取得し、ループの外側で Select-AzSubscription を切り替えながら同様の処理を行うことができます。

診断設定を削除して転送を停止する

ログの転送を止めるには、診断設定そのものを削除します。名前とリソース ID を指定するだけです。

Remove-AzDiagnosticSetting -Name "SendDSCLogs" -ResourceId $autoId

Automation アカウント本体を削除しても診断設定リソースは同時に削除されますが、Log Analytics ワークスペース側のログデータは保持期間が切れるまで残る点に注意してください。

Log Analytics に転送された DSC ログの活用方法

診断設定が完了したら、Log Analytics で実際にログを活用できるようにしていきます。ここでは、代表的なクエリ例と運用シナリオを紹介します。

直近 24 時間で失敗した構成適用ジョブを抽出する

DSC のジョブが失敗している場合、原因調査の入口となる一覧を作ることができます。

JobLogsTable
| where TimeGenerated &gt; ago(24h)
| where Status != "Completed"
| project TimeGenerated, ResourceGroup, AutomationAccount = Resource, JobId, RunbookName, Status, StatusMessage
| order by TimeGenerated desc

このクエリをベースに、特定の Automation アカウントや特定の構成名に絞り込んで利用すると、日々の運用監視がぐっと楽になります。

構成ドリフトのアラート化

「有効なノードのうち、準拠していないものが存在する」状況を検知してメールや Teams に通知するシナリオも一般的です。

DscNodeStatusTable
| where TimeGenerated &gt; ago(30m)
| summarize arg_max(TimeGenerated, *) by NodeName
| where ConfigurationStatus != "Compliant"

このクエリを Azure Monitor のアラートルールとして保存し、「結果が 1 件以上でアラート発火」という条件を設定すれば、構成ドリフトが発生した際に通知を飛ばせるようになります。

ワークブックによる可視化

Log Analytics を使い慣れていない運用メンバー向けには、ワークブックを作成して、DSC ノード状態やジョブ結果をグラフや一覧で見やすく表示するのがおすすめです。

ノードごとの準拠率(合計ノード数に対する準拠ノード数の割合)
時間軸で見たジョブ成功/失敗の推移
直近 1 日・7 日で最も失敗回数が多い構成名ランキング

これらをワークブックとしてまとめておくことで、障害発生時だけでなく定期的なヘルスチェックにも活用できます。

コスト最適化と設計上のベストプラクティス

Automation DSC のログを Log Analytics に送り始めると、時間の経過とともにワークスペースのデータ量が増えていきます。設計段階で以下のポイントを押さえておくことで、不要なコスト増を防ぎつつ必要なログだけを残すことができます。

送信するカテゴリを厳選する

必須: DscNodeStatus – 構成準拠状況の監視に直結するため、通常は必須。
優先度高: JobLogs – いつどの構成が成功/失敗したのかを追うために重要。
用途に応じて: JobStreams – 詳細な出力が必要な場合のみ有効化。バースト的に大量出力される可能性が高く、費用インパクトも大きい。
監査目的: AuditEvent – コンフィグ変更やジョブ実行操作を追跡する必要がある場合に有効化。

最初からすべてを有効化するのではなく、まずは最小構成で運用を始め、必要に応じて段階的に範囲を広げるアプローチが現場では有効です。

保持期間(リテンション)の設計

Log Analytics ワークスペースごとに保持期間を設定できるため、DSC ログの利用目的に応じて期間を決めます。

ユースケース	目安保持期間	ポイント
日常の運用・障害対応	30～90 日	トラブル発生からの振り返りができれば良いケースが多い
セキュリティ・監査要件	6 ヶ月～数年	AuditEvent や構成ドリフト情報を長期間残す必要がある場合
検証環境	7～30 日	最低限の期間だけ残し、コストを抑える

ワークスペースを用途ごとに分け、「本番/監査用」「検証環境用」で保持期間を変える設計もよく採用されます。

クロスサブスクリプション設計

Automation アカウントと Log Analytics ワークスペースが異なるサブスクリプションに存在していても、同一テナント内であれば診断設定で連携可能です。運用上は次のようなパターンが考えられます。

各サブスクリプションにワークスペースを用意する
管理単位ごとにログを分離でき、運用委託先や請求の分離を行いやすい。
共通のセキュリティ/監査用ワークスペースへ集約する
セキュリティチームが全体像を把握しやすく、横断的な分析が可能。

どちらのパターンを採用するにせよ、診断設定を IaC(コード)として管理することで、環境間の整合性を担保しやすくなります。

ARM テンプレート / Bicep で診断設定を IaC 管理する

GUI や PowerShell で設定を行ったとしても、最終的には IaC に落とし込んでおくと、再現性の高い環境構築が可能になります。ここでは Bicep の例を示します。

Bicep による diagnosticSettings リソース定義例

@description('Automation アカウント名')
param automationAccountName string

@description('Log Analytics ワークスペースのリソース ID')
param logAnalyticsWorkspaceId string

resource automation 'Microsoft.Automation/automationAccounts@2020-01-13-preview' existing = {
  name: automationAccountName
}

resource diag 'Microsoft.Insights/diagnosticSettings@2021-05-01-preview' = {
  name: 'SendAutomationDscLogs'
  scope: automation
  properties: {
    workspaceId: logAnalyticsWorkspaceId
    logs: [
      {
        category: 'DscNodeStatus'
        enabled: true
      }
      {
        category: 'JobLogs'
        enabled: true
      }
      {
        category: 'JobStreams'
        enabled: false
      }
      {
        category: 'AuditEvent'
        enabled: true
      }
    ]
    metrics: [
      {
        category: 'AllMetrics'
        enabled: false
      }
    ]
  }
}

ポイントは scope に Automation アカウントリソースを指定し、その配下に Microsoft.Insights/diagnosticSettings リソースをぶら下げる形で記述する点です。カテゴリの ON/OFF をパラメータ化しておくことで、環境別にログ種別を変えたい場合でも柔軟に対応できます。

Terraform を利用している場合も、azurerm_monitor_diagnostic_setting リソースでほぼ同様の構成が可能です。いずれにしても、「Automation アカウントを作成するテンプレート」と「診断設定を適用するテンプレート」を同じパイプラインで実行するようにしておくと、作り忘れを防げます。

運用でつまずきやすいポイントと対処法

実際の運用でよく質問されるポイントをいくつか挙げ、それぞれの確認観点を整理します。

ログが Log Analytics に出てこない場合のチェックリスト

診断設定の送信先として指定した Log Analytics ワークスペースが正しいか
Automation アカウント側の診断設定で、目的のカテゴリが有効になっているか
Log Analytics でクエリ対象としているテーブルが正しいか( AzureDiagnostics なのか、リソース固有テーブルなのか )
DSC ノードが実際にチェックインしているか(Automation アカウントの State Configuration 画面でも確認可能)
ネットワーク制限(ファイアウォール/プロキシ)により、ノードから Azure への通信がブロックされていないか

特に最後のネットワーク制限は、オンプレミスサーバーを DSC ノードとして登録しているケースで見落とされがちです。Azure Automation DSC が利用するエンドポイントへのアクセスが許可されているかを確認してください。

DSC ノード側のトラブルシューティング

Log Analytics 連携とは少し離れますが、ノード側で DSC 構成がうまく適用されていないと、そもそも Automation アカウントにレポートが上がってきません。代表的な確認ポイントは次の通りです。

ローカルの DSC イベントログ(Windows なら Microsoft-Windows-DSC 関連ログ)の確認
ローカルの Get-DscConfigurationStatus コマンドの実行結果
LSCM(Local Configuration Manager) の設定値(リフレッシュ間隔や構成モード)

これらノード側の情報も Log Analytics に集約したい場合は、Azure Monitor エージェント(AMA)や他の監視エージェントの導入も検討対象になります。

まとめ

本記事では、Azure Automation State Configuration のログを Azure Monitor Logs / Log Analytics ワークスペースへ連携するための手順と前提条件を、ポータル・PowerShell・Bicep のそれぞれの観点から解説しました。

Automation アカウントと Log Analytics ワークスペースを用意し、必要な RBAC 権限を付与する。
診断設定を利用して、DSC ノード状態やジョブログなどのカテゴリを選択し、ワークスペースへ転送する。
PowerShell で Set-AzDiagnosticSetting を使えば、多数の Automation アカウントにも一括で設定できる。
転送されたログは、Kusto クエリ・ワークブック・アラートで可視化・自動通知に活用できる。
ログカテゴリと保持期間を設計し、必要最小限のログでコストを抑えることが重要。
ARM テンプレートや Bicep で Microsoft.Insights/diagnosticSettings をコード化しておくと、環境再現性とガバナンスの両立がしやすい。

これらのポイントを押さえておけば、Azure Automation State Configuration の情報を確実かつ継続的に Azure Monitor Logs に取り込み、構成ドリフトの検知から障害解析、監査対応まで一気通貫で行える監視基盤を構築できます。既に Automation DSC を利用している環境であれば、まずは 1 つの Automation アカウントとワークスペースから試し、徐々に全体へ展開していくのがおすすめです。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Azure Automation State Configuration と Azure Monitor Logs を連携してDSC構成を可視化する方法

Azure Automation State Configuration と Azure Monitor Logs 連携の全体像

前提条件と準備事項

必要な Azure リソース

必要な RBAC 権限

PowerShell / Az モジュールの準備

Azure ポータルからの設定手順

Automation アカウントで診断設定を作成する

選択すべき主なログカテゴリ

Log Analytics 側でテーブルを確認する

PowerShell による診断設定の作成と管理

基本的な診断設定の作成例

複数カテゴリをまとめて有効化する例

複数 Automation アカウントへ一括適用するサンプル

診断設定を削除して転送を停止する

Log Analytics に転送された DSC ログの活用方法

最新のノード準拠状況を一覧する

直近 24 時間で失敗した構成適用ジョブを抽出する

構成ドリフトのアラート化

ワークブックによる可視化

コスト最適化と設計上のベストプラクティス

送信するカテゴリを厳選する

保持期間(リテンション)の設計

クロスサブスクリプション設計

ARM テンプレート / Bicep で診断設定を IaC 管理する

Bicep による diagnosticSettings リソース定義例

運用でつまずきやすいポイントと対処法

ログが Log Analytics に出てこない場合のチェックリスト

DSC ノード側のトラブルシューティング

まとめ

この記事を書いた人

コメント

コメントするコメントをキャンセル

Azure Automation State Configuration と Azure Monitor Logs を連携してDSC構成を可視化する方法

Azure Automation State Configuration と Azure Monitor Logs 連携の全体像

前提条件と準備事項

必要な Azure リソース

必要な RBAC 権限

PowerShell / Az モジュールの準備

Azure ポータルからの設定手順

Automation アカウントで診断設定を作成する

選択すべき主なログカテゴリ

Log Analytics 側でテーブルを確認する

PowerShell による診断設定の作成と管理

基本的な診断設定の作成例

複数カテゴリをまとめて有効化する例

複数 Automation アカウントへ一括適用するサンプル

診断設定を削除して転送を停止する

Log Analytics に転送された DSC ログの活用方法

最新のノード準拠状況を一覧する

直近 24 時間で失敗した構成適用ジョブを抽出する

構成ドリフトのアラート化

ワークブックによる可視化

コスト最適化と設計上のベストプラクティス

送信するカテゴリを厳選する

保持期間(リテンション)の設計

クロスサブスクリプション設計

ARM テンプレート / Bicep で診断設定を IaC 管理する

Bicep による diagnosticSettings リソース定義例

運用でつまずきやすいポイントと対処法

ログが Log Analytics に出てこない場合のチェックリスト

DSC ノード側のトラブルシューティング

まとめ

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル