all right so good morning good afternoon and good evening everyone thank you very much for joining this webinar today we're gonna see how to gain visibility to Cloud native Technologies and this session in particular is part of item visibility and governance webinar series you will see that there are also other events planned for the same series for this year so we're looking forward to see you all in there this session today is also part of live on service now and program and this is an interactive event series that will connect you with our experts they will help you deploy and adopt our Solutions and most and foremost and to achieve value faster you can see the schedule in scanning the QR code that you see here or we're just posted actually in the chat the link so you can check it right there now a few housekeeping items before we get going so please make sure that everyone is muted you can use the Q a feature to ask questions throughout the session and we actually encourage that feel free to introduce yourselves when asking questions because we'll love to know who you are please and participate in the polls we're going to have two polls today so not a lot of efforts required from your side uh but your effort is much appreciated and this session is the previous sessions is being recorded and will be shared and on the servicenow community Forum after this session and then at the end of this session you'll be prompted to fill out a short survey and we would really appreciate your feedback so please um feel free to fill it out now let me introduce myself my name is Jamari de Luigi I'm part of the outbound product management team specifically for item visibility in governance and I will be your host for today now I'm taking over Steve's spot so I'm delighted to be here with you today and I'm definitely looking forward for this session ramen near are gonna be the speakers together with me so please guys feel free to introduce yourself maybe I'll go first hey Ram devanathan here you all can address me as RAM I'm part of the item product management group handling the cloud visibility and the cloud governance Cloud provisioning products and uh yeah very happy to be talking about visibility the cloud native Technologies and the approaches that we have set up today and we'll also follow with the demo on that over to near go ahead please hi everyone I'm Nira Rossi I'm product manager for Icon Health my responsibility is monitoring event management health log analytics and we'll talk later on about our solution for cloud native monitoring thank you both all right so as I mentioned we're going to have two polls today and one is already there so the call has been launched and we want to know from you which methods are using to discover kubernetes and containers currently you can select all the options that apply and I'm going to read them out loud for you so I using third-party tools or are you rather using scheduled Discovery runs using patterns or alternatively are you using managed kubernetes Discovery via eks AKs j k e or are you using Cloud native operations also known as CNO also some of you will be wondering should we actually discover kubernetes and containers so I'm gonna give you other 10 seconds and then we're gonna see the results I see a lot of answers are coming in um about half of years already replied so five four three two one and we can end the poll right so it looks like the majority of you is using schedule Discovery using patterns followed by uh people that are actually wondering whether we should actually discover a kubernetes and containers and a lot of views are used in third party tools CNL few and the minorities using managed kubernetes Discovery via eks AKs and gke so um we can yeah we can stop now so today's session is going to be focused on how to gain visibility to kubernetes and containers but before we see how to do so uh let's talk about how um and why especially you need to discover kubernetes and containers nowadays companies um experience a number of challenges with Cloud native Technologies in different areas specifically when it comes to kubernetes and containers so starting from the Chief Information security officers perspective the main challenge there is to really ensure security across the board so in particular they want to know what is the security posture for kubernetes and containers and what is the software installed inside the containers and if the actual software that has been installed there is current or not and then they want to know um how is the business impacted by the container security risks then on the other side from the asset manager's point of view the main challenge is to really ensure a software license compliance specifically within containers so in detail they want to know what software first of all is being deployed inside those containers then if there is some overspending related to that software or in general if there are some cost optimizations opportunities in that space talking instead about the sres or it operations senior Managers from their perspective they want to make sure that the service is being provided are actually healthy so they want to know how to pinpoint the root cause of app issues whenever they arise and how is the business actually impacted by the operational alerts that are generated or how can the remediations be automated for a containerized applications now the now platform offers solutions for all these different areas and all these different challenges now the cmdb is your organization's data foundation and it is the foundation of service now as well it is as you know the central repository of configuration data that is needed to drive outcomes for your transformational goals now the cmdb helps you address the challenges with Cloud native Technologies through these key products that you see in this slide first of all through it operations management that allows you to gain visibility of the install software inside containers and making sure that at the same time your services are healthy then we have software asset management app management that allows you to ensure software license compliance from one hand and at the same time optimize your spend then also we have security operations which are very helpful to prioritize your vulnerability response based on the business impact that it has now we can see that across all these different products will always have centralized visibility of all the kubernetes resources across platforms while at the same time we'll have the service context awareness just like on your on-premises resources having automatic visibility of containerized resources is key to driving technology service operations extends now with servicenow item visibility you can discover your containerized resources across all the major kubernetes providers that we can see in the slide and add them to the cmdb which is the data Foundation as we say for your organization and for servicenow you can then gain visibility to your kubernetes topology and get more insights for each cluster but you can also gain visibility to containers and specifically to the install software inside those containers you can gain visibility two times and to service contacts and especially every time you're going to have near real time visibility now this will allow you to solve the challenges that we mentioned before so the outcomes will be having an improved security posture with your containers ensuring Regulatory Compliance for different standards you can have an actual control of your software expense so you can actually go and optimize the costs you will have a centralized visibility of all the kubernetes resources across different platforms and you will always have the service context awareness and eventually you're gonna have the chance to manage your services Health through AI Ops as we'll see later now poll number two already we want to know from you which use cases will you use um uh Discovery kubernetes and containerized containers sorry four so the Alternatives here again you can select all the ones that apply uh either you go for vulnerability management um use case or you go for software Asset Management use case AI Ops or devops change or Regulatory and compliance with the different standards so I'm gonna give you again another uh 10 seconds to give all of you the opportunity to go through them and select the most appropriate ones and then we're going to see the main results thanks everyone I see a lot of you putting your answers there so five four three two one and we can end the poll so interestingly enough so the most common use case that you're using discovered or when you use discovered kubernetes and continuous four it will be for software Asset Management followed by vulnerability management use case and then Regulatory and compliance AI Ops almost the same and then the minority won't use it for devops change so very interesting insights today uh I'm gonna now pass it over to Ram that is gonna bring us through how to actually discover kubernetes and containers thank you Ron if you can hear us you're welcome thanks John and um yeah I'm gonna share now so folks uh once again happy to be leading this part of the discussion here let's talk about how to discover kubernetes and your and your containers we'll start with uh the kubernetes discovery approaches right first of all it was reassuring to see uh many folks who are actually driving the managed kubernetes Discovery as well as uh working with CNO and uh several people also indicated your discovering patterns through the discovering containers through the patterns right so very simply put this three primary approaches you would uh use and um they all have certain uh you know things that you need to know about in terms of what is discovered and what is to be followed by what you know I'll lead you through the process there if you have uh either on-prem you know the openshift kind of uh kubernetes clusters or other uh kubernetes clusters uh which are on-prem yeah right they're just running in your Labs or they're running in your in your instances uh in your uh in your data center right um this this uh direct connection the connectivity that you can set up by setting up uh the better tokens or the cloud credentials right you could also be having um eks AKs kind of uh clusters that you have set up individually on the cloud and to discover each of those individually on the cloud right you could actually set up your uh Cloud credentials or directly access the controller uh and uh talk to the controller and run our patterns what we discover is basically the topology of the cluster an example of that is the screenshot shown about that on the left side here right and the tags and the software inside the containers so all of these are automatically discovered uh so we have multivarious patterns as you know we have kubernetes patterns and we have the also uh uh the the docker related patterns and both of these run uh you know in in the same schedule and uh they will get you all the information you need and we'll talk a little more about uh software discovered inside the containers in in a couple of next slides later um which kind of answers to the Sam use case that many people are talking about right uh and the setup is pretty simple you basically create a discovery schedule for each uh communities cluster and uh you would basically connect to each of those clusters using the credentials provided there this works great for uh you know your self-hosted or your Cloud KS deployments with access to the credentials and the better tokens in the case of AWS if some of you have seen a video that I've shared earlier uh but I'll send the link to later uh customers also can uh use the if it's on AWS with eks right you can also use the assume role capability so it can be rid of the cloud credentials approach and directly connected to the plus front get the details so this is one thing but it is relying on your creation of Discovery schedule for each given this cluster right obviously if you have like let's say 10 20 40 100 so many clusters eks or AKs or gke or whatever on the cloud you don't want to be setting up the automatic Discovery uh you don't want to be setting up the discovery schedule for each of those clusters it's a lot of painful effort there so we introduced um you know probably middle of last year or maybe Q3 or of last year uh the automated kubernetes Discovery scheduling so automated kubernetes Discovery scheduling works specifically with the cloud-based communities clusters uh specifically looking at uh clouds that we support AWS Azure and Google uh so uh like we connect to endpoints and we discover um your VMS in the cloud like we connected uh you know the these Cloud endpoints and we discover um storage buckets or databases Cloud databases right in the same manner we'll also discover these clusters right we just make the additional pattern query uh the API and we'll get that the security access for this is simply the same Cloud credentials with additional permissions for listing and describing uh the the specific uh you know uh K test cluster there and the setup will basically now be enhanced now not only will we discover uh you know these clusters but we'll also set up the schedules for getting into the details of each of those clusters and actually drive that story this is best suited for uh you know AKC case gke kind of uh cluster discovery where the initial run will be very much like getting the list of cluster names and the high level cluster details there and then there will be a subsequent Discovery schedule that will run that is automatically created that automatic Discovery schedule will uh get more details about each of those individual clusters right so that that hopefully uh gives you a perspective on that and with this this problem that we are talking about here not necessarily a problem manual effort is gone because it automatically comes for this right now there's another so both of these are you know kind of agentless approaches right because we are relying on the apis and we are driving it through an approach to uh connect via the mid sitting somewhere and able to connect to the you know uh to the to the kubernetes cluster either through uh cloud apis or or through direct kubernetes APS so that's the two parts of the story there as a third part of the story Cloud native operations for visibility uh now Cloud native operations is another piece for the monitoring aspect uh the same uh the app also extends to provide the monitoring for the communities cluster which near we'll talk about later but if you just talk about the visibility aspects right this first of all is very different uh in the in the deployment and it offers some additional value also it gives you continuous topology tax services and software in the containers because it's sitting inside the communities cluster in fact it is sitting as a micro service because uh you know we deploy a containerized uh made and uh we deploy ACC agent out into the each cluster and it's constantly listening and it's uh it's updating there and the setup is also very simple we'll talk a little about that later right and uh it's best suited for basically your Cloud native app teams as well as uh you know infrastructure teams who are very interested too uh get a very real-time uh information and it also gives you that ability to monitor the creators using our aaps approach again which they will be talking about here right so these are three approaches again you need to mix and match uh automated kubernetes Discovery scheduling with agentless Discovery right that'll naturally help you there and the cloud native operations is again a different approach there uh more details uh in the later presentation by uh later on that the about gaining visibility of uh uh you know uh your kubernetes clusters quickly and natively with either of these approaches just to pictorially indicate what's what's happening there right so on the right side is your KDs cluster right you have all your uh Services running there right you have your Tomcat Parts you have your MySQL pods and all of that right now one approach that we talked about was agentless Discovery using uh KRS Discovery schedule where the mid right and that's sending that information and that configuration data that metadata everything is obtained and it's pushed into cmdb so we get as detailed information as uh the cluster information namespace information the node information the part workload deployment stateful set everything is obtained there we'll see that in a minute in the UI we also get to the point where we can actually generate tag based service maps and ml based service maps with the details that are available obtained by our Discovery there right in an automated manner the the so that's like this this arrow and this going forward that's like the one approach to that now another approach is the CNO uh approach where uh you have the actual uh mid and ACC actually deployed out as a service and it operates like a stateful set there and it's constantly doing that checking via ICC and it's continuously streaming that configuration events from the communities API and the good news is this can be hosted on any of these platforms right openshift or direct kubernetes itself and the configuration uh info events are sent out and on the servicenow side we listen in and we update into cmdb so that we can give you the same values here the the big difference is that this is you know you could you could uh you know it's really really uh real time in that sense whereas this is uh driven through a sort of a scheduled and a pulled mechanism there is something to keep in mind there great so this is uh the deployment state for uh you know the agentless and the agent-based approach there if I take a look at end user perspective here you heard John already talk about the outcomes and the need right and also from the poll results it was very clear Samus the software Asset Management aspects is high on uh majority of the people's minds here right so we didn't have it until uh but the February parents uh release but in the February patterns release we actually introduced the ability to do the software Discovery inside containers there how does this basically work we have the substrate of the kubernetes container Discovery uh happening so we discover the containers right but we also Connect into the Container image by connecting it to the communities uh the docker registry for instance right and then we use the 3v open source software library to connect into the and read the you know the docker file from the container image we understand the software that's present on it and get the software install information with the software install information we can actually get into a heavy amount of details as to uh what is actual software here here to the right is is a good example of the sort of information that we collect there later in the in our demo will also show it please do keep in mind this is Ms SQL Docker container right I I have to mention here an interesting statistic that came about uh this was as a latest 2023 only this is systic report or you know those of you who have still doubts 87 of container images have high or critical vulnerabilities because main case they're all open source images and you might imagine that in many cases in open source images open source code uh you know several uh open issues vulnerabilities are there and uh the reality is that uh just open source corres cannot fix everything I struggle finding the right parameters so that's that's that's huge uh to keep in mind so vulnerability is one aspect cost is another aspect to keep in mind right so knowing the software information there is pretty important and knowing the license information there is pretty important when you get the software install information we can pass that information and our own capabilities around the software Asset Management uh in our Sam portfolio that will give you more details about the licensing and other other details in that area right very key feature that has been introduced again doesn't take any effort from your site maybe I'll I'll uh later I'll also show a demo of how that actually works uh how it gets that software install information and what sort of information is is available there okay so moving on here I want to talk a little about container vulnerability response with the install software and also how we offer the business context in that area so we all know how it works they have container images and the container images uh you know become uh manifest as active containers running inside pods and in turn the active containers uh now now uh spawn of uh communities based uh Services right that's a simple uh you know it's a premise that we work upon what we introduced uh in our secops world and this going back to your conversations around the security and the vulnerabilities and other aspects there in the in the country of vulnerabilities world uh we introduced a contain availability management uh software and I'll set the store app link for that once my presentation is done here right and uh basically what it does it it it integrates with the third party tools like Prisma as well as it also reads uh the cve information from uh database like the national vulnerability database nvd right so that information is obtained and uh it it just basically has all the CBI information it'll scan each of the container images and it will basically tell uh which are the containable limited items there okay now the next part is the is the sort of the uh you know Continuum of the of the story here we already discussed how with the approaches that we've discovered that we do the discovery setup right we've done the communities and the container Discovery right we connect and get the container image OS software package so the while while this will scan and Report container level ideas but actual software packages are obtained through the discovery process here and we relate that installed software packages into the containers here right so the not only the container images we also get it to the active containers in the in the Pod sheet right so this gives you a more rounded uh information there and combine it along with our detailed discovery on the of the of the kubernetes uh cluster right you are actually getting a lot more information about uh you know which container which pod and which service is actually affected there and of course with items service mapping you can actually establish the impact through the business context by taking it to the next level there right you can you can you can just get the entire flow if you look at it this way you're starting from uh the container vulnerability which is obtained through external database systems where uh you know known vulnerabilities are obtained and then you take it to the next level where you're getting the details of the actual installed software and that install software relates to the active containers and which containers are activated in which pod and then take it to the community service and then to the business context uh right so second items combining together they're providing the crucial linkage where uh the details along with the impact of the uh you know the business uh the service Maps there right that's basically the the broader perspective there again as I said the the patterns app contains this information the service mapping is available already you all know it uh it's available uh uh on on even the service mapping Plus app is available on the store which will help you in the ml based search mapping aspects there and the content availabilities app is also available on the store these all work with uh you know uh your uh your existing Investments there so I'll switch over to uh a demo there any questions so far that we need to look into John or Steve yeah so far we have um a question here from Sharon so is there a maturity path laid out for cloud resources discovery and that's I think Steve is going to answer this question live yeah both of them seems to be yeah yeah so we're gonna answer them afterwards both so far we'll take it live I guess uh we'll probably keep that to the end then uh right so let's do that uh somebody raised a hand uh was there a question there folks okay uh feel free to bring up if there's anything else that you need to discuss about let me move to the demo here right real simple uh obviously when I'm talking my session times out here so let me re-engage the session here okay uh February release of uh the cloud operations workspace app is available on the store again links available here I'll talk about a minute here the February release of that has the new uh kubernetes Explorer so if you go to Cloud operations workspace you can you can do a few things with Cloud operations workspace with interesting things with Cloud operation one is the you can do your Discovery schedule setup for cloud from there right and then the other one is you can also view your overall uh standard Cloud resources your VMS your databases and your storage and all that stuff on the on the cloud right so you can view that and and the last bit is this kubernetes Explorer uh that has been introduced in this since February release the aim behind the kubernetes Explorer is to give you that overview of your overall uh kubernetes estate tells you the number of clusters you have and uh how things have changed over time what is your Trend your number of nodes your number of namespaces services and all that and the distribution of the parts uh also is given as part of the story here uh based on Regional data center based on geolocation information also based on Country location right so you know like if you're in the cloud like where it's actually placed and if it's uh if it's actually on-prem we also show what is on-prem that part information is actually obtained here you can find a lot of uh you know pods actually running inside in the East US region in Amazon and uh you know and then break down by AI Japanese clusters there is additional information about the actual clusters right and the details about the Clusters that are available here at this time it's more of a read-only kind of a view that you have with some links in between that explain like how uh you know you're you're Connecting the Dots here uh so from your greatest part you can find the details of which namespace it belongs to uh from the workloads or or Services you can actually connect to the service where that that was running there so the which kubernetes cluster it is part of they can actually go from your service to that right and uh again uh interesting uh sort of charts and uh we see how this can mature into as next faces feel also the first version released so in the next phase is we'll also see this maturing into providing even more detail even more uh cross launch and even more service mapping kind of information into the into the picture here right but uh very quickly if I go to Docker images um I can I can see all my Docker images uh again not necessarily related to the kubernetes Clusters all your Docker images are present here right uh so if you take a simple one like maybe this one the server right and uh you you get the details in a bit here and it doesn't have any tags so you know key values are mentioned here the image ID and image digest and all is here in the in the container image OS packages you can actually see what is the software that is running on that so you can find that there's several several tools here some of its license some of the mobile Source right but several several tools are present here right and additionally you can also kind of see the Docker containers that uh which are running this so the MS SQL container that is actually running at this point of time uh right and which image ID is built on that that Ms SQL container is having this image right and uh as far as Parts go which part it's running in which cluster it's running in all of those details are available here so you can trace back uh we'll work on the visual representation of this in the future release but we'll Trace back how uh you know this Docker image is used in a particular container in a pod and that part goes back to the cluster there that kind of details are available there uh you can uh you can you can you can try it out right some of these uh are this the cloud operations workspace is available so happy to uh work with you as you as you try it out please do reach out if you have any questions around this area okay so this is the visualization of the kubernetes Explorer there if I take a step back and uh you know I attempt to show you uh how the uh you know the kubernetes Explorer uh came to get all this information right so let me go to Cloud operations workspace and and go to Cloud Discovery here so in the cloud Discovery area we have set up several schedules and our schedules are basically connecting to various clouds right it's loading there and from from these schedules right uh we are basically creating additional schedules for the individual clusters that have been detected uh in the in the cloud there how is this actually being done so if I go to the system properties foreign list and if I search for uh you know cadis here you'll find a few interesting uh settings here the one that you're interested in and it's documented is the create schedule enabled which is set it to True by default it's set to false but you set it to true and once you said that what happens is let me take you to uh the discovery schedules listing here Discovery underscore schedules dot list and you'll find that automatic creation of the communities uh clusters is happening here so going back to the point I was saying earlier if you remember the three approaches and the three part diagram representation there it was basically saying we have one part where in the middle we connected to the Discovery schedules where the discoveries Cloud Discovery schedules and we are getting all the communities clusters and then for each of the Clusters we are setting up individual schedules which are serverless schedules that will actually get the details of that right so that's kind of the uh you know the story uh behind this right and if you go into the actual schedule you'll find more details of the schedule and how the server serverless schedule pattern run now all those details that are actually appearing here okay let me close this now as part of the same story when your Docker pattern runs right we also discover uh Docker images now this is listed as part of the so if you go to image now if you search for image in the left now here you find Docker and then Global images local images and then for AWS and all that so you look at Global images you'll find the same listing there it's a same dvci Docker image right this is the part where it gets interesting where you know uh using the uh you know the the actual Docker image itself you can go in and I can I can take a look at additional details there so if I take the CI prod uh information uh it has uh very clear lineage for the Clusters and all those details and if if the uh you know the software discovery on that image has been run you'll also see details here now let me switch over and quickly show you how that software image on that uh how that software discovery on that on that image is actually running right so okay that's interesting there so I've got a history here and uh yeah this is the table I wanted to look at so let's take I've just kind of uh curtailed uh the filter for one particular image here and the image name is server here right and what happens here is I will uh scan status is the Tv scan status here right I'm going to set it to none right and when I said to the none it's a regular timed uh scan that runs on the image here right which uh you know every minute it basically runs so and uh you'll find that shortly this scan status will change and eventually it'll become like scanned and when that gets scanned we can go into the image and we can see more details of that okay so that should take a about a minute to actually uh uh come up there Okay so any any questions to answer in the meantime there's a couple of chat here okay thanks Steve for adding those links there okay no no questions in the Q a uh yet feel free uh folks uh please do feel free to log in your information there yeah there you go it changed to uh scan cities in progress this is where the 3B Source uh the open source software is actually doing that and now it changed to scan right just refreshing that uh for a moment the demo demo Gods I thought were not with me no they came back so that's good so um when when you go in and you can see the details of the uh the the the the the the actual containers and uh details so this same information you found it also in the kubernetes Explorer that we showed earlier and uh again it's a work in progress we'll we'll make additional releases where we'll show the service mapping dependency mapping and all those details there okay so in simple terms we've come to the point where we understood uh how the schedule should be set up we understood how uh Discovery uh runs uh how the automatic schedules are created and then we obtained all the uh you know details from the Clusters we brought it back here also we get the details of the software uh packages inside the containers there so this way you can actually find out like okay open SSL sitting on how many containers there you know we can quickly detect that and find out like uh there's a well already to be addressed there very simple story for you so now let me move over to uh and I need to log in again here I want to look more to another instance um where I want to show you the vulnerability uh aspects of the of the discussion there so let me quickly go to an overview here on our vulnerability tool on the setup side the container vulnerability management gives you all the containers details are all available here right so if I want to kind of get into the next level of discussion uh about okay the container of all British and actually take a look at that I go into say the cvits that are there the CV it is clearly indicate which Docker image has that problem right and it kind of says like what is the vulnerability right so let's click into the details on the cvit right it's basically saying that which cluster is affected which Docker image is uh using that right and it says what is the vulnerability and how it has been fixed and you find also more details as to what is the package name and all that details right it's great from that standpoint now you can actually go into uh you know the service mapping the dependency mapping and actually find out like which cluster is impacted from that Docker image so from that Docker image you can trace it back to kubernetes Cluster another details there right so let me come back and come back to uh this and uh I'll take one case where in fact a service mapping has been set up here so search for Google great so maybe I have it open around the window there I just want to ensure that I can show you the full example here with uh with a Google thing there just give me a minute I need to get it from a link here yeah there you go so if I if I if I go to this this is interesting because as you can see here the save at cbit has been mapped to a Docker image and that Docker image is in fact participating in our kubernetes namespace and a cluster and it's actually part of some assignment group here right but it gets uh even more interesting there because I can go in and I can look the dependency map and when I look at the dependency map I can also find which Services impacted there because it's actually having a connection to a Currency Service which is a tag based service uh that has been set up there right so from this I know that this Docker image going through this current uh this uh you know this kubernetes service here actually impacts a particular Business Service there that's the business impact story here so if I say view map it actually tells me like hey you know the tax service the Currency Service is actually impacted because of a particular vulnerability here right that whole end-to-end picture is actually uh given there thanks to the combined value that we are sort of offering here uh you can now use uh approaches like uh you know the remediation tasks that are available in the second side as well as data operations oriented uh updates to the docker images so you can bring in the new Docker images into play there right so overall uh you know uh this hopefully gives you a great perspective into how our Discovery works with the agentless approach for starters right and then how we get into additional details into finding out uh outcomes in deriving outcomes that are important from your software Asset Management as well as from a vulnerability standpoint there and driving the broader uh you know governance in that area great I'll I'll stop uh sharing here and uh you know I'd like to turn it over to near to continue with the rest of the questions the rest of the presentation sorry thanks Ron okay so the last part is about item health for CNO it's about collecting event metrics logs uh what we have today in version 1.1 that we released in February and so once the agent and the mid are deployed as a part they are starting collecting events and metrics events are collected from the kubernetes server and the metrics are collecting from Prometheus um once we have the CI created by the discovery and the continuous Discovery we can start collecting these events and metrics for the different kubernetes objects we will see that later on in the demo and what we plan for the next major release is to also integrate so you can see this animation we will have the ACC demon set install on on selected nodes and that will allow also a collection of logs from the application ports and here we leverage all the existing capabilities and the engines that we have in item Health event alert grouping correlation metric intelligence anomaly detection and health log Analytics let's move to the short demo so let's start with the my environment so first of all let um I have two clusters here two eks clusters let's see the pods that I have and so you can see different namespaces first of all that Chrome it is installed and istio and I also have these Boutique namespace the boutique names this contain multiple microservices and what is this Boutique up it's an e-commerce application it's a real application that is running in the cluster it's exposed as a service so I can just access it from via the Internet and I can really shop stuff here and it really works so the the different microservices are communicating with each other and and it works so back to my uh Cube CTL so you can see the different micro Services each one of them is a pod I have my ad service card service database email service and so on now let's move to my instance and go to the service dashboard in service operating workspace so we have two main Service Groups I used tag based service mapping to create the boutique service boot each one of the services the micro services or the Pod that we've seen before we can see different uh colors or alerts with different severities that I generate or simulated using mostly static threshold on metrics I put very low because it's not a real website not real traffic but I simulated this using low values on the metrics that we collect for example we'll click this warning on the ad service and we see that we had this alert it's a static threshold alert the message is you see it's a very low threshold but it can be any number of course just to simulate how it works and then if I go to the metrics tab I can see the featured metrics the important metrics that we collect as I mentioned from Prometheus and if I click here on Metric Explorer I can even further uh select more metrics I can show the alerts on the timeline this is the static pressure alert that I got I can zoom in and out I can play with the timer enter I can troubleshoot and so on and so that's a static pressure a lot I'm not in I will not demonstrate here the anomaly detection that's a we need more more time for this but basically it works pretty much the same you get alerts and you see The Matrix back to my service dashboard now I am the Persona that monitors the health of the cluster so the second service group is my kubernetes clusters and let's click on this one I have a critical alerts here let's first of all see the service map so this view shows me my cluster and I can see the namespaces the nodes of the cluster and I can see where I have problems so I can see the different colors the different severities so my Boutique or my service now nice place is where the series now pod the mid and the agent are deployed and this is my Boutique application nice place and these are other kubernetes namespaces and if I go to the advanced map I can see all the related alerts of this cluster and if I click on my Boutique namespace I could see first of all a static pressure alert for a memory metric of the boutique namespace but I can see also part that you cannot see here because it's a it can be a very large number of pots so we we don't visualize this but you see the impact here on the boutique namespace of the different parts this pod exceeded a specific CPU number and so on so that's your service map I can also use service details of this cluster and go to the related record so here I can see all the CIS of this cluster this is a for example uh the CI itself the kubernetes cluster CI and here even without an alert context I can go and see the featured metrics of the cluster CI and again here I can use metric Explorer and further investigate and same for sorry so same for other object of a cluster like the next result so I have four nodes so a node I want to see node metrics so these are different metrics for the node level so pretty much the same for all the different objects of kubernetes last but not least I want to start to show events collection so let's move to the my other cluster so what I did here is I I generated um I generated some kubernetes events using I did some over provisioning I tried to deploy 100 Apache pods apparently I have only four nodes so I don't have enough resources enough memory and I could not deploy this so what I get here is um I do Cube CTL get events from this namespace but I can see a lot of insufficient memory alerts I cannot deploy I cannot fulfill this deployment I cannot deploy the nodes let's see how where we see this uh events in in the instance so I will move to the other cluster and here I can see these 100 warnings let's use our alert grouping because I don't want to see a discrete alert so we have more than 100 alerts but each one of this group contains most of them each one has around 50. so if I'll open this group I can see 50 alerts let's open one of them and it's about the port that oh sorry it's not the right one but this one for example is about a specific Port that could not be deployed due to insufficient memory I think that's it in a nutshell if you have any question feel free to ask perfect thank you so much I'm just gonna re-share my screen really quickly so we can go um first of all to the question session so let me make sure that we all see the screen so for Q a um Ram if you want to get started with the questions that were highlighted by Steve so first of all and as you can see the question that was mentioned from Sharon so is there a maturity path laid out for cloud resources discovery so um in terms of the typical level of uh um you know for cloud Discovery where how do you start generally what we've seen customers are doing is we start out with the basic what you would call as Cloud infrastructure resources discovery again it's not restricted to your VM and uh you know networks and all that stuff alone databases storage all of these also will come into play there that's where customers mostly start and then uh the next level is uh engaging in the actual uh discovery of let's say install software within those VMS so uh you know you could have uh depending on the need again right if these are mostly test Dev kind of instances you don't really concern about what is running inside those uh virtual machines computes in the cloud you may stop at that level you don't have to do the install software Discovery but their production VMS let's say then you probably want to go to the next level where you have mids that can connect into those uh you know virtual virtual machine servers on the cloud and be able to detect and discover the install software get additional information from a Sam perspective you want to kind of start looking at any licensing and other things so that Discovery becomes important that even on the cloud as much as it is on your data center there that's like the next step there so um then you get to the place where you're discovering your additional uh pass kind of instances while doing all these things you continue to you know also build your service mapping story uh there also ensure that you're getting your tags at the same time the good news is all our patterns pick up the tax they bring it back so you can actually measure uh you can actually monitor and check if the tags that you want are present there because uh tag governance app has provides you an ability to create policies to check that your basic tags like for instance you might be checking for um you know the the the the the purpose of that uh resource in the cloud uh you might be checking for uh things like owner or you might be checking for app ID or app name right and also cost center so if these are missing then your your UVM is probably running unaccountered now or a database is running under content on the cloud so from that angle you may want to use Tag governance to check those tags there so this is like the various faces there and then you get to the point where uh you know your folks are doing Cloud native stuff you're discovering okay one very important thing before I move away is uh there is something called the for for those who don't know and who not tried it out there's the resource inventory pattern which helps you to pick up on um any resources in the cloud for which we don't have dedicated patterns right so obviously when AWS has a 700 or 800 member strong team or even more probably who are creating Services day by day we can create patterns for each and every new service that AWS or Azure will create right and in some cases these are very small small black box kind of entities so you don't even need a full dedicated pattern in that respect so for those reasons we provide you the resource inventory pattern which connects into the asset inventory service on Asset Management Service on each of those clouds like for instance for AWS reconnecting with AWS config for Azure we connect into uh the Azure inventory service and for gcp connector gcp asset inventory service and we get all those you know details of those objects and we bring it back and that way you don't have to have a dedicated pattern there and this is going to help you because you might have some crucial uh thing like let's say a a key pair or uh uh you know maybe a storage endpoint or something like that that we don't have a pattern for but that's actually a pretty crucial part of your business Maps uh your service maps and from that standpoint the discovery is important there so great look at it from that angle and resource unitary patterns also we should apply there again it's part of the patterns package you just need to check it out and you have to update a table called the whitelist table for the relevant clouds there right so that's like the next level of uh I wouldn't say maturity is just complete completion of the first level of maturity there you have infrastructure you have the pass and then you have the you know the responsibility pattern and then there's the if I were to kind of draw the further line it's the cache container as a service part where the communities and other things come in and your Docker uh uh you know information also comes in there so look at it from that angle go about in the point of view of the details of uh you know your traditional to your modern and start to look at it obviously your traditional is a much higher number and your modern is going to be a little bit of a growing number there so go about in that path hopefully Sharon that helped give a perspective happy to have further discussions on this as needed there um if I could move on to yeah yeah um time we only have two minutes maybe you can try to quickly answer another one right uh so very very quick uh Johann uh short answer for IBM fcr mq uh CIS they are containers and uh you know as long as they're containers running within AKs we have the ability just by using the cube apis and pick up those containers and bring it back and using the ability with the to read the software inside that we can also get the software applications inside that so answer to that is yes maybe George question about oh we out of box event rules for kubernetes is something near can take right yeah so I think this is it so thank you very much for answering these questions RAM and then I feel uh we'll make our best to reply to all of your other guy um that you out of your questions um separately from here so in the chat you will find more resources about all the topics that we talked about today and please submit your ideas on um support.servicenow.com ideas the ones that will have more than some 10 submissions will make it to our roadmap um then and lastly call to action just try these capabilities try them out in some production showcase the value to stakeholders and get them excited uh connect with your new friends outside of this Workshop hopefully you make new ones and we're here for you so as servicenow smes for help whenever you need some and eventually just share your success story with us that will be very precious for us uh we'll wait um until next month in March 21st for our next uh webinar for this series and we'll talk about how to extend agent client collector capabilities uh so I will be very excited to have you joining this session in the future and then that's it for today so thank you very much it was a great pleasure having you attending this webinar and we'll see you soon thank you thank you foreign