Control which CIs can become part of application services in the following methods:
- Include CIs based on classes
- Define the CI classes to allow only CIs belonging to these CI classes or
their extensions to participate in tag-based discovery. By default, this
list is empty and CIs belonging to all CI classes are included in
tag-based discovery.
- Exclude CIs based on their install status
- By default, CIs with the Retired or
Absent
install status are not included in application
services, based on tags. You can broaden this list of install statuses
to include statuses like Pending install or
Stolen, for example.
- Modify CI relationships used for tag-based discovery
- Service Mapping
includes CIs that are part of these relationships even if these CIs
do not have tags assigned to them. The CI relationships
participating in tag-based discovery are stored in the Application
Services [svc_traversal_rules] table. You can exclude preconfigured CI
relationships from tag-based discovery. You can also configure
additional CI relationships to use in the tag-based discovery process.
For example, you can add a CI relationship between Linux
servers and storage devices to discover servers hosting storage devices
based on tags.
Note: You cannot delete or modify preconfigured CI
relationships used for tag-based discovery from the Application
Services [svc_traversal_rules] table.
Table 1. Preconfigured CI relationships participating in tag-based
discovery by default
CI |
Relationship |
CI |
Virtual Machine Instance
[cmdb_ci_vm_instance] |
Virtualized by::Virtualizes |
Hardware [cmdb_ci_hardware] |
Hardware [cmdb_ci_hardware] |
Runs::Runs on |
Application [cmdb_ci_appl] |
Kubernetes Pod
[cmdb_ci_kubernetes_pod] |
Contains::Contained by |
Operating-system-level Virtualization
Container [cmdb_ci_oslv_container] |
Note: Service Mapping user
interface refers to CI classes as CI types.