Posted in Azure Monitor

Azure Lighthouse why is it so important

Working for a Managed Service Provider (MSP) I have many times faced the challenges of managing multiple separate customers from one single pane. Weather it is multi tenant active directory, single AD or a vanilla Azure tenant. An MSP is only good when they can build tools to manage all customers in a streamlined fashion.

In the Microsoft sphere, partners and large enterprises have faced many of the same challenges. If you are a large enterprise, you might be eligible for an Enterprise Agreement.
As a partner you can apply to become a (tier 1) Cloud Solution Provider (CSP). The tools provided are are far from good enough. The challenge is that you are still bound to the tenant isolation. If you wanted to have a view of all alerts in Azure Monitor for all your customers. You need to create a tool that authenticate against each individual tenant and retrieve this information. Similar to what I did with SCOM.

Project Towboat

Last year I attended a side meeting for MSPs at Ignite. We discussed at scale management in the Azure Portal. We where promised that something called Project Towboat was planned. Since then it have been dead silent.
Out of the blue, Microsoft announced Azure Lighthouse. Promising simplified cross tenant resource management. So what makes this so great?

Delegated resource access

Azure Lighthouse uses delegated resource access. In essence, the customer establish a trust with your (managemen/master) tenant. This allows for the users in the management directory (tenant) to mange resources on behalf of their customers. Many uses Azure AD B2b to manage resources cross multiple tenants. With Azure Lighthouse, you can do that without changing the context of the user.

In my opinion. Here’s some of the features that make Azure Lighthouse a deal breaker.

Cross tenant monitoring in Azure

Azure Monitor is now multi tenant. As long as the resource group or subscription is available for the person using Azure Monitor. Application and infrastructure monitoring is available.

Multi tenant Log Analytics

Log Analytics is a part of Azure Monitor, and is called Azure Monitor Logs. The engine behind is Log Analytics. With Azure Lighthouse, Log Analytics have multi-tenancy capabilities, as it’s already able to query cross subscriptions. For example, activity logs can be connected directly, as if it was your own subscription.
The same applies to Azure storage accounts and virtual machines.

Azure security center for all customers

The beauty with delegated resource management just continues. Another great thing for your security team, apart from Log Analytics is Azure Security center is available in Azure Lighthouse. This means that the team (or that one person) can look at one single dashboard, or write the integration against one tenant.

Summary

With Azure Lighthouse greatly simplifies at scale and cross tenant management. Being tightly integrated with Azure Resource Manager for deployment, as well as Azure Monitor and Security Center for monitoring infrastructure and security.

I am really looking forward to create solutions and working more with Azure Lighthouse. It is a long awaited product, and with this launch, Microsoft is way ahead of it’s competitors.
Expect more dedicated posts on how to manage and automate using lighthouse in the future.

You can read more and find examples on the official Azure Lighthouse documentation and Azure Lighthouse github examples

Metric alerts for Azure monitor logs

A common thing for traditional companies is to have one team responsible for monitoring. A few years ago, this team where close friends with the team provisioning infrastructure. Now, more and more companies are shifting to the “DevOps” world. Even Microsoft have killed SCOM and are only using Azure Monitor. Meaning that the one deployed the code (and the infrastructure) should be responsible for monitoring.  In essence, this is great. But this transition takes time, and one should not underestimate the knowledge of the team who have been responsible for monitoring your entire infrastructure for decades.

If you are familiar with SCOM, you know that rules and monitors is targeted against a class of objects. IE, Windows 2016 operating system. When we move our workloads to Azure, we want to use Azure Monitor to monitor our workloads and VMs.

Enter Log alerts

Log Alerts has been around for quite some time and is commonly used to alert on actual log data. IE custom application logs, Windows event log and so on. But Log alerts has a “hidden” feature, especially for your monitoring teams, not wanting to manage hundreds of duplicate rules.

By using Log alerts with metric measurements you can almost replicate the what discoveries in SCOM does- find resources of a specific type, and attach some kind of monitoring to them. For example, you can create a search query for all your IaaS VMs and alert on their CPU counter.

This will let your monitoring team recreate all their logic, and have control over the entire infrastructure, almost as they had on-permises. At the same time you can leverage more DevOps practices and at the end have every team responsible for their own work.

Kusto examlpe

Below is a simple example that will list all VMs and their processor time. You can create an alert straight from Azure Monitor logs (former Log Analytics) or start from a new alert.

Perf | where ObjectName == "Processor" and CounterName == "% Processor Time" | summarize AggregatedValue = avg(CounterValue) by bin(TimeGenerated, 5m), Computer

Summary

You have the option to monitor multiple VMs using one Alert Rule in Azure Monitor already. But one limitation is that this solution will not add new VMs to the alert rule. And for the time being, it only supports virtual machines
Log alerts are dependent on your query. So as long as your data is available, you can alert on it. Whether it is a web app, a SQL server or a custom log.

With Log Alerts, the transition to a public cloud-based infrastructure might be easier. Your operations teams can use their knowledge and re-create their on-premises monitoring logic as searches.
Application alerts could still be handled by the developers, and you can provision those using ARM templates or similar.

PS: I was going to write a longer post on how to manage and programmatically create log alerts, but with these great examples in Microsoft docs, there’s no need to re-invent the wheel.

SCOM Azure monitor

Microsoft killed SCOM internally

Microsoft no longer uses SCOM to monitor their own workloads. They have replaced their entire SCOM based monitoring stack with Azure Monitor. Allegedly reduced alert noise and administration overhead.

Even if I have moved from SCOM as my main responsibility, I am still very much involved in the whole monitoring and management scope. Over the last years we have heard alot of talk about Azure Monitor replacing SCOM, but that cooled off after a while, maybe until now?

Technology change or cultural change

Microsoft’s story on how they killed SCOM internally was released one day before the official announcement on Operations Manager 2019. But we first heard the story at Ignite in 2018. One may ask, why the re-initiate this topic now?
For SCOM 2019, the focus is to better support hybrid cloud environments, which is good. If Microsoft doesen’t want to use it, should you?

I have written and spoken about the use of SCOM as your hub for Azure Monitor, and my opinion hasn’t changed that much. I belive that transition to you a new monitoring stack will happen with changes to the infrastructure.

When you read the article you’ll see that this was the case for Microsoft as well. There are two quotes i find partculary interesting in the announcement.

“This is not just a technology change, but a culture change,” Baxter says. “It wasn’t only that we would remove SCOM central monitoring, but we had to tell our application teams, now you’re going to manage alerts..”

It was January of 2017 when Baxter got the call. “Our goal was not just to get rid of SCOM, but to move to a Software as a Service (SaaS) solution and retire Virtual Machine (VM) based infrastructure,” she says.


The key here is change in culture. Microsoft went full on DevOps for their internal IT, and by doing that technology will change, and your monitoring will follow.
Further, the showcase mention monitoring was desentralized, which is true. But ther’s another key part of this story. The monitoring team built an integration service between their monitoring stack (Azure Monitor, app insights) and their ITSM system. This system allows for more meta data on each alert etc before ending up as a ticket.

Final notes

If you’re organization runs most of your IaaS on premises, you don’t have to make change yet. Allow the culture to drive the change. A long the way, your SCOM environment can be that integration service between Azure PaaS, FaaS, XaaS and ITSM.