I'm actually experiencing some issues on this machine.
It crashes when I click Select Computers, so I'm going to have to walk
you through the rest of this. You're going to select the remote
machine that you've configured, and then lastly, you can optionally
filter to grab only particular logs, particular kinds of events.
If you need to change the credential, that's what the Advanced button is.
And at that point, you're ready to go.
I've got one collector initiated subscription already set up, and you
can see its metadata here. One source computer,
it's dc1, Collector Initiated where I'm going to the Forwarded Events log. If I
double‑click that, it will allow us to get into the query filter. And you can
see I'm just saying Any time, Event level can be,
I forgot to actually select this.
So let me choose, probably you're not going to want
to do everything like I am here,
but you get the idea. You choose the verbosity of
the logging, By log or By source.
You could just say show me particular event sources if you're looking at
a particular service. You might want to just subscribe to occurrences of
a particular event ID number or keyword.
This is actually a pretty cool technology, no question about it.
So from here on out, we could create some artificial traffic.
Like let me do a mstsc to open up a Remote Desktop connection
against dc1, and let me do some failed logons. That didn't
work, so let me try another account.
Okay, so that should trip off some security‑related events.
Now remember, in a collector‑initiated subscription,
this machine is periodically going to query dc1 and
ask, do you have any events for me?
And it looks like we haven't had a refresh In a little while here
because we haven't yet seen, let's see, 1221. It looks like these are a
couple of minutes stale. But these are, in fact, all coming from the
security log. And you can see here that the computer that's generated
these events is dc1.timw.info.
The forwarded events is all well and good.
But like I said in the theory part of this lesson,
you really want to start thinking about centralized event log
management. And we can do that if you're already in Azure by
using the Log Analytics workspace.
So you create one of these resources in your subscription, and you come
down to Agents management. And you can onboard your local servers by
installing the Windows or Linux agent on those machines, providing the
workspace ID and one of the two keys.
Now don't worry.
I regularly regenerate my keys, so I'm not concerned about having
these in plain text. But in your environment, you definitely want to
make sure that you don't leak this data, all right? So that would
allow you to onboard those machines.
Now it seems to me that this machine I'm teaching on,
I've already onboarded to Log Analytics.
I can verify that by opening up Control Panel and seeing if
I have, which I do, a Microsoft Monitoring Agent Control
Panel. If I go to Log Analytics,
I can verify that the Microsoft Monitoring Agent has
successfully been configured, and I am handshaked, if that's
the word, handshook, into that workspace ID.
So I'm sending Telemetry remote measurement data.
Now, what is that data that's going from these agents?
Well, that's what Agents configuration is all about.
And particularly, I want to draw your attention to these first two tabs,
Windows event logs and Windows performance counters.
Initially, nothing is collected, so you choose which log or
logs you want, and you can remove any that you may not need
anymore, as you can see here.
So right now, I've cut this down to application system.
What if I want to add security? I can filter the event logs. Whoops,
that's to filter the active list.
Let me go to Add windows event log and go to Security and bring that
guy in. And you can adjust the degree of verbosity that you want to
see. And that would immediately, during the next update cycle, that
change would immediately be honored on the basis of your agent
systems. And notice that we can also do the same thing for collecting
performance counters.
We can add performance counters in from the list, provider list, and
then we can choose our sample rate in seconds.
And so this is a great way for us to leverage centralized
management of not only our Windows event logs, but also
Performance Monitor counters from Azure. And then if you're
wondering, well, how do you report on this data?
What you do is use the Kusto Query Language. If you go down to Logs,
that will bring us into this query interface where we can see all of
that log data surfaced as these virtual tables.
Let me show you what I mean.
If I go to Queries, and then if I come down to Virtual Machines, let me
try to find one that's interesting here, a lot of IIS stuff. I was trying
to look just for CPU stuff, CPU entries. What data is being collected?
Virtual Machine free disk space.
Okay, well how about I load that into the editor?
The Kusto language allows you, it's a centralized, it's a standardized, really,
query language that has some similarities to Splunk, has some similarities to
SQL The idea is that you find which virtual table contains the log data that
you're looking for, and then you can fine tune those results using the pipe
character along with different keywords. And so this one is looking at virtual
machine available memory, and you can adjust the time range, either in the
query, this is saying in the last hour, or we can adjust it up here
graphically. And that's going to assume that you have data that's been
aggregated.
I just very recently, whoops! That's looking at a particular VM
too. I just recently onboarded some machines, so I'm not surprised
that it's not coming back with data.
But anyway, it's worth your time and worth your while to get up
to speed with KQL for your career's sake.
And if you plan to take other Azure exams, it'll also be relevant
there. My Pluralsight colleague, Robert Cain, has created at least
two excellent Pluralsight courses on KQL, so I strongly suggest that you check those out.