🍟

Log Analytics のリージョン間レプリケーションを試して制限や注意点を確認する

Masato Ueda

2025/06/07に公開

はじめに

Log Analytics のリージョン間 Replication が一般提供 (2025/05/21)
有効化した以降に収集するログを、指定したセカンダリリージョンにも複製する機能。既存ログは複製されない。
セカンダリワークスペースは、プライマリワークスペースと、同じリソースID で同一構成になる。セカンダリワークスペースは、Azure Portal 等に個別のリソースとしては見えない（ストレージアカウントの GRS のような感じ）。
フェイルオーバーはユーザー自身が API を叩いて実行。リージョン障害などで MS が自動実行するものではない。フェールバックも同様。
フェールオーバーは DNS の名前解決結果が変わることで実現。ログの収集もクエリも、セカンダリに対して実行されるようになる。
レプリケーションの有効化、フェイルオーバー、フェールバックの実行は API を叩く必要があり、Azure Portal から GUI での操作ではできない。(2025/06/04 時点)
コストは、レプリケートされたデータの量によって課金 (2025/06/04 時点で ¥52.514/GB)。 → Azure Monitor の価格

主な制限事項や注意点

Application Insights、 VM Insights、 Container Insights は利用できない。また、PrivateLink (AMPLS) をフェールオーバー中は利用できない等、いくつか制限あり。→ デプロイに関する考慮事項
利用可能リージョンは注意が必要だと思われます。 → サポートされているリージョン
特に、西日本リージョンをセカンダリ（レプリケーションの場所）とすることが現時点ではできない点は注意。

プライマリとセカンダリは同一リージョングループで組み合わせる必要がある。例えば、東日本リージョンをプライマリ、　韓国中部リージョンをセカンダリは可能。東日本リージョンをプライマリ、米国西部をセカンダリはできません。
どのリソースから収集したログをレプリケーションするか、データ収集エンドポイント(DCE) を設定したデータ収集ルール (DRS) を割り当てることで明示する必要がある。 DCE を設定していない場合には、Log Analytics Workspace のレプリケーションが有効になっていても、アクティブなワークスペース（基本的にはプライマリワークスペース）にのみログが送られるようです。

構成・動作イメージ

レプリケーションを有効化すると、DCE とセカンダリワークスペースが、作成されます。
インジェストエンドポイントを介して収集するログが、プライマリワークスペースとセカンダリワークスペース双方に対して複製されるようになります。

正常時

フェールオーバーした時

フェールオーバー時には、名前解決の結果がセカンダリ側に変わり、そちらにログが収集されるようになります。アラートやログのクエリなども、セカンダリのワークスペースに対して実行されるようになります。

補足 : DRS に DCE を紐づけた場合と、紐づけていない場合

わかりづらいですが、一応、表にしておきます。

DRS に DCE を紐づけたか	通常時のログ送付先	フェールオーバー時の送付先	備考
紐づけていている DRS でログを収集	プライマリワークスペースとセカンダリワークスペース　両方	プライマリワークスペースとセカンダリワークスペース、両方（リージョン障害の場合、プライマリ側は収集出来ないが、レプリケーション自体は試す）	レプリケーションを有効にした LAW に対して、レプリケーションする形でログを送付する、本来の使い方。
紐づけていない DRS でログを収集	アクティブなワークスペースのみ（つまり、プライマリワークスペースのみ）	アクティブなワークスペースのみ（つまり、セカンダリワークスペースのみ）	それほど重要なリソースではないがレプリケーションが有効な LAW にログを送っているといった構成で、コストを抑制したい等の理由がある場合には、レプリケーションをさせないようにも出来る。

DCE を紐づけている場合には、レプリケーションが実施されます。

一方、紐づけを行っていない場合は、従来通りアクティブなワークスペース（プライマリワークスペース）にのみログが送られます。

例えば、それほど重要なリソースではないが、レプリケーションが有効な LAW にログを送っているといった構成で、その一部リソースについてはコストを抑制したい等の理由がある場合には、レプリケーションをさせないようにも出来るかなと思います。

紐づけをしていない状態でも、フェールオーバー後にはアクティブになったセカンダリワークスペースにログが収集されるので、東西どちらかでログが取れてさえいればいい（一元管理できなくても、ログがある程度残っていればOK）といった場合には、選択することがあるのかもしれません。

設定の流れ

今回は西日本リージョンをプライマリ、東日本リージョンをセカンダリとする構成で試します。

Log Analytics Workspace のレプリケーションを有効化して、DCRとの関連付けを作成し、確認をしながらフェールオーバー/フェールバックを試してみます。 API は Azure Cloud Shell (Azure CLI) を使ってキックしていきます。
流れは以下の通りです。

Step	概要
1. レプリケーションの有効化	API を叩く形で Log Analytics Workspace のレプリケーションを有効化します。これにより、セカンダリワークスペースとデータ収集エンドポイント (DCE) が作成されます。
2. データ収集ルールを適用する	Log Analytics Workspace の東/西両方にログを送付したいリソースについて、データ収集ルール (DRS) に 1. で作成されたデータ収集エンドポイント (DCE) を関連付けします。
3. 状態確認	フェールオーバー前に、レプリケーションが成功していることを確認します。セカンダリリージョンに対するクエリなども試し、フェールオーバーできる状態であることを確認します。
4. フェールオーバーの実行	API を叩いてフェールオーバーを実行します。フェールオーバーの操作は Activity Log に記録されます。
5. フェールオーバー後の状態確認	3. 同様に、フェールオーバー後の Log Analytics Workspace の状態を確認します。
6. フェールバックの実行	4. 同様に、API を叩いてフェールバックを実行します。操作は Activity Log に記録されます。

0. API を叩くにあたり利用するコマンド (Azure CLI)

まずは一通り使うコマンド類をまとめておきます。

変数の設定

AzureCLI

# 変数の設定　この値を組み合わせて、各操作での API のエンドポイントを指定しています。
MySubscriptionID="<- subscription ID ->"
MyResourceGroupName="<- Resource Group Name ->"
LogAnalyticsName="<- LAW Name ->"
APIver="2025-02-01"

レプリケーションの有効化

西日本リージョンをプライマリ、東日本リージョンをセカンダリとする場合の API のエンドポイントを設定してます。

AzureCLI

# 対象となる LogAnaltics Workspace の リソースID を指定。
url=https://management.azure.com/subscriptions/$MySubscriptionID/resourceGroups/$MyResourceGroupName/providers/Microsoft.OperationalInsights/workspaces/$LogAnalyticsName?api-version=$APIver

# az rest コマンドを使って API を叩き、レプリケーション機能を有効化。
az rest --method PUT \
    --uri $url \
    --body '{
    "properties": {
        "replication": {
            "enabled": true,
            "location": "japaneast"
        }
    },
    "location": "japanwest"
}'

Log Analytics Workspace の状態確認

AzureCLI

# 対象となる LogAnaltics Workspace の リソースID を指定。
url=https://management.azure.com/subscriptions/$MySubscriptionID/resourceGroups/$MyResourceGroupName/providers/Microsoft.OperationalInsights/workspaces/$LogAnalyticsName?api-version=$APIver

# az rest コマンドを使って API を叩き、レプリケーション機能が有効化されているか、フェールオーバしているかなど、状態を確認する。
az rest --method GET \
    --uri $url

Failover の実行

AzureCLI

# locations として セカンダリのリージョンを含み、かつ最後に /failover を付けた形の API のエンドポイントを設定
failoverURL=https://management.azure.com/subscriptions/$MySubscriptionID/resourceGroups/$MyResourceGroupName/providers/Microsoft.OperationalInsights/locations/japaneast/workspaces/$LogAnalyticsName/failover?api-version=$APIver

# POST で Failover を実行する
az rest --method POST \
    --uri $failoverURL

Failback の実行

AzureCLI

# 元のプライマリ ワークスペースに戻すため、  API のエンドポイントを設定
failbackURL=https://management.azure.com/subscriptions/$MySubscriptionID/resourceGroups/$MyResourceGroupName/providers/Microsoft.OperationalInsights/workspaces/$LogAnalyticsName/failback?api-version=$APIver

# POST で Failback を実行する
az rest --method POST \
    --uri $failbackURL

1. レプリケーションの有効化

それでは、実際に Azure CLI を使って、LogAnalytics のレプリケーションを有効化し、Failover を実行してみます。
API を叩くと、比較的すぐ1 分以内くらいで実行結果が返ってきてました。 replication のプロパティは以下のように、 "enabled": true で、 "provisioningState": "EnableRequested" となりました。

# - 略 -
    "replication": {
      "createdDate": "2025-06-02T08:16:54.8188506Z",
      "enabled": true,
      "lastModifiedDate": "2025-06-02T08:16:54.8188506Z",
      "location": "japaneast",
      "provisioningState": "EnableRequested"
    },
# - 略 -

自動作成される DCE は、Log Analytics Workspace と同じリソースグループ内に、 dce-la-jpwest-8d1bd1b7e2f54bba85dba1aff8946 のような、　dce + <LAW名> + <LAW のリソースID の一部> という形式で、作成されました。
今回は 1-2分で、Azure Portal 上に、自動作成された DCE が表示されてきました。

レプリケーションの有効化実行結果 : 全文

レプリケーションの有効化

$ MySubscriptionID=" Subscription ID "
$ MyResourceGroupName="rg-logrep-west"
$ LogAnalyticsName="LA-jpwest"
$ APIver="2025-02-01"
$
$ url=https://management.azure.com/subscriptions/$MySubscriptionID/resourceGroups/$MyResourceGroupName/providers/Microsoft.OperationalInsights/workspaces/$LogAnalyticsName?api-version=$APIver
$
$ az rest --method PUT \
    --uri $url \
    --body '{
    "properties": {
        "replication": {
            "enabled": true,
            "location": "japaneast"
        }
    },
    "location": "japanwest"
}'

レプリケーションの有効化実行結果

{
  "etag": "\"c001d292-0000-2400-0000-683d5df60000\"",
  "id": "/subscriptions/<-- Subscription -->/resourceGroups/rg-logrep-west/providers/Microsoft.OperationalInsights/workspaces/LA-jpwest",
  "location": "japanwest",
  "name": "LA-jpwest",
  "properties": {
    "createdDate": "2025-06-02T08:15:59.793505Z",
    "customerId": "d9e40808-43d1-4d2a-8f4f-80828333c87f",
    "features": {
      "enableLogAccessUsingOnlyResourcePermissions": true,
      "legacy": 0,
      "searchVersion": 1
    },
    "modifiedDate": "2025-06-02T08:16:54.8184947Z",
    "provisioningState": "Updating",
    "publicNetworkAccessForIngestion": "Enabled",
    "publicNetworkAccessForQuery": "Enabled",
    "replication": {
      "createdDate": "2025-06-02T08:16:54.8188506Z",
      "enabled": true,
      "lastModifiedDate": "2025-06-02T08:16:54.8188506Z",
      "location": "japaneast",
      "provisioningState": "EnableRequested"
    },
    "retentionInDays": 30,
    "sku": {
      "lastSkuUpdate": "2025-06-02T08:15:59.793505Z",
      "name": "pergb2018"
    },
    "workspaceCapping": {
      "dailyQuotaGb": -1.0,
      "dataIngestionStatus": "RespectQuota",
      "quotaNextResetTime": "2025-06-03T04:00:00Z"
    }
  },
  "tags": {},
  "type": "Microsoft.OperationalInsights/workspaces"
}
$

2. DCE を紐づけた DRS を適用

作成されたデータ収集エンドポイント(DCE) を、データ収集ルール (DRS) に関連付けます。
Azure Portal から GUI で設定します。
[データ収集ルール] -> [DCE の構成] から [データ収集エンドポイント] をプルダウンで選択します。レプリケーション機能の有効化によって自動作成された DCE があるはずなので、選択します。

この DRS を適用したリソースから収集するログは、プライマリワークスペースとセカンダリワークスペース双方にレプリケーションされるようになります。

3. フェールオーバー前に LAW の状態を確認

API での確認

レプリケーションの有効化後、しばらく時間をおいて、Log Analytics Workspace のレプリケーション機能の有効化が完了したことを確認します。
さきほど有効化直後に確認した "provisioningState"　が "EnableRequested" から "Enabling" へ、最後は "Succeeded" へと変化していきます。
私の場合、 10 分程すれば "Succeeded" になっていました。

# - 略 -
    "replication": {
      "createdDate": "2025-06-02T08:16:54.8188506Z",
      "enabled": true,
      "lastModifiedDate": "2025-06-02T08:16:54.8188506Z",
      "location": "japaneast",
      "provisioningState": "Succeeded"
# - 略 -

レプリケーションの有効化後の確認 : 全文

AzureCLI 確認例

$ az rest --method GET \
    --uri $url
{
  "etag": "\"c001d2c5-0000-2400-0000-683d5e8a0000\"",
  "id": "/subscriptions/<-- Subscription -->/resourceGroups/rg-logrep-west/providers/Microsoft.OperationalInsights/workspaces/LA-jpwest",
  "location": "japanwest",
  "name": "demo-log-rep",
  "properties": {
    "createdDate": "2025-06-02T08:15:59.793505Z",
    "customerId": "d9e40808-43d1-4d2a-8f4f-80828333c87f",
    "features": {
      "enableLogAccessUsingOnlyResourcePermissions": true,
      "legacy": 0,
      "searchVersion": 1
    },
    "modifiedDate": "2025-06-02T08:19:22.9461488Z",
    "provisioningState": "Succeeded",
    "publicNetworkAccessForIngestion": "Enabled",
    "publicNetworkAccessForQuery": "Enabled",
    "replication": {
      "createdDate": "2025-06-02T08:16:54.8188506Z",
      "enabled": true,
      "lastModifiedDate": "2025-06-02T08:16:54.8188506Z",
      "location": "japaneast",
      "provisioningState": "Succeeded"
    },
    "retentionInDays": 30,
    "sku": {
      "lastSkuUpdate": "2025-06-02T08:15:59.793505Z",
      "name": "pergb2018"
    },
    "workspaceCapping": {
      "dailyQuotaGb": -1.0,
      "dataIngestionStatus": "RespectQuota",
      "quotaNextResetTime": "2025-06-03T04:00:00Z"
    }
  },
  "tags": {},
  "type": "Microsoft.OperationalInsights/workspaces"
}
$

Azure Portal からも確認

確認は API を叩かなくとも、 Azure Portal の Log Analytics ワークスペースの「概要」のページからも同様に確認ができます。API version は 2025-02-01 を指定します。

また、セカンダリロケーションも表示されるようになっています。

セカンダリワークスペースにクエリを実行して確認

Azure Portal から、セカンダリワークスペースに対してクエリを実行して、レプリケーションできていることを確認します。
右上 [...] に、「セカンダリリージョンに対してクエリを実行する」があるので、このトグルを ON にしてからクエリすれば OK です。
もしログが取れていない場合には、まだレプリケーションが完了していないか、DRS に DCE が設定されていない可能性があります。

クライアント側での名前解決結果を確認

さてフェールオーバーを行う前に、 Client側 Azure Monitor Agent を導入している Windows Server 上で、どこへログを送ることになっているか、確認しておきます。

ログデータ取り込みのエンドポイント <ワークスペース ID>.ods.opinsights.azure.com → 通信先について詳細はこちら
DCEの構成アクセスエンドポイント <unique-dce-identifier>.<regionname>-1.handler.control。　→ DCE のコンポーネント
DCEのログのデータ受信エンドポイント <unique-dce-identifier>.<regionname>-1.ingest
DCEのメトリックインジェストエンドポイント <unique-dce-identifier>.<regionname>-1.metrics.ingest

を確認し、結果は以下の通り、全て Japan West になっていました。

名前解決結果

PowerShell ログデータ取り込みのエンドポイント

Resolve-DnsName 8d1bd1b7-e2f5-4bba-85db-a1aff8946f6d.ods.opinsights.azure.com

Name                           Type   TTL   Section    NameHost
----                           ----   ---   -------    --------
8d1bd1b7-e2f5-4bba-85db-a1aff8 CNAME  4     Answer     os-oi-ods.trafficmanager.net
946f6d.ods.opinsights.azure.co
m
os-oi-ods.trafficmanager.net   CNAME  4     Answer     ipv4-os-oi-ods-cses-a.japanwest.cloudapp.azure.com

Name       : ipv4-os-oi-ods-cses-a.japanwest.cloudapp.azure.com
QueryType  : A
TTL        : 6
Section    : Answer
IP4Address : 20.18.181.163

PowerShell DCE の構成アクセスエンドポイント

> Resolve-DnsName dce-la-jpwest-8d1bd1b7e2f54bba85dba1aff8946-ek4h-japanwest.z1.handler.control.monitor.azure.com

Name                           Type   TTL   Section    NameHost
----                           ----   ---   -------    --------
dce-la-jpwest-8d1bd1b7e2f54bba CNAME  60    Answer     japanwest.handler.control.monitor.azure.com
85dba1aff8946-ek4h-japanwest.z
1.handler.control.monitor.azur
e.com
japanwest.handler.control.moni CNAME  60    Answer     amcs-prod-wjp-handler.trafficmanager.net
tor.azure.com
amcs-prod-wjp-handler.trafficm CNAME  60    Answer     amcs-prod-wjp-0-handler.japanwest.cloudapp.azure.com
anager.net

Name       : amcs-prod-wjp-0-handler.japanwest.cloudapp.azure.com
QueryType  : A
TTL        : 10
Section    : Answer
IP4Address : 40.74.101.201

PowerShell DCE のログのデータ受信エンドポイント

Resolve-DnsName dce-la-jpwest-8d1bd1b7e2f54bba85dba1aff8946-ek4h-japanwest.logs.z1.ingest.monitor.azure.com

Name                           Type   TTL   Section    NameHost
----                           ----   ---   -------    --------
dce-la-jpwest-8d1bd1b7e2f54bba CNAME  60    Answer     japanwest.prod.la.ingest.monitor.core.windows.net
85dba1aff8946-ek4h-japanwest.l
ogs.z1.ingest.monitor.azure.co
m
japanwest.prod.la.ingest.monit CNAME  60    Answer     gig-la-prod-japanwest.trafficmanager.net
or.core.windows.net
gig-la-prod-japanwest.trafficm CNAME  60    Answer     gig-la-prod-cluster-jpw-5-fe.japanwest.cloudapp.azure.com
anager.net

Name       : gig-la-prod-cluster-jpw-5-fe.japanwest.cloudapp.azure.com
QueryType  : A
TTL        : 10
Section    : Answer
IP4Address : 20.18.181.166

PowerShell DCE のメトリックインジェストエンドポイント

Resolve-DnsName dce-la-jpwest-8d1bd1b7e2f54bba85dba1aff8946-ek4h-japanwest.metrics.z1.ingest.monitor.azure.com  -Type A

Name                           Type   TTL   Section    NameHost
----                           ----   ---   -------    --------
dce-la-jpwest-8d1bd1b7e2f54bba CNAME  60    Answer     japanwest.prod.hot.ingest.monitor.core.windows.net
85dba1aff8946-ek4h-japanwest.m
etrics.z1.ingest.monitor.azure
.com
japanwest.prod.hot.ingest.moni CNAME  60    Answer     japanwest-dcr.prod.hot.ingest.monitor.core.windows.net
tor.core.windows.net
japanwest-dcr.prod.hot.ingest. CNAME  60    Answer     gig-hot-prod-dcr-japanwest-level1.trafficmanager.net
monitor.core.windows.net

Name       : gig-hot-prod-dcr-japanwest-level1.trafficmanager.net
QueryType  : A
TTL        : 60
Section    : Answer
IP4Address : 40.74.101.35

ちなみに DCE のエンドポイントは Portal からも確認できます。

4. LAW のフェールオーバーの実行

それでは、フェールオーバーを実行してみます。
API を叩くと、フェールオーバーが実行されます。

実行結果

# locations として セカンダリのリージョンを含み、かつ最後に /failover を付けた形の API のエンドポイントを設定
failoverURL=https://management.azure.com/subscriptions/$MySubscriptionID/resourceGroups/$MyResourceGroupName/providers/Microsoft.OperationalInsights/locations/japaneast/workspaces/$LogAnalyticsName/failover?api-version=$APIver

# POST で Failover を実行する
az rest --method POST \
    --uri $failoverURL

実行後、特に何も表示されることはなく、プロンプトもすぐ返ってきました。

フェールオーバーのアクティビティログ

フェールオーバーが実行されたのか不安になりますが、アクティビティログを確認すると、しっかり実行されていることがわかりました。 Log Analytics Workspace と DCE のフェールオーバーが行われたことがアクティビティログに記録されていました。

Azure CLI でアクティビティログを確認

$ az monitor activity-log list -g $MyResourceGroupName --offset 24h --query "[?contains(operationName.value, \`ailover\`)].{ resourceId:resourceId, EventTimestamp:eventTimestamp, operationName:operationName.value, operationNameLV:operationName.localizedValue, status:status.value }" -o table
ResourceId                                                                                                                                                                          EventTimestamp                OperationName                                                       OperationNameLV                                 Status
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------  ----------------------------  ------------------------------------------------------------------  ----------------------------------------------  ---------
/subscriptions/<- SubscriptionID ->/resourceGroups/rg-logrep-west/providers/Microsoft.OperationalInsights/locations/japaneast/workspaces/LA-jpwest                  2025-06-06T06:56:23.4554792Z  Microsoft.OperationalInsights/locations/workspaces/failover/action  Failover Workspace                              Succeeded
/subscriptions/<- SubscriptionID ->/resourcegroups/rg-logrep-west/providers/microsoft.insights/datacollectionendpoints/dce-la-jpwest-8d1bd1b7e2f54bba85dba1aff8946  2025-06-06T06:56:09.7851291Z  microsoft.insights/datacollectionendpoints/triggerFailover/action   Trigger failover on a data collection endpoint  Succeeded
/subscriptions/<- SubscriptionID ->/resourcegroups/rg-logrep-west/providers/microsoft.insights/datacollectionendpoints/dce-la-jpwest-8d1bd1b7e2f54bba85dba1aff8946  2025-06-06T06:56:06.7226771Z  microsoft.insights/datacollectionendpoints/triggerFailover/action   Trigger failover on a data collection endpoint  Started
/subscriptions/<- SubscriptionID ->/resourceGroups/rg-logrep-west/providers/Microsoft.OperationalInsights/locations/japaneast/workspaces/LA-jpwest                  2025-06-06T06:56:01.831903Z   Microsoft.OperationalInsights/locations/workspaces/failover/action  Failover Workspace                              Accepted
/subscriptions/<- SubscriptionID ->/resourceGroups/rg-logrep-west/providers/Microsoft.OperationalInsights/locations/japaneast/workspaces/LA-jpwest                  2025-06-06T06:56:01.1912723Z  Microsoft.OperationalInsights/locations/workspaces/failover/action  Failover Workspace                              Started

5. LAW フェールオーバー後の確認

API での確認

コマンドで Log Analytics Workspace の状態を確認してみます。 "failover" のプロパティで "state" が "Active" になっていました。

# - 略 -
    "failover": {
      "lastModifiedDate": "2025-06-06T06:56:13.4994263Z",
      "state": "Active"
    },
# - 略 -

フェールオーバー後の確認 : 全文

AzureCLI 確認例

az rest --method GET \
    --uri $url
{
  "etag": "\"0000bde3-0000-2400-0000-6842910d0000\"",
  "id": "/subscriptions/<- SubscriptionID ->/resourceGroups/rg-logrep-west/providers/Microsoft.OperationalInsights/workspaces/LA-jpwest",
  "location": "japanwest",
  "name": "LA-jpwest",
  "properties": {
    "createdDate": "2025-06-04T04:26:50.5615771Z",
    "customerId": "8d1bd1b7-e2f5-4bba-85db-a1aff8946f6d",
    "failover": {
      "lastModifiedDate": "2025-06-06T06:56:13.4994263Z",
      "state": "Active"
    },
    "features": {
      "enableLogAccessUsingOnlyResourcePermissions": true,
      "legacy": 0,
      "searchVersion": 1
    },
    "modifiedDate": "2025-06-06T06:56:13.4993669Z",
    "provisioningState": "Succeeded",
    "publicNetworkAccessForIngestion": "Enabled",
    "publicNetworkAccessForQuery": "Enabled",
    "replication": {
      "createdDate": "2025-06-05T00:56:50.41872Z",
      "enabled": true,
      "lastModifiedDate": "2025-06-05T00:56:50.41872Z",
      "location": "japaneast",
      "provisioningState": "Succeeded"
    },
    "retentionInDays": 30,
    "sku": {
      "lastSkuUpdate": "2025-06-04T04:26:50.5615771Z",
      "name": "pergb2018"
    },
    "workspaceCapping": {
      "dailyQuotaGb": -1.0,
      "dataIngestionStatus": "RespectQuota",
      "quotaNextResetTime": "2025-06-05T03:00:00Z"
    }
  },
  "tags": {},
  "type": "Microsoft.OperationalInsights/workspaces"
}
masato [ ~ ]$

Azure Portal での確認

Azure Portal の Log Analytics ワークスペースの「概要」のページを覗くと、「このワークスペースはフェールオーバーモードです。データとサービスにアクセスすることはできますが、ワークスペースの設定は変更できません。」と表示され、フェールオーバーされた状態である旨が表示されます。
ただし、それ以外の箇所はフェールオーバーされた状態でも以前のリソースのままで、たとえばリージョンなどは以前のまま JapanWest になっていることがわかります。

また、DCE は、Azure Portal 上では、 json で表示にする必要がありますが、確認すると activelocation が japaneast になっていることがわかります。

クライアント側の名前解決結果を確認

確認の結果は以下の通り、DCE のメトリックインジェストエンドポイント以外は JapanEast へ名前解決されるようになり、ログの送付先が切り替わっていることがわかります。

ログデータ取り込みのエンドポイント : JapanWest から JapanEast へ
DCE の構成アクセスエンドポイント : JapanWest から JapanEast へ
DCE のログのデータ受信エンドポイント : JapanWest から JapanEast へ
DCE のメトリックインジェストエンドポイント : JapanWest のまま

名前解決結果

PowerShell ログデータ取り込みのエンドポイント

Resolve-DnsName 8d1bd1b7-e2f5-4bba-85db-a1aff8946f6d.ods.opinsights.azure.com -Type A

Name                           Type   TTL   Section    NameHost
----                           ----   ---   -------    --------
8d1bd1b7-e2f5-4bba-85db-a1aff8 CNAME  6     Answer     ejp-oi-ods.trafficmanager.net
946f6d.ods.opinsights.azure.co
m
ejp-oi-ods.trafficmanager.net  CNAME  6     Answer     ipv4-ejp-oi-ods-cses-b.japaneast.cloudapp.azure.com

Name       : ipv4-ejp-oi-ods-cses-b.japaneast.cloudapp.azure.com
QueryType  : A
TTL        : 3
Section    : Answer
IP4Address : 40.79.194.118

PowerShell 構成アクセスエンドポイント

Resolve-DnsName dce-la-jpwest-8d1bd1b7e2f54bba85dba1aff8946-ek4h-japanwest.z1.handler.control.monitor.azure.com

Name                           Type   TTL   Section    NameHost
----                           ----   ---   -------    --------
dce-la-jpwest-8d1bd1b7e2f54bba CNAME  60    Answer     japanwest.handler.control.monitor.azure.com
85dba1aff8946-ek4h-japanwest.z
1.handler.control.monitor.azur
e.com
japanwest.handler.control.moni CNAME  60    Answer     amcs-prod-wjp-handler.trafficmanager.net
tor.azure.com
amcs-prod-wjp-handler.trafficm CNAME  60    Answer     amcs-prod-wjp-0-handler.japanwest.cloudapp.azure.com
anager.net

Name       : amcs-prod-ejp-1-handler.japaneast.cloudapp.azure.com
QueryType  : A
TTL        : 6
Section    : Answer
IP4Address : 20.43.70.102

PowerShell ログのデータ受信エンドポイント

Resolve-DnsName dce-la-jpwest-8d1bd1b7e2f54bba85dba1aff8946-ek4h-japanwest.logs.z1.ingest.monitor.azure.com

Name                           Type   TTL   Section    NameHost
----                           ----   ---   -------    --------
dce-la-jpwest-8d1bd1b7e2f54bba CNAME  18    Answer     japaneast.prod.la.ingest.monitor.core.windows.net
85dba1aff8946-ek4h-japanwest.l
ogs.z1.ingest.monitor.azure.co
m
japaneast.prod.la.ingest.monit CNAME  18    Answer     gig-la-prod-japaneast.trafficmanager.net
or.core.windows.net
gig-la-prod-japaneast.trafficm CNAME  18    Answer     gig-la-prod-cluster-jpe-5-fe.japaneast.cloudapp.azure.com
anager.net

Name       : gig-la-prod-cluster-jpe-5-fe.japaneast.cloudapp.azure.com
QueryType  : A
TTL        : 7
Section    : Answer
IP4Address : 172.207.65.130

PowerShell メトリックのデータ受信エンドポイント

Resolve-DnsName dce-la-jpwest-8d1bd1b7e2f54bba85dba1aff8946-ek4h-japanwest.metrics.z1.ingest.monitor.azure.com  -Type A

Name                           Type   TTL   Section    NameHost
----                           ----   ---   -------    --------
dce-la-jpwest-8d1bd1b7e2f54bba CNAME  8     Answer     japanwest.prod.hot.ingest.monitor.core.windows.net
85dba1aff8946-ek4h-japanwest.m
etrics.z1.ingest.monitor.azure
.com
japanwest.prod.hot.ingest.moni CNAME  8     Answer     japanwest-dcr.prod.hot.ingest.monitor.core.windows.net
tor.core.windows.net
japanwest-dcr.prod.hot.ingest. CNAME  8     Answer     gig-hot-prod-dcr-japanwest-level1.trafficmanager.net
monitor.core.windows.net

Name       : gig-hot-prod-dcr-japanwest-level1.trafficmanager.net
QueryType  : A
TTL        : 8
Section    : Answer
IP4Address : 40.74.101.35

フェールオーバー後にクエリを実行してみる

フェールオーバー前のログも含めてクエリできています。また、ブックなどでも引き続き参照ができていました。見かけ上まったくフェールオーバー前と変わりがなく、本当にクエリがセカンダリワークスペースに対して実行されているのか、疑問に思うくらいです。

どこにクエリをしているか確認するため、今回検証している Log Analytics Workspace とは別に、もう一つ Log Analytics Workspace を用意し、そちらへ Log Analytics Workspace の診断ログを保存するようにしました。これで、実行したクエリがどちらのリージョンに対して実行されたのかが、別 Log Analytics Workspace の LAQueryLogs テーブルに格納されますので、確認してみます。
WorkspaceRegion が japaneast になっており、セカンダリワークスペースに対してクエリが実行されていることがわかります。また、isWorkspaceInFailover が True になっており、フェールオーバーが行われていることもわかりました。

6. フェールバックの実行

それでは、フェールバックも実行してみます。

AzureCLI

# 元のプライマリ ワークスペースに戻すため、  API のエンドポイントを設定
failbackURL=https://management.azure.com/subscriptions/$MySubscriptionID/resourceGroups/$MyResourceGroupName/providers/Microsoft.OperationalInsights/workspaces/$LogAnalyticsName/failback?api-version=$APIver

# POST で Failback を実行する
az rest --method POST \
    --uri $failbackURL

フェールバックのアクティビティログ

同様に、DCE と Log Analytics Workspace のフェールバックが行われます。

az monitor activity-log list -g $MyResourceGroupName --offset 24h --query "[?contains(operationName.value, \`ailback\`)].{ resourceId:resourceId, EventTimestamp:eventTimestamp, operationName:operationName.value, operationNameLV:operationName.localizedValue, status:status.value }" -o table
ResourceId                                                                                                                                                                          EventTimestamp                OperationName                                                      OperationNameLV                                 Status
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------  ----------------------------  -----------------------------------------------------------------  ----------------------------------------------  ---------
/subscriptions/<- SubscriptionID ->/resourceGroups/rg-logrep-west/providers/Microsoft.OperationalInsights/workspaces/LA-jpwest                                      2025-06-06T09:18:56.8263978Z  Microsoft.OperationalInsights/workspaces/failback/action           Failback Workspace                              Succeeded
/subscriptions/<- SubscriptionID ->/resourcegroups/rg-logrep-west/providers/microsoft.insights/datacollectionendpoints/dce-la-jpwest-8d1bd1b7e2f54bba85dba1aff8946  2025-06-06T09:18:43.6990066Z  microsoft.insights/datacollectionendpoints/triggerFailback/action  Trigger failback on a data collection endpoint  Succeeded
/subscriptions/<- SubscriptionID ->/resourcegroups/rg-logrep-west/providers/microsoft.insights/datacollectionendpoints/dce-la-jpwest-8d1bd1b7e2f54bba85dba1aff8946  2025-06-06T09:18:41.5894999Z  microsoft.insights/datacollectionendpoints/triggerFailback/action  Trigger failback on a data collection endpoint  Started
/subscriptions/<- SubscriptionID ->/resourceGroups/rg-logrep-west/providers/Microsoft.OperationalInsights/workspaces/LA-jpwest                                      2025-06-06T09:18:36.5767404Z  Microsoft.OperationalInsights/workspaces/failback/action           Failback Workspace                              Accepted
/subscriptions/<- SubscriptionID ->/resourceGroups/rg-logrep-west/providers/Microsoft.OperationalInsights/workspaces/LA-jpwest                                      2025-06-06T09:18:36.1548662Z  Microsoft.OperationalInsights/workspaces/failback/action           Failback Workspace                              Started

フェールバック後の確認

フェールバック後の Log Analytics Workspace の状態は以下のように "failover" のプロパティの "state" は "Inactive" に変わりました。

        "failover": {
            "state": "Inactive",
            "lastModifiedDate": "2025-06-06T09:18:45.7661276Z"
        }

フェールバック後の確認 : 全文

AzureCLI 確認例

az rest --method GET \
    --uri $url
{
  "etag": "\"0100671e-0000-2400-0000-6842b2750000\"",
  "id": "/subscriptions/<- SubscriptionID ->/resourceGroups/rg-logrep-west/providers/Microsoft.OperationalInsights/workspaces/LA-jpwest",
  "location": "japanwest",
  "name": "LA-jpwest",
  "properties": {
    "createdDate": "2025-06-04T04:26:50.5615771Z",
    "customerId": "8d1bd1b7-e2f5-4bba-85db-a1aff8946f6d",
    "failover": {
      "lastModifiedDate": "2025-06-06T09:18:45.7661276Z",
      "state": "Inactive"
    },
    "features": {
      "enableLogAccessUsingOnlyResourcePermissions": true,
      "legacy": 0,
      "searchVersion": 1
    },
    "modifiedDate": "2025-06-06T09:18:45.7661235Z",
    "provisioningState": "Succeeded",
    "publicNetworkAccessForIngestion": "Enabled",
    "publicNetworkAccessForQuery": "Enabled",
    "replication": {
      "createdDate": "2025-06-05T00:56:50.41872Z",
      "enabled": true,
      "lastModifiedDate": "2025-06-05T00:56:50.41872Z",
      "location": "japaneast",
      "provisioningState": "Succeeded"
    },
    "retentionInDays": 30,
    "sku": {
      "lastSkuUpdate": "2025-06-04T04:26:50.5615771Z",
      "name": "pergb2018"
    },
    "workspaceCapping": {
      "dailyQuotaGb": -1.0,
      "dataIngestionStatus": "RespectQuota",
      "quotaNextResetTime": "2025-06-05T03:00:00Z"
    }
  },
  "tags": {},
  "type": "Microsoft.OperationalInsights/workspaces"
}

フェールバック後の Azure Portal とクエリ

フェールバック後は、Azure Portal 上でのフェールオーバー中である表示も消えています。

また、フェールバックの API を実行した時刻 (2025/6/6 18:19) の前後でも問題なくログがとれています。クエリの実行先はフェールバック後に JapanWest に戻っていることがわかります。

まとめ

API を叩く形なの少し面倒でしたが、問題なくフェールオーバー/フェールバックができました。
セカンダリワークスペースへログがレプリケーションできていることも確認できましたし、フェールオーバー/フェールバックしても問題なく収集やクエリができていました。

実際の利用にあたっては、主な制限事項や注意点あたりにも記載しましたが、

東日本リージョンをプライマリ、西日本リージョンをセカンダリとする構成は現時点では不可
既存の LAW で有効化しても、今後取得するログのみレプリケーションされる
Application Insights や VM Insights が対応していない、等の機能制限がある

といったあたりは特にハマりそうな落とし穴かなという気がしますので、注意が必要かなと思います。

参考

本当に全件レプリケーションされているのか？ - 件数を check

確認した範囲では、問題なさそうです。
やはり、プライマリにログが収集される方が早いようではあり、セカンダリの方に最新のログがレプリケーションされるまでは時間差があるようではありますが、時間をおけばデータ件数は同件になっており、問題なさそうです。
参考までに以下に一定期間中での Perf テーブルの件数を、1時間単位で集計した結果を記載しておきます。

フェールオーバー(15:56) / フェールバック(18:19)を実行したタイミングでも、問題なく取れていそうではあります。

KQL - Perf 件数を1時間単位で集計

Perf
| where TimeGenerated between(datetime(2025-06-06 03:00:00) .. datetime(2025-06-06 13:00:00))
| summarize PerfDataCount = count() by bin(TimeGenerated, 1h)

TimeGenerated(by 1h)	Primary LAW - PerfDataCount	Secondary LAW - PerfDataCount
2025/6/6 21:00:00.000	1380	1242
2025/6/6 20:00:00.000	2760	2760
2025/6/6 19:00:00.000	2760	2760
2025/6/6 18:00:00.000	2760	2760
2025/6/6 17:00:00.000	2732	2732
2025/6/6 16:00:00.000	2732	2732
2025/6/6 15:00:00.000	2760	2760
2025/6/6 14:00:00.000	2760	2760
2025/6/6 13:00:00.000	2760	2760
2025/6/6 12:00:00.000	2760	2760

より細かい件数の確認

●プライマリ

●セカンダリ

可視化が上手くいかない場合がある？

私の環境だけかもしれませんが、プライマリでは上手くいくのに、セカンダリワークスペースに対しては可視化(render timechartなど)が上手くいかない事象がありました。何か見落としているかもしれませんが、現時点ではわからなかったので、参考までに記載しておきます。

●プライマリ

●セカンダリ
おなじクエリを実行しても、セカンダリワークスペースでは可視化が上手くいかない。

データ自体はセカンダリにもちゃんとあり、値もしっかり入っている。

| project TimeGenerated, CounterValue に絞ってからなら可視化できる。

本当に東日本プライマリは出来ない？ - できない。`Location japanwest is not supported for replication`

当然、できませんでした。
JapanEast で作成した LAW に対して、JapanEast をプライマリ、 JapanWest をセカンダリにして試しましたが、エラーが出てできませんでした。

AzureCLI

# az rest コマンドを使って API を叩き、レプリケーション機能を有効化。
az rest --method PUT \
    --uri $url \
    --body '{
    "properties": {
        "replication": {
            "enabled": true,
            "location": "japanwest"
        }
    },
    "location": "japaneast"
}'
Bad Request({"error":{"code":"InvalidParameter","message":"Location japanwest is not supported for replication. Operation Id: '46360d60ffeae3906db23b939afdcf17'","target":"properties.replication.location"}})

参考 URL

Log Analytics ワークスペースのリージョン間レプリケーション - 概要や、構成方法、制限事項など
ファイアウォールのエンドポイント - ログデータの取り込みの通信要件
DCE のコンポーネント - DCE の構成や通信要件
LAQueryLogs - レプリケーションを有効にした Log Analytics Workspace 自体の診断ログをどこか（例えば別の LAW)に取ると、LAQueryLogs テーブルが記録されています。isWorkspaceInFailover　に、クエリ中にワークスペースが切り替えモードであったかどうか(True、False) が記録されます。また、どのリージョンに対してクエリを実行したかが WorkspaceRegion 欄に記録されています。これを用いて、目的のリージョンに対してクエリを実行したかどうかを確認することができます。
データ収集ルール作成時のデータ収集エンドポイントの構成について - DCE の hogehoge エンドポイントってなんだ？という時に、オススメ。
Public Preview: Log Analytics Workspace Replication - プレビュー時の blog 記事だが読みやすい

以下の @kongou_ae さんの記事も非常に参考になります。

Microsoft (有志)Publication

Microsoft Azureをはじめとする最新技術情報をお届けします。 ※このPublicationは日本マイクロソフトまたは米Microsoft所属社員による個人の見解であり、所属する組織の公式見解ではありません。 ※Publicationに参加希望の社員は @07JP27までご連絡ください。

はじめに

主な制限事項や注意点

構成・動作 イメージ

正常時

フェールオーバーした時

補足 : DRS に DCE を紐づけた場合と、紐づけていない場合

設定の流れ

0. API を叩くにあたり利用するコマンド (Azure CLI)

変数の設定

レプリケーションの有効化

Log Analytics Workspace の状態確認

Failover の実行

Failback の実行

1. レプリケーションの有効化

2. DCE を紐づけた DRS を適用

3. フェールオーバー前に LAW の状態を確認

API での確認

Azure Portal からも確認

セカンダリ ワークスペース にクエリを実行して確認

クライアント側での名前解決結果を確認

4. LAW のフェールオーバーの実行

フェールオーバーのアクティビティログ

5. LAW フェールオーバー後の確認

API での確認

Azure Portal での確認

クライアント側の名前解決結果を確認

フェールオーバー後にクエリを実行してみる

6. フェールバック の実行

フェールバックのアクティビティログ

フェールバック後の確認

フェールバック後の Azure Portal と クエリ

まとめ

参考

本当に全件レプリケーションされているのか？ - 件数を check

可視化が上手くいかない場合がある？

本当に東日本プライマリは出来ない？ - できない。Location japanwest is not supported for replication

参考 URL

Discussion

構成・動作イメージ

セカンダリワークスペースにクエリを実行して確認

6. フェールバックの実行

フェールバック後の Azure Portal とクエリ

本当に東日本プライマリは出来ない？ - できない。`Location japanwest is not supported for replication`