Make sure Discovery and Service Mapping plugin is enabled:
- Configure Entry point(s) properly
- View Map
- Run Discovery
- If some CIs are not discovered in SM, check if those CIs are present in "cmdb_ci" table
- If those CIs are not present run a Quick Discovery on those CI (IP address) using the appropriate MID Server.
- If Quick Discovery completes sucessfully, Run Discovery again on Service Map
To check which SM application is using a particular endpoint and vice versa:
Check "sa_m2m_service_entry_point" table.
Connection between CIs can be establised using:
1) Pattern based - Always check all the incomming connections from the top down menu in Discovery Log because different incomming connections can create different connections.
2) Traffic Based - When using TBD it is always recommended to enable ML suggestions by setting "sa_ml.connection_suggestions.active" property to "true" so that traffic-based connections do not create connections automatically in the maps. Instead the user is presented with list of connection suggestions they can choose from.
3) Manual connection - Click on the connection and see if its showing Manual connection: True or Added as CI: True in properties pane on right hand side.
i) Manually add a connection - this will trigger any matching Connections pattern
ii) Add a CI - used for CIs that are non discoverable like proxies.
Ways to create connection using Pattern:
1) Using configuration file: we can extract IPs and/or ports to make connection to next layer.
2) Using netstat -ano command and filtering required outgoing IPs / ports in the next step of the pattern.
3) Using GlideRecord : This method may impact system performance
var gr = new GlideRecord('cmdb_ci'); // we can use any other table also
var sockets="";
gr.addEncodedQuery('copy encoded query from cmdb_ci table and paste here');
gr.query();
ports=[4080,4180,4280,4380,2600]; // example
while(gr.next()){
if (gr.name.startsWith('name1')){
sockets+= ","+gr.ip_address+":"+ports[4];
}
else if(gr.name.endsWith('name2') || gr.name.endsWith('name3')){
for (i=0;i<2;i++){
sockets+= ","+gr.ip_address+":"+ports[i];
}}
else{
for (i=0;i<4;i++){
sockets+= ","+gr.ip_address+":"+ports[i];}}
}
4) Hardcoding the Incoming IP address and Outgoing IP address and port: This means those particular hardcoded entry point IP address CIs will always connect to hardcoded outgoing IP address CIs.
To write JavaScript code in the pattern:
Use: EVAL(javascript: your code)
1) If you want to use an exisiting variable from pattern in your code, there are two ways:
i) var a= CTXgetattribute('variable_name'); rtrn a;
OR
ii) var a = ${variable_name}; rtrn a;
2) If you want to use an exisiting table from pattern in your code:
var t = ${table_name}; rtrn t;
Remember: It does not support return, instead use rtrn.
If different CIs in a SM is accessible by different MID Servers.
Ex: suppose in same SM application, the LB is accessible by MID server A and a web-server is accessible by MID server B then:
- Add LB IP address in MID server A IP ranges.
- Add web-server IP address in MID server B IP ranges.
When two or more applications have same entry points:
Add some extra variable towards the end of HTTP(S) entrypoint. For example:
https://entrypoint.com/a
https://entrypoint.com/b
https://entrypoint.com/c
and so onn....
In SM the entry points has to unique but the resolved IP address will remain same for all the above given entrypoints because SM works using the hostname for identification.
Tips to remember while creating new Connection Section:
Always try to Add a Precondition or Match condition equals the entrypoint either using IP or hostname or url or comments and terminate if no matching found. Try to avoid conditions like not equals, not contains etc as it would then apply to all.
Precondition or Match evaluation:
| Condition 1 | Condition 2 | All (AND) | Any (OR) |
| False | False | False | False |
| False | True | False | True |
| True | False | False | True |
| True | True | True | True |
Example: To remove two or more IPs or URLs from entering that step the Precondition or Match condition can be configured in two ways:
i) Meet All; condition 1 Not Equals ip_address; condition 2 Not Equals ip_address ; if true
ii) Meet Any ; condition 1 Equals ip_address ; condition 2 Equals ip_address ; if false
When there are many IPs / URLs to include or exclude in Precondition of any pattern:
Step 1: Set Parameter Value
Value: Specify all IPs / URLs that needs to be excluded, each seperated by comma
Name: $IPs_2_xclude
Step 2: Parse Variable
Variable : $IPs_2_xclude
Table: IPs_table
Delimiter: ','
Step 3: Precondition
$IPs_table.IP Not Equals $entry_point.ip_address
Some Errors and their solutions:
First try "Click Handle Error" -> View Instructions (if available for that particular error)
| Error | Solution |
| Duplicate entrypoint found | Go to "cmdb_ci_endpoint" table and delete all unnecessary duplicate endpoint records. |
| There are duplicate dependent CIs | 1. Navigate to "reconcile_duplicate_task" table. 2. Open each duplicate task, and delete redundant CIs on the Duplicate Audit Results list. 3. Click Retry Discovery |
| CI not identified | Check the Identification section pattern to see if proper rules are set. Use temporary variables in debug mode to set proper identification rules. |
| When TBD is enabled it creates connection records in "cmdb_ci_endpoint" table. Sometimes it happens that even after disabling TBD those connections are still reflected in map. | Go to "cmdb_ci_endpoint" and delete those records from table. |
| No MID server found or SSH error | Do a "MID selection Test" and fill in application as "Service Mapping". Assign a proper MID server for that IP(s). |
| A CI having wrong name but correct IP and port in Service Map | Caused due to Identification section pattern misconfiguration. Please correct the pattern steps as required. |
| Identification Engine errors: See Identification Logs for more info. Update failed with error: commit failed or was not attempted due to other errors. Found multiple relations [parent:'XXXXX'/child:'XXXXX'/type:'XXXX'] between payload items: | 1. Go to "cmdb_rel_ci" table 2. Search the CI name in parent or child column 3. Filter only Runs on::Runs type 4. Delete duplicate records. |
Some Tips:
1) We can use different target table name (in Filter table operation) for branching same source table for different operations.
2) A SM can use one or more MID server as CIs in the application may use different MID server.
4) If there is an existing manual connection and afterwards a pattern is created for the same connection, then it will only have pattern based connection as manual connection is overriden.
5) Timeout can be a reason for wrong Identification
6) In Pattern:
i) For Identification section the entrypoint is the CI (IP or Hostname) itself
ii) For Connection section the entrypoint is the CI (IP or Hostname) that is just above that layer.
7) Changes made for a CI in one service map will be reflected in all other maps if that specific CI (except LB) is being used by other application service maps.
A Scenario to be aware of:
If two or more Application Service Maps uses same sets of CI (excluding LB) there can be two possibility:
i) Upper layer CIs are same and lower level CIs are different, then it would be difficult to distinguish those applications in the next levels as (whichever Application Service Maps runs latter) will overide the existing service map.
ii) Upper layers CIs are different and lower level CIs are same, then it is easy to distinguish those Application Service Maps as the lower part will be exactly same for all those application service maps.
Love the article, we've managed to get Service Mapping working and are seeing early promising results.
The only hiccup I'm seeing is that all changes to the map, on the timeline, present as approved? I'm trying to track down information on where this can be modified but it's not something covered in training.
How did you go on this front? I can see a technical team changed a service (without an active change) but ServiceNow says the change had approval.
