Single vs. multiple instances of Log Analytics

[Deleted]

I have multiple client environments streaming data to Log Analytics.  What are the pros and cons to use a single instance versus individual instnaces of Log Analytics. Please point me to the business benefits . Thank you.

[#2]

Hi Avijeet, I'm started to use multiples instances for my clients. But latest the resource "Computer Groups" is launched I have trying to use my costumers on single instance. After that I am keeping my alerts so identified. Recently I think we will can associate a selected type of license to a determined costumer. It`s will be great to use one environment to me on terms of administration.

[#3 · Accepted solution]

With single instance you will have to manage RBAC only on that instance with multiple you will have the burden to manage it on all of them. If you need to create a query that goes across multiple workspaces you will have to explicitly write in the query the workspaces you want to query. If you do not have any regulatory reasons to keep data in multiple workspaces I would suggest to move to a single one. The more data you have the better analysis you can do on your data.

[#4]

Interesting question which I also gave quite some thought. There is no doubt a single instance is easier. However, there are two issues I have in an (large) enterprise environment.
I need to separate the different operate groups such as DBA, Server Ops, Security. They all need their own, customized home page in OMS. I don't see how I can manage that in the same workspace, the RBAC is not that sophisticated.
The other issues is the amount of data in the individual instances and the complexity of the workspaces. DBAs only want data and solutions related to certain Azure Resource Types, they have no interest in e.g. Windows event logs and VM related solutions. Security might also require a much longer retention time then operations. 

In smaller environments I tend to use a single workspace, but in larger ones I'm leaning towards multiple workspaces. Any thoughts on that?

[#5]

Hi I see your pain. To customize pages currently you will have to do some work. Obviously currently to segregate data you can use functions (previously compute groups). Based on functions you can show data for different apps, servers, etc. To visualize that data you can use Azure Dashboards or View Designer. Of course you will have to create separate dashboards for each group which is not an easy work if there many of them and of course it does not work with built-in views. View designer recently introduced some filtering capabilities so hopefully at some point they will enable the possibility to choose particular function and visualize the data based on its scope. Also hopefully they will do that for the built-in views. I've been giving that feedback for quite some time so I hope they will implement it. On segregating data based on RBAC I not so fond in such solution. I think if there is no some regulatory compliance to hide data between different teams I think all teams should see the data. Problems are resolved between teams and working in collaboration rather silos. If there is problem with SQL it may happen that the problem starts within the OS rather SQL itself. This is just one example. So in that case if you cannot cope with the above two currently you would go with more than one workspace but you will loose overall visibility of our envrionment. You can do cross worksapce queries but that is only in the Analytics portal and up to 10 workspaces.

[#6]

Hi, Thanks for sharing the pros and cons of having a shared Log Analytics instance versus multiple workspaces for unique/individual client needs. In the case with multiple Log Analytics workspaces, can you please share the reference model/architecture that meet these needs?

From my perspective, I think we need to consider the following steps for the first client setup and repeat step 2 through step 4 for the next cleint :

1. Have an Azure subscription.
2. Choose a workspace name.
3. Associate the workspace with the subscription.
4. Choose a geographical location.

@Stanislav_Zhelyazkov can you please validate the architecture and process? Thank you.

[#7]

Hi, There isn't reference architecture or model when you have multiple workspaces. It depends on your scenario and requirements why would you have multiple workspaces and how you will use them. The agent even supports connecting to multiple workspaces so you could even have different solutions enabled on different workspaces for the same server. It really depends on your scenarios and your requirements. The steps below are not something that applies to Log Analytics. Log Analytics is an Azure service. As an Azure service you will need to have Azure Subscription. Inside your Azure subscription you choose to deploy Log Analytics with name and region.

[#8]

Other reason for multiple workspaces are the data retention and cost impact. Some data you need 2 years, other only form the last 30 days