File synced and byte synced, these are metric values,
again, time series, timestamped,
numeric measurements that are just here to help you in terms of a
quick eyeball of how the sync group is behaving.
Now, in terms of monitoring, I've mentioned that several times,
let's head on over to my Log Analytics workspace because this
is really where you should be focusing the majority of your
work with infrastructure monitoring, and what you'll want to do,
if you haven't already done so,
is make sure that your on‑premises registered servers are
reporting to the Log Analytics workspace,
and the way that you can do that is, well,
you could make them Arc‑enabled,
and you can sign them in via the extension model,
but if you want to install the Log Analytics agent manually,
you can come to Agents management, download the agent,
and then install providing the workspace ID and either the primary
or the secondary key to get into that machine.
As a matter of fact, the machine I'm teaching on has that agent installed.
If you open up Control Panel after you've installed the Log Analytics agent,
you can customize its behavior by going to the Microsoft
Monitoring Agent Control Panel as you can see here,
and if we go to the Azure Log Analytics page,
this is where you can configure the agent to report to one or more workspaces.
I think I mentioned earlier in the training that you can
multi‑home a Windows Server virtual machine to have it
report to multiple workspaces.
I'm concerned with the second one in the list.
I've evidently got a problem with my first one.
I'm going to remove it from the list and just leave my
production workspace ID right here.
You click Add,
this is where you can provide again the workspace ID and one of
those two keys for that Log Analytics workspace.
Let me stop, and restart that service.
And if we come back to Log Analytics, we can then go to Agents configuration,
and this is where you can customize data collection,
and what I've done here is I've clicked Add windows event log,
and I've added in just a few representative file sync agent logs.
Now there is a whole bunch of them, there is at least eight or nine,
and I've just brought in Diagnostic, Operational,
TieringResults, and I don't want too much telemetry,
so I'm just filtering that to error and warning.
So this is going to ensure that I have file sync
agent data coming into the service.
If I go over to Monitor,
let me show you how we can look at metrics for the Azure File Server service,
the AFS service in the cloud.
If we go to Metrics, Azure Monitor asks us to select a scope.
My sync service is in my contoso‑rg resource group,
so let me scroll down and select it in the list,
click Apply, and this is going to surface available metrics,
and as you can see, Files not syncing, Files Synced,
etc, Server Online Status, this kind of stuff.
Let me select File Sync,
and then we can change the time grain here up at the top to some
other range and granularity if we need to.
This can be a good way to get a quick check on behavior,
but we also can do some pretty useful work here in terms of creating
Azure alert rules based on some of these metrics.
For example, if the server online status is less than one,
raise an alert, you see what I mean.
So we could go to New alert rule,
and this would start off the process of defining an alert,
and it adds the condition in automatically,
and we can customize that if we want to.
And normally, an alert rule that's based on a metric or a query,
you specify the grain here.
So we're going to say, if the operator is less than one,
which as you can see would have fired an alert earlier today,
then that would satisfy the conditions of the alert,
and then when you create an alert rule in Azure,
you create or link to an existing action group,
and an action group is simply a collection of notifications that
you can make either to Azure role holders,
or you could just do direct email, text message,
push, voice notifications.
The reason why these are called action groups is
that in addition to notifications,
you can run code in a variety of different hosted contexts as you can see here.
So that's a powerful engine for sure.
Let me go back to Monitor, and let me go to Logs because
I had mentioned Kusto a few times, the Kusto query language,
this is the query language Microsoft designed for this kind of analytical work.
Let me select my contoso‑rg resource group as our scope,
and then we have a number of virtual tables based on the diagnostic
settings and logs that we're onboarding into this service,
you see.
You can lookup sample queries here by going to the Queries button,
and we could look up by resource type or by category,
by topic, and we can find potentially useful queries that we can run.
I have one actually on my other monitor.
If we're looking at AFS client issues,
we might want to define a query on each of our registered servers.
Remember, if we onboard our registered servers into Log Analytics,
and we customize the event logs that are coming in,
we then can surface that data here in Log Analytics,
and I doubt you'd see a Kusto query on your AZ‑800 or 801 exam,
but just in case you do, the way they work is you have your virtual table,
so that's going to be step one getting familiar with finding which
virtual table or tables is the one that you want.
Event is the virtual table that categorizes and collects all
of your Windows event logs for any Windows machines that are
reporting to the workspace.
And then after the virtual table,
we separate our clauses with the pipe character.
This editor in the portal is very nice in terms of it
has fast IntelliSense as you can see,
so it can bring up all of the various keywords where you
can constrain and format your results.
What's this one saying?
This one says look in the event logs on all connected Windows machines
where the source is Microsoft‑FileSync‑Agent or FileSync‑Management where
the event level name does not equal informational,
so we want to see warning and error messages.
Again, we can adjust the time grain here.
I'm not sure if we'll get any results back here at this point.
Oh we do, good.
And then you might be thinking, geez,
there is a lot of feedback here in terms of columns.
You can customize the computers that you're seeing here by just
selecting the appropriate data ManagementGroupName,
Message, Parameter, I'm trying to reduce noise a little bit in this query,
TimeGenerated type.
So you see the idea.
Now,
another thing you can do here that's kind of cool is that
you can dynamically generate charts,
that's not going to work necessarily for this view,
but one of the benefits of log analytics is being able
to do that kind of granular work.
So let me see here, EventLevel,
let me expand one of these rows to see if there is anything interesting.
So it looks like, in this case, on my localdc1,
we've got a warning, and then we've got EventData,
File Sync service failed to update a particular item.
So you can begin to scope the query using project as an
alternative to using this switcher here,
and you can just select certain columns,
and you can add additional clauses,
so we might want to look only for a particular type of FileSync‑Agent error,
and ideally when we run this query, we want it to return 0 rows.
Again to tie in with monitoring, we can create an alert rule based on that query,
this is called a log search query or a log query,
and the idea, for example,
is that our condition can be whenever this query returns more than say one row,
so if we have greater than 0 rows returned,
then that would fire the alert.
You see what I mean?
Microsoft or Azure will run this query basically on a loop,
that's one of the benefits of the log query so kind
of a custom query architecture.
Lastly about DFS, I have a DFS‑R topology set up here,
it may be a little bit small.
I wish there was a way I could increase the font here.
But anyway, under Namespaces, I've created a single namespace,
\\contosolocal\corpfiles.
I've just got one target here, a shared folder called scripts,
and I'm replicating that scripts folder to another host,
so I have two hosts.
The main host is this one that I'm on right now.
So following Microsoft's guidance,
you would create a sync group that matches your topology and
begin to plug in those shared folders on your primary
registered server into sync groups.
And then you can do the same thing with your secondary servers.
Alright.
And again, just to come back to the interface,
let's come back to our storage sync service,
let me select my dfs‑root sync group.
Although you can have only one cloud endpoint,
you can have multiple server endpoints feeding into that
single bowed endpoint destination.
So either way,
you're going to probably have to refactor your DFS architecture in your
migration and think about how you want to surface it in Azure,
but you do have that flexibility given the limitations that I've outlined thus far.