hi everyone in today's video we're gonna see how servicenow helps you discover and monitor your VMware State my name is John Mario de Luigi I'm part of the outbound product management team for servicenow item and today I'm gonna show you how item visibility allows you to discover and gain service contacts of your VMware resources my counterpart Victoria long is then going to show you how to prevent issues from happening in your VMware resources thanks to item health in order to discover your VMware Resources with servicenow item visibility you can use two different approaches the first one is to configure a discovery schedule like we already did here we very simply need to Define which mid server we want to use we then need to Define how often do we want to run that Discovery schedule in this case we decided to run it on demand but we can decide how frequently we want to run it and then we need to define the Discovery range sets so we basically want to define the discovery IP ranges that we're going to Target in these specific Discovery schedule once we've done that we need to make sure to insert our VMware credentials so in our instance we need to have our user and password basically our read-only credentials for VMware and that would allow us to have visibility of all of our VMware resources that we have on our state this is a very powerful tool because servicenow allows you with only this set of read-only credentials to discover everything they have in your VMware estate in particular you'll be able to popular your cmdb with all these different CI such as vcenter data center even ESX servers we can see in fact they will have a list of all the ESX servers that have been first of all discovered and then added to our cmdb and this is valid for all the other CIS of course whenever we have the respective resources in our state another way to populate our seem to be a keep it up to date is to leverage the mid server extension specifically talking about the vcenter when collectors in this case we have already configured them and we're basically establishing a persistent connection between the mid server and B Center so whenever we have events on our VMware resources such as a machine that is being paused or that has been restarted Etc will have a notification driven discovery that will automatically update our cmdb so now that we have populated and updated our cmdb we can Leverage The cmdb workspace this is a single pane of glass from where we can access details about what we have populated are the cmdb with we can see here clear indicators of our overall cmdbci's health and also of the health of the relationships between the CIS that we have discovered as well as how many new CIS we have and different information about our different sea ice that we have discovered at the very top here we can even perform the intelligent search we can see among our recent searches that we were asking the cmdb workspace to show us the recently discovered ESX servers and as a matter of fact we have the full list of ESX servers that have been recently discovered here we can then navigate to the management tab in order to create cmdb groups Dynamic CI groups Etc so cmdb groups are groupings of Ci's that have properties in common we can even set up new cmdb groups in this way we can identify the group name in this case we want to group together the ESX servers and the group type will be a default group and we just hit save we can now then specify which cmdbcis we want to include in this new cmdb group specifically we can type in ESX server and we can then set even further conditions such as asset location company etc etc because we may have different CIS in different locations or we can set all different sorts of conditions here to group together the cmdbcis so we can just set the policy and then hit save and this is how we made sure to create the cmdb CI group we can then go back to our management Tab and Define a new Dynamic CI group the difference between the Dynamics a group and the cmdb group is that Dynamic CA group actually utilizes the cmdb group for filtering but then exposes the result as an actual CI whereas a cmdb group isn't actually a CI the Dynamics a group in practice history as a logical system of similar or related Ci's they are typically the focus of a technical service offering and here we're dealing with VMware which is basically a technical service offering and that's why it's important to leverage the dynamic CA groups we'll now hit new name the new Dynamics CA group as ESX test one we'll scroll all the way down and Define the cmdb group that we previously set so if we scroll we'll find ESX servers we'll make sure to put it as operational so it will be visible by the system and we'll just hit save once it gets saved we can just view the cmdb 360 data and we'll be able to see how it has been recognized as a technical service so if we go back and open the dependency View and we click details we'll be able to see all the associated Ci's that are part of these Dynamics CA group and in case we have any incident problem or changes that occurred we'll be able to see them in this single and unified view what we can do now is to go to our cmdb key value table where we'll be able to see all the CIS that have a key value so they have a tag we can group them based on the key so if we hit Group by key we'll be able to see how many keys we have in our state we can see perhaps application key Department key location key Etc but in order to gain even more insights we can launch the interactive analysis the interactive analysis is a very simple way for us to visualize our CIS in our state and see how we can group them by key as we did here and we stack them by configuration item class we can see perhaps that for the application key we have 342 VMware virtual machine instances or for the Department key we have 320 VMware virtual machine instances or for the name we have 24 Ci's where the class is cloud subnet and so on and so forth we can get all the details that we want and at the same time we can keep the same classification as we saw before where we're grouping our CI is based on the key once we have a better understanding of the CIS inside our state we can then go and Define the CI type categories so we can group different tags together for Simplicity here we can just see a test tag category that I just created in this specific case I decided to select the application tag key but we can select multiple ones here and then we can go and select the tag based service families and as a matter of fact they created one already that is already including the tag category that we just saw there we can insert different tag categories within the tag based service family it's just a way for us to group things together in this specific case tags and tag categories and then we can go and see which service candidates we have so with servicenow we can leverage the tag-based service families in order to map our services we can see here that we have different service candidates perhaps we can select the media Wiki and we can choose to map the selected service now the list of map services will be processed every 24 hours but in this case we're going to select the media Wiki service and we're going to recalculate it hitting recalculate service this is exactly how the media Wiki service will then be mapped and if we select view map we'll be brought to the service map here as a matter of fact we can click in each element of the service map and we'll be able to see what that is so as an example we can here see that we have a VMware virtual machine instance the media Wiki service is here and we have a series of different VMware virtual machine instances on which the service is running this is a great way to visualize which CIS are involved in your services and to visually understand how your services work if you want to better understand how to set the different relationships that you want to appear in your service Maps you have to then configure the tag based transversal rules in here you'll be able to understand which relationship types you want to have in your Maps so now that we understood how to best leverage our tags in order to visualize our services it's time for Victoria my counterpart to go through how item Health can help you prevent issues from happening from VMware resources and prevent these issues from impacting your business Victoria over to you thank you John for showing us how italm visibility can help you monitor your VMware state now my name is Victoria Lowe and I'll show you how itom health complements everything that John just showed you starting off with the integration Launchpad in the service operations workspace so you're going to have a lot of Integrations whether it's VMware or dynatrace or datadog for example and you need an easy way to set them all up in your servicenow instance so first what we can do is that we can browse all the out-of-the-box Integrations that we have available and for example if you didn't really have a specific one that you're looking for you could first just filter by the type of integration so whether it's just events we can just select this bubble just go for metrics or just looking for any of the log Integrations that are available and can also filter by the event type so push or pull connectors but if you know exactly what you're looking for and it's not very easily searchable by just scrolling through this we can search it directly here so just typing right here um vsphere here we can see all the available out of the box Integrations for vsphere so clicking right here you can select the Asian client collector for the appropriate operating system that you would like to install ACC on and once you've installed this we can go to the policies page to look at all the policies that we've created for vsphere so right now I'll just search up these sphere right here and just for example I'm going to choose just the ESX server metrics policy for vsphere so after selecting the policy vsphere ESX server metrics we can see all the information about the policy right here we can look at the monitored Ci's that we set up so in this case is the ESX server is the monitor CI type you can also see the proxy settings so the agent cluster name is The Crucible proxy agents which we'll go into after this we can also look at the scheduling and set that up and then also look at what credentials are used for this policy now down here we can also look at the check instances so in this case it is the vsphere metric ESX server and going to that page by just clicking here we can see all the information about the check instance and just so you know you have to enter the hostname for the check instance itself which would be right here now going back to what we saw about the proxy agent clusters if we go to the proxy Asian cluster page we can see The Crucible proxy agents that were referred to in the policy page that I showed you previously and clicking here we can see all the agents in the cluster and agents in a cluster enable you to assign that cluster to multiple policies instead of having to assign the agents individually to every policy so that's the benefit of having a proxy agent cluster now going back to integration Launchpad after setup looking at the policies looking at the proximation cluster if you want to look at everything that you already have set up in your environment you can go to the my Integrations tab right here and you can see all the active Integrations as well as any inactive Integrations you may have now staying in the service operations workspace we are going to move on to the service dashboard and here we can see all these services that are set up so depending on how you want to look at your services you can Group by business criticality or any of these other groupings and you can also change the group order or the segmentation of the groups or if you have a lot of services and you can't really find the one you're looking for by just looking at the dashboard itself you can always search it up so I will search up the one that John set up for the purpose of this demo ESX test one and we can see that it is a not critical business service but there are a lot of alerts on it right now so clicking here and then clicking service details we can see all the information about it that we have it is a non-critical technical service it's operational its name is ESX Texas one as well as we can look at the related records so we can see all the alerts that are related to the service as well as all the associated Ci's and you can do this for any of the other services that are also on this dashboard as you can see here moving on to another feature of the service operations workspace which is the express list the express list provides an at a glance view of all the alerts coming to your system where you can easily access all the key information that you need for any which alert that comes into this list which is also a live list so right now we can see that there are four filters that are applied in this scenario I'm going to clear them all and now you can see that we have 717 alerts so if all these alerts didn't match you whether it's not the specific service that you actually care about for your role you can filter here by impacted services it's been the case that you're just perusing the alert list you can just scroll and scroll and scroll some more because there's infinite scroll on this list and look at all the alerts that have come in but if you took a 15-minute coffee break and you left your computer and now you're back and you want to see what just happened in the past 15 minutes we can click right here and set the time to the last 15 minutes so that all the alerts that we'll show here will only be what's occurred in that specific time frame so in the last 15 minutes they've apparently actually been five alerts um which may not be great depending on how severe they are and they are critical so not great but this is also a great example because we can see that in the past 15 minutes there have been five alerts that were all clustered together because they all shared similar descriptions but I will just go back to the all-time time frame just so that we can see all the alerts so looking at the filters there are several ways that you can filter all these alerts that are coming in you can filter it based off of State severity priority Source number configuration items impacted services node description which is free text so for example if I just want to see all the alerts that talk about CPU all I have to do is type CPU and click right here and every alert that contains CPU in the description will now populate the list you can also look at the assign to assignment group Metric name group maintenance and acknowledged and here's a quick look of some of the columns that are available for you to use in your Express list but in this case the only service I care about is the exx technical service so clicking on the impacted Services filter I'm just going to search up ESX test one or I can also just search up ESX and now all the alerts in this list are only alerts that impacted the specific service now looking at the seller right here we can see all the quick information that you need to just understand what the alert was in the first place we can see that the alert was closed which is great but we can also see the resource the metric name The Source the configuration item and some additional information right here and if you want to look at the configuration item all you have to do is click here and a separate tab will open up just so you can get a bit more detail on the configuration item that was affected here we can see the details the related records and the metrics and here are some of the metrics that we can see about the specific CI now going back to the live list of alerts now going back to the live alert list on Express list we're going to open a different alert so by clicking on the description here another side panel pops out with all the same information that I mentioned before where applicable and when the solar panel pops out and you're analyzing the alert information you also have the ability to close the alert acknowledge the alert or create an incident from it and to close the panel all you have to do is just click this preview panel x button right here and you may notice for some alerts they are clustered so for example here we see that there are two alerts which follows the description which have the same description so if I click the arrow right here the two alerts that were grouped together are shown and the reason for the clustering is what we can see in the description right here so if we want to look at the full description of the alert cluster we can see that it is because they both have the same description apart from the configuration item itself or if you click the description of the alert cluster itself we will see the two alerts with their short description then affected configuration items in the side panel that pops up similarly you can see other alert clusters as we scroll down and they were grouped for various reasons as you can see here in the descriptions of the Clusters and another feature that you may find useful as an individual or a team that cares only about a certain type of alert is that you can create and save filters so by default there are four filter conditions that are automatically applied but for the purposes of right now I've cleared them all and let's say for example the state of the alert does not matter to you you want to see all the alerts whether they're open or closed but maybe for impacted Services you only care about the ESX test one service that John created earlier so I will just type that here and I only care for when the value contains ESX for impacted services and then maybe I only care about if the severity is critical or major so I will uncheck everything except for critical and major and then at this point I have two applied conditions that you can apply more if you'd like and now I will save this filter and you can name the filter whatever you want um I'll just name it tests ESX for now and if you'd also like to set it as the default filter all you have to do is check this button but I will just save it as is and now if you ever want to access this filter with these two preset conditions all you have to do is press this in the drop down menu for the filters going back from the default filters that are applied and then just clicking here to access the test filter that I just created moving away from the service operations workspace we are now in the platform analytics workspace so you may have noticed before when I was looking at the CI I showed you a bit of metrics that are accessible on the page of a CI but if you'd like to see a more broad picture of your VMware State you can go into the platform analytics workspace and go to the dashboards and see here that we have a certified out-of-the-box dashboard just for VMware vsphere monitoring so just click here and now you can see various metric types for VMS ESX servers the data center and datastore as well as alerts if there are any related alerts here we can see the various metrics that are available for VMS so CPU usage CPU demand CPU wait time and the widgets go on and here we can see the metrics for ESX servers again metrics such as CPU Reserve capacity power usage storage adapter latency and so on and for data centers we can see metrics such as migrations with vmotion power on operation power off operations host change operations and even more operations and metrics for a data store include red average read average throughput contention throughput usage and so on and if you have any alerts they will show up right here so after this demonstration the three key takeaways that you should come out with are that these are all out of the box capabilities two only one read-only credentials required and three this is incredible fast time to value with that on behalf of John and I I would like to thank you for watching this video and please stay tuned for more