Use tags that help categorize and organize configuration items (CIs) in your
organization to map application services. Tag-based mapping does not require configuring credentials or providing users with
elevated rights.
A tag is a label that consists of
a key-value pair. Your organization may use tags to categorize its assets, to
enhance query and reporting capabilities. Discovery and Cloud Management can
discover tags used by all major cloud providers and container ecosystems. Once
the tags are discovered, Service Mapping can create
application services
based on these tags. For example,
you can use tags to map all application services your organization uses in the
production environment in the EMEA region. You can
effectively use tags to map multiple application services.
As a preparation for tag-based mapping, create tag categories that contain tags with
similar use.
Define
a tag-based service family and define tags that you want Service Mapping to use for mapping. Based on the tag definitions
for the tag-based service family, Service Mapping creates service
candidates - suggested application services. You
review the candidates and decide which ones you want to use to create the actual
tag-based application services.
For details on the tag-based mapping process, see Tag-based discovery in Service Mapping.
Only CIs that have discovered tag values for the tag categories you selected become
part of
application services.
Service Mapping creates a separate service candidate for each tag
value combination. If you narrow the criteria down by defining the tag values in
addition to tag categories,
Service Mapping maps only CIs that have
the matching values. CIs that have more than one tag assigned to them, can be part
of multiple services. You may want to create a tag category for tags related to
different types of environments, if your organization uses "production" and
"staging" tag values.
Tag-based
mapping is not case-sensitive; same key names and key values spelled with upper
and lower case are identified as the same.
Table 1. Examples of defining tag-based mapping criteria for service
families
Definitions for service family |
Category |
Key |
Value (optional) |
Result |
Example 1: one tag category, no values |
Environment |
Env |
Not defined |
Service Mapping creates a service candidate
for each tag value for the Env key. Each service candidate
contains only CIs with the same value for the Env key. |
Example 2: one tag category, one value |
Environment |
Env |
Production |
Service Mapping creates the service candidate
containing only CIs that have the Env tag key with the
Production tag value. |
Example 3: one tag category, two values |
Environment |
Env |
Staging,Production |
Service Mapping creates two service
candidates: One containing CIs that have the Production tag
value; another containing CIs that have the Staging tag value. |
Example 4: two tag categories, no values |
Environment Application |
Env App |
Not defined |
Service Mapping creates a service candidate
for each combination of tag values for all defined tag
keys. |
Example 5: two tag categories, two values for each
category |
Environment Application |
Env App |
Production,Staging
HR,Finance
|
Service Mapping creates four service
candidates: production::hr, production::finance, staging::hr,
staging::finance. |
Service Mapping
creates names for tag-based services using tag values discovered for the tag
definitions, to which these tag-based services belong. For example, for
Environment and Application tag categories with Production and HR as their
respective tag values, the default service name is production::hr. Tag-based service
names use low case.