Azure Monitor 内の Log Analytics ワークスペース、アプリケーション、リソース全体のデータにクエリを実行する

複数のワークスペース、アプリケーション、リソースのデータにクエリを実行するには、次の 2 つの方法があります。

• 明示的 - この記事で説明するように、 workspace()、 app()、または resource() 式を使用して、ワークスペース、アプリ、またはリソースをターゲットにします。
• 暗黙的 - リソース コンテキスト クエリを使用します。 特定のリソース、リソース グループ、またはサブスクリプションのコンテキスト内でクエリを実行すると、そのクエリはこれらのリソースのデータを含むすべてのワークスペースから、関連データを取得します。 リソースコンテキスト クエリは、従来の Application Insights リソースからはデータを取得しません。

この記事では、明示的な workspace()、 app()、および resource() 式を使用して、複数の Log Analytics ワークスペース、アプリケーション、およびリソースのデータを照会する方法について説明します。

Azure Lighthouse を使用して他の Microsoft Entra テナントのサブスクリプションを管理する場合、それらの顧客テナントで作成された Log Analytics ワークスペースは、ワークスペース間のクエリで使用できます。

必要なアクセス許可

考慮事項

• リソース間クエリとサービス間クエリでは、パラメーター化された関数と関数をサポートしていません。その定義には、 adx()、 arg()、 resource()、 workspace()、 app()など、他のクロスワークスペース式またはサービス間式が含まれます。
• 1 つのクエリ内には、最大 100 個の Log Analytics ワークスペースまたは従来の Application Insights リソースを含めることができます。
• 多数のリソースに対してクエリを実行すると、クエリの速度が大幅に低下する可能性があります。
• ログ検索アラート内のクロスリソース クエリは、現行の scheduledQueryRules API でのみサポートされます。 レガシ Log Analytics Alerts API を使用している場合、現行の API に切り替える必要があります。
• 別のワークスペースなどのクロスリソースへの参照は明示的に行う必要があり、パラメーター化することはできません。

関数を使用してクエリを簡略化する

このセクションでは、関数を使用して、または使用せずにワークスペース、アプリケーション、およびリソースに対してクエリを実行する方法について説明します。

関数を使用せずにクエリを実行する

明示的な式を直接使用して、複数のリソースに対してクエリを実行できます。 これらのリソースとしては、ワークスペースとアプリを組み合わせて使用できます。

3 つのワークスペースにわたるクエリの例:

union 
  Update, 
  workspace("00000000-0000-0000-0000-000000000001").Update, 
  workspace("00000000-0000-0000-0000-000000000002").Update
| where TimeGenerated >= ago(1h)
| where UpdateState == "Needed"
| summarize dcount(Computer) by Classification

詳細については、共用体演算子、where 演算子、および サマライズ演算子を参照してください。

関数を使用したクエリ

クロスリソース クエリを使用して、複数の Log Analytics ワークスペースおよび Application Insights コンポーネントのデータを関連付ける場合、クエリは複雑になり、管理が困難になる可能性があります。 Azure Monitor ログ クエリでの関数を利用して、クエリ リソースの範囲設定からクエリ ロジックを分離する必要があります。 この方法で、クエリの構造を簡略化できます。 次の例は、複数の Application Insights コンポーネントを監視し、アプリケーション名毎に失敗した要求の数を視覚化する方法を示しています。

次の例のように Application Insights コンポーネントの範囲を参照するクエリを作成します。 withsource= SourceApp コマンドで、ログを送信したアプリケーション名を指定する列を追加します。 このクエリを関数として保存し、applicationsScoping という別名を付けます。

// crossResource function that scopes my Application Insights components
union withsource= SourceApp
app('00000000-0000-0000-0000-000000000000').requests, 
app('00000000-0000-0000-0000-000000000001').requests,
app('00000000-0000-0000-0000-000000000002').requests,
app('00000000-0000-0000-0000-000000000003').requests,
app('00000000-0000-0000-0000-000000000004').requests

これで、次の例のようなクロスリソース クエリでこの関数を使用できるようになります。 関数のエイリアス applicationsScoping から、すべての定義済みアプリケーションから要求テーブルの和集合が返されます。 このクエリによって、失敗した要求がフィルター処理され、アプリケーション別に傾向が視覚化されます。 parse 演算子はこの例では省略可能です。 SourceApp プロパティからアプリケーション名が抽出されます。

applicationsScoping 
| where timestamp > ago(12h)
| where success == 'False'
| parse SourceApp with * '(' applicationId ')' * 
| summarize count() by applicationId, bin(timestamp, 1h) 
| render timechart

workspace() を使用して Log Analytics ワークスペース全体にクエリを実行する

workspace() 式を使用して、同じリソース グループ、別のリソース グループ、または別のサブスクリプション内にある、特定のワークスペースからデータを取得します。 この式を使用して、Application Insights クエリにログ データを含めたり、ログ クエリで複数のワークスペースのデータにクエリを実行したりできます。

構文

workspace( 識別子)

议論

Identifier: 次の表の明示的な識別子形式は、最も効率的であるため、ワークスペースのクエリを実行する最適な方法です。

ワークスペース名またはワークスペース リソース名のみを使用する他のワークスペース識別子は、ワークスペース間でクエリを実行するときにパフォーマンスが低下し、エラーが発生する可能性があるため、推奨されません。

例

workspace("00000000-0000-0000-0000-000000000000").Update | count

workspace("/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/Contoso/providers/Microsoft.OperationalInsights/workspaces/contosoretail").Event | count

union 
( workspace("00000000-0000-0000-0000-000000000000").Heartbeat | where Computer == "myComputer"),
(app("00000000-0000-0000-0000-000000000000").requests | where cloud_RoleInstance == "myRoleInstance")
| count  

union 
(workspace("00000000-0000-0000-0000-000000000000").Heartbeat), (app("00000000-0000-0000-0000-000000000000").requests) | where TimeGenerated between(todatetime("2023-03-08 15:00:00") .. todatetime("2023-04-08 15:05:00"))

app() を使用して従来の Application Insights アプリケーション全体にクエリを実行する

app 式を使用して、同じリソース グループ、別のリソース グループ、または別のサブスクリプション内にある、特定の従来の Application Insights リソースからデータを取得します。 ワークスペース ベースの Application Insights リソースを使用している場合、テレメトリは、その他のすべてのログ データと共に Log Analytics ワークスペースに格納されます。 workspace() 式を使用して、複数のワークスペース内のアプリケーションのデータにクエリを実行します。 同じワークスペース内にある複数のアプリケーションのデータにクエリを実行するために、クロスワークスペース クエリは必要ありません。

構文

app( 識別子)

议論

Identifier: 次の表の明示的な識別子形式は、最も効率的であるため、アプリのクエリを実行する最適な方法です。

例

app("00000000-0000-0000-0000-000000000000").requests | count

app("/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/Fabrikam/providers/microsoft.insights/components/fabrikamapp").requests | count

union 
(workspace("00000000-0000-0000-0000-000000000000").Heartbeat | where Computer == "myComputer"),
(app("00000000-0000-0000-0000-000000000000").requests | where cloud_RoleInstance == "myColumnInstance")
| count  

union 
(workspace("00000000-0000-0000-0000-000000000000").Heartbeat), (app("00000000-0000-0000-0000-000000000000").requests)
| where TimeGenerated between(todatetime("2023-03-08 15:00:00") .. todatetime("2023-04-08 15:05:00"))

resource() を使用してリソース間でデータを関連付ける

resource 式は、他のリソースからデータを取得するために、リソースをスコープとする Azure Monitor クエリで使用されます。

構文

resource( 識別子)

议論

Identifier: データを関連付けるリソース、リソース グループ、またはサブスクリプションを識別します。

例

union (Heartbeat),(resource("/subscriptions/xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcesgroups/myresourcegroup/providers/microsoft.compute/virtualmachines/myvm").Heartbeat) | summarize count() by _ResourceId, TenantId

union (Heartbeat),(resource("/subscriptions/xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcesgroups/myresourcegroup").Heartbeat) | summarize count() by _ResourceId, TenantId

関連コンテンツ

ログ クエリの概要と、Azure Monitor ログ データがどのように構成されているかについては、Azure Monitor でログ データを分析することに関するページをご覧ください。