- 필수 기능
- 시작하기
- Glossary
- 표준 속성
- Guides
- Agent
- 통합
- 개방형텔레메트리
- 개발자
- API
- Datadog Mobile App
- CoScreen
- Cloudcraft
- 앱 내
- 서비스 관리
- 인프라스트럭처
- 애플리케이션 성능
- APM
- Continuous Profiler
- 스팬 시각화
- 데이터 스트림 모니터링
- 데이터 작업 모니터링
- 디지털 경험
- 소프트웨어 제공
- 보안
- AI Observability
- 로그 관리
- 관리
Datadog Service Catalog is pre-populated with entries detected through APM, eBPF-based autodiscovery with Universal Service Monitoring, and RUM applications.
With APM, Datadog can automatically discover the dependencies for an instrumented service, such as a database, a queue, or a third-party dependencies, even if that dependency hasn’t been instrumented yet. These uninstrumented dependencies are categorized as separate services. Datadog changed service names of client spans (span.kind:client) to represent dependencies of your instrumented services. For example, a span representing a client call from a service auth-dotnet to a PostgreSQL database would be tagged with service:auth-dotnet-postgres.
If you are using APM and would like to remove the automatically named services from your Service Catalog and Service Map, you can opt in to new inferred entities experience, which allows you to filter Service Catalog entries by entity type, such as database, queue, or third-party dependencies. You can optionally remove any service overrides like service:my-service-http-client from your catalog or map.
To specify on-call, source code, or documentation for your services, you can add metadata to any existing services via the UI, APIs, or other automation. 2.2 is the recommended version. To try experimental features, you can opt into the beta program for schema 3.0 by submitting a request.
The Service Definition Schema is a structure that contains basic information about a service. See the full schema on GitHub.
service.datadog.yaml
schema-version: v2.2
dd-service: shopping-cart
team: e-commerce
application: shopping-app
tier: "1"
type: web
languages:
- go
- python
contacts:
- type: slack
contact: https://yourorg.slack.com/archives/e-commerce
- type: email
contact: ecommerce@example.com
- type: microsoft-teams
contact: https://teams.microsoft.com/example
links:
- name: Runbook
type: runbook
url: http://runbook/shopping-cart
- name: Source
type: repo
provider: github
url: https://github.com/shopping-cart
- name: Deployment
type: repo
provider: github
url: https://github.com/shopping-cart
- name: Config
type: repo
provider: github
url: https://github.com/consul-config/shopping-cart
- name: E-Commerce Team
type: doc
provider: wiki
url: https://wiki/ecommerce
- name: Shopping Cart Architecture
type: doc
provider: wiki
url: https://wiki/ecommerce/shopping-cart
- name: Shopping Cart RFC
type: doc
provider: google doc
url: https://doc.google.com/shopping-cart
tags:
- business-unit:retail
- cost-center:engineering
integrations:
pagerduty:
service-url: https://www.pagerduty.com/service-directory/PSHOPPINGCART
opsgenie:
service-url: "https://www.opsgenie.com/service/uuid"
region: "US"
ci-pipeline-fingerprints:
- id1
- id2
extensions:
additionalProperties:
customField1: customValue1
customField2: customValue2
To explore the complete set of actions specifically related to Service Catalog, navigate to the Datadog Action Catalog. Filter for the actions you need:
Below is a comprehensive list of actions available for Service Catalog in Datadog Workflow Automation. Note that this list may evolve as new actions are added.
The service color is used in trace visualizations. Click the service type icon to change it.
With Service Catalog metadata schema 2.2, you can specify the type and language for user-defined services or overwrite the auto-detected type and language for instrumented services. Correctly label the service type and language to help other teams further understand what your services do and how to interact with them.