Catalog utiliza esquemas de definición para almacenar y mostrar metadatos relevantes sobre sus entidades. Los esquemas tienen reglas de validación integradas para garantizar que solo se acepten valores válidos. Puede visualizar advertencias en la pestaña Definición en el panel lateral de Catalog para cualquier servicio seleccionado.
Versiones admitidas
El esquema del modelo de entidad v3.0 no es compatible con su sitio de Datadog seleccionado ().
Datadog admite cuatro versiones del esquema de definición:
v3.0: Versión más reciente con modelo de datos ampliado, compatibilidad con propiedad múltiple, declaración manual de dependencias y funciones mejoradas para infraestructura compleja.
v2.2: Admite anotaciones de usuario para metadatos personalizados y asociaciones de canalizaciones de CI para vincular servicios con sus procesos de compilación.
v2.1: Admite agrupaciones de servicios para una mejor organización e introduce campos adicionales para descripciones de servicio más completas.
v2: Versión admitida más antigua, que proporciona campos esenciales para metadatos y documentación básica de servicios.
Cada versión se basa en la anterior, añadiendo nuevas funcionalidades mientras mantiene la compatibilidad con versiones anteriores. Elija la versión que mejor se adapte a sus necesidades y a la complejidad de su infraestructura.
Comparación de versiones
Las siguientes características son compatibles en cada versión:
Característica
v3.0
v2.2
v2.1
v2.0
Metadatos básicos
Agrupaciones de servicios
Anotaciones de usuario
Asociaciones de canalización de CI
Modelo de datos expandido
Propiedad múltiple
Declaración manual de dependencias
Para obtener información detallada sobre cada versión, incluidos esquemas completos y archivos YAML de ejemplo, consulte las páginas de versiones individuales en Supported versions.
Detalles de la versión
Opte por la vista previa para obtener la versión más reciente de Catalog.
El esquema del modelo de entidad v3.0 no es compatible con su sitio de Datadog seleccionado ().
Características clave
Modelo de datos expandido: la v3.0 admite múltiples tipos de entidades. Puede organizar sus sistemas utilizando varios componentes como sistemas, servicios, colas y Datastore.
Propiedad múltiple: puede asignar varios propietarios a cualquier objeto definido a través del esquema de la v3.0 para especificar múltiples puntos de contacto.
Mapeo de relaciones mejorado: con los datos de APM y USM, puede detectar automáticamente las dependencias entre los componentes. La 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 sus sistemas.
Herencia de metadatos del sistema: los componentes dentro de un sistema heredan automáticamente los metadatos del sistema. Ya no es necesario declarar los metadatos para todos los componentes relacionados uno por uno como en la v2.1 y la v2.2.
Ubicación precisa del código: agregue el mapeo de la ubicación de su código para su servicio. La sección codeLocations en la v3.0 especifica las ubicaciones del código con el repositorio que contiene el código y su paths asociado. El atributo paths es una lista de globs que deben coincidir con las rutas en el repositorio.
Registros y eventos filtrados: declare consultas guardadas de registros y eventos para un system a través de las secciones logs y events y visualice los resultados en la página del Sistema.
Entidades personalizadas: defina tipos de entidades personalizados más allá de Servicio, Sistema, Datastore, Cola y API. Defina el contexto de las tarjetas de puntuación y las acciones para tipos específicos de entidades.
(Próximamente) Integrations: intégrese con herramientas de terceros para obtener información de forma dinámica relacionada con sus componentes (por ejemplo, solicitudes de extracción de GitHub, incidentes de PagerDuty y canalizaciones de GitLab). Genere informes y escriba reglas de tarjetas de puntuación para cualquier fuente de terceros.
(Próximamente) Agrupar por producto o dominio: organice los componentes por producto, lo que permite múltiples capas de agrupación jerárquica.
Componentes que forman parte de múltiples sistemas
Si un solo componente forma parte de múltiples sistemas, debe especificar ese componente en el YAML para cada sistema. Por ejemplo, si el Datastore orders-postgres es un componente tanto de un conjunto de postgres como de una aplicación web, especifique dos YAML:
Para el conjunto de postgres (managed-postgres), especifique una definición para kind:system:
El campo inheritFrom indica a la canalización de ingesta que herede los metadatos de los metadatos de la entidad referenciados por <entity_kind>:<name>.
entity.datadog.yaml
inheritFrom:<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 bajo las siguientes condiciones:
Solo hay un sistema definido en el archivo YAML.
La cláusula inheritFrom:<entity_kind>:<name> no está presente en el archivo YAML.
Migración a la v3.0
La 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, existen nuevos puntos finales de API y un nuevo recurso de Terraform para la v3.0.
Para crear, obtener y eliminar definiciones para todos los tipos de entidades como puntos finales, sistemas, Datastore y colas, consulte la referencia de la API de catálogo.
Características clave
Anotaciones de usuario
Sobrescribir el tipo de servicio y los lenguajes detectados automáticamente usando type y languages
Asociar la canalización de CI con un servicio usando ci-pipeline-fingerprints
Lógica de validación menos restrictiva para contact.type y link.type
Para crear, obtener y eliminar definiciones para nuevos tipos de componentes como sistemas, Datastore y colas, consulte la referencia de la API de catálogo.
Para crear, obtener y eliminar definiciones para nuevos tipos de componentes como sistemas, Datastore y colas, consulte la referencia de la API de catálogo.
Para crear, obtener y eliminar definiciones para nuevos tipos de componentes como sistemas, Datastore y colas, consulte la referencia de la API de catálogo.
Las extensiones personalizadas están en Disponibilidad Limitada para todas las versiones de esquema.
Las extensiones personalizadas le permiten adjuntar metadatos específicos de la organización a las entidades, lo que permite el soporte para herramientas y flujos de trabajo personalizados. Por ejemplo, utilice extensions el campo para incluir notas de la versión, etiquetas de cumplimiento o modelos de propiedad en las definiciones de sus entidades.
Datadog también admite claves de extensión específicas para ciertas funciones. Estas incluyen:
datadoghq.com/dora-metrics: Defina patrones de ruta de código fuente para filtrar confirmaciones de Git al calcular métricas DORA.
datadoghq.com/cd-visibility: Controle qué confirmaciones se consideran parte de una implementación en CD Visibility.
El siguiente ejemplo define una extensión personalizada utilizada para gestionar la programación de versiones en todos los entornos:
Validación de esquema a través del complemento de IDE
Datadog proporciona un JSON Schema para las definiciones, de modo que cuando edita una definición en un IDE compatible, se proporcionan funciones como autocompletado y validación.
