With Colin Christie
In this article, we will be talking about Machine Learning (ML) Service Mapping and enhancements that have been made around traffic-based discovery and utilizing the machine learning-based connection suggestions for the Rome Release.
Enhancements to Traffic-Based Discovery
When we're talking about the enhancements that were made to Machine Learning connection suggestions, we're also talking about traffic-based discovery when it comes to service maps. Traffic-based discovery previously would have gathered netstat data while running discovery on these servers, and it would have started drawing outgoing connections from the servers based on the netstat data that it found. This would lead to connections being drawn and servers being included in the map that are not necessarily part of this application service, and because of this, customers have traditionally been disabling traffic-based discovery because it brings a lot of clutter into the map and it makes them pretty unusable.
With the enhancements that have been made to the traffic-based discovery, we can utilize the connection suggestions instead of just getting all the connections that were found to be drawn on the map. For this application, what was discovered so far was discovered by the out-of-the-box patterns, So we haven't had to do any additional development work to get this result. Now we are at the point where we know there should be another connection from this Apache server. We know that because we sent a questionnaire to the application SME, and he provided me with the details on this application. It was indicated on that questionnaire that there should be an outgoing connection from this Apache server on port 5678.
Before the updates to the connection suggestions, if that connection was found, it would have been drawn, but so would every other connection that was found. Now you can click on that CI and say show me connection suggestions. For this example, we found an outgoing connection — it’s showing us which IP, and it's telling us it's on port 5678; that's exactly what we are looking for. Before the enhancements, we would have had to either create a new extension section or connectivity section, or we would have had to manually add this in.
This gives us a third option where you can tell ServiceNow, this is something I want to be included in this map. You can just go ahead and select add. Now we should see that the service will update and include that connection. We are going to go ahead and refresh the map. Now we're seeing that the service update is in progress, and you should expect to see that new connection get brought into the map (reference video at 3:35).
We were able to do that very quickly without any development work, and now every time discovery re-runs on this application service map to refresh the data, it will include this connection in the map. Now that we’ve included the connection we were looking for into the EU Billing service map, my work is done here; well that is true as long as you want this connection to be included in every application service map where this Apache server exists and a connection to port 5678 is found on this host. Let's take a look at the APAC Billing application service, which is the APAC version of the EU Billing application service we were just looking at.
Setting Up a Connection Rule
We can see the same Apache server exists, and we've got the same worker process CI, and the same connection on this host to port 5678. You may be thinking, “Isn’t essentially the same thing as how we had it before, where traffic-based discovery is drawing connections to CIs that aren't actually part of this application service?” Here's where we get to do a little bit of fine-tuning and really tell the service mapping what we do and don’t want. If you wanted to only include that connection in the EU Billing application service, you can set up a connection rule to tell it to do that. For Port 5678 on Apache for EU Billing, we're going to specify similar conditions to the connection suggestion record that we had, only now we're going to add an extra step (reference video at 5:55).
We populate our IP address, Port (5678), and Source Ci (Apache). . Now we still have a field that needs to be filled out, discovered application service. We have this available because the scope is set to local. If we change the scope to global, now this rule would apply to any application service. By setting the scope to local, you can now specify I only want this rule to apply to the EU Billing application service. Now we will save this, and our connection rule will be specific to the EU Billing application service.
We are going to do a quick reset, and the next time discovery runs on the APAC billing, that connection should not reappear now that we’ve removed it from the connection suggestion. Let's go back to EU Billing, and it should be gone from there as well. We can see it has been removed and that is because this will apply to every application service if you go ahead and add this into the map. If you only want it to apply to a single application service, you can utilize the connection rule.
Did you find this Machine Learning (ML) Service Mapping in ServiceNow article helpful? Are you ready to start your journey with ServiceNow? If you want to find out more information about GlideFast Consulting and our ServiceNow implementation services, you can reach out to us here.
About GlideFast Consulting
GlideFast is a ServiceNow Elite Partner and professional services firm that provides tailored solutions and professional services for ServiceNow implementations, integrations, managed support services, application development, and training. Reach out to our team here.