When it comes to monitoring and reporting on our SD-WAN manager, we're going to find that this is
a conversation around what Cisco calls alarms, events, and logs. And so let's go ahead and start
with the first topic, which is alarms. Alarms are what we're going to spend the most time
interacting with. For the most part, as network admins, we're going to care greatly
about the alarms when they're going off. These typically mean that we have some kind of urgent
action item that needs to be resolved. This is especially relative to events, which events are a
little bit more informative than they are, hey, there's something that needs to be done that can
certainly not be the case at times. But again, alarms are really telling us that something is
broken and we need to change it. Now, as usual, there's going to be a level of severity associated
with our alarms. The most critical alarm is going to be, you know, what we might expect, which is a
critical level. Now, critical, as I wrote it out here in red, is going to be given a red icon in
the UI. And so that's definitely going to catch our eyes when we're having problems. Then we next
have major. Major is drawn with a yellow icon to try to get our attention. This is where things get
a little bit different depending on which version of code you've been running,
because we have a medium level of alerting, and this is green, followed by the last one, which is
minor, and that is blue. Now, the reason why I said this is potentially going to be interesting
based on the level of code you're running is that Cisco has actually recently changed. Well, let me
be more clear with the arrow here. Medium and minor got swapped. So I'm going to say there was
a recent swapping of this, depending on when you're watching this video. It might not be so recent
anymore, but the point is that if we're running an older version of manager, especially if it's
truly Viptela vManage in the title, then you're probably going to see them swapped. Why did they
swap? Well, because Viptela originally had medium in blue and minor in green, because they felt like,
well, minor alerts are the ones that are like, you know, we think of green as being everything
is okay, right? Like, don't worry too much about this. And that's great, except that's not the
scheme that Cisco uses in all of their other products. Cisco has the red, yellow, and green
to say that, hey, there's really urgent tasks and some not so urgent tasks, and then some tasks you
should really take care of. And they use blue as the, like, hey, just don't even worry about this.
They usually call it informational. Now, they didn't change it to informational. They kept it
as minor. But again, there's no right or wrong answer to whether green should be here or here,
or blue should be in either one of those. Cisco just really wanted to synchronize it with the
rest of their products. And so the good news is the names didn't change. We still have critical,
major, medium, and minor. And yeah, might throw us off a little bit that this medium is between
major and minor, but it is what it is. Now, what's going to be very important to us as network
admins is that we are going to want to configure notifications. Alarms can trigger notifications.
As we might imagine, we are going to want a text in the middle of the night, as much as anybody
wants a text in the middle of the night, I suppose. But if the network is indeed down and we have
critical problems, the notifications would probably be ideal so we don't find out at 8 a.m. that the
network has been down all night. So what can we do with notifications? Well, primarily in the UI,
we're going to find that we have two options. We can send an email, which probably isn't going to
cut it for us. Emails are not typically going to wake us up in the middle of the night or alert us
to what's happening if we're not really paying that much attention to our phones, and that's
fine. But if we do want email notifications, which can be part of a holistic approach to notifications,
we're going to need to configure an SMTP server just to make sure that manager knows how to send
an email, and that's great. The other option is the popular way to do this these days is simply
to allow us to configure a webhook. Rather than manager being individually capable of somehow
sending text notifications, we can send webhooks. Webhooks can be configured to do a lot of things.
For example, specifically, Cisco likes to point out that we can use this to send notifications
into WebEx as well as Slack via their APIs, and so that's good. I mean, WebEx and Slack can both
be configured to alert our phones, but naturally, we can also make custom applications that can send
text messages. Now, it's worth noting that I can, in most cases, send an email to our... well, how do we
want to say this? I can send a text message via email. We can do this with most service providers.
For example, my phone number, which is a bunch of numbers in a row, however many numbers there are,
either way, you can send an email to this number and then at my service provider dot
com or whatever it is. So many of us on our service providers, we can receive text if we
get an email at this specific email address. So I could actually use the email notification
to send a text to my phone via email. So we have ways of sending texts, but we're not going to find
in the manager graphical user interface that we have a radio button that says, okay, send a text
on notification. But we can indeed send notifications and we can configure it in
one way or another to get text notifications to my phone. So let's pause coming away from
the chalkboard to actually see where this is configured and where this is seen in our manager,
because we haven't spent a lot of time looking at log messages and the like. And indeed, we are
going to go to this tab called logs in order to see our alarms and our events and our different
types of logs, which we're about to talk about. I can also come up to monitor and click down here
on logs, but it really just takes us to this tab over here. Now there's a lab environment. There's
not a lot going on in here. I don't see any alarms or anything like that, but this is where we'd see
a history of a nice timeline of this. I can actually click on events and I can see what
this would look like. I can see that events are first of all categorized differently. We'll talk
about that in a moment, but this type of timeline will show up on here when we're just, we're not in
a lab environment where there's really not a whole lot going on. I can also click on alarm notifications
here to see if there have been any notifications and if not, or if I need to configure it, I can
configure my alarm notifications. I can decide which types of alarms to notify on, which is
important because I need to decide what level of severity that I want to report on. And then also
whether it's going to be an email or a webhook type of situation. So we see that we've got
built-in webhooks for WebEx and Slack, like we mentioned, and then we also can do custom webhooks
if we want to configure those to do, you know, maybe notifications on our custom
NOC software or whatever it is that we are using to monitor the SD-WAN. So that is alarms. Next up
is the concept of events. We took a brief look at events there, and events are going to be similar
to alarms, but they are generated for different occurrences. And so these are typically, again,
less of action items and they are a little bit more informative, but the difference can be a
little bit nuanced at times. Either way, we have events categorized, again, I use the colors here,
as critical events, which would be in red. We have major events. So far this looks very familiar.
Major events are in yellow. And then we have minor events in green. Yeah, this is a little
different because now we just got done saying that minor's in blue for monitoring, for alarms rather.
And so that's great and all, except that's it. We're done. There is no medium categorization.
There are no blue colors here with events. So it is slightly different, and it's important
that we recognize that. So that is how events come together. And then there's logs. So lastly,
we have the concept of logs. There are two primary log types. We have our audit log,
and I can use this to see pretty much any activity in manager. So I can see my users, what they're
logging in, what they're doing. But naturally, this pushes down to all of my control components
and edges. So it's really over the architecture as a whole. I can also look and see the access
control list logs. When I configure access control lists, I'm able to make, let's say,
like a deny statement and whatever I'm denying. And then I can add the log statement as part of
that. In the UI, it's just a checkbox that I say, hey, I do want to log this information.
And that's going to go into the access control list log. So if there's a user having problems
accessing an app, I can go into the access control list log and find out if that user's traffic is
getting denied by an access control list, so long as I'm enabling logging in my ACLs.
Now, last and not least, this is all well and good. I can log into the UI and see all of these
alarms and events and logs. But access to data is important. And so I need the ability to
see this data in a lot of ways. So first of all, I can export this as CSVs. I can log into
the manager interface, and I can go to look at my alarms or my events, and I can export this out,
basically putting it into a spreadsheet. I can also export this via REST API. So I can log in,
I can pull my information via REST API and make it a much more automated process.
Now, just keep in mind, though, that only 250 of my REST API sessions are accessible at a time
or can be logged into the system at a time. And so if I'm already doing a lot of automation,
I better be careful about how much I'm logging into my REST API to grab my logs.
So if we're seeing error messages in the logs about my REST API access, then that might be
something I need to consider. But either way, we see that monitoring and reporting is very robust
inside of the SD-WAN architecture, especially logging into manager,
gaining access to my alarms and events and logs, pushing notifications out,
and of course, exporting that data so that I can see it and parse through it.