惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

GbyAI
GbyAI
阮一峰的网络日志
阮一峰的网络日志
G
Google Developers Blog
J
Java Code Geeks
Blog — PlanetScale
Blog — PlanetScale
大猫的无限游戏
大猫的无限游戏
云风的 BLOG
云风的 BLOG
Vercel News
Vercel News
L
LangChain Blog
Hugging Face - Blog
Hugging Face - Blog
T
The Blog of Author Tim Ferriss
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
Stack Overflow Blog
Stack Overflow Blog
P
Proofpoint News Feed
腾讯CDC
博客园_首页
博客园 - 聂微东
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
M
MIT News - Artificial intelligence
WordPress大学
WordPress大学
D
DataBreaches.Net
Microsoft Security Blog
Microsoft Security Blog
有赞技术团队
有赞技术团队
博客园 - 叶小钗

Datadog | The Monitor blog

Introducing our open source AI-native SAST Instrument and monitor Boomi integration flows with OpenTelemetry and Datadog Not all index scans are equal: How we cut query latency by over 99% Platform engineering metrics: What to measure and what to ignore Integrate Recorded Future threat intelligence with Datadog Cloud SIEM CI/CD security: threat modeling using a MITRE-style threat matrix CI/CD security: How to secure your GitHub ecosystem Ingress NGINX is EOL: A practical guide for migrating to Kubernetes Gateway API Operating agentic AI with Amazon Bedrock AgentCore and Datadog LLM Observability: Lessons from NTT DATA Introducing the Datadog Code Security MCP Capture and analyze custom heatmaps in Session Replay Understand session replays faster with AI summaries and smart chapters Monitor ClickHouse query performance with Datadog Database Monitoring How we designed empathetic alert sounds for on-call engineers Search and act across Datadog to resolve issues faster with Bits Assistant Measure the business impact of every product change with Datadog Experiments Analyzing round trip query latency Configuring JavaScript caches for better performance Introducing Bits AI Dev Agent for Code Security Datadog achieves ISO 42001 certification for responsible AI Monitor Nutanix clusters, hosts, and VMs with Datadog Monitor Juniper Mist in Datadog A new Host Map for modern infrastructure Annotate traces to improve LLM quality with Datadog LLM Observability What’s new in Cloud SIEM: AI-powered investigations, enhanced threat intelligence, and scalable security operations Explore Kubernetes with native OpenTelemetry data Monitor Oracle Fusion Cloud Applications with Datadog Announcing the Datadog Terraform provider v4.0.0 Scaling Kubernetes workloads on custom metrics How to design cloud environments for AI-powered threat analysis
Import Backstage YAML files into Datadog to manage all yo...
Lei Wang, David Lentz · 2023-07-20 · via Datadog | The Monitor blog

The Datadog Software Catalog centralizes your organization’s knowledge about the ownership, reliability, performance, costs, and security of your services. If you’re also using Backstage to keep track of your services, you can leverage our support for Backstage YAML to easily consolidate and maintain all your service information in the Software Catalog.

By automatically importing your Backstage YAML, Datadog lets you manage all your services in a single platform, so you can view service data side-by-side with observability data from your applications and infrastructure and eliminate knowledge gaps. Datadog also keeps your Software Catalog complete and up to date, even as you create and modify services in Backstage.

In this post, we’ll show you how to: - Populate the Software Catalog with your Backstage YAML - Import multiple service definitions to easily create or modify any number of services - Validate service metadata by viewing schema version information

Populate the Software Catalog with your Backstage YAML

The Software Catalog gives teams throughout your organization a central repository for managing services. When you enable the GitHub integration—as shown in the screenshot below—Datadog will automatically create and maintain Software Catalog entries for your Backstage services.

On the APM configuration page, you can link source code in your GitHub repositories to automatically create Software Catalog entries.

The integration constantly scans your repositories for Backstage YAML files named service.datadog.yaml and catalog-info.yaml—which you create when you add your service to the Backstage Software Catalog. The code snippet below shows an example of catalog-info.yaml.

apiVersion: backstage.io/v1alpha1

kind: component

metadata:

annotations:

backstage.io/techdocs-ref: github://design/doc

some.annotation: value

namespace: distribution

name: delivery-tracker

title: Delivery App

description: delivery app component responsible for transit processes

tags: ["framework:spring", "db:mysql"]

links:

- title: Wiki

url: https://backstage.core.shopist.org/docs/default/component/delivery-cancel

icon: help

- title: runbook

url: https://backstage.core.shopist.org/docs/default/component/rollback

icon: help

- title: source

url: https://gitlab.shopist.org/shopist/delivery-app

icon: gitlab

- title: jira

url: https://shopist.atlassian.net/browse/DA

icon: help

- title: diagram

url: https://shopist.atlassian.net/wiki/spaces/DA

icon: help

ignore-attribute:

id: 1

value: "ignore_value"

spec:

type: service

lifecycle: production

owner: delivery-app

system: logistics

Datadog automatically imports these new or revised Backstage files to keep the Software Catalog up to date. Along with the ability to automatically create and maintain Software Catalog entries based on your Datadog-formatted service definition files, this enables you to troubleshoot, investigate, and collaborate across all your services in a single platform.

As an alternative to using the GitHub integration, you can post Backstage YAML files to the Datadog API. This allows you to programmatically send Backstage service definitions that may not exist in your GitHub repositories.

Import multiple Backstage service definitions at once

To quickly get started managing all your Backstage services in the Software Catalog, you can register any number of new services by adding their definitions to a single YAML file and then sending that file to Datadog via the API or adding it to a repository to be imported by our GitHub integration. The code snippet below shows an example of how you could define multiple services in a single YAML file. Each service definition begins with three dashes to delineate it from the other services.

---

apiVersion: backstage.io/v1alpha1

kind: component

metadata:

annotations:

backstage.io/techdocs-ref: github://architecture/doc

namespace: shopping

name: delivery-transit-prod

title: Delivery App Transit

description: delivery-app component responsible for transit

spec:

type: service

lifecycle: production

owner: delivery-app

system: logistics

---

apiVersion: backstage.io/v1alpha1

kind: component

metadata:

annotations:

backstage.io/techdocs-ref: github://architecture/doc

namespace: shopping

name: delivery-aggregate-prod

title: Delivery App Aggregation

description: delivery-app component responsible for aggregation spec:

type: service

lifecycle: production

owner: delivery-app

system: logistics

After you’ve imported your Backstage YAML, all your service data will be centralized in Datadog, alongside observability and security data from your applications and infrastructure.

Datadog creates and maintains Software Catalog entries from the Backstage YAML you provide. That YAML is based on the Backstage schema, which includes the metadata required by the Backstage Software Catalog. But that schema leaves out some metadata that the Software Catalog can use to help your team manage the complexity of your microservices architecture.

Software Catalog makes it easy to see which service definitions are based on the Backstage schema so that you can easily identify services that might be missing key metadata. In the screenshot below, the Schema Version column is highlighted to show the schema used by each service definition. Datadog has imported Backstage YAML for services such as bitsburg to automatically create Software Catalog entries for them. You can see that this service is based on the Backstage schema, which indicates an opportunity to enrich it with additional metadata that the Software Catalog can use, such as a service team’s on-call schedule and contact information.

The Software Catalog’s Schema Version column shows schema information for each service, indicating whether it’s a Backstage or Datadog schema and specifying the schema version.

Once a Backstage service definition has been imported, you can update it to ensure that the service metadata is complete and that it takes full advantage of the Software Catalog’s capabilities to help you organize and communicate information about your services. The screenshot below shows the built-in editor where you can add or modify service metadata. We’ve added a URL to the PagerDuty integration field so that the Software Catalog will show on-call information for this service.

The built-in metadata editor contains fields for team, description, contact information, and on-call integrations.

Once you’ve modified metadata that’s been imported from Backstage, it’s automatically converted to use the Datadog schema. In the screenshot below, the Software Catalog shows that the service now uses version 2.2 of the Datadog schema. The on-call column now shows contact information for the team members currently on call.

The Software Catalog shows that after the metadata for the service has been edited, the schema version is now Datadog v2.1.

Manage all your services with the Software Catalog

With support for Backstage YAML, Datadog automatically creates and maintains Software Catalog entries for your Backstage-based services so that you have a single platform that provides visibility into all your services. See our documentation to start importing Backstage service definitions into the Software Catalog.

You can also populate the Software Catalog using APM, USM, service telemetry, and via the Datadog UI. If you’re not already using Datadog, you can start today with a 14-day free trial.