This article is contributed. See the original author and article here.

Hello Folks,


 


Lately I’ve had a few conversations regarding Log Analytics workspace design.  More specifically, questions like:


 



  1. Do I create one central workspace with all data?

  2. Should I create one workspace per application?

  3. Should each team have their own workspace?


Design conundrum


Figuring out how many workspaces, you need is determined by one or more of the following requirements:


 



  • Which region do you need to store the data; do you have data sovereignty or compliance issues we need to comply with?

  • Data Retention. How long do you need to keep the data?

  • Data Access. The workspace is the security boundary for Log Analytics. If you have log data from two different teams, that are not allowed to see each other’s data, you’ll need to setup different workspaces.

  • Data Collection.  Solutions and data collection settings are set on workspace level. So, if you turn on collection of warnings in the Application log on Windows servers, that setting will be applied to all connected Windows servers, even if we only need it from some of your servers.


 


These items are really important to figure out since Log Analytics workspace provides by design:



  • A geographic location for data storage.

  • Data security by being able to grant different users different access rights to the data.

  • Scope for configuration of settings like pricing tierretention, and data capping.


 


IT shops these days are setup either in a centralized, decentralized, or an in-between hybrid of both structures. Therefore, the following workspace deployment models have been commonly used to map to one of these organizational structures:


 



  • Centralized: All logs are stored in a central workspace and administered by a single team, with Azure Monitor providing differentiated access per-team.


    • This scenario is easier to manage, search across resources, and cross-correlate logs


  • Decentralized: Each departments or teams runs their own workspaces in a resource group they own and manage. In this scenario, the workspace can be kept secure and access control is consistent with resource access, but it’s difficult to cross-correlate logs.


    • I know in that past I wrote about “Querying multiple Log analytics workspace at once” however I have come to realize that when your organization grow and new resources are added if you are adding new Workspaces, you have to edit all your existing cross-workspace queries.


  • Hybrid: Both deployment models in deployed in parallel.


 



    • This commonly results in a complex, expensive, and hard-to-maintain configuration with gaps in logs coverage.

    • To achieve this we can use the Log Analytics workspace data export method to export from all resource Workspaces to a central Storage account.



data-export-overview.png


 


 



  • Configuration can currently only be performed using CLI or REST requests. You cannot use the Azure portal or PowerShell.

  • The –export-all-tables option in CLI and REST isn’t supported. You will have to provide the list of tables in export rules explicitly.


  • Your Log Analytics workspace can be in any region except for the following:


    • Switzerland North

    • Switzerland West

    • Azure government regions


  • The destination storage account or event hub must be in the same region as the Log Analytics workspace.




    • However, there are a few limitations at this point:



So, I really think that a central Workspace is a more reasonable solution for most organizations that have a need for querying all resources.  If you don’t or seldom require cross-workspace queries, then a decentralized approach may be appropriate.


Manage access to log data and workspaces.


When deploying a centralized model.  You need to manage access to the logs and to administer the workspaces, including how to grant access to:


 



  • The workspace using workspace permissions.

  • Users who need access to log data from specific resources using Azure role-based access control (Azure RBAC) – also known as resource-context

  • Users who need access to log data in a specific table in the workspace using Azure RBAC.


You can view the access control mode configured on a workspace from the Azure portal or with Azure


 

workspace-access.png


 


The 2 Access options are:


 


Workspace-context: with this access, you can view all logs in the workspace you have permission to. Queries in this mode are scoped to all data in all tables in the workspace. And are queried in the Log Analytics workspace itself. By accessing the workspace, selecting Logs from the left side menu and writing your query in the editor.


 

workspace-access-3.png


 


Or


 


Resource-context: this model is aimed at Application teams. Administrators of Azure resources being monitored.  When you access the workspace for a particular resource, resource group, or subscription, such as when you select Logs from a resource menu in the Azure portal, you can view logs for only resources in all tables that you have access to.


 

Queries in this mode are scoped to only data associated with that resource. This mode also enables granular Azure RBAC.


 


For more information about designing your Azure Monitor Logs deployment there is more information in the following documentation.


 


Cheers!


 


Pierre


 

Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.

%d bloggers like this: