- 필수 기능
- 앱 내
- 서비스 관리
- 인프라스트럭처
- 애플리케이션 성능
- 디지털 경험
- 소프트웨어 제공
- 보안
- 로그 관리
- 관리
- 인프라스트럭처
- ci
- containers
- csm
- ndm
- otel_guides
- overview
- slos
- synthetics
- tests
- 워크플로
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:
dd-team
, which are removed from v2.1.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.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.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.
The Entity Definition Schema is a structure that contains basic information about an entity. See the full schema on GitHub.
v3.0 supports multiple kinds of entities. You can organize your systems using various components such as applications, services, queues, and datastores.
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.
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.
kind:application
entity.datadog.yaml
apiVersion: v3
kind: application
metadata:
name: myapp
namespace: default
displayName: My App
tags:
- tag:value
links:
- name: shopping-cart runbook
type: runbook
url: https://runbook/shopping-cart
- name: shopping-cart architecture
provider: gdoc
url: https://google.drive/shopping-cart-architecture
type: doc
- name: shopping-cart Wiki
provider: wiki
url: https://wiki/shopping-cart
type: doc
- name: shopping-cart source code
provider: github
url: http://github/shopping-cart
type: repo
contacts:
- name: Support Email
type: email
contact: team@shopping.com
- name: Support Slack
type: slack
contact: https://www.slack.com/archives/shopping-cart
owner: myteam
additionalOwners:
- name: opsTeam
type: operator
integrations:
pagerduty:
serviceURL: https://www.pagerduty.com/service-directory/Pshopping-cart
opsgenie:
serviceURL: https://www.opsgenie.com/service/shopping-cart
region: US
spec:
components:
- service:myservice
- service:otherservice
extensions:
datadoghq.com/shopping-cart:
customField: customValue
datadog:
code:
- paths:
- baz/*.c
- bat/**/*
- ../plop/*.java
events:
- 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
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
:
entity.datadog.yaml
apiVersion: v3
kind: application
spec:
components:
- datastore:orders-postgres
- datastore:foo-postgres
- datastore:bar-postgres
metadata:
name: managed-postgres
owner: db-team
For the web application (shopping-cart
), declare a separate definition for kind:application
:
entity.datadog.yaml
apiVersion: v3
kind: application
spec:
lifecycle: production
tier: critical
components:
- service:shopping-cart-api
- service:shopping-cart-processor
- queue:orders-queue
- datastore:orders-postgres
metadata:
name: shopping-cart
owner: shopping-team
additionalOwners:
- name: sre-team
type: operator
---
apiVersion: v3
kind: datastore
metadata:
name: orders-postgres
additionalOwners:
- name: db-team
type: operator
---
apiVersion: v3
kind: service
metadata:
name: shopping-cart-api
---
apiVersion: v3
kind: service
metadata:
name: shopping-cart-processor
---
entity.datadog.yaml
inheritFrom:<entity_kind>:<name>
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.
Components (kind:service
, kind:datastore
, kind:queue
, kind:ui
) inherit all metadata from the application that they belong to under the following conditions:
inheritFrom:<entity_kind>:<name>
is absent in the YAML file.POST https://api.datadoghq.com/api/unstable/catalog/definition Permission: SERVICE_CATALOG_WRITE
curl --location 'https://api.datadoghq.com/api/unstable/catalog/definition' \
--header 'DD-API-KEY: <KEY>' \
--header 'DD-APPLICATION-KEY: <APP_KEY>' \
--data-raw '
apiVersion: v3
kind: application
metadata:
name: shopping-cart-app
tags:
- tag:value
links:
- name: shopping-cart runbook
type: runbook
url: https://runbook/shopping-cart
contacts:
- name: Support Email
type: email
contact: team@shopping.com
- name: Support Slack
type: slack
contact: https://www.slack.com/archives/shopping-cart
owner: myteam
spec:
code:
components:
- service:shopping-cart-processing
- service:shopping-cart-checkout
---
apiVersion: v3
kind: service
metadata:
name: shopping-cart-processing
---
apiVersion: v3
kind: service
metadata:
name: shopping-cart-checkout
'
GET https://api.datadoghq.com/api/unstable/catalog/definition Permission: SERVICE_CATALOG_READ
curl --location 'https://api.datadoghq.com/api/unstable/catalog/definition' \
--header 'DD-API-KEY: <KEY>' \
--header 'DD-APPLICATION-KEY: <APP_KEY>'
GET https://api.datadoghq.com/api/unstable/catalog/definition/id/
curl --location 'https://api.datadoghq.com/api/unstable/catalog/definition/id/<id>' \
--header 'DD-API-KEY: <KEY>' \
--header 'DD-APPLICATION-KEY: <APP_KEY>'
GET https://api.datadoghq.com/api/unstable/catalog/definition/ref/ Permission: SERVICE_CATALOG_READ
curl --location 'https://api.datadoghq.com/api/unstable/catalog/definition/ref/<ref>' \
--header 'DD-API-KEY: <KEY>' \
--header 'DD-APPLICATION-KEY: <APP_KEY>'
URL Parameter: ref <kind>:<name>
DELETE https://api.datadoghq.com/api/unstable/catalog/definition/ref/ Permission: SERVICE_CATALOG_WRITE
curl --location --request DELETE 'https://api.datadoghq.com/api/unstable/catalog/definition/ref/<ref>' \
--header 'DD-API-KEY: <KEY>' \
--header 'DD-APPLICATION-KEY: <APP_KEY>'
URL Parameter: ref <kind>:<name>
Additional helpful documentation, links, and articles: