You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
title: Azure Monitor for Service Providers | Microsoft Docs
3
-
description: Azure Monitor can help Managed Service Providers (MSPs), large Enterprises, Independent Software Vendors (ISVs) and hosting service providers manage and monitor servers in customer's on-premises or cloud infrastructure.
2
+
title: Azure Monitor Logs for Service Providers | Microsoft Docs
3
+
description: Azure Monitor Logs can help Managed Service Providers (MSPs), large enterprises, Independent Software Vendors (ISVs) and hosting service providers manage and monitor servers in customer's on-premises or cloud infrastructure.
4
4
ms.service: azure-monitor
5
5
ms.subservice: logs
6
6
ms.topic: conceptual
7
7
author: MeirMen
8
8
ms.author: meirm
9
-
ms.date: 08/06/2019
9
+
ms.date: 02/03/2020
10
10
11
11
---
12
12
13
-
# Azure Monitor for Service Providers
14
-
Log Analytics workspaces in Azure Monitor can help managed service providers (MSPs), large enterprises, independent software vendors (ISVs), and hosting service providers manage and monitor servers in customer's on-premises or cloud infrastructure.
13
+
# Azure Monitor Logs for Service Providers
14
+
15
+
Log Analytics workspaces in Azure Monitor can help managed service providers (MSPs), large enterprises, independent software vendors (ISVs), and hosting service providers manage and monitor servers in customer's on-premises or cloud infrastructure.
15
16
16
17
Large enterprises share many similarities with service providers, particularly when there is a centralized IT team that is responsible for managing IT for many different business units. For simplicity, this document uses the term *service provider* but the same functionality is also available for enterprises and other customers.
17
18
18
-
For partners and service providers who are part of the [Cloud Solution Provider (CSP)](https://partner.microsoft.com/Solutions/cloud-reseller-overview) program, Log Analytics in Azure Monitor is one of the Azure services available in [Azure CSP subscriptions](https://docs.microsoft.com/azure/cloud-solution-provider/overview/azure-csp-overview).
19
+
For partners and service providers who are part of the [Cloud Solution Provider (CSP)](https://partner.microsoft.com/Solutions/cloud-reseller-overview) program, Log Analytics in Azure Monitor is one of the Azure services available in Azure CSP subscriptions.
20
+
21
+
Log Analytics in Azure Monitor can also be used by a service provider managing customer resources through the Azure delegated resource management capability in [Azure Lighthouse](https://docs.microsoft.com/azure/lighthouse/overview).
19
22
20
23
## Architectures for Service Providers
21
24
22
25
Log Analytics workspaces provide a method for the administrator to control the flow and isolation of [log](data-platform-logs.md) data and create an architecture that addresses its specific business needs. [This article](design-logs-deployment.md) explains the design, deployment, and migration considerations for a workspace, and the [manage access](manage-access.md) article discusses how to apply and manage permissions to log data. Service providers have additional considerations.
23
26
24
27
There are three possible architectures for service providers regarding Log Analytics workspaces:
25
28
26
-
### 1. Distributed - Logs are stored in workspaces located in the customer's tenant
29
+
### 1. Distributed - Logs are stored in workspaces located in the customer's tenant
30
+
31
+
In this architecture, a workspace is deployed in the customer's tenant that is used for all the logs of that customer.
32
+
33
+
There are two ways that service provider administrators can gain access to a Log Analytics workspace in a customer tenant:
27
34
28
-
In this architecture, a workspace is deployed in the customer's tenant that is used for all the logs of that customer. The service provider administrators are granted access to this workspace using [Azure Active Directory guest users (B2B)](https://docs.microsoft.com/azure/active-directory/b2b/what-is-b2b). The service provider administrators will have to switch to their customer's directory in the Azure portal to be able to access these workspaces.
35
+
- A customer can add individual users from the service provider as [Azure Active Directory guest users (B2B)](https://docs.microsoft.com/azure/active-directory/b2b/what-is-b2b). The service provider administrators will have to sign in to each customer's directory in the Azure portal to be able to access these workspaces. This also requires the customers to manage individual access for each service provider administrator.
36
+
- For greater scalability and flexibility, service providers can use the [Azure delegated resource management](https://docs.microsoft.com/azure/lighthouse/concepts/azure-delegated-resource-management) capability of [Azure Lighthouse](https://docs.microsoft.com/azure/lighthouse/overview) to access the customer’s tenant. With this method, the service provider administrators are included in an Azure AD user group in the service provider’s tenant, and this group is granted access during the onboarding process for each customer. These administrators can then access each customer’s workspaces from within their own service provider tenant, rather than having to log into each customer’s tenant individually. Accessing your customers’ Log Analytics workspaces resources in this way reduces the work required on the customer side, and can make it easier to gather and analyze data across multiple customers managed by the same service provider via tools such as [Azure Monitor Workbooks](https://docs.microsoft.com/azure//azure-monitor/platform/workbooks-overview). For more info, see [Monitor customer resources at scale](https://docs.microsoft.com/azure/lighthouse/how-to/monitor-at-scale).
29
37
30
-
The advantages of this architecture are:
31
-
* The customer can manage access to the logs using their own [role-based access](https://docs.microsoft.com/azure/role-based-access-control/overview).
38
+
The advantages of the distributed architecture are:
39
+
40
+
* The customer can confirm specific levels of permissions via [Azure delegated resource management](https://docs.microsoft.com/azure/lighthouse/concepts/azure-delegated-resource-management), or can manage access to the logs using their own [role-based access](https://docs.microsoft.com/azure/role-based-access-control/overview).
41
+
* Logs can be collected from all types of resources, not just agent-based VM data. For example, Azure Audit Logs.
32
42
* Each customer can have different settings for their workspace such as retention and data capping.
33
43
* Isolation between customers for regulatory and compliancy.
34
44
* The charge for each workspace will be rolled into the customer's subscription.
35
-
* Logs can be collected from all types of resources, not just agent-based. For example, Azure Audit Logs.
36
45
37
-
The disadvantages of this architecture are:
38
-
* It is harder for the service provider to manage a large number of customer tenants at once.
39
-
*Service provider administrators have to be provisioned in the customer directory.
40
-
*The service provider can't analyze data across its customers.
46
+
The disadvantages of the distributed architecture are:
47
+
48
+
*Centrally visualizing and analyzing data across customer tenants with tools such as Azure Monitor Workbooks can result in slower experiences , especially when analyzing data across more than 50+ workspaces.
49
+
*If customers are not onboarded for Azure delegated resource management, service provider administrators must be provisioned in the customer directory, and it is harder for the service provider to manage a large number of customer tenants at once.
41
50
42
51
### 2. Central - Logs are stored in a workspace located in the service provider tenant
43
52
44
53
In this architecture, the logs are not stored in the customer's tenants but only in a central location within one of the service provider's subscriptions. The agents that are installed on the customer's VMs are configured to send their logs to this workspace using the workspace ID and secret key.
45
54
46
-
The advantages of this architecture are:
47
-
* It is easy to manage a large number of customers and integrate them to various backend systems.
55
+
The advantages of the centralized architecture are:
48
56
57
+
* It is easy to manage a large number of customers and integrate them to various backend systems.
49
58
* The service provider has full ownership over the logs and the various artifacts such as functions and saved queries.
50
-
51
59
* The service provider can perform analytics across all of its customers.
52
60
53
-
The disadvantages of this architecture are:
54
-
* This architecture is applicable only for agent-based VM data, it will not cover PaaS, SaaS and Azure fabric data sources.
61
+
The disadvantages of the centralized architecture are:
55
62
63
+
* This architecture is applicable only for agent-based VM data, it will not cover PaaS, SaaS and Azure fabric data sources.
56
64
* It might be hard to separate the data between the customers when they are merged into a single workspace. The only good method to do so is to use the computer's fully qualified domain name (FQDN) or via the Azure subscription ID.
57
-
58
65
* All data from all customers will be stored in the same region with a single bill and same retention and configuration settings.
59
-
60
66
* Azure fabric and PaaS services such as Azure Diagnostics and Azure Audit Logs requires the workspace to be in the same tenant as the resource, thus they cannot send the logs to the central workspace.
61
-
62
67
* All VM agents from all customers will be authenticated to the central workspace using the same workspace ID and key. There is no method to block logs from a specific customer without interrupting other customers.
63
68
64
69
### 3. Hybrid - Logs are stored in workspace located in the customer's tenant and some of them are pulled to a central location.
@@ -81,4 +86,4 @@ There are two options to implement logs in a central location:
81
86
82
87
* Generate summary reports using [Power BI](../../azure-monitor/platform/powerbi.md)
83
88
84
-
*Review the process of [configuring Log Analytics and Power BI to monitor multiple CSP customers](https://docs.microsoft.com/azure/cloud-solution-provider/support/monitor-multiple-customers)
89
+
*Onboard customers to [Azure delegated resource management](https://docs.microsoft.com/azure/lighthouse/concepts/azure-delegated-resource-management).
description: Learn how to effectively use Azure Monitor Logs in a scalable way across the customer tenants you’re managing.
4
+
ms.date: 02/03/2020
5
+
ms.topic: conceptual
6
+
---
7
+
8
+
# Monitor delegated resources at scale
9
+
10
+
As a service provider, you may have onboarded multiple customer tenants for Azure delegated resource management. [Azure Lighthouse](../overview.md) allows service providers to perform operations at scale across several tenants at once, making management tasks more efficient.
11
+
12
+
This topic shows you how to use [Azure Monitor Logs](../../azure-monitor/platform/data-platform-logs.md) in a scalable way across the customer tenants you’re managing.
13
+
14
+
## Create Log Analytics workspaces
15
+
16
+
In order to collect data, you’ll need to create Log Analytics workspaces. These Log Analytics workspaces are unique environments for data collected by Azure Monitor. Each workspace has its own data repository and configuration, and data sources and solutions are configured to store their data in a particular workspace.
17
+
18
+
We recommend creating these workspaces directly in the customer tenants. This way their data remains in their tenants rather than being exported into yours. This also allows centralized monitoring of any resources or services supported by Log Analytics, giving you more flexibility on what types of data you monitor.
19
+
20
+
You can create a Log Analytics workspace by using the [Azure portal](../../azure-monitor/learn/quick-create-workspace.md), by using [Azure CLI](../../azure-monitor/learn/quick-create-workspace-cli.md), or by using [Azure PowerShell](../../azure-monitor/learn/quick-create-workspace-posh.md).
21
+
22
+
## Deploy policies that log data
23
+
24
+
Once you’ve created your Log Analytics workspaces, you can deploy [Azure Policy](../../governance/policy/index.yml) across your customer hierarchies so that diagnostic data is sent to the appropriate workspace in each tenant. The exact policies you deploy may vary depending on the resource types that you want to monitor.
25
+
26
+
To learn more about creating policies, see [Tutorial: Create and manage policies to enforce compliance](../../governance/policy/tutorials/create-and-manage.md). This [community tool](https://github.com/Azure/Azure-Lighthouse-samples/tree/master/Azure-Delegated-Resource-Management/tools/azure-diagnostics-policy-generator) provides a script to help you create policies to monitor the specific resource types that you choose.
27
+
28
+
When you've determined which policies to deploy, you can [deploy them to your delegated subscriptions at scale](policy-at-scale.md).
29
+
30
+
## Analyze the gathered data
31
+
32
+
After you've deployed your policies, data will be logged in the Log Analytics workspaces you’ve created in each customer tenant. To gain insights across all managed customers, you can use tools such as [Azure Monitor Workbooks](../../azure-monitor/platform/workbooks-overview.md) to gather and analyze information from multiple data sources.
33
+
34
+
## Next steps
35
+
36
+
- Learn about [Azure Monitor](../../azure-monitor/index.yml).
37
+
- Learn about [Azure Monitor Logs](../../azure-monitor/platform/data-platform-logs.md).
38
+
- Learn about [cross-tenant management experiences](../concepts/cross-tenant-management-experience.md).
0 commit comments