[Music] hello my name is gerard berte i'm an outbound product manager in the itunes business unit at servicenow this presentation may contain forward-looking statements this is the second part of a series of three videos on getting studied with servicenow item health without any prior discovery or cmdb the scenario that we will cover today is that we will discover windows and linux servers using item basic discovery we will add them manually to the service and generate new alerts against those individual servers in operator workspace we will view how those alerts are grouped together and how impact analysis is visualized using the ai ops capabilities in item health the business outcomes obviously is to show you that you as you add more ci's in your cmdb you benefit from more granular fault identification with enhanced impact and root cause analysis and obviously this reduces the time for operators to identify the main cause of alerts now let's jump on to use case number two for that i will actually add two servers to the service map and i will do that manually so as i go to the map first of all the map by itself has nothing except an entry point and an application ci which i which was created when the service was created but let's if we go to the full map we want to edit that map and add those two servers now i remember that i have actually discovered two services two servers and i will going to add them manually here so the first one is the linux server i'm going to type linux server and i know it has an ip of 56.50 and i will add this server the next thing i'm going to do is actually add another ci in parallel this is going to be now a windows server and all i did was actually discover those servers by specifying their ip address and their login credentials and for that it's also another ip184 so here's what my map looks like what i'm going to do now is generate alerts against those two servers so map should be reflected here so let's actually create the first event against the linux server so i'm going to copy the name and generate an event let's say from xenos i'm going to make it a minor alert remove the event i'm going to say it is ready to be processed i'm going to remove the alert number it's going to be a minor event from xenos and i'm not sending this event to the service anymore so i'm going to remove the additional information i'm going to remove the processing nodes and for the node i'm simply going to say give it the name of that node let's send this event and see what happens it should be converted into an alert very soon here it is and alert 172. now let's send some other alerts one being from dynatrace let's say to the other ci so the dot 184 so i'm going to copy the name of that windows server and i'm going to send that event on behalf of that server i'm going to say that it is actually a warning alert from let's change the state to ready remove the alert i'm going to say actually it's a warning event from dynatrace and let's remove the processing nodes sending this event on behalf of dynatrace to on that windows server eventually will generate a an alert into my um into item health here it is what i i wrote 173. now let me generate another alert from app dynamics let's say against the same windows server and i'm going to say this is actually a critical alert i'm going to say it's ready i'm going to remove the alert id here i'm going to say that it is a critical event from app dynamics remove the processing nodes and i'm going to simulate sending this event from app dynamics critical event to from the windows server just take a few seconds for the alert to show up all right so now it's been processed now if i go back to operator workspace and look at my production service i find that it actually has two primary alerts now i have a total of five alerts right two of them are combined into one as i saw from use case number one because they were related to the same ci they were grouped together now it seemed like another primary alert is a group alert yes it is indeed it's a cmdb based grouping which means that the alerts happen on ci's which are related in the cmdb obviously they are since in my map they are related to the same ci so because we have different alerts on the ci's which are related in cmdb those alerts are grouped automatically so if we look at the details of this alert 174 i can see in the activity that a couple of alerts were grouped together because of ci relationships and then one was set as a primary alert because it is the root cause the other one was also set the primary alert because it's the oldest with the highest severity and the grouping also because of cmdb so you see that all these different alerts were processed automatically without doing anything this is the power of item health and it's a iops algorithm working in the background to group alerts the objective is that out of five alerts as you see that i have here the operator is only given two top priority alerts to deal with thus a very significant reduction in alert noise so here i can see that the alert 174 is actually a group alert with three secondary alerts with being the one that i just created against those windows and linux servers thank you this concludes part two of a series of three videos on getting studied with servicenow item health without any prior discovery or cmdb