Alright, let's do this.
In this demonstration,
we'll work with configuring off‑cloud and on‑cloud
machines for monitoring within Azure.
I'm going to focus specifically on Log Analytics.
Alright, so let's open up the portal, jump in here,
and I'm going to start by going to my Log Analytics workspace.
Now how many workspaces you need in your organization?
I would say start with one.
Start with two if you're going to use Azure Sentinel.
Sentinel needs its own workspace.
From there,
it's going to be a question of whether you need to silo monitoring data.
I just have one workspace here in my subscription,
and I want to start by coming down under Workspace Data Sources,
Virtual Machines,
and what this will do is enumerate all Windows and Linux virtual
machines across all regions and subscriptions.
It's going to be a tenant‑wide view,
and to connect an Azure VM to the workspace from here
is just as easy as selecting the VM, clicking Connect,
and Azure deploys the Log Analytics agent to that machine.
Alright.
You also could create a reference during deployment,
like I mentioned earlier,
in your ARM template or your bicep script to inject and onboard the machine.
There is just, there is no one really canonical way to go.
Now can a machine report to more than one Log Analytics workspace?
As of this recording, yes,
but only Windows can do multi‑homing and you configure that in Control Panel,
which I'll show you momentarily.
Alright, so this is for Azure virtual machines.
Now, if you've historically been using the Azure Diagnostics extension,
you have all of your diagnostic stuff in storage accounts.
You can still capitalize on that historical data here.
Notice that there is an entry for Storage account logs.
So you can onboard storage accounts and pull that log data directly from
there and then report on it singly in Log Analytics,
which I think is really fantastic.
Similarly,
your System Center Operations Manager and System Center
Config Manager Management Groups, you can onboard those,
it's actually operations manager and take advantage of that
historical data in an off‑cloud on‑premises environment.
Now, next, let's go up to Settings, Agents management,
and this is where we can download the Windows agent,
as well as Linux agent, and there are some instructions here.
The bottom line is you want to make sure to provide the workspace ID for
your workspace and either the primary or secondary key.
Now these keys you should regenerate regularly because they're sensitive
and they're displayed here in the portal in plain text.
The Log Analytics Gateway is simply a Windows service that acts as a proxy.
So this is the solution to the problem where you have on‑premises
machines that are behind special network restrictions.
As long as they can communicate with the Log Analytics Gateway
on‑prem that can get out to the internet,
that gateway can forward the Log Analytics client data,
the log, whatever you configure here under Agents configuration,
will send it into the workspace.
And then here under Agents configuration,
you specify what event logs and the verbosity of the
logs that you want to capture,
performance monitor counters and their associated sample rate.
You can do the same thing for Linux machines.
Again for Linux, there are Syslog data sources,
and then for IIS, Windows and Linux,
you can collect W3C IIS log files from those machines.
So that's the extent of the configuration there.
Let me minimize the browser here.
I'm pretty sure I've already installed the monitoring agent on this machine.
We'll find out when I click Next.
Yes, it says Repair.
It's just basically a Next, Next, Finish.
The only thing it'll ask you for that you'll need,
as I said before, is you'll need to paste in the workspace ID,
as well as either the primary or the secondary API key.
On Windows, you'll then want to go into the old fashioned Control Panel,
not the newer Settings application, and go to Microsoft Monitoring Agent,
and here, we have what I already told you about,
a reference to OMS.
This is actually Log Analytics,
and this is where you can multi‑home a Windows server system.
Right now, I'm already connected to my workspace,
but I can add an additional one.
Why would I want to do this?
Well, for example, I might want this machine to report,
not only to my Log Analytics workspace for infrastructure monitoring,
but I might have a separate workspace that's associated with
Azure Sentinel for security specific monitoring,
you see.
So that is that.
So far so good, right.
I had mentioned that for a deeper integration between
off‑cloud machines and Azure Resource Manager,
there is Azure Arc.
So let's go over to Azure Arc Servers.
I have a couple of my on‑premises machines already connected.
Let's click Add, and I'm going to generate a script for a single server here.
So what we're going to do is wind up creating a resource in our Subscription
and Resource group hierarchy for this off‑cloud machine.
We provide a Azure region that's associated and what
operating system we're dealing with.
We could communicate with the remote machine for
Azure Arc using a private endpoint.
I'm going to do the public over the internet, though, with HTTPS.
We've got some taxonomic tags, I'll leave all that at the default,
and then I'll download the onboarding script,
which as you can see, it shows you what's going on here,
basically it's just opening up a web request to pull down a
Bootstrapper that then orchestrates the installation of what's
called the Connected Machine Agent.
Remember that for your AZ‑801 exam, okay?
It's called the Connected Machine Agent,
and that's specifically for Azure Arc for Servers or
Arc enabled servers technically.
So now let me open up an elevated Windows PowerShell console,
and I'll go into Downloads and verify that it's there.
Let's see.
Onboarding script, right.
Well let me Get‑ExecutionPolicy Bypass so it'll work.
I'll do .\OnboardingScript.ps1 and it's going to give
us verbose output here by default, which is cool.
It's going to pause and ask us to sign in because,
of course,
we don't want to give anybody the ability to onboard
an off‑cloud VM into Azure Arc,
so we're going to need specific role‑based access
control authorization to do so,
and we'll use a device code based flow in just a moment.
Here we go. So let me copy that code in and let me point my browser to aka.ms/devicelogin.