Schema v3.0 introduce varias funciones nuevas y mejoras para ofrecer más flexibilidad y definiciones detalladas.
Características principales
Modelo de datos ampliado: la versión 3.0 admite varios tipos de entidades. Puedes organizar tus sistemas utilizando varios componentes, como sistemas servicios, colas y almacenes de datos.
Multipropietario: puedes asignar múltiples propietarios a cualquier objeto definido a través del esquema v3.0 para especificar múltiples puntos de contacto.
Asignación de relaciones mejorada: con los datos de APM y USM, puedes detectar automáticamente las dependencias entre los componentes. v3.0 admite la declaración manual para aumentar la topología del sistema detectada automáticamente y garantizar una visión completa de cómo interactúan los componentes dentro de tus sistemas.
Herencia de los metadatos del sistema: los componentes de un sistema heredan automáticamente los metadatos del sistema. Ya no es necesario declarar uno a uno los metadatos de todos los componentes relacionados, como en las versiones 2.1 y 2.2.
Localización de código precisa: añade la asignación de tu localización de código para tu servicio. La sección codeLocations en v3.0 especifica las localizaciones del código con el repositorio que contiene el código y sus paths asociadas. El atributo paths es una lista de globs que debe coincidir con las rutas en el repositorio.
Entidades personalizadas: define los tipos de entidad personalizados que no sean Servicio, Sistema, Almacén de datos, Colas y API. Limita las scorecards y acciones a tipos de entidad específicos.
(En vista previa) Integraciones: integra con herramientas de terceros para obtener dinámicamente información relacionada con tus componentes (por ejemplo, solicitudes pull de GitHub, incidentes de PagerDuty y pipelines de GitLab). Informa y escribe reglas de scorecard contra cualquier fuente de terceros.
Agrupar por producto o dominio: organiza los componentes por producto, permitiendo múltiples capas de agrupación jerárquica.
Elige la Vista previa para obtener la última versión de Software Catalog.
Entity Definition Schema es una estructura que contiene información básica sobre una entidad. Consulta el esquema completo en GitHub.
En la versión 3.0, el campo aplicación se ha sustituido por sistema en la documentación para ajustarse a la terminología actualizada del esquema público.
Ejemplo de YAML para kind:system
entity.datadog.yaml
apiVersion:v3kind:systemmetadata:name:myappdisplayName: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:codeLocations:- repositoryURL:https://github.com/myorganization/myrepo.gitpaths:- path/to/service/code/**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
Especificar componentes comunes que forman parte de varios sistemas
Si un único componente forma parte de varios sistemas, debes especificar dicho componente en el YAML de cada sistema. Por ejemplo, si el almacén de datos orders-postgres es un componente tanto de una flota postgres como de una aplicación web, especifica dos YAML:
Para la flota postgres (managed-postgres), especifica una definición para kind:system:
El campo inheritFrom indica al pipeline de ingesta que hereda los metadatos de los metadatos de la entidad a la que hace referencia <entity_kind>:<name>.
Herencia implícita
Los componentes (kind:service, kind:datastore, kind:queue, kind:ui) heredan todos los metadatos del sistema al que pertenecen en las siguientes condiciones:
Solo hay un sistema definido en el archivo YAML.
La cláusula inheritFrom:<entity_kind>:<name> está ausente en el archivo YAML.
api_version es la versión del esquema: 2.0, 2.1, 3.0
kind es nuevo y define el tipo de componente: servicio, cola, almacén de datos, sistema o API
metadata incluye el nombre, la descripción, la propiedad, los enlaces (documentación, runbooks, repositorios, contactos, dashboards), y etiquetas
spec incluye el nivel, el ciclo de vida, el lenguaje, el tipo y las relaciones con otros componentes
integrations incluye conexiones con PagerDuty y OpsGenie
Datadog incluye formas de filtrar y enlazar con otros datos de Datadog, como localizaciones de código, pipelines, logs y eventos
Migración a la versión 3.0
v3.0 admite los mismos métodos de creación de metadatos que las versiones anteriores, incluidos Github, API, Terraform, Backstage, ServiceNow y la interfaz de usuario. Sin embargo, hay nuevos endpoints de API y un nuevo módulo de Terraform para v3.0.
kind es nuevo y define el tipo de componente: servicio, cola, almacén de datos, sistema o API
dd-service es ahora metadata.name
team es ahora owner y additionalOwners si hay varios equipos
lifecycle, tier, languages y type están ahora en spec
links, contacts, description y tags están ahora en metadatos
application se ha mejorado para convertirse en su propio tipo: system. Ya no existe como campo discreto en un servicio
Páginas de sistema y API en el Software Catalog
La definición de entidades de kind:system y kind:api crea agrupaciones jerárquicas de entidades que incluyen servicios, colas, almacenes de datos y endpoints. Para definir componentes dentro de un sistema o API, puedes especificar valores para la clave components en el campo spec de la definición v3 de la entidad.
Ejemplo de YAML para kind:system:
entity.datadog.yaml
apiVersion:v3kind:systemmetadata:name:product-recommendationdescription:Surfaces personalized product suggestions in ShopistdisplayName:"Product Recommendation"tags:- product:recommendations- business-line:shared-componentsowner:shopistadditionalOwners:- name:Shopist Support Teamtype:Operatorspec:lifecycle:productiontier:"0"components:- service:product-recommendation- service:orders-app- api:products- system:shopist-user-trends
El sistema definido por el usuario anterior aparece en el Software Catalog como se muestra a continuación. Esta página contiene los datos de relación de los componentes entre el sistema y las dependencias ascendentes y descendentes, así como scorecards, logs y eventos agregados a todos los componentes del sistema.
La API definida por el usuario aparece en el Software Catalog como se muestra a continuación. Esta página contiene datos de relación de cómo interactúa la API con las dependencias, los componentes de la API, una vista previa de OpenAPI, y logs y eventos agregados a través de todos los endpoints.