Dynatrace helps you answer these questions by extending AI observability for a new wave of coding agents, including Claude Code, Google Gemini CLI, OpenAI Codex CLI, OpenCode, and GitHub Copilot SDK. Together, these integrations give engineering leaders, platform teams, and developers a consistent way to understand agent activity, token consumption, costs, tool behavior, and runtime impact: without forcing teams to stitch together fragmented telemetry across terminals, SDKs, dashboards, and development workflows. Dynatrace public AI agent instrumentation examples on GitHub demonstrate how to provide industry leading observability that drives performance, cost efficiency, and governance across complex, distributed AI-driven systems—all through a unified Dynatrace platform experience that developers can access directly via MCP without leaving their IDE.

From agent activity to engineering insight

As organizations adopt multiple coding agents, new adoption challenges emerge. One team might use Claude Code in the terminal, another may build internal tools with GitHub Copilot SDK, while others experiment with Gemini CLI or Codex CLI. Platform teams want visibility into usage, availability, and costs. Engineering leaders want to know whether agents improve delivery. Security and governance teams want confidence that all prompts, tool usage, and actions can be monitored appropriately.

Dynatrace provides a practical answer to these challenges: a single observability layer for agile development workflows. For agents that emit OpenTelemetry directly, such as Claude Code, Gemini CLI, and Codex CLI, Dynatrace can ingest telemetry related to sessions, tokens, costs, tool executions, errors, and performance. For GitHub Copilot workflows, Dynatrace adds production context, software delivery automation, and GitHub-based integrations that connect agent activity to real engineering workflows.

The payoff is clear. Developers gain visibility into how agents behave in real work. Platform teams can track adoption, usage trends, and cost signals. Engineering leaders can correlate agent activity with commits, pull requests, and delivery outcomes. And with an MCP-enabled production context, teams can connect coding-agent actions to what is happening in production.

“Before we instrumented Claude Code, we had no easy way to break down how our engineers actually used AI, which models, for what tasks, and at what cost. Now we can pinpoint inefficient model use and guide usage toward better cost-performance tradeoffs.”
— Markus Heimbach, Senior Director Software Development

Multiple coding agent experiences, one observability strategy

Each coding agent has a different operating model, which is why a common observability layer matters.

Claude Code

Claude Code already supports built-in OpenTelemetry, making it easy to send metrics and logs to Dynatrace with no code changes. Teams can track sessions, tokens, costs, tool activity, API health, and engineering output such as commits and pull requests. Logs, dashboards, and alerts help teams investigate failures, spot latency spikes, and catch unusual spend or error patterns early.

Gemini CLI

Gemini CLI includes OpenTelemetry-based observability and preconfigured dashboards, making it a strong fit for Dynatrace AI observability. Teams can correlate agent activity with broader platform signals and move quickly from raw telemetry to action. This includes debugging failed runs, identifying slow or error-prone tool calls, and alerting on cost or reliability regressions.

Codex CLI

Codex CLI supports opt-in OpenTelemetry monitoring, giving teams a path to audit usage and strengthen governance across CLI, IDE, and app experiences. With Dynatrace, logs and traces help investigate request flows, delays, and failures across agent workflows. Alerts can flag degraded reliability, unexpected behavior, or rising token consumption before they become larger issues.

GitHub Copilot SDK

GitHub Copilot SDK lets teams embed agentic workflows directly into applications, while Dynatrace adds live observability and security context. This matters because embedded agents become part of real engineering and production-adjacent workflows. Dynatrace helps trace execution paths, use logs for debugging and auditability, and set alerts for failures, latency, or policy-relevant events.

OpenCode

OpenCode is a terminal-based AI coding agent that helps developers work through coding tasks directly from the command line. Because OpenCode ships with native OpenTelemetry support, teams can route telemetry to Dynatrace without code changes by setting standard OTLP environment variables. With Dynatrace, teams can track LLM call volume, session activity, tool usage, request latency, and workflow behavior across real developer sessions. Traces help teams inspect LLM requests, tool executions, session lifecycle events, message processing, file snapshots, or diff operations.

Across all operating models, the value is the same: one strategy for monitoring adoption and impact, understanding costs, logging and tracing agent activity, alerting on reliability issues, and debugging real-world workflows as coding agents scale across the enterprise.

Why this matters now

Teams are no longer asking whether coding agents are useful. They’re asking how to drive adoption, scale them safely, govern them consistently, and prove their impact. That requires visibility into usage, cost, reliability, and engineering outcomes across teams and tools. Dynatrace helps organizations make that shift with the observability and production context needed to expand coding-agent adoption with confidence.

The coding-agent market is moving fast. Claude Code, GitHub Copilot SDK, Google Gemini CLI, and OpenAI Codex CLI each represent a different path toward agentic software delivery, from terminal-based workflows to embedded SDKs and governed local execution. At the same time, Dynatrace has been expanding its developer-facing AI surface with the Dynatrace MCP Server, GitHub Copilot integrations, and AI observability capabilities built to connect agent behavior with real production systems. The timing matters because teams are no longer evaluating whether coding agents are useful. They’re deciding how to drive adoption, scale up usage safely, govern usage consistently, and measure real impact.

Ready to see AI coding agents through a Dynatrace lens?

With Dynatrace, teams can understand adoption, spend, reliability, tool behavior, and engineering outcomes in one place, while giving agents access to the live production context they need to make better decisions.

Whether your developers are working in Claude Code, building on GitHub Copilot SDK, experimenting with Gemini CLI, or adopting Codex CLI, Dynatrace helps bring observability, governance, and production awareness into the heart of agentic software delivery.

Public examples already demonstrate this approach for Claude Code, and the broader Dynatrace MCP and AI observability ecosystem provides the foundation to extend the same value across the next generation of coding agents.

Ready to learn more?

In our Git repository, you’ll find step-by-step examples for supported coding-agent workflows, including how to configure OpenTelemetry export, send telemetry data to Dynatrace, and use the provided dashboards to analyze the activity of your AI coding agents.

The post Dynatrace expands AI Coding Agent monitoring for Claude Code, Google Gemini CLI, Codex CLI, OpenCode, and GitHub Copilot SDK appeared first on Dynatrace news.

Every software development team grappling with Generative AI (GenAI) and LLM-based applications knows the challenge: how to observe, monitor, and secure production-level workloads at scale. Traditional debugging approaches, logs, and occasional remote breakpoint instrumentation can’t easily keep pace with cloud-native AI deployments, where performance, compliance, and costs are all on the line. How can you gain insights that drive innovation and reliability in AI initiatives without breaking the bank?
Dynatrace helps enhance your AI strategy with practical, actionable knowledge to maximize benefits while managing costs effectively.

Amazon Bedrock, equipped with Dynatrace Davis® AI and LLM observability, gives you end-to-end insight into the Generative AI stack, from code-level visibility and performance metrics to GenAI-specific guardrails.

Developers deserve a frictionless troubleshooting experience and fast access to real-time data—no more guesswork or costly redeployments. Here’s how Dynatrace, combined with Amazon Bedrock, arms teams with instant intelligence from dev to production, helping to accelerate innovation while keeping performance, costs, and compliance in check.

Introducing Amazon Bedrock and Dynatrace Observability

Amazon Bedrock is a serverless service for building and scaling Generative AI applications easily with foundation models (FM). It provides an easy way to select, integrate, and customize foundation models with enterprise data using techniques like retrieval-augmented generation (RAG), fine-tuning, or continued pre-training.

Dynatrace is an all-in-one observability platform that automatically collects production insights, traces, logs, metrics, and real-time application data at scale.  With powerful Davis AI engine Dynatrace notifies teams about production-level issues before they disrupt users, helps predict resource usage,costs, and performance issues, and delivers guardrails that protect data and maintain compliance.

Together, Amazon Bedrock and Dynatrace provide an end-to-end observability solution for AI applications:

• Predictive operations: Proactive usage and cost forecasting to reduce unexpected operational expenses and token usage.
• Production performance monitoring: Service uptime, service health, CPU, GPU, memory, token usage, and real-time cost and performance metrics.
• Guardrail analysis: Detect hallucinations, track prompt injections, mitigate PII leakage, and ensure brand-safe outputs.
• Full-stack tracing: Track each user request across multiple FMs, vector databases, orchestrators (LangChain), and custom business logic.
• Compliance: Document all inputs and outputs, maintaining full data lineage from prompt to response to build a clear audit trail and ensure compliance with regulatory standards.

^{Figure 1. Video overview of Amazon Bedrock dashboard with Dynatrace AI and LLM Observability solution.}

How it works

Dynatrace seamlessly instruments your LLM-based workloads using Traceloop OpenLLMetry, which augments standard OpenTelemetry data with AI-specific KPIs (for example, token usage, prompt length, and model version).

Combined with Amazon Bedrock, you can:

• Spin up your AI model on Amazon Bedrock—choose from providers like AI21, Anthropic, Cohere, Stability AI, Mistral AI, Meta, or Amazon’s own Nova/Titan foundation models.
• Automatically instrument your application with OpenTelemetry.
• Configure OpenLLMetry to capture specialized LLM details as spans and metrics, like model name, completion time, token count, token cost, and prompt text.
• Send unified data to Dynatrace for analysis alongside your logs, metrics, and traces.

Behind the scenes, Dynatrace merges the standard telemetry with these advanced AI attributes, surfaces them in real-time dashboards, and applies AI-driven analytics to discover anomalies, forecast usage costs, and diagnose root causes.

How to set up and instrument your data with OpenLLMetry

Traceloop OpenLLMetry is an open source extension that standardizes LLM and Generative AI data collection. By layering on top of OpenTelemetry standards, OpenLLMetry captures the critical metrics you can’t get by default—like the number of tokens, model temperature, or guardrail triggers.

Here’s how to set it up for Amazon Bedrock:

1. Install OpenLLMetry in your Python or Node.js environment:

 pip install traceloop-sdk

from traceloop.sdk import Traceloop

headers = {

'Authorization': f"Api-Token {environ.get('DYNATRACE_TEAM_KEY')}"

}

Traceloop.init(

app_name=environ.get('DYNATRACE_APP_NAME'),

api_endpoint=environ.get('DYNATRACE_URL'),

headers=headers

)

2. Configure environment variables to send data to Dynatrace via your ingest token:

 DYNATRACE_URL =https://123abcde.live.dynatrace.com/api/v2/otlp 

DYNATRACE_TEAM_KEY=dt0.....

3. You can optionally add OpenLLMetry decorators or instrumentation to your LLM calls (for example, with LangChain or direct Bedrock SDK calls).

When your application queries Amazon Bedrock, OpenLLMetry automatically captures:

• Prompt tokens vs. completion tokens
• Finish reason (did the LLM stop due to a user request, or was the max token limit reached?)
• Model type (which Amazon foundation model or third-party model is used?)
• Performance: Response time, throughput, and error rate
  • Guardrail activations: Toxicity, PII, denied topics, and hallucinations
  • System, prompt, and completion messages and roles

This data is instantly correlated in Dynatrace so you can visualize or alert on critical thresholds (for example, if your average token usage spikes or your overall cost forecast grows beyond budget).

How to debug incorrect responses in production

Let’s walk through a real-world scenario:

Your production travel agent application—powered by Amazon Bedrock and Dynatrace—gives users incorrect travel recommendations. Perhaps it suggests flights or hotels that don’t exist or mixes up time zones. This isn’t just a minor inconvenience; it jeopardizes user experience and can directly impact revenue and trust.

Here’s how Dynatrace helps you trace and resolve the issue quickly:

Proactive alerting with Davis AI

You receive an alert from Dynatrace Davis AI anomaly detection indicating incorrect system behavior. There might be a spike in “incorrect itinerary” complaints or conversation outcomes flagged as “nonsensical.” Davis AI correlates the unusual LLM responses with application telemetry and usage patterns, so you immediately know something is off in the recommendation flow.

Full-stack end-to-end tracing

In Dynatrace Distributed Tracing, you see the entire transaction trace for the affected user session. This includes front-end requests, back-end aggregator logic, calls to Amazon Bedrock, and any vector database lookups performed for retrieval-augmented generation (RAG). Rather than sifting through multiple logs, you have a single timeline that reveals exactly where the LLM call returned unexpected data.

Inspecting the GenAI model details

By drilling down into the span data enriched by OpenLLMetry, you can see:

• Prompt and completion text and tokens used.
• The specific foundation model version (for example, anthropic.claude-v1 or amazon.nova).
• Temperature setting and max token limits.
• Any error codes or guardrail triggers.

This clarity helps you pinpoint if the model produces off-base recommendations because of a misaligned temperature, an out-of-date context, or a mismatch in user inputs.

Root cause analysis

With Dynatrace, you quickly correlate the LLM anomaly to a specific function in your microservice code. You discover that an external data source used for itinerary validation had missing or stale updates, causing the LLM prompt to reference invalid flights. You’ve found the “why” without manually spelunking logs in disparate systems.

Resolving and validating

A fix might involve updating your data pipeline or refining the prompt logic. You can deploy the change and watch in near real-time as Dynatrace collects new traces and logs. Davis AI recognizes that the anomaly is cleared, confirming that your fix resolved the incorrect responses—no guesswork required.

You can find the code example for our travel agent application here for review, and the dashboard on our Dynatrace Playground instance.

Summary

By integrating Amazon Bedrock with Dynatrace end-to-end observability, you not only catch issues early but also trace them across your entire AI stack to the root cause. Building or scaling Generative AI applications with Amazon Bedrock requires robust insights into your environment—from model usage and performance metrics to cost forecasts and guardrail efficacy.

Dynatrace helps you scale with:

• Complete end-to-end tracing across your services, external data pipelines, and LLM calls.
• Predictive analytics that forecast AI resource usage and cost trends, letting you proactively manage budgets.
• Unified dashboards that bring performance, cost, code-level data, logs, metrics, and audit events together.
• Compliance and governance that integrate security checks, data masking, and guardrail analysis.

Whether you’re a developer racing to put your latest AI-powered application or a new feature into production or an SRE ensuring your system meets enterprise-grade SLAs, Dynatrace and Amazon Bedrock help you to create frictionless AI applications, focusing on performance and observability—at any scale, in production, with no downtime.

Useful resources

• Dynatrace Amazon Bedrock instrumentation documentation
• Supported GenAI technologies
• Dynatrace Playground demo
• Video webinar: AI and LLM Observability with Dynatrace

The post Deliver secure, safe, and trustworthy GenAI applications with Amazon Bedrock and Dynatrace appeared first on Dynatrace news.

Deploying software in Kubernetes is often viewed as a straightforward process—just use kubectl or a GitOps solution like ArgoCD to deploy a YAML file, and you’re all set, right? Unfortunately, Kubernetes deployments can be fraught with challenges beyond the surface level. Numerous hurdles can hinder successful deployments, from resource constraints to external dependencies and monitoring inadequacies. In this article, we’ll explore these challenges in detail and introduce Keptn, an open source project that addresses these issues, enhancing Kubernetes observability for smoother and more efficient deployments.

Understanding Kubernetes deployment challenges

Deploying software using Kubernetes is, on the surface, easy, but there is a lot more to ensure a healthy deployment. There are a lot of potential problems that can prevent the successful deployment of a Kubernetes application, such as:

Resource constraints

In Kubernetes, managing resources efficiently is crucial to prevent performance bottlenecks and application failures. Insufficient CPU and memory allocation to pods can lead to resource contention and stop Pods from being created.

External dependencies

Many applications rely on external services, such as databases, APIs, or third-party services. Ensuring seamless connectivity to these dependencies during deployment is essential for application stability. Consider a scenario where a web application depends on an external payment gateway. Any connectivity issues with the payment gateway during deployment could result in transaction failures and impact the application’s functionality.

Infrastructure health

The underlying infrastructure’s health directly impacts application availability and performance. Vulnerabilities or hardware failures can disrupt deployments and compromise application security. For instance, if a Kubernetes cluster experiences a hardware failure during deployment, it can lead to service disruptions and affect the user experience.

Monitoring inadequacies

Comprehensive monitoring is essential for detecting and resolving issues during deployment. Inadequate monitoring tools or configurations can result in operational blind spots, delaying issue detection and resolution.

Performance degradation

Deploying new versions of applications can sometimes lead to unexpected performance degradation. Changes in application code or configurations can impact performance metrics, affecting user experience and application functionality. For instance, deploying a new version of a web application that introduces inefficient database queries could lead to increased response times and decreased user satisfaction.

This is the problem domain on which Keptn can help Platform Engineers provide a solution and guard rails for teams to deploy software that works perfectly.

Addressing Kubernetes deployment challenges with Keptn

Using Keptn, combined with your standard deployment tooling or practices,

you can move from “I guess it’s okay” to “I know it’s okay”. Keptn allows you to wrap governance and automated checks around the deployment process to ensure that the end-to-end deployment process is healthy and that your application meets the SLOs you’ve defined. This is done by configuring Keptn to execute KeptnTasks and KeptnEvaluations before and after deploying a Kubernetes Workload.

With these, you can implement checks that ensure your infrastructure is in a healthy state before a new version of a deployment is rolled out. This way, you can avoid the problems mentioned above by:

• Verifying that your cluster has enough resources to run a workload.
• Checking the reachability of external services that your workloads might require.
• Ensuring that your monitoring solution monitors your cluster.
• Verifying that there are no open problems within your cluster.

After successfully deploying a workload, Keptn also provides the means for post-deployment checks. These can be crucial in ensuring that the performance of your newly deployed workload meets your expectations before promoting it to the next stage.

How to get started

Keptn can be installed through Helm with this simple set of commands:

helm repo add keptn https://charts.lifecycle.keptn.sh
helm repo update
helm upgrade --install keptn keptn/keptn Dynatrace® Software Intelligence Platform
   -n keptn-system --create-namespace –wait

For further information and configuration options, head to the Keptn installation documentation. Otherwise, if your application uses the recommended Kubernetes labels, you are ready to go. Keptn will detect your application and provide observability of your deployment out of the box.

Usually, Keptn does not act in isolation during a deployment. In the logical timeline of events, there will be tools acting before Keptn (such as GitOps tools like ArgoCD) and tools that act after Keptn (such as security scanning tools).

If the tools before Keptn begin generating OpenTelemetry data (for example, spans and traces), it would be beneficial to see Keptn’s portion of the work in the correct context as part of the same distributed trace. Similarly, anything that happens after Keptn but still in the same logical “deployment” operation should be included in the end-to-end trace view.

To achieve this, Keptn now accepts tools to pass W3C trace IDs into Keptn

and Keptn will pass such W3C trace IDs out of Keptn, creating true end-to-end visibility.

With this information, Keptn can track from “PR merged” all the way to “deployment running in production,” allowing DevOps to slice and dice observability data to understand how the application reached that state.

After installing Keptn, you can get started by going through the several guides listed below that will introduce you step by step to the features provided by Keptn.

• Integrate Keptn with your applications, which shows you how to configure your applications to be deployed with Keptn.
• OpenTelemetry observability, which shows how to configure Keptn to make use of its observability features, so you can have a holistic overview of your application deployments and any issues that arise during deployment.
• Multi-stage application delivery, which serves as an example of how you can integrate Keptn with ArgoCD and GitHub to take the previous concepts and apply them across multiple application environments, giving you full observability of your application deployment from development into production.

Conclusion

Keptn empowers DevOps teams to conquer the Kubernetes deployment challenge confidently, ensuring smoother and more efficient deployments. By addressing the complexities inherent in Kubernetes deployments and seamlessly integrating with existing tools, Keptn delivers unparalleled visibility and control. Start your journey with Keptn by downloading the first Release Candidate for v2 available now on GitHub.

The post Mastering Kubernetes deployments with Keptn: a comprehensive guide to enhanced visibility appeared first on Dynatrace news.