Service Catalog uses service definition schemas to store and display relevant metadata about your services. The schemas have built-in validation rules to ensure that only valid values are accepted and you can view warnings in the Definition tab on the side panel for any selected services.
There are four supported versions of the schema:
V2 is the earliest version, and contains some experimental features, such as dd-team, which are removed from v2.1.
V2.1 supports additional UI elements such as service groupings and fields like application, tier, and lifecycle. Application, along with Teams, can be used as grouping variables in Service Catalog. Lifecycle helps you differentiate between production, experimental, or deprecated services to indicate development stages and apply different reliability and availability requirements. Tier indicates the criticality of services, to prioritize during incident triage. For example, tier 1 typically represents the most critical services whose failure would result in severe customer impact, whereas tier 4 services typically have no impacts on actual customer experience.
V2.2 supports user annotation and overwriting auto-detected service type and languages using the fields type and languages. It also adds support for associating CI pipelines with a service using the field ci-pipeline-fingerprints. This version also includes less restrictive validation logic for contact.type and link.type, so users should expect fewer warnings while submitting YAML.
V3.0 adds a kind field that supports schemas for additional component types including applications, internal and external libraries, queues, and datastores. Any components within an application implicitly inherit its metadata. Furthermore, this version supports manually declaring dependency relationships, in addition to the auto-detected topology through Distributed Tracing and Universal Service Monitoring.
For more information about the latest updates, see the schemas on GitHub.
Opt in to the private beta for metadata schema v3.0!
The Entity Definition Schema is a structure that contains basic information about an entity. See the full schema on GitHub.
New features in v3.0
Expanded data model
v3.0 supports multiple kinds of entities. You can organize your systems using various components such as applications, services, queues, and datastores.
Enhanced relationship mapping
With APM and USM data, you can automatically detect dependencies among components. v3.0 supports manual declaration to augment auto-detected application topology to ensure a complete overview of how components interact within your applications.
Inheritance of application metadata
Components within an application automatically inherit the application’s metadata. It’s no longer necessary to declare metadata for all related components one-by-one as in v2.1 and v2.2.
Example YAML for kind:application
entity.datadog.yaml
apiVersion:v3kind:applicationmetadata:name:myappnamespace:defaultdisplayName:My Apptags:- tag:valuelinks:- name:shopping-cart runbooktype:runbookurl:https://runbook/shopping-cart- name:shopping-cart architectureprovider:gdocurl:https://google.drive/shopping-cart-architecturetype:doc- name:shopping-cart Wikiprovider:wikiurl:https://wiki/shopping-carttype:doc- name:shopping-cart source codeprovider:githuburl:http://github/shopping-carttype:repocontacts:- name:Support Emailtype:emailcontact:team@shopping.com- name:Support Slacktype:slackcontact:https://www.slack.com/archives/shopping-cartowner:myteamadditionalOwners:- name:opsTeamtype:operatorintegrations:pagerduty:serviceURL:https://www.pagerduty.com/service-directory/Pshopping-cartopsgenie:serviceURL:https://www.opsgenie.com/service/shopping-cartregion:USspec:components:- service:myservice- service:otherserviceextensions:datadoghq.com/shopping-cart:customField:customValuedatadog:code:- paths:- baz/*.c- bat/**/*- ../plop/*.javaevents:- name:"deployment events"query:"app:myapp AND type:github"- name:"event type B"query:"app:myapp AND type:github"logs:- name:"critical logs"query:"app:myapp AND type:github"- name:"ops logs"query:"app:myapp AND type:github"pipelines:fingerprints:- fp1- fp2
Specify common components that are part of multiple applications
If a single component is part of multiple applications, you must specify that component in the YAML for each application. For example, if the datastore orders-postgres is a component of both a postgres fleet and a web application, specify two YAMLs:
For the postgres fleet (managed-postgres), specify a definition for kind:application:
The inheritFrom field instructs the ingestion pipeline to inherit metadata from the entity’s metadata referenced by <entity_kind>:<name>.
Note: The entity reference only applies to an entity from the same YAML file.
Implicit Inheritance
Components (kind:service, kind:datastore, kind:queue, kind:library) inherit all metadata from the application that it belongs to under the following conditions:
The component belongs to only one application in the same YAML file. For example, if a component of kind:service is specified as part of two separate kind:application definitions, it does not implicitly inherit the metadata from either parent application.
The clause inheritFrom:<entity_kind>:<name> is absent in the YAML file.
