Schema v3.0 is the latest version of the Service Definition schema and is in beta. It introduces several new features and enhancements to provide more flexibility and detailed service definitions.
Opt in to the private beta for metadata schema v3.0!
Expanded data model: v3.0 supports multiple kinds of entities. You can organize your systems using various components such as systems, services, queues, and datastores.
Multi-ownership: You can assign multiple owners to any objects defined through the v3.0 schema to specify multiple points of contact.
Enhanced relationship mapping: With APM and USM data, you can automatically detect dependencies among components. v3.0 supports manual declaration to augment auto-detected system topology to ensure a complete overview of how components interact within your systems.
Inheritance of system metadata: Components within a system automatically inherit the system’s metadata. It’s no longer necessary to declare metadata for all related components one-by-one as in v2.1 and v2.2.
Precise code location: You can add the mapping of your code location for your service. The codeLocations section in v3.0 specifies the locations of the code with the repository that contains the code and its associated paths. The paths attribute is a list of globs that should match paths in the repository. Learn more about how this addition improves your experience with Datadog Code Analysis.
Metadata Schema v3.0 (beta)
The Entity Definition Schema is a structure that contains basic information about an entity. See the full schema on GitHub.
In v3.0, the application field has been replaced with system in the documentation to match the updated public schema terminology.
Example YAML for kind:system
entity.datadog.yaml
apiVersion:v3kind:systemmetadata: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 systems
If a single component is part of multiple systems, you must specify that component in the YAML for each system. 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:system:
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:ui) inherit all metadata from the system that they belong to under the following conditions:
There is only one system defined in the YAML file.
The clause inheritFrom:<entity_kind>:<name> is absent in the YAML file.
