Azure Monitor Log Analytics KQLを活用した統合ログ管理と運用最適化

Tech

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

Azure Monitor Log Analytics KQLを活用した統合ログ管理と運用最適化

Azure Monitor Log Analyticsは、Azure環境におけるログ管理と分析の中心的なサービスです。多様なソースから生成されるログデータを一元的に収集、保存し、Kusto Query Language（KQL）を用いて高度な分析を可能にします。本記事では、クラウドアーキテクトの視点から、Log Analytics KQLのアーキテクチャ、設定、運用、セキュリティ、コスト最適化、そして一般的な落とし穴について詳しく解説します。

アーキテクチャ

Azure Monitor Log Analyticsは、Azure環境の分散型ログデータを集約するためのハブとして機能します。そのコアコンポーネントはLog Analytics Workspaceであり、これはデータ収集、インデックス作成、KQLによるクエリを可能にする専用のAzureリソースです。

主なデータソースとフローは以下の通りです。

  1. Azureリソース: Azure Virtual Machines (VMs)、Azure Kubernetes Service (AKS)、Azure Functions、Azure SQL Databaseなど、多くのAzureサービスが診断ログを直接Log Analytics Workspaceに送信できます。

  2. Azure Monitor Agent (AMA): 2024年7月時点では、Log Analytics Agent (MMA) の後継となるAMAは、Windows/Linux VMやAzure Arc対応サーバーからOSログ、パフォーマンスデータ、イベントログなどを収集し、Log Analytics Workspaceに送信します。

  3. カスタムログ/API: カスタムアプリケーションやオンプレミス環境からのログも、Data Collector APIやAzure Logic Appsなどを介して取り込むことが可能です。

  4. KQLによる分析: Workspaceに集約されたデータはKQLを用いて検索、集計、可視化、アラート設定が可能です。

以下に、Log Analyticsにおけるデータフローの概要をMermaidフローチャートで示します。

flowchart TD
    subgraph Data Sources
        A["Azure VM"] -->|via AMA| B("Log Analytics Workspace")
        C["Azure Kubernetes Service"] -->|Diagnostic Settings| B
        D["Azure Functions"] -->|Diagnostic Settings| B
        E["Azure SQL Database"] -->|Diagnostic Settings| B
        F["カスタムアプリケーション"] -->|Data Collector API| B
    end

    subgraph Log Analytics Workspace
        B --> G["Kusto Query Language (KQL)"]
        G --> H["アラート"]
        G --> I["ダッシュボード/Workbooks"]
        G --> J["エクスポート/Automation"]
    end

    style B fill:#f9f,stroke:#333,stroke-width:2px

設定手順

Log Analytics Workspaceの作成と、基本的なデータ収集の設定手順をPowerShellで示します。

1. Log Analytics Workspaceの作成

まず、Log Analytics Workspaceを作成します。以下の例では、「MyLogAnalyticsWorkspace」という名前で「Japan East」リージョンに作成します。

# 変数の定義

$resourceGroupName = "myResourceGroup"
$workspaceName = "MyLogAnalyticsWorkspace-$(Get-Random)" # ユニークな名前を生成
$location = "Japan East"

# リソースグループが存在しない場合は作成 (初回のみ)

try {
    Get-AzResourceGroup -Name $resourceGroupName -ErrorAction Stop | Out-Null
    Write-Host "Resource group '$resourceGroupName' already exists."
} catch {
    Write-Host "Creating resource group '$resourceGroupName'..."
    New-AzResourceGroup -Name $resourceGroupName -Location $location
    Write-Host "Resource group '$resourceGroupName' created successfully."
}

# Log Analytics Workspaceの作成 (2024年7月31日現在)

Write-Host "Creating Log Analytics Workspace '$workspaceName' in '$location'..."
$workspace = New-AzOperationalInsightsWorkspace -ResourceGroupName $resourceGroupName -Name $workspaceName -Location $location -Sku PerGB2018
Write-Host "Log Analytics Workspace '$workspace.Name' created with ID: '$workspace.ResourceId'."

# 作成されたWorkspaceの情報を表示

$workspace | Format-List Name, Location, Sku, ProvisioningState, CustomerId

Sku PerGB2018は従量課金制のSKUです。コミットメント層を利用する場合は、後述のコスト最適化で言及します。

2. Azure Monitor Agent (AMA) を利用したVMからのデータ収集設定

AMAを使用してVMからログを収集するには、まず対象のVMにAMAをインストールし、次にデータ収集ルール (DCR) を作成してどのデータを収集するかを定義します。

# 前提: 対象のVMがAzure上に存在し、Managed Identityが有効化されていること。


# また、AMA拡張機能がVMにインストールされていること。

# 変数の定義 (既存のVMとWorkspaceを使用)

$resourceGroupName = "myResourceGroup"
$vmName = "myLinuxVm" # 対象VMの名前に変更
$workspaceName = "MyLogAnalyticsWorkspace-..." # 先ほど作成したWorkspaceの名前に変更
$subscriptionId = (Get-AzContext).Subscription.Id
$logAnalyticsWorkspace = Get-AzOperationalInsightsWorkspace -ResourceGroupName $resourceGroupName -Name $workspaceName

# データ収集ルール (DCR) の作成 (2024年7月31日現在)


# 例: Linux Syslogとパフォーマンスデータを収集するDCR

$dcrName = "myLinuxSyslogPerfDCR"
$dcrLocation = $logAnalyticsWorkspace.Location

$dcrJson = @"
{
  "location": "$dcrLocation",
  "properties": {
    "dataSources": [
      {
        "kind": "Syslog",
        "streams": [
          "Microsoft-Syslog"
        ],
        "sendFacilityName": true,
        "syslogName": [
          "auth",
          "authpriv",
          "cron",
          "daemon",
          "kern",
          "mail",
          "mark",
          "news",
          "syslog",
          "user",
          "uucp"
        ],
        "logLevels": [
          "Emergency",
          "Alert",
          "Critical",
          "Error",
          "Warning",
          "Notice",
          "Informational",
          "Debug"
        ],
        "name": "mySyslogDataSource"
      },
      {
        "kind": "PerformanceCounter",
        "streams": [
          "Microsoft-Perf"
        ],
        "counterSpecifiers": [
          "\\Processor(_Total)\\% Processor Time",
          "\\Memory\\Available MBytes",
          "\\LogicalDisk(_Total)\\% Free Space"
        ],
        "samplingFrequencyInSeconds": 60,
        "name": "myPerfCounterDataSource"
      }
    ],
    "destinations": {
      "logAnalytics": [
        {
          "workspaceResourceId": "$($logAnalyticsWorkspace.Id)",
          "name": "myLogAnalyticsDestination"
        }
      ]
    },
    "dataFlows": [
      {
        "streams": [
          "Microsoft-Syslog",
          "Microsoft-Perf"
        ],
        "destinations": [
          "myLogAnalyticsDestination"
        ]
      }
    ]
  }
}
"@

# DCRを作成または更新

New-AzDataCollectionRule -ResourceGroupName $resourceGroupName -Name $dcrName -JsonString $dcrJson -Location $dcrLocation

Write-Host "Data Collection Rule '$dcrName' created/updated."

# VMとDCRを関連付ける

$vm = Get-AzVM -ResourceGroupName $resourceGroupName -Name $vmName
New-AzDataCollectionRuleAssociation -ResourceGroupName $resourceGroupName -RuleId "/subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/Microsoft.Insights/dataCollectionRules/$dcrName" -TargetResourceId $vm.Id -Name "myVmDcrAssociation"

Write-Host "VM '$vmName' associated with DCR '$dcrName'."

このPowerShellスクリプトは、Linux VMのSyslogと基本的なパフォーマンスカウンターをLog Analytics Workspaceに送信するためのDCRを作成し、VMと関連付けます。Windows VMの場合や、より詳細なログ（IISログ、イベントログなど）を収集する場合は、DCRのdataSourcesセクションを適切にカスタマイズする必要があります。

運用監視

Log Analytics KQLは、運用監視において不可欠なツールです。

  • インシデント調査: KQLを用いて特定の期間、リソース、エラーコードでログを検索し、問題の原因を特定します。例えば、過去1時間の特定アプリケーションのエラーログを検索する AppLogs | where TimeGenerated > ago(1h) and Level == "Error"。

  • パフォーマンス監視: パフォーマンスカウンターデータ（VM Insightsなど）を集計し、CPU使用率やメモリ使用量のトレンドを把握します。

  • セキュリティイベント分析: Azure Active Directory (現 Microsoft Entra ID) ログやセキュリティイベントログを監視し、異常なログイン試行や不正アクセスを検出します。

  • カスタムアラート: KQLクエリ結果に基づいてアラートを設定できます。例えば、「過去5分間に特定のアプリケーションでエラーが10回以上発生した場合に通知」といったルールを作成し、オペレーターに自動的に通知します。

  • SLAとバックアップ/DR: Azure Monitor Log Analyticsは、ログ収集サービスに対して99.9%の可用性SLAを2023年11月1日より提供しています[1]。Log Analytics自体はデータレプリケーションと耐久性を提供しますが、長期的なアーカイブや法規制対応のためには、データ保持期間を設定し、必要に応じてデータをAzure Storageなどにエクスポートする戦略を検討します。データ保持期間は最大730日まで設定可能です。

セキュリティ

Log Analytics Workspaceは機密性の高いログデータを扱うため、厳格なセキュリティ対策が求められます。

  • アイデンティティとアクセス管理 (Microsoft Entra ID/RBAC):

    • Azure ロールベースのアクセス制御 (RBAC): Log Analytics WorkspaceへのアクセスはRBACで制御されます。主要な組み込みロールには、「Log Analytics 共同作成者」 (Workspaceへの構成変更とデータクエリを許可) と「Log Analytics 閲覧者」 (データクエリのみ許可) があります[2]。最小権限の原則に基づき、必要な権限のみを付与します。

    • マネージドID: Azure VMや他のAzureサービスがLog Analytics Workspaceにログを送信する際、マネージドIDを使用することで、資格情報をコードに埋め込むことなく安全に認証できます。

  • ネットワークセキュリティ:

    • Azure Private Link: 2024年7月22日の情報によると、Log Analytics Workspaceへのアクセスをプライベートエンドポイント経由に制限し、パブリックインターネットからのアクセスを排除できます[3]。これにより、組織のVNet内からのみWorkspaceにアクセス可能になり、データ漏洩のリスクを低減します。

    • Firewall: Workspaceのファイアウォール設定により、特定のIPアドレス範囲からのアクセスのみを許可することが可能です。

  • データ保護:

    • 保存時の暗号化: Log Analyticsに保存されるデータは、Azure Storageに保存されるデータと同様に、Microsoftマネージドキー (MMK) によって既定で暗号化されます。

    • 顧客管理キー (CMK): コンプライアンス要件が厳しい場合、Log Analytics Workspaceのデータを暗号化するための暗号化キーをAzure Key Vaultで管理するCMKを2024年7月18日の情報で利用可能です[4]。

  • 条件付きアクセス (Conditional Access): Log Analytics Workspaceへの直接アクセスというよりは、Azure PortalまたはAzure CLI/PowerShellを通じてWorkspaceを管理する際のMicrosoft Entra ID認証フローに適用されます。例えば、「信頼された場所からのみAzure Portalへのアクセスを許可する」といったポリシーを設定し、管理アクセスに対するセキュリティを強化します。

コスト

Log Analyticsのコストは主に以下の要素で構成されます[5]。

  • データインジェスト: Log Analytics Workspaceに取り込まれるデータの量（GB単位）に基づいて課金されます。

  • データ保持: データを保持する期間（日単位）に基づいて課金されます。保持期間が長くなるとコストが増加します。最初の31日間は通常無料です（一部のサービスを除く）。

コスト最適化戦略:

  1. コミットメント層の活用: Log Analyticsは、データインジェスト量に応じて従量課金制（PerGB2018）とコミットメント層（Capacity Reservation）を提供しています。コミットメント層は、特定のデータ量を事前にコミットすることで、従量課金制よりもGBあたりの単価が安くなります。日々のデータインジェスト量が予測可能な場合は、適切なコミットメント層を選択することで大幅なコスト削減が可能です。契約期間は1年間。

  2. データフィルタリング: 不要なログや冗長なログを収集しないように設定します。AMAのDCRや診断設定で、ログレベルやイベントIDを絞り込むことで、インジェスト量を削減できます。

  3. データ保持期間の最適化: ログの目的（監査、トラブルシューティング、長期分析）に応じて、適切な保持期間を設定します。例えば、トラブルシューティング用ログは短期間、監査ログは長期間保持するなど、ニーズに合わせて細かく調整します。

  4. エクスポートとアーカイブ: 長期間の保存が必要なログは、低コストなAzure Storageアカウント（例: Blob Storage）にエクスポートし、Log Analyticsでの保持期間を短縮することでコストを削減できます。

落とし穴

Log Analytics KQLの利用にはいくつかの一般的な落とし穴があります。

  1. 予期せぬ高コスト: データインジェスト量の見積もり不足により、想定外の高額な請求が発生することがあります。特に、デバッグレベルのログを無制限に収集したり、多数のVMから全てのパフォーマンスカウンターを収集したりする場合に発生しがちです。

    • 対策: DCRや診断設定でログレベルを適切に設定し、不要なデータをフィルタリングします。コミットメント層の適切な選択と定期的な見直しも重要です。

  2. 非効率なKQLクエリ: 大量のデータに対して非効率なクエリ（例: starts-withの代わりにcontainsを使う、summarizeの前に大規模なjoinを行うなど）を実行すると、クエリの実行時間が長くなったり、リソースを過剰に消費したりする可能性があります。

    • 対策: KQLのクエリ最適化プラクティスを理解し、where句で早い段階でデータを絞り込む、ago()関数を活用して期間を限定する、適切な演算子を選択する、などのベストプラクティスを適用します[6]。

  3. 不適切なデータ保持ポリシー: 保持期間が短すぎて過去の監査やトラブルシューティングに必要なデータが失われる、または長すぎてコストが膨らむことがあります。

    • 対策: 各ログカテゴリの要件（法規制、運用要件）に基づいて保持期間を明確に定義し、定期的に見直します。

  4. セキュリティ設定の不備: Log Analytics Workspaceへのアクセス権が広すぎる、またはPrivate Linkが設定されていない場合、機密データが不正アクセスに晒されるリスクがあります。

    • 対策: 最小権限の原則に基づいたRBACの適用、マネージドIDの活用、可能であればPrivate Linkの導入を徹底します。

まとめ

Azure Monitor Log Analytics KQLは、クラウド環境におけるログ管理と分析を統合し、運用効率とセキュリティを向上させる強力なサービスです。アーキテクチャの理解、適切な設定、そしてKQLを最大限に活用することで、システムの可観測性を高め、迅速な問題解決とプロアクティブな監視を実現できます。一方で、コスト管理、セキュリティ対策、および効率的なクエリ作成には注意が必要です。本記事で解説したプラクティスを参考に、貴社のAzure環境におけるログ戦略を最適化してください。

参考文献: [1] Microsoft Azure. Azure Monitor の SLA. (2023年11月1日). https://azure.microsoft.com/ja-jp/support/legal/sla/monitor/v1_0/ [2] Microsoft Docs. Log Analytics ワークスペースへのアクセスを管理する. (2024年7月18日). https://learn.microsoft.com/ja-jp/azure/azure-monitor/logs/manage-access [3] Microsoft Docs. Azure Private Link を使用して Azure Monitor をセキュリティで保護する. (2024年7月22日). https://learn.microsoft.com/ja-jp/azure/azure-monitor/logs/private-link-security [4] Microsoft Docs. Azure Monitor Log Analytics でカスタマー マネージド キーを構成する. (2024年7月18日). https://learn.microsoft.com/ja-jp/azure/azure-monitor/logs/customer-managed-keys [5] Microsoft Azure. Azure Monitor の価格. (2024年7月1日). https://azure.microsoft.com/ja-jp/pricing/details/monitor/ [6] Microsoft Docs. Kusto クエリ言語の最適化. (2024年7月15日). https://learn.microsoft.com/ja-jp/azure/data-explorer/kusto/query/query-optimization

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました