How To - Event Management
and out as this session concludes as well as the slides so without further ado we're going to really cover how to get started with event management specifically within servicenow so whether you've started to implement event management or you have not yet this is really going to dive deeper into the things you need to kick it off and be successful with it in your servicenow instance so of course we're going to walk through mostly the configuration steps the components you need to set it up to maximize it customize it to your environment especially for those monitoring pools that you may have but we'll also touch on the skills that you need to implement it and keep it up and running we'll leave you with some good materials to take home with you and keep the momentum going but just a deeper dive into today's agenda we're going to start with a recap of what event management does the value it brings to our customers here at servicenow we're going to also touch on the training paths available to you from a servicenow perspective to gain those skills keep them up and running for this particular implementation and then we're going to spend the bulk of the time talking about configuration so both the manual steps there's about six of them that need to be taken to configure event management and tailor it to your environment so we're going to walk through each of those and what they entail i'll show you those steps in my demonstration environment and then we'll talk about guided setup as well to take a quicker approach to getting all those things configured so just to get started with event management that quick recap of the value it brings really high level of how it works before we see it in detail today the bulk of it itom health is really intended to help the it operations folks in your organization to handle that overwhelming wave of alerts that is coming in at them from all angles so a lot of data a lot of events and alerts are coming in from the different monitoring tools that you have and so we handle that by really aggregating that data to make it both manageable and actionable so rather than spending time sorting through all that data that's not necessarily helping to deduce the root cause we want to make sure that we're hitting our op scenes with data that's manageable and actionable to reduce that time to resolution and so to really drive the attention to the things that are most important we really have to prioritize connecting that monitoring data back to the service level and then looking at this from the end user's perspective and prioritizing really what matters to them when it comes to keeping things up and running and optimizing the performance of the services that they're leveraging so what things are affecting user experience what is the overall service status across our organization having that visibility as well as the near real time status of each of those components is going to be very very valuable so of course deducing all that data is one part of the equation the first part of the occasion in our case but when it comes to take action and remediate against those alerts that are coming in we really want to leverage the automated workflow capabilities that servicenow is known for by presenting those workflows at the fingertips of our operations teams so they can then take the relevant courses of action to solve the problems at hand and again kind of reducing that mean time to resolution handling alerts prioritizing accordingly all of those really relevant metrics that are important to our operations teams so over time as our operations folks find the automated workflows that remediate best for specific events the workflows start to prove themselves we can really configure the system to run those workflows immediately as of alert generation rather than waiting for that human interaction so these remediations whether it's to actually remediate on the host against the alert for things like creating an incident right away getting things directed to the right teams to take action those things we're actually going to configure in our lab today to happen upon alert generation so again reducing that time to take action and the last piece of this as this knowledge sort of accumulates over time and the ops teams are getting more familiar with the workflows and automation capabilities available to them within this tool not only is your operations team learning how to best leverage the system but the system will also actually be learning from itself in the sort of continuous feedback loop that we see here detecting what courses of action are most successful and where those are so this is leading us to more proactive and intelligent remediation across the board here we'll take a look at these today when we get to the demonstration environment as well because we have quite a few of these workflows available out of the box you today to activate and turn on now to really deliver on this vision as i mentioned it does start with a lot of that data and so servicenow is really prioritizing pulling in as much data as we can so we can get a clear and correct vision of your organization from a monitoring perspective as well as when it comes to the cmdb and so if you're familiar with servicenow discovery orchestration integration we do leverage that same mid server that's relevant in those applications to make this connection back to servicenow to really pull that data from your different monitoring tools across your environments into the servicenow ecosystem and cmdb if you're not as familiar with the mid server yet from a high level it's agentless it's a lightweight java application that's essentially going to connect those external monitoring tools that you can see listed some of those on the left it's going to connect those monitoring systems back to the mid server that acts as that liaison tool and then back into the servicenow ecosystem to push or pull that data into our environment to start doing the normalization that we're going to look at so of course we'll look at both push and pull connectors today as i mentioned we have quite a few of these connectors out of the box we'll look at the full list in my environment but you can see some of the ones we have out of the box available on the left here one thing to note is that the data is being normalized before it's coming into the system this is really going to help us to sift out any of those redundant unnecessary events and messages and that's what's going to be that first level filtering to leave us with a digestible number of actionable alerts so again we're reducing that noise that's kind of our priority one to prevent our ops teams from wasting time sorting through messages that aren't helping us get to that root cause and i did mention the cmdb we'll talk more about this but essentially these alerts are also going to be bound to their relevant configuration items as found in the cmdb and that's going to be really valuable in the sense that it's giving us that relationship information it's giving us that visibility into okay this alert is coming in it's talking about this host but why does that matter to me what else is that host impacted by across our entire digital state so that's really going to be very valuable visibility information here and so as i mentioned there's quite a bit of noise reduction that's going on a big part of that is the automatic grouping and correlation of alerts so not a lot of the alerts that are coming in are going to be stand alone for the most part they're all going to be part of a larger issue here and so we use several different methods to actually automatically group related alerts for that noise reduction so walk through these quickly but you'll see them in our environment today as well the first one for temporal analysis basically we're leveraging machine learning to find the patterns that come in historically over time and then based on those trends that we're seeing and again this is machine learning so it's running in the background it's looking for those trends that have come in over time it's looking for alerts that should be grouped it makes sense for them to be grouped based on the historical data and it's going to alert a group those alerts that are essentially telling the same story when it comes to topological analysis again this is a machine learning approach but essentially the system is using ci based patterns and it's identifying things like causal relationships that tell the same story so for example when there's a database server that's out and there's three other servers that are directly dependent on that server we don't need 50 different alerts to tell us that same thing that's not helping us to pinpoint that root cause when we're getting lost in that level of noise so it's going to automatically group those alerts based on the core primary alert based on that core ci that for example that database server that the outage is affecting and not necessarily overwhelming us with noise from the other related alerts so looking for those ci relationships in the topological analysis and then the last two methods of grouping these alerts for that noise reduction are less machine learning and more human-defined so just like it sounds essentially at servicenow we respect the fact that you have human experience of your staff and they're able to identify the logical groupings that have taken place should take place based on your specific tools your specific environment things they have seen over time and so you're able to refine those rules to reflect that for example okay when alert a comes in alert b always immediately follows it those two things should be grouped based on your team's expertise and we'll be able to refine those in today's demonstration as well and the last thing to note here when it comes to that grouping capability semi-supervised learning essentially techniques can always be tuned by your human staff who can identify you know maybe an alert has been added to the wrong group or there was a group that should be grouped with these 15 others and it wasn't recognized that's really going to feed that machine learning to continuously improve for future performance so although we're really leveraging machine learning to correlate these alerts to reduce that noise everything can always be tuned and customized to your alert and that's going to make the machine learning stronger over time i just dropped a lot of information on you in a short few minutes here just to recap the value of event management and really why it's important for us i'm going to pause here to check the shot here or any questions if there's any questions feel free to throw those in terry asked what about timed events example first event goes out but not responded to and another alert happens every 15 minutes so that's what's going to be called our flapping events so if they keep happening we can set some settings to actually address that and happy to send out some documentation on the flapping settings that are configurable within event management it'll be within our flapping section of our alert management documentation i'll grab that link at the end here we have a few more minutes any other questions at this point we're going to get a bit more technical as we go on from here on out all right so take to take a break from the event management overview if that sounded like a lot maybe you're not as familiar with the value that event management brings this is brand new we heavily recommend taking some sort of event management training before tackling the event management implementation process these are the two options hosted by servicenow so we have both a self-paced training option for event management as well as an instructor-led option for event management fundamentals i've personally taken the self-paced one it's on your own time you have a lab it's extremely hands-on but i know that the instructor-led gives you some opportunities to ask more detailed questions custom questions based on your environment so both are heavily recommended by servicenow and our partners we'll send out these slides in the recordings for you to check out these links afterwards as well but heavily heavily recommended so for the rest of our time here we're really going to dive into the configuration aspect again this is going to be a lot of information feel free to throw questions in as they come up or we'll have some time at the end to talk through some of these things but we're first going to go through what i call the manual approach to configuration essentially this is going to be the route you'll want to take if you have a more customized environment you really want to take your time go through each of these steps and tailor it to your environment we'll talk about the guided setup option to really i don't want to say spoon feed but give you some more support as you walk through these steps and remind you what each of these things need and what they are so there's two options here we'll go through the manual route first and so from a high level here there are six high configuration steps to have the configuration of event management we'll go through each of these in detail but essentially this whole process is going to start with making sure you have the event management plugin active and ready to go in your environment so if you're not 100 sure that you have event management license in your servicenow environment make sure you talk to you to me to your rep we'll get you connected with the people who can get you that answer if you are licensed for this capability or not but if you are licensed or you're going to be soon for event management you still need to go ahead and submit that request on the now support portal to get that event management plugin up and running in your designated servicenow instance so that's going to be the first step if you're not seeing any of these other steps you probably need to go back and check for that plugin so once we have our event management plugin ready to go we do need to make sure that you have that validated mid server installed and active so as i mentioned this may sound familiar if you've leveraged servicenow discovery orchestration or integrations before that use a mid server it's the exact same application but we're using it with the event management function so as you can see a couple of best practices that we have on this screen it is recommended to have each mid server designated with a single purpose so in this case if you already have mid servers that you're leveraging for discovery it's probably going to be best that you spin up a new mid server and designate it for event management separately that's going to give you that best performance when it comes to ingesting all this data that we're going to put together so how about mid server up have event management active on it as the primary function you can deploy a mid server both on linux or windows depending on your environment this may vary but as a best practice we typically recommend installing that mid server on a windows server because it's really going to maximize the hosts and areas that can be discovered on it and ingesting that data based on the host versus linux is typically limited to other unix hosts we have some additional best practices here we'll send this out as well as the detailed documentation on installation instructions for mid servers and these other best practices but essentially once you have that plug-in active you will need an event management mid server active validated and ready to go so with that mid server serving as that liaison point for the data ingestion we're going to look at how to set up these event source connectors so these are basically those push and pull connectors that we looked at briefly in our slides that are connecting servicenow via that mid server to your monitoring tools that you already have and so a lot of these connectors as we'll see the full list in just a moment are going to be out of the box we've really built out quite a list of out of the box event source connectors based on the monitoring tools that are most common across our customers that will be a growing list but you can customize these connectors as well to monitoring tools that don't already have an out of the box connector available and we'll look at that in my instance to see what that means one best practice to note here as you're setting up these event source connectors it's very critical to work with your monitoring tool teams whoever is managing these different monitoring tools that you'll be connecting to in your organization to make sure you have the correct connection parameters we'll see when we set this up in a moment what that means for different monitoring tools but each of these connectors is going to require those connection parameters and credentials so that servicenow can actually access these different event tables across your different tools at solarwinds at zabx those different areas we need those credentials to be correct in order to have this information digested so make sure you're not doing this in a siloed approach so once we have our data our event data starting to be ingested via those connectors and i do want to pause at that point to call out using our mid server there are various options which we'll talk about using the mid server as an snmp trap setting up apis so there's a few different options to ingest the data but the mid server is going to be required for each of those once we have our data starting to be ingested into our events table and service now this is where we want to start to think about our event rules so essentially this is talking about okay based on all these events coming in now i just have one database of all my events from all these different siloed monitoring tools but as i mentioned our base value of event management and of itom health is to reduce that noise and so we really want to make sure that we're setting these rules say based on all these events coming in from our connectors what should determine if an event should escalate into an alert common things that we see in these roles and again we have quite a few out of the box that we'll look at but we see a lot of thresholds ci based alerting and this is all contributing to the to that noise reduction benefit and as a best practice we do recommend leveraging the out of the box rules available to start out and you can customize of course but we'll show you on the demo how to actually leverage those out of the box event rules based on the monitoring tools that you're using now we're kind of building up the ladder here so once we have our events coming in we have those event rules to really dictate based on these criteria based on these rules what should actually be important enough to become an alert that's actionable to my alert management team my operating team once you've defined that and what generates an alert you want to define the specifics of what alerts actually do and really start to leverage that automated workflow capability that i mentioned the now platform has invested so much in so for example what automatically happens when certain alerts are generated and things that we see quite a bit are things like okay based on specific alert criteria we need to have an incident be created right away we need to get our incident response team looped in our incident management team or things like automatically kicking off specific remediation workflows at the host depending on that criteria of the alert so there's a lot that we can do here to automate upon alert generation to again really speed up that time to resolution get the right teams involved or in some cases even remediate automatically if it's a time sensitive alert we have a lot of out of the box options to support here again so we'll look at those alert management rules that we've created out of the box for you to tune and activate as well so lots of out of the box here for you to leverage and that's probably a trend you've noticed we definitely recommend leveraging the out of the box resources available before you start to customize we have some detailed links that will send out to you no need to jot these down and the last thing i'm going to note here before we go into the demonstration and again we're going to recap each of these steps in the instance so you'll be able to see a bit more information about it but lastly we've defined what generates an alert what happens when these alerts are generated but essentially now we need to define the alert correlation rules and so again that's that last type of that i talked about those different approaches those machine learning approach that actually group these alerts for that second level of noise reduction so this is how your your teams can leverage that customization capability to really tailor how things are are grouped how these alerts are grouped primary versus secondary these are going to be called those alert correlation rules and again this method this more human-based approach to alert correlation is in addition to those ai-based correlation and that cmdb correlation method and the last thing so when an alert is in maintenance mode we definitely don't want or excuse me when a ci is in maintenance mode i should say we don't want to have a bunch of false alerts unnecessary alarm coming into our operator workspace just because something is in maintenance versus being actually down and so by default here basically any ci that has an active change window is going to be automatically marked as being in maintenance status and those alerts based on that ci are going to go ahead and be suppressed within that change window so even if alerts are coming into the operator workspace will go ahead and be suppressed due to that change window being open due to it being in maintenance mode and you can of course customize those maintenance rules turn that default status off under the maintenance rules within the event management module i'm going to pause here before we go into the demonstration any questions on any of those configuration steps before we kind of recap and see those in the environment all right looks like none so far i'm going to switch over my screen here to my demo environment please let me know if at any point this becomes too small or glitches for you i want to make sure we can all see this clearly but in my demo environment i'm going to skip over those first two phases of the configuration so at this point i'm assuming i already have my event management plug-in active installed to my environment again you're going to want to request that through the now support portal if you haven't already in my environment that's active ready to go and i've already gone ahead ahead of time and installed my mid server on my network that's again been a dedicated mid server to event management so i've done those first two steps and i'm going to hop to the third step of configuring event management so at this point i want to start ingesting that data across my different monitoring tools to get that into service now which is going to be done as i mentioned it can be done a few different ways you can have the mid server serve as an snmp trap you can set up custom apis but the easiest and most common way is going to be to leverage these connector definitions to get those push and pull connectors transferring and ingesting that information from your monitoring tools into servicenow so what we're looking at here these are our different connector definitions so you can essentially think of these as templates or forms that have been pre-built by servicenow based on our most popular club excuse me monitoring tools that we see across our customers so it's quite a long list we have about 22 out of the box today so you can see some names you may recommend recognize solarwinds today we'll set up one for zabbix and so again think of these as templates and if i click into for example my xavix connector definition you can see the fields that have been predefined by servicenow in this out of the box template so there's not a lot for us to do here i'll show you how to connect my credentials to this and tell it to connect specifically to my xavix environment but a couple of things to call out here that you'll see within these pre-built connector definitions and if you customize your own so you're going to want to set a value for the default schedule essentially this telling it this connector how often to check that event table at the source and check for new events to bring into servicenow generally that's going to be set similar to this one at 120 seconds so essentially every two minutes every two minutes this connector is going to be reaching back into that zabx event table looking for new events to bring in and ingest into servicenow as i scroll down here you can see any connector instances that i've gone ahead and used this definition to actually connect to my xavix environment which we'll look at in just a moment so i can track any specific connectors i've actually activated based on this format and with our parameters table here i can see exactly what service now needs to go ahead and establish this connected this connection to xavix in this case so as soon as i test my connection connector instance which i'll do in just a moment it's going to be looking for these parameters to actually go ahead and establish this connection to xavix and again in this case because it's an out of the box connector definition this has all been pre-built out for me so now what i want to do is actually create an instance of that connector to tie it back to my actual xavix environment and start ingesting those events so i've gone to my connector instances this would be where you're going to create a new actual connector based on those definitions or based on your own so for the sake of time i've gone ahead and put a xavix connector together for us and so in opening that up to connect this back to that list of connector definitions we're just looking at the first thing you're going to do when you create a new connector instance is actually select which connector definition you're leveraging so if i click this field i can see that same list we were just reviewing if you customize your own connector definition it'll be on this list as well for you to select and by selecting which connector definition you want to leverage to put this connector together that's what's going to tell this form what specific data points it needs to actually get this up and running so given it a name i've given it my host ip in this case for zabic specifically and again this is why we really emphasize working with your monitoring teams with the two with the teams that are managing these different monitoring tools in your organizations because they're going to be the ones who hold the keys to this information they have the parameters and credentials that you need to set this up successfully and if this does not validate you will not be able to ingest this the event data that's coming in so connection parameters you'll want the credentials as well depending on the type of definition you're leveraging the tool you're leveraging it's going to prompt you with these different forms for the type of credentials and credential fields that are needed we also have some pretty extensive documentation on credentials and how they work within servicenow and then again all those same parameters that we were just looking at and the last component here that mid server again as i mentioned that second step in setting this all up basically a prerequisite is to have that mid server enabled with event management and ready to go because you're going to need to select that liaison point for this connector to run so i'm going to go ahead and test my instance connector again this is going to be required for that data to start ingesting into your environment so because i had the correct connection parameters i had the correct credentials that i've gotten from my tool team here the last thing you want to do to start actually ingesting that event data from in this case our zabic's environment is go ahead and actually activate this particular connected connector instance and that's going to start ingesting this data into servicenow every 120 seconds based on our connector definition that it was defined in we have a question in the chat is there documentation on external connections using credentials absolutely so for we do support cyber arc and we do support a few other third-party credential stores when we pause at the end here for questions i'll grab that link as well and throw it in the chat for you all on that third-party credential store absolutely so now that we've gotten our connector it's tested successfully we've activated it that data should start ingesting from the source i've connected it to so i'm going to go to where that data should be landing which is our all events table under the event management module here so this table is not going to be what you think of when it comes to alerts this certainly is not the operator workspace that our ops team should be working out of this is really going to be the table you go to for that raw event data so this is typically only going to be a concern for our event management teams versus others are only going to be really concerned about those actionable alerts after that noise reduction has taken place which we'll also talk to but essentially when you want this raw event data this is where you can find it and so as we can see just today alone from this one tool that i have a couple tools i have connected in my environment we have over almost 5 000 alerts or excuse me events that are coming in so this is again why that noise reduction can be incredibly important especially at a commercial enterprise level so sifting to my zabic source with that connector that we just reviewed and that's flowing into servicenow i can actually see going over to our right hand column well these are our events that are coming in from zabics i can actually see going all the way over to the right if and when it has actually escalated into an alert and that's going to be leveraging those event rules that we talked about briefly in the slides and we're going to talk about a bit more now i'm going to first click into that actual event record and in this case this event has been processed and turned into an alert as we saw in that right hand column so a couple of things i want to call out about this event form here so for every raw event that we click into from that table you can see it's in a pretty clean format given its raw event data so connectors in the background are actually mapping the raw data points from coming in from the tools from zabbix and to the fields we see here and we'll deep dive on that in just a few minutes as well but a couple of fields to call out for my event management folks on the line here first thing we want to look out for when we're looking into our actual event records is the state so in this case this is how we're able to see that first level filtering that's being applied in this case this event has been processed it's been compared to event rules to determine if it should become an alert if it should be added to a group of alerts or not and so again that's that noise reduction at the event level that's taking place and in our processing notes here at the bottom we can actually see exactly what logic is taking place from the time the event is being pulled into servicenow so we can see at the bottom here in this case okay was processed an event rule was applied which is what made it into an alert it did meet the criteria of that event rule to be escalated to an alert an actionable alert whether that's on its own or added to a group we'll see in just a moment but we can actually see what specific event rule has been applied and just to emphasize here as we mentioned the best practice is to start with some of these out-of-the-box event rules just to get started but as you begin to customize against these event rules and creating your own this is going to be really important for you to actually monitor how those new rules that you're tuning and creating are actually being applied to the different events that are coming in last thing on this is this additional information area so anything else that's coming in from the tool that goes beyond these defined fields and again we'll look at how to actually map this data and customize this but anything else that hasn't been explicitly mapped to come into these fields it's going to fall into this table here or this box here i should say and since this can be really good information just in the event that you want to identify some additional filtering as you're creating your event rules you can identify some trends in this box as well based on this additional information that's coming in from in this case the zabics tool so our event rules are being applied here to escalate into an alert so we're going to take a look at some of those event rules and the out of the box options available to you to kind of customize create your own or tune the available event rules so these are event rules across the different sources that are out of the box so quite a few as you can see whether it's aws as a monitoring tool we have i think it's almost 200 of these out of the box event rules for you to leverage so sticking with our example today i'll go ahead and look up zabbix as my source for these event rules and so even for zabics alone i have quite a few event rules out of the box that i can activate in my environment tune just to make sure again we're going back to that noise reduction to define from an event that's coming in from those four thousand five thousand events coming in of those what should become an actionable alert for my teams to actually spend time on so clicking into one of these zabbix out of the box event rules we can see really what it takes to configure a rule on your own or even to review and start to activate some of these out of the box options so for each of our event rules whether again you're creating your own or reviewing some of these options you'll give it a name you'll give it an order of operations but really what you're going to want to spend some time on here is this event filter part so essentially just like it sounds you're essentially filtering out which specific events should be picked up by this filter and therefore the rule applied to so in this case this out of the box rule is saying any event that comes in from zabbix and has a classification of metric and has an application's name of cpu or performance and again when you're creating these different criterias you can see on the right here our event excuse me event input it has several several fields that typically come in around our zabic's events and the common value examples that it sees for each of those fields so this can really help you to tailor when you're creating your own filters for what event should actually be escalated in this case this can also be fairly dynamic so for example if i add a new criteria and i want to say wanted events description maybe it's not anything so explicit but it does match a regular expression you can be fairly dynamic with these criteria that you're setting here so things like matches a regular expression you could type that out you have the option to make it match a pattern so there's a lot you can do here to actually customize these filters in terms of what you set to be an event to an alert criteria and as a last note here of course if you want to create explicit ignore rules by default all events if they do not match an event rule they're still going to be escalated to alerts by default in the system that is the case so that if any new one-off events are coming in and they don't match any of your explicitly defined event rules if they're still going to get promoted to you to take action on or decide what to do with them in the future they're not just lost in the noise so this is where event rules become really important to have that noise reduction even if it's just these explicit ignorables hey your ops team is saying that a bunch of events came in it's not anything relevant for them no actions needed you can create these filters to make sure they're no longer escalated to the alert level so once we've set our filter here and this is what's going to kind of go back to that data mapping concept that i mentioned when we looked at our raw event form and how that data actually maps from the monitoring tool table into these forms that we have for both events and alerts to make sure we have the information we need in the right places again kind of speeding up this time to resolution making sure teams have the info they need it where they needed to start to act accordingly and so you can really map customize how this works to actually map where the data is going in these desired variables and so again looking at our right hand column we still have those data pills for the expected data in this case coming in from zabics to pool over and match the data to these different variables on our alert form to give us the data we need and then second to last step here going ahead and adding a threshold to our event rule if it makes sense so essentially for example let's say we only want this event to become an alert if it happens let's say four times within two minutes if it happens one time within two minutes based on what our teams know that's probably fine but if it happens more than that it's probably an anomaly and we want to be notified about it at an alert level so you can add thresholds you can also similarly add idle thresholds if it idles after it generates for another two minutes five minutes you can go ahead and have it close out so lots to do there when it comes to thresholds and the filtering to really customize these rules according to your environment and the last thing here is has to do with binding so essentially this is the logic that binds these events and alerts coming in all those data points that were we just looked at in that form to the configuration items within your cmdb that's what's giving us that ci visibility that business level visibility to really make sure we're looking at a service map in servicenow but not only are we seeing the configuration items but also their near real-time status when it comes to monitoring so when it comes to this particular setting we typically recommend you leave this alone as much as possible because this logic is built in to really bind to those ci's as these events and alerts are coming in but just want to know what that is here first any questions on event rules and how that first level filtering works to escalate into alerts all right nothing coming in so far i'll keep an eye on our chat here so the last thing i want to know when it comes to event rules before we go on to our alert management section of this is at the top here we have a machine let me see one question come in is it on the cmdbci table or is it class specific for the cis so it's actually going to be at the whole cmdb level so if it's effect it's going to map based on the host that it's monitoring for it's going to map to that particular ci regardless of where it is in the cmdb so it's that kind of that wider level last thing to note here at the top of our event rules application we see this bar at the top this is again going to be more of a machine learning capability here basically this logic banner is using machine learning to examine all of our events that have been coming in and it's actually going to be recommending out of all of these out of the box rules because there are a lot it's going to look across those out of the box rules and based on our events that it's analyzing let us know which of those rules based on our event data might be best for us so we can click in there machine learning saying hey we analyzed all the events you've gotten in from zabic's or your other connecting sources we want to recommend these couple of rules for you to consider activating in your environment so that might be a good place to start to review your recommendations once you have your events starting to be ingested all right so for one of our last things we're going to take a look at is when it comes to the alert management rules let me shift over there so now that we've defined based on an event what should become an alert we really want to define that automation capability so we have those not that first level noise reduction going on we're filtering what should be in our operator workspace now we want to define what can actually happen as of alert generation to really leverage that automation capability so a couple of those that we see most often are things like i mentioned creating an incident automatically creating a security incident automatically or even things like actually remediating going to that host where that alert is coming in from and actually remediating with a specific workflow that we've built out or even one of these out-of-the-box options so we have several out-of-the-box options as well for our alert management rules to have some of this automatic logic kick off upon alert generation so we'll look at the most common one we see our customers turning on right away which is our create incident on primary out of the box alert rule so now we've opened that up essentially these are pre-built flows to again just like it sounds open that incident automatically based on the details of our alert group so right away and again if you're creating your own it'll look very similar to this you'll fill in these data fields but if i scroll down i can actually see the times that this this particular workflow was kicked off based on my alerts so i can see all the executions of this particular automated flow but very similar to our event rules when we're creating these filters we're again filtering the logic to focus only on the alerts groups to where the criteria is met before it kicks off this automatic workflow so in this case with this pre-built option basically it's saying any alerts any alert groups that have a critical severity and have an empty task in them aka nothing has already been set to kick off from a workflow perspective we want to go ahead and qualify that and we want to use all the data from that primary alert in the group so not the secondary not the later alerts but that primary alert in the group we're going to use data from that one if this criteria is met to kick off this incident creation workflow that we've built out already so again you can modify the filter criteria but that's going to really filter out and select the alerts that are qualifying for this automatic workflow remediation and so our last step of this automatic workflow remediation actions this is really where the rubber is going to meet the road in terms of what action is kicking off and usually this is going to be a flow designer workflow to really dictate what action is taking place again this is all out of the box in this case so go ahead and click to open that workflow here and so as that's loaded here we're leveraging because this is a great incident example for that out of the box alert management rule i want to call out that as a best practice as you're customizing these flows for alert management or for other areas of servicenow always make sure that you're copying the subflow before you modify any of the fields just so you're not impacting other areas of the organization that may be leveraging this particular core flow so go ahead and do that give it a version and this will create a copy of this flow for us to start to customize and tailor for the correct teams that we want to create this incident for if we want to again you can leverage this out of the box but as you'll see when we're actually creating the task open that up here as we're creating this task so in this case i don't want to over complicate this but we're kicking off this remediation flow so when the alerts meet the criteria we've defined in the filter we want to kick off this flow automatically to create the incident so create task is where the meat and potatoes of this task is going to be so you can see out of the box with this flow we're pulling data already from that primary alert in the group this has all been predefined so as we're creating these data fields on the incident record that's being created the data will match up to the fields coming in from that primary alert again the importance of data pills and having that data coming in from zabx correctly but if we want to customize this to really customize how our incident is created and who it's going to we can do that here in the subfloor that we're looking at now so for example i can do things like maybe the assignment group i don't see that on here already i can really customize who within my incident management team and organization should be responsible for this particular incident based on maybe some of the data pill criteria of my alert and again i can keep this dynamic maybe the assignment group that's going to be assigned based on a regex expression based on a scripted variable using these data pills here so definitely not a requirement to do that to customize these as you're leveraging these out of the box workflows you could run this as is and you can review exactly where that data is coming from when it's launching this incident but just to note there's a lot of customization that could take place and most of the time this is going to be out of that flow designer workflow that's really kicking off this action that's taking place i'm going to shift back over to our slides feel free to keep the questions coming as we're coming up towards the end of our presentation here just one thing to note on that as you're leveraging those workflows and making things happen automatically make sure you're remembering to keep in contact with your other team so if you're making an incident go to your incident management team you're kicking off a security alert or excuse me a security incident make sure you're leveraging those teams to see what processes they may already have in place and the last thing i'm going to talk about quickly here before we wrap up and have some time for questions is that guided setup approach that i mentioned so the guided setup option is just going to offer you some extra support and really walk you through step by step those same steps we just went through and then as you get more familiar as you have the training that you need to be comfortable with event management you can certainly always access those same applications same modules that we went through today to kind of tune and refine so essentially guided setup is going to get you the same achievements that we just walked through today it's just a bit simpler of an interface but to know the technical prerequisites for you to using that guided setup approach that we'll look at in just a moment in my environment this should look pretty familiar to you you still want to make sure you have that event management plug-in requested and active ready to go as well as that mid server setup for event management and make sure before you begin guided setup that you've worked with your monitoring teams and you have the credentials and connection information for at least one of your event sources that you'll be connecting to because you'll still need those credentials and parameters to establish those connectors that we looked at so switching back over to my instance for the last time here i'll show you what that guided setup looks like and where that lives so you'll just want to search itom guided setup and essentially it's really just going to walk you through each of the phases that need to be configured in order to have event management up and running so you can see it even we'll walk you through that mid-server configuration task that's prerequisite we have itom guided setup for discovery but for the sake of today's presentation we're really going to hone in on this event management module here and it's going to walk you through to configure you'll click into this it will give you the step-by-step guide to do things like configure the connectors for your different monitoring tools set up those event rules to escalate accordingly map the data as we looked at and give you some support and resources as you walk through that so giving you some guidance along the way and so regardless of if you're leveraging the guided setup approach or that manual approach that we walked through earlier on we heavily heavily recommend consulting with the different teams in your organization we have some core recommendations on the screen here but making sure you're not doing this in a silo making sure you're not putting yourself in a box talk to your security team talk to your monitoring teams especially as there are credential requirements things like we had in the question about external data stores make sure you understand your organization's rules and posture around that before you begin this process and of course as you're doing things like incidents and event management of course loop in those teams and work with them as well so just to wrap up here in our last few minutes key takeaways right we really want you to connect to those monitoring tools maximize the data that you're bringing into servicenow because the whole value of event management of itom health is to pull that data in give you that single source of truth give you visibility across your organization across those hosts and make sure you can remediate accordingly and you can't do that unless you have full visibility of the monitoring status and of your organization so connecting to those monitoring tools to get that data correlation in make sure you have those proactive operations reduce the noise set up those event rules so you have only meaningful and actionable alerts hitting your operator workspace to reduce that that noise and that meaningless time sorting through data that's not necessarily helping to get to that root cause and remediate automating with those alert rules really taking advantage of those automated workflows that we looked at and then of course if you want to leverage that guided setup to get started that will really speed up the process of going through the configuration again we'll send this out as well as the recording we do have some additional resources through for you here as well as quite a few links throughout the slides that we went through so we'll send out the slides with all those hyperlinks available to you but with that that comes to the end of our presentation i'm going to stick around for a few minutes to answer any questions that may trickle in but if you have to jump and do the rest of your day thank you so much for attending our event management how-to clinic there should be a survey that pops up as you close out of this webinar if you wouldn't mind spending a few minutes answering those questions but other than that best of luck on your event management journey and please let me know if you have any other questions or concerns have a great rest of your day and i'll stay on for a few minutes to answer some questions that came in here so it looks like there is one question that came in why subflows and not core flows so you can certainly leverage the core flows as you're building out those alert management rules however if you're modifying those fields and you're customizing it it's just the best practice to copy a sub flow so that you're not interrupting any other areas of the platform that's leveraging that same core flow any other questions coming in from the chat and qa all right not seeing anything else coming in with that i'm going to stop the share close out of the webinar i hope everyone has a great rest of your day and week thank you so much again for attending feel free to email with any additional questions and take care everybody bye
https://www.youtube.com/watch?v=UEkKPp9BJs8