I think a lot of developers are quietly afraid right now. Not because AI is going to replace them any time soon. Most experienced developers don’t actually believe that.

The fear is more subtle than that. They’re afraid of getting left behind, learning the wrong tools or building the wrong way. Afraid that younger developers are adapting faster or that others understand all of this better.

I feel that pressure too.

I use Claude® Code CLI constantly. Every day. At this point I can’t imagine building software without it. I’m dramatically faster than I was a year ago, and the amount of experimentation I can do now is honestly kind of incredible. Yet when I open Reddit, LinkedIn, BlueSky, Twitter, YouTube, even TikTok, suddenly I’m hearing about:

• New coding agents
• Orchestration systems
• Autonomous workflows
• MCP setups
• Self-healing applications
• AI IDEs
• AI browsers
• AI terminals
• AI everything

And every one of them is apparently “the future.” How do you know what to ignore and what to adopt?

Look for people who are working in public and demonstrating real value

There’s a lot of confusion around productivity in AI conversations. People equate productivity with:

• More generated code
• Faster feature completion
• One-shot demos
• Or “look what I built in six minutes”

But none of that necessarily creates value. I can generate a giant pull request full of AI code this afternoon. That doesn’t mean it survives:

• Integration tests
• Security review
• Observability requirements
• Real users doing unpredictable human things

Real productivity is delivering value to users more quickly. AI helps with that, but developers waste enormous amounts of time chasing hype right now. Good marketing does not automatically equal good value. I’ve seen tools receive massive amounts of attention that, once I dug deeper, simply didn’t improve my workflow in any meaningful way.

The tools that matter are the ones that genuinely make you more productive while still allowing you to maintain understanding and control over what you’re building. That balance matters to me. I don’t want to become disconnected from the software itself.

Yes, developers should pay attention to what other people are doing. Part of being a software engineer has always been committing yourself to continuous learning. You should read Reddit. You should follow developers on social media. You should pay attention to emerging workflows and ideas.

But you also need to learn how to distinguish hype from value. Look for the people who are actually building things in public. Look for the people sharing process instead of certainty.

Ask yourself: “Was this content created to share knowledge, or to drive engagement?”

Those are very different things.

The people I trust most right now are usually the ones showing unfinished work, explaining tradeoffs, discussing failures, and sharing lessons learned from actual implementation. Not the people pretending they’ve solved software development permanently because they chained six agents together in a demo video.

That’s exactly how I ended up changing workflows myself. A friend of mine seemed to be moving leaps and bounds faster than I was. He had piles of documentation, a giant application, and everything looked polished and organized. So, I asked him to show me what he was using.

That was the first time I saw Claude Code CLI in action. Everything clicked. It had access to the filesystem. It could read the actual code I wanted modified. It could maintain context across the project. It could document what it was doing and why.

For the first time, AI coding stopped feeling like a clever autocomplete tool and started feeling like a genuine development partner. I instantly saw productivity, and it was real, not hype.

Keeping learning by doing

The developers who are adapting well right now are not the ones consuming the most AI content. They’re the ones building with AI consistently.

You need reps. The same way you learn almost anything else. You do not become a better golfer by watching YouTube videos about golf swings. At some point you need to stand over the ball and embarrass yourself for a while.

AI coding is the same thing. You need to build things. Not startup ideas. Not the next billion-dollar SaaS. Not some massive architecture astronaut project. Solve a problem in your own house. Maybe your family needs a better way to plan meals. Maybe you want to track something like the number of times you turn off light switches. Maybe you want a better view into your finances.

Those are the best projects right now because you already understand what success looks like. You can judge whether a tool helped you succeed. And you develop real skill that will transfer to whatever the next big thing is.

The post Quit trying to keep up with every new AI tool and keep building appeared first on Dynatrace news.

At Dynatrace, we believe the future of observability and cloud-native operations is open. Not “open” as a slide-deck buzzword, but open as in showing up every day to write code, review PRs, chair working groups, and build tools the community can use, extend, and make their own.

We’re proud to be an active contributor to the cloud-native ecosystem. We build in the open because we’ve seen firsthand that open collaboration produces better software for our customers, the community, and the industry.

This post looks at some of our most significant open source contributions — why we built them, why we open sourced them, and how they’ve grown into thriving community projects. It’s not exhaustive; for the full set, explore our projects on GitHub.

The OpenTelemetry community, setting the standard for observability

What is the OpenTelemetry ecosystem?

The OpenTelemetry® (OTel) ecosystem provides an open source, vendor-neutral way to generate, collect, process, and export telemetry data, specifically traces, metrics, and logs. Born from the merger of the OpenTracing and OpenCensus projects in 2019, the OTel community is now the second most active Cloud Native Computing Foundation® (CNCF) community after Kubernetes and the de facto standard for instrumenting cloud-native applications.

Before OpenTelemetry standards, every observability vendor had its own proprietary agent, data format, and instrumentation libraries. Switching vendors meant ripping out instrumentation and starting over. The standards change that by providing a single set of APIs, SDKs, and a Collector that work with any backend. You instrument once, and you can send your telemetry data wherever you need it.

How Dynatrace contributes to the OpenTelemetry ecosystem

Dynatrace has been involved in the OpenTelemetry ecosystem since the project’s earliest days, and our engagement goes well beyond code commits. Our engineers hold leadership positions across the project:

• Governance Committee: Daniel Dyla, a Senior Open Source Architect at Dynatrace, serves on the OpenTelemetry Governance Committee, helping shape the project’s strategic direction.
• Technical Committee: Armin Ruech, a Team Lead and Product Owner at Dynatrace, sits on the Technical Committee, guiding the cross-language specification that ensures consistency across all OTel implementations.
• SIG Maintainers and Approvers: Dynatrace engineers serve as maintainers or approvers across multiple Special Interest Groups. Contributors like Mario Jonke, Marc Pichler, Evan Bradley, Giovanni Liva, Joao Grassi, and many more are active across these SIGs.
• Community Management: Adriana Villela, a Principal Developer Advocate at Dynatrace, recently took on the role of OpenTelemetry Community Manager, working to grow the contributor and end-user community and raise the OTel community’s profile within the CNCF and the broader open source world.

Dynatrace also ships its own distribution of the OpenTelemetry Collector, with enterprise-grade support and curated components so teams can confidently run OTel in production. Our acquisition of Bindplane, a telemetry pipeline built on OpenTelemetry standards, extends that commitment.

How the community benefits

The OpenTelemetry community has fundamentally changed how the industry approaches observability. Developers no longer commit to a single vendor’s instrumentation at the code level, SREs can standardize on one set of libraries across polyglot environments. Organizations can evolve their observability strategy, switching or combining backends without re-instrumenting their applications.

Get involved

Check out OpenTelemetry.io and find an interest group that matches your interests. Also check out the first episode of the Observation Deck to learn more about the community and how to get involved.

W3C® Trace Context: Making distributed tracing actually work

What is W3C Trace Context?

W3C Trace Context is a specification that defines a standardized set of HTTP headers for propagating distributed tracing context between services. Before it existed, every tracing tool—both commercial and open source—used its own proprietary headers, which resulted in a high volume of broken traces. We saw the problem firsthand every day across thousands of customer environments: Traces would vanish whenever a request crossed a boundary between two monitoring tools or passed through a cloud provider’s managed service. The root cause was always the same: no agreed-upon header format.

Trace Context solves this by defining a universal traceparent header that all compliant tools and middleware recognize and forward. It’s a deceptively simple idea with a massive practical impact on end-to-end tracing in production.

How Dynatrace contributes

Dynatrace helped lead W3C Trace Context. Alois Reitbauer, now Dynatrace’s Chief Technology Strategist, chaired the W3C Distributed Tracing Working Group; colleagues including Christoph Neumüller and Daniel Khan worked alongside engineers from Google, Microsoft, and New Relic to iterate on the standard, and Daniel Dyla contributed as a co-author alongside his OpenTelemetry work. Dynatrace was a founding sponsor of the working group when it moved into the W3C in 2018, and the first vendor to ship production support for the standard.

How the community benefits

W3C Trace Context has been adopted by the OpenTelemetry project (which uses it as its default propagation format), Microsoft Azure services, Google Cloud Platform™ services, Elastic® services, and many others. Middleware, service meshes, and cloud-managed services now forward traceparent headers automatically, making end-to-end visibility achievable in environments where it was previously impossible. It’s one of those standards that, once adopted, makes you wonder how anything worked without it.

OpenFeature: An open standard for feature flags

What is the OpenFeature standard?

The OpenFeature project, a CNCF Incubating project, defines a vendor-neutral open standard for feature flag management. It provides a unified API and SDK developers can code against regardless of the backend — an in-house solution, a commercial platform, or an open source tool.

Feature flags are a core practice in modern software delivery: They let teams decouple deployments from releases, roll out features to targeted user groups, run A/B experiments, and instantly kill-switch problematic features — all without redeploying code. But the ecosystem has historically been fragmented: Every vendor and homegrown solution has its own API, so migrating between solutions requires rewriting application code.

The OpenFeature project remedies this with a standardized abstraction layer. You write your evaluations once against the OpenFeature API; to switch backends — say, from an in-house solution to a commercial vendor — you swap out the “provider” (a thin adapter), and your application code doesn’t change.

How Dynatrace contributes

Dynatrace initiated and led the creation of the OpenFeature project. In 2022, we assembled an industry consortium of top feature flag management solutions and submitted the standard to the CNCF as a sandbox project. We remain one of the project’s key drivers, contributing to the specification, SDKs, and provider ecosystem.

Dynatrace engineers play central roles in the project’s governance and day-to-day development:

Governance Committee: Michael Beemer, a Product Manager at Dynatrace, serves on the OpenFeature Governance Committee and has been instrumental in driving the project from its earliest days. Alois Reitbauer, Dynatrace’s Chief Technology Strategist and a driving force behind many of our open source initiatives, has recently passed leadership to Jonathan Norris following our acquisition of DevCycle.

Project Maintainer: Todd Baert, a Software Engineer at Dynatrace, works almost entirely as an OpenFeature project maintainer, focusing on SDK development, integration points, extensibility, and the OpenTelemetry hook that bridges feature flags with observability data.

Observability is built in by design: The OpenTelemetry API supports OpenFeature flags, so feature flag evaluations are automatically captured as part of distributed traces. Observability platforms like Dynatrace can show you not just what happened in a request, but which flags were evaluated, what values were returned, and how those flags affected performance and user experience.

In early 2026, Dynatrace acquired the DevCycle® platform, a feature management solution built natively on the OpenFeature standard, deepening our investment in open, standards-based progressive delivery.

How the community benefits

The OpenFeature standard lets developers adopt feature flags without vendor lock-in. Outgrow an in-house solution? Move to a commercial provider without rewriting code. Vendor sunsets their product? Your application code is unaffected; just swap providers. And because feature flag evaluations are captured as part of distributed traces, teams can correlate flag states with performance data, error rates, and user experience metrics — making progressive delivery measurably safer.

Get involved

Visit openfeature.dev to learn about the standard, try a provider, or contribute to an SDK. The community is active on the CNCF Slack.

Keptn toolkit: Cloud-native application lifecycle orchestration

What is Keptn toolkit?

Keptn toolkit is a CNCF Incubating project that provides event-driven orchestration for cloud-native application delivery and operations. It connects observability to operations through a declarative approach to automation for deployment pipelines, quality gates, and auto-remediation workflows.

In practical terms, Keptn toolkit lets you define Service Level Objectives (SLOs) and automatically evaluate them at every stage of your delivery pipeline. Did that new deployment meet its performance targets? Keptn toolkit checks your SLIs (Service Level Indicators) against your SLOs and decides automatically whether to promote the release or roll it back. It’s often described as “SRE in a Box.”

Field teams at Dynatrace kept seeing the same pattern across customer engagements: every organization was writing the same Jenkins scripts, the same ServiceNow® integrations, the same dashboard-checking routines, just with slight variations.

Keptn toolkit is tool-agnostic by design: it integrates with whatever CI/CD, testing, monitoring, and notification tools you already use. You define the “what” — your delivery and operations strategy — and Keptn toolkit orchestrates the “how” using your existing toolchain.

Keptn toolkit’s unique value in the CNCF landscape is its focus on observability-driven operations. SLOs drive its orchestration decisions, bridging the gap between “we deployed it” and “it’s actually working well for users.” For SRE and platform engineering teams, it’s a structured, declarative way to codify operational best practices without being tied to any specific tool.

How Dynatrace contributes

Dynatrace created Keptn toolkit internally in 2019 and donated it to the CNCF as a sandbox project in 2020. It was promoted to CNCF Incubating status in 2022 after significant community growth.

Key Dynatrace contributors include Alois Reitbauer (Keptn toolkit creator and Dynatrace CTS), Andreas Grabner (co-founder and DevOps Activist at Dynatrace), and Johannes Bräuer (co-founder). The project was born directly out of our work helping customers implement autonomous cloud operations.

Get involved

Head to keptn.sh to learn about the project, try the quickstart, or build an integration for your favorite tool.

How the community benefits

Since joining the CNCF, Keptn has grown tenfold in adoption, with more than 100 production instances and more than 40 companies using it in production including Citrix, T-Systems, and others. The project has attracted dozens of community-built integrations and inspired the CDEvents standard in the Continuous Delivery Foundation.

OffOn.dev: Building the Open Source Community of tomorrow

Every project in this post depends on something that doesn’t show up in a GitHub® commit graph: the people who sustain them — maintainers, contributors, mentors, and the next generation of developers who haven’t written their first PR yet. They’re often overlooked. Most platforms, foundations, and content formats are built with enterprises, legal teams, or marketing goals in mind, not for individual maintainers or attracting new contributors. Yet these are the people who keep open source alive.

OffOn.dev was created to address that gap. Too many community spaces are built to react to problems — they grow, but stay focused on troubleshooting rather than adoption, innovation, and exploration. The Open Ecosystem takes a different approach: a practical, vendor-agnostic space for builders working with open standards and cloud-native tools, focused on reproducible, hands-on knowledge — tutorials with real code and configs, Q&A with accepted solutions, technical challenges, and a Community Voices space for members’ projects and demos.

This is not a sales channel. Companies like Dynatrace may sponsor with resources or funding, but sponsors don’t influence the content or the mission. The purpose is to sustain open source momentum and help create the maintainers of tomorrow’s digital landscape — a need made more urgent by digital sovereignty and emerging regulations like the CRA and EU AI Acts.

Whether you’re an SRE wiring up an OpenTelemetry pipeline, a developer experimenting with OpenFeature flags, a student writing your first contribution, or a maintainer mentoring the next generation — the Open Ecosystem is built for you. Introduce yourself, jump into a challenge, share what you know. Head to OffOn.dev and come build with us.

The post Building in the open: How Dynatrace invests in open source to move the industry forward appeared first on Dynatrace news.

You deploy a small change to a Node.js service. All tests pass. You top off your coffee. Fifteen minutes later, alerts start firing.

Your once-snappy API endpoint is crawling. Dashboards light up. Slack fills with “Anyone seeing latency?” messages. You open the logs and start the familiar dance: grep, trace, redeploy, repeat.

We’ve all been there. The hardest part isn’t fixing the bug — it’s finding it.

Why we lose hours chasing logs and people

As developers, we have telemetry overload — yet still lack the one piece of context we need: What line of code introduced the regression?

Modern cloud-native systems aren’t just applications anymore, they’re distributed systems. When something has already happened, the first question isn’t what happened, it’s where?

And in distributed systems, “where” can mean:

• Any container replica
• Any downstream API call
• Any async job or queue consumer
• Any recent deployment or configuration change

Each service has its own logs, metrics, and traces — often split across different tools and dashboards. Context lives in Slack threads. Deployment history lives somewhere else. Institutional knowledge lives in someone’s head.

So, you correlate timestamps manually. You pivot across dashboards. You ask in Slack.

This isn’t debugging — it’s archaeology.

Finding the source means pulling in Dev, Ops, SRE, and application owners — trying to piece together the context of both code and infrastructure.

In other words, is it the code — or is it the node?

When you need code-level insight

Now imagine a different outcome. You immediately see which function in your code triggered the latency spike — without redeploying, adding debug logs, or trying to reproduce the issue locally.

That’s the promise of code-level observability.

Instead of stitching together logs, metrics, and traces across multiple tools, runtime instrumentation automatically captures what executed, where time was spent, and how requests flowed across services. You move from guessing to knowing.

Manual instrumentation is brittle. It adds overhead, introduces blind spots, and slows down delivery. As builders, you want to focus on the business logic and functionality, not maintaining observability integration.

That’s why platforms like Dynatrace automatically instrument the runtime and correlate traces, logs, and method-level execution into a unified view. With OneAgent, OpenTelemetry support, and open APIs, teams get deep visibility without manual instrumentation or lock-in.

In the Distributed Tracing view, logs, traces, and code-level analysis are correlated into a single problem context. Developers can see what failed, where latency was introduced, and which code path was responsible — without losing focus or switching tools.

Real-world example: Tracing a bad commit in a Node.js microservice

You’ve got a simple Node.js microservice that fetches orders from multiple downstream APIs and returns them to checkout.

// routes/server.js
router.get('/api/orders', async(req, res) = >{
  const start = performance.now(); // better precision than Date.now()
  try {
    const orders = await fetchOrders();
    const durationMs = performance.now() - start;​ // ← capture request duration for monitoring​

    // You would normally send this to your metrics system (Prometheus, StatsD, OpenTelemetry...)
    console.log({
      endpoint: '/api/orders',
      orderCount: orders.length,
      durationMs: Math.round(durationMs),
      durationHuman: `$ {
        durationMs.toFixed(1)
      }
      ms`
    });
    res.json(orders);
  } catch(err) {
    // duration even on error is useful for observability
    const durationMs = performance.now() - start;
    console.error({
      endpoint: '/api/orders',
      error: err.message,
      durationMs: Math.round(durationMs)
    });
    res.status(500).json({
      error: 'Failed to fetch orders'
    });
  }
});

After a recent commit, latency climbs to 600ms and error rates spike. Logs show scattered warnings. Locally, everything looks fine. Under light load, tests still pass.

This is the kind of regression that eats up entire afternoons.

The data you need is split across:

• Application logs
• Distributed traces
• Kubernetes events
• Deployment history

What the trace reveals

Opening the distributed trace view in Dynatrace (PurePath®) you can inspect the full execution path of a single request — across services, methods, and downstream dependencies.

You immediately see:

• Failed /api/checkout requests
• Elevated response times
• A downstream gRPC calls consuming the majority of request time

From logs alone, you only see where errors surfaced:

callErrorFromStatus (/app/node_modules/@grpc/grpc-js/build/src/call.js:32)
Object.onReceiveStatus (/app/node_modules/@grpc/grpc-js/build/src/client.js:193)
Object.onReceiveStatus (/app/node_modules/@grpc/grpc-js/build/src/client-interceptors.js:361)
Object.onReceiveStatus (/app/node_modules/@grpc/grpc-js/build/src/client-interceptors.js:324)
<anonymous> (/app/node_modules/@grpc/grpc-js/build/src/resolving-call.js:129)
AsyncLocalStorage.run (node:internal/async_local_storage/async_hooks:91)
process.processTicksAndRejections (node:internal/process/task_queues:85)
ServiceClientImpl.makeUnaryRequest (/app/node_modules/@grpc/grpc-js/build/src/client.js:161)
ServiceClientImpl.<anonymous> (/app/node_modules/@grpc/grpc-js/build/src/make-client.js:105)
AsyncLocalStorage.run (node:internal/async_local_storage/async_hooks:91)
<anonymous> (/app/node_modules/@opentelemetry/instrumentation-grpc/build/src/clientUtils.js:130)
<anonymous> (/app/node_modules/@opentelemetry/instrumentation-grpc/build/src/instrumentation.js:215)
AsyncLocalStorage.run (node:internal/async_local_storage/async_hooks:91)
AsyncLocalStorageContextManager.with (/app/node_modules/@opentelemetry/context-async-hooks/build/src/AsyncLocalStorageContextManager.js:33) 

The logs tell you where the exception bubbled up. It does not tell you where the regression started. The trace timeline adds the additional context.

The root cause

Method-level timing shows that fetchOrders() is now executing downstream lookups sequentially instead of in parallel.

// routes/server.js
router.get('/api/orders', async(req, res) = >{
  const start = Date.now();
  const orders = await fetchOrders();
  const duration = Date.now() - start;
  console.log(`Request completed in $ {
    duration
  }
  ms`);
  res.json(orders);
});

Under low traffic, this isn’t obvious.
Under load, latency compounds.

Now our dev team can update the code to fix the issue:

// fixed version of fetchOrders
async 
function fetchOrders()  {
  // run order detail lookups in parallel
  const results  =  await Promise.all(orderIds.map(getOrderDetail));
  return results;
}

The regression only surfaced once concurrency increased— something unit testing didn’t expose.

By correlating runtime traces with deployment metadata, you can see exactly when the behavior changed and which commit introduced it.

How you can cut MTTR from hours to minutes

Depending upon the scenario, we often get judged not by how fast we ship — but by how fast we recover. Mean time to repair (MTTR) is what builds (or breaks) trust between Developers and SREs.

That’s why instrumentation and observability need to be placed before code reaches production — not added after something breaks.

Here’s what happens when you move from manual debugging to connected code-level insight:

With distributed tracing in Dynatrace, every transaction is captured end-to-end, from your Node.js route to downstream APIs and databases, all correlated with the build and deployment that introduced it.

Instead of debating whether it’s the code or the node, both developers and SREs see the same execution path, the same timeline, and the same root cause.

Enabling code-level analysis in your stack

You don’t need to refactor your application or add manual instrumentation to anything. Here’s how most teams get started:

1. Deploy Dynatrace OneAgent on your service host or Kubernetes cluster.
2. Enable Node.js auto-instrumentation in enabled (no code changes required.
3. Integrate CI/CD metadata so commits, build IDs, and deployment versions appear alongside traces.
4. Inspect live traces directly in your IDE (VS Code or IntelliJ) using the Dynatrace plugin — jump from failing span to the exact method instantly.

Within minutes, your next deployment is automatically traced end-to-end — from the first line of code to the live transaction in development through testing and into production.

Less time in tools. More time in flow.

Every debugging session risks pulling you out of flow.

Code-level observability shortens incident response, reduces cognitive load, and replaces guesswork with execution context. Developers gain confidence in what they ship. SREs see fewer escalations and cleaner hand-offs because the root cause is already visible.

Less troubleshooting. More building. That’s the real win.

Explore how Dynatrace connects commits, traces, and runtime behavior — so you can move from incident to resolution without leaving your workflow.

code. observe. deliver.

The post Use code-level analysis to cut MTTR before you push to production appeared first on Dynatrace news.

Organizations are racing to integrate AI agents into developer and operations workflows. Developers are using coding agents to help build new features and even entire applications, while simultaneously building agents to automate business processes, or even orchestrate multi-agent workflows. Companies are discovering what works, what breaks, and what moves the needle for developers in the agentic era. Across industries—from telecom to aerospace to finance—a few patterns are emerging.

Based on presentations from customers at Perform 2026, here are five real-world lessons for operationalizing agentic AI in developer workflows.

1. Give agents real-time access to telemetry data

Teams need real‑time, deterministic signals to govern autonomous agents safely. This message came through clearly at Perform.

At TELUS, engineers were doing what most teams do early in their AI journey: copying logs, pasting traces, and moving between dashboards and chat tools. The models could reason, summarize, and even suggest fixes – but they had no direct pathway to telemetry data. Without structured access to Dynatrace Intelligence, GKE, and change events, the agents lacked runtime awareness.

The turning point came when TELUS stopped stitching together ad-hoc data pulls and instead enabled agents to access telemetry through MCP. Instead of manually stitching context together, agents could retrieve live data including traces, logs, and dependency data directly through shared access patterns.

The result: AI grounded in the same real time observability data engineers use to investigate end-to-end.

That’s why MCP was pivotal. As TELUS described it, MCP replaced ad-hoc fetches with a consistent model for safely accessing structured infrastructure and application context. AI agents no longer relied on static or point in time snapshots; they operated against live state and followed shared rules of engagement.

Lockheed Martin faced a similar challenge. Their teams were navigating multiple tools, each with its own interface and data models. AI could help, but it needed real time, unified access across Dynatrace, ServiceNow, and other tools. As Lockheed Martin Chief Observability Engineer David Walker described it, MCP became “the universal translator” that provided a “universal language” for agents to access all of them – transforming siloed tools into a single context layer.

2. Meet developers where they are

The organizations moving fastest in agentic AI are treating developer experience as a first-class concern. The pattern is simple: bring AI and telemetry into the tools where developers already spend their time.

At TELUS, observability isn’t something engineers leave their IDE to access. Using local MCP servers in VS Code, agents can retrieve Dynatrace metrics, logs, and problem details directly within the editor.

They extended this further with n8n to automate workflows and embedded AI into Slack through IRIS, their conversational incident assistant. Engineers ask natural language questions — “What’s the status of service X?” — and IRIS routes the request to the appropriate n8n workflow and MCP endpoint.

At Autodesk, more than 80% of developers already use AI‑assisted IDEs. Many were independently wiring MCP servers into tools like Cursor to access telemetry while coding. Autodesk responded by formalizing this approach with a hosted, governed MCP platform integrated directly into those assistants.

Similarly, Lockheed Martin built MCP servers tailored for agentic assistants in VS Code, enabling developers to retrieve metrics, logs, and problem details without leaving their editor.

3. Standardize telemetry and enrich it with domain context

API access is only the starting point. AI is only as effective as the structure and context behind the data it can access.

Lockheed Martin customized MCP servers with internal knowledge, such as which systems were mission‑critical, how their baselines typically behaved, or which team owned specific services. They called these “Lockheed‑Martin’ized MCPs.”

In one comparison, the generic configuration produced about a 60% success rate. The contextualized version increased that to 95%. As Chief Observability Officer David Walker put it, the added domain knowledge was the difference between “noise and signal.”

Autodesk provided one of the clearest examples. After years of acquisitions and organic growth, they found themselves with 20+ observability tools and seven different tracing systems – a patchwork that made incidents slow and painful to unravel. Standardization was the solution explained Alex Bicalho, Autodesk Senior Director of Engineering, Developer Platform Services during his presentation. They adopted OpenTelemetry as a universal instrumentation layer and consolidated metrics and traces in Dynatrace.

United Wholesale Mortgage extended this concept further by promoting business events—structured signals extracted from logs via OpenPipeline. This created a telemetry layer that mapped technical anomalies directly to customer-facing processes and business impact.

Instead of asking only, “What broke?” the team could ask, “What business process is impacted, and how do we prevent it?”

4. Observe and govern the AI stack itself

As agents become part of developer workflows, they must be treated with the same security and operational standards as existing systems.

Macquarie Group recently launched a customer-facing agent called Q for its Australian retail banking customers. “We needed total visibility, so we built a Dynatrace dashboard that has usage, effectiveness, cost, and downstream dependency health,” says Phillip Grasso-Nguyen, head of reliability for Macquarie’s Banking and Financial Services division. “That gave us the confidence to release.”

At TELUS, their automation backbone, powered by n8n and MCP servers, had become mission‑critical. To ensure reliability, they instrumented n8n itself with OpenTelemetry, routed metrics into Dynatrace, and correlated that data with Kubernetes and log analytics.

In other words, they treated their AI automation stack like any other production service: observable, measured, and governed.

5. Close the loop from insight to action

When teams put the right structure, data, and guardrails in place, operational feedback loops shrink from hours or days to minutes.

Agents don’t misbehave out of malice. They often misbehave because they try too hard. Autodesk provided a vivid example: As developers began experimenting with MCP servers from across the internet— integrating them into Cursor, Copilot Cloud, and other AI‑assisted IDEs—agents began issuing extremely broad observability queries, hammering GitHub, CI systems, and telemetry backends.

As Alex Bicalho, Autodesk Senior Director of Engineering, Developer Platform Services, described it, the agents were “trying to find an atom in the solar system.” They were doing exactly what they were asked, just without guardrails.

The solution was governance. Autodesk created a hosted, governed MCP platform, where each tool and workflow had defined scope, limits, and predictable behavior. Macquarie Group has an SRE agent that pulls real-time data from the Dynatrace API to help act on issues before they become incidents.

TELUS demonstrated this clearly with IRIS, their Slack‑based incident assistant. IRIS blends telemetry, logs, change history, and conversation transcripts into real‑time summaries during active incidents.

While engineers troubleshoot on an incident management call, IRIS ingests Dynatrace data and generates a rolling update every 15 minutes: what happened, who did what, what changed, actions taken, open questions, and the most likely root cause.

The impact is practical. Executives don’t interrupt status updates. Engineers don’t repeat themselves across Slack threads. This is closed-loop automation in practice. Everyone operates from the same continuously-updated view.

Other companies are leaning into this vision as well. Macquarie has an SRE agent that pulls data from the Dynatrace API to help act on issues before they become incidents.

United Wholesale Mortgage uses Business Flow visualizations that connect performance degradation directly to customer-facing processes. Remediation becomes faster and more aligned with business impact.

What’s next?

Agentic AI is already reshaping how developers build, observe, and deliver software. The organizations moving faster aren’t just experimenting with models – they’re integrating AI into their telemetry, workflows, and systems, from development through testing and into production.

The organizations succeeding with agentic AI are rebuilding their developer workflows with observability as the real-time control plane that gives agents context, guardrails, and the ability to act safely and autonomously.

The post Five real-world lessons for building developer workflows in the agentic era appeared first on Dynatrace news.

In January 2026, I ran an experiment: I published one blog post every single day for 31 days about building production software with AI. Not toy demos. Not “hello world” chatbots. Real, shipped, supported product. The whole series was built around one project: collectyourcards.com, a sports card collection app I built entirely with Claude Code over three months of nights and weekends. 1,000,000+ cards, an achievement system, universal sub-200ms search, Excel exports. All of it.

I called it 31 Days of Vibe Coding. “Vibe coding” is the increasingly common practice of describing features to an AI assistant and iterating on generated code instead of writing every line manually.

I documented my journey on a website and newsletter that covered my learnings in bite sized chunks. Check out the full series. If any of these lessons resonated, the detailed posts have the code, the prompts, and all the messy parts I couldn’t fit here. I also appeared on the PurePerformance podcast to discuss my learnings. Writing about and discussing my work helped me better understand what I learned. Here are a few important insights I gleaned from my work.

1. You’re the architect. AI is the junior developer.

This is the framing that makes everything else work. You decide what to build, how it should be structured, and what trade-offs are acceptable. AI helps you build it faster. When you flip that relationship and start expecting AI to make design decisions for you, things go sideways fast.

I learned this the hard way when I described a notification system to Claude and asked it to “figure out the best approach.” It picked polling every 30 seconds. That works fine for 10 users. At 10,000 users, that’s 333 requests per second hitting your server for no reason. When I instead described my proposed approach and asked Claude to poke holes in it, it identified five real problems I hadn’t considered, including the scaling issue. Same tool, completely different outcome, because I stayed in the architect role.

AI doesn’t replace your judgment. It accelerates your execution.

2. Write specs, not prompts.

Early on, I was typing things like “build me a card search feature” into Claude and getting back something that technically worked but was missing pagination, fuzzy matching, error handling, and observability. The output was exactly as vague as my input.

The fix was treating every feature like a spec. I started writing GitHub Issues as full feature specifications before ever opening a conversation with AI. Context, intent, constraints, examples, and how to verify it works. When I built the achievement system for collectyourcards.com (1,200+ achievements across 14 categories), the entire thing was driven by a single well-written GitHub Issue. AI even helped me write the spec before a single line of code existed, and then created follow-up issues during implementation for database indexes, notification hooks, and edge cases I’d missed.

Vague input gets vague output. Specific input gets production-ready output. Every time.

3. Break every feature into phases.

Never ask AI to build a complex feature in one shot. I tried this exactly once with the achievement system. Forty-five minutes of generated code spread across dozens of files, and none of it worked because everything was interdependent and untestable. I couldn’t even figure out where to start debugging.

I threw it all away and started over with phases.

• Phase 1: core achievement engine with 150 basic achievements. That shipped in one session and worked immediately.
• Phase 2 added categories.
• Phase 3 added the notification system. Each phase produced working, deployable, independently verifiable software. The total time was less than my failed single-shot attempt.

This applies to everything. My universal search feature went from basic text matching to fuzzy search to multi-entity results to filters to autocomplete, each phase shipping on its own. If Phase 1 alone isn’t useful, your phases are too small. If Phase 1 takes more than one session, your phases are too big.

4. Commit before every AI operation.

Git is your undo button. This sounds obvious until you skip it once and lose an hour of your life.

I asked Claude to change a five-word error message in a validation function. Simple, right? When I looked at the diff afterward, it had touched 12 files. It renamed the function from `validateUser` to `checkUserStatus`, refactored the validation logic, and updated three other files that referenced the original function name. The app crashed. Without a prior commit, I spent 50 minutes manually figuring out what had changed and reversing the damage.

Now I commit before every significant AI operation. `WIP: before achievement refactor`. `WIP: before search update`. It takes five seconds. When AI changes something you didn’t ask for (and it will, inevitably), you run `git diff`, see exactly what happened, and revert cleanly. Think of it like saving before a boss fight in a video game.

5. Configure your AI once, not every conversation.

AI has no memory between conversations. Every new session starts from zero. For weeks, I was repeating the same instructions: “Use TypeScript, use Prisma, use the service layer pattern, add structured logging, don’t use console.log.” Every. Single. Time.

The fix was a CLAUDE.md file in my project root that defines my tech stack, coding patterns, and explicit “Always” and “Never” lists. I added annotated pattern files that show, not describe, how services should be structured. I added a common mistakes file documenting errors AI kept making so it would stop making them.

Before configuration, asking Claude to “create an endpoint to update user email” produced JavaScript with raw SQL and console.log. After configuration, the exact same prompt produced TypeScript with strict types, Prisma, a proper service layer, and structured telemetry logging. Same AI, same prompt, dramatically different output, because the context was already there.

6. AI builds for the happy path. You have to demand the rest.

AI-generated code is optimistic. Really optimistic. It assumes your database is always up, your network is always fast, and your users always send valid JSON. It writes code that works perfectly when everything goes right and fails silently when anything goes wrong.

I built a card-fetch endpoint that looked clean and correct. Eight lines of straightforward code. When I ran a security audit (by asking Claude to switch into adversarial “penetration tester” mode), it found four vulnerabilities: no ownership check (any user could fetch any other user’s cards), sensitive data exposure (returning all owner fields including email), no rate limiting, and no access logging. The fix was about 15 lines, but it never would have written them unless I explicitly asked.

Security, operability, edge cases, and test coverage don’t happen unless you ask for them separately. I started using what I call the “3am test” for every feature: if this broke at 3am, would I know it happened? Would I know why? Would I know how to fix it? If the answer to any of those is no, the feature isn’t done.

7. Observability replaces manual code review.

When you’re shipping AI-generated code, you’re not reading every line. You can’t. The volume is too high and the iteration speed is too fast. So how do you know it works? You watch it run.

I add structured logging, metrics, and tracing to every new feature on Day one. When a user gets locked out of their account on collectyourcards.com, I can diagnose why in 30 seconds by looking at the authentication telemetry: user ID, IP, user agent, error message, all structured and searchable. Before I had this, the same diagnosis took hours of guessing.

This isn’t optional when you’re building with AI. It’s the substitute for the line-by-line code review you’re no longer doing. OpenTelemetry with traces, metrics, and logs became the foundation of every feature I built. If I couldn’t observe it in production, I didn’t ship it.

8. Use AI to review AI.

One of the most useful patterns I found was using AI to check AI’s own work. But there’s a trick: run multiple focused review passes, not one general review.

A single “review this code” pass might catch three or four issues. Four separate focused passes (security, performance, edge cases, maintainability) routinely caught 12 or more. I’d ask Claude to review a user registration endpoint once for security vulnerabilities, once for performance problems, once for missing edge cases, and once from the perspective of someone maintaining this code at 3am. Each pass found things the others missed.

I also used AI to write tests for AI-generated code, to refactor AI-generated code, and to find edge cases I’d never think of. A `formatUserName()` function seems simple until AI points out: What about right-to-left text? Emoji in names? HTML injection? A user who entered no name at all (producing “undefined undefined” on the profile page, which actually happened)?

9. Measure whether it’s actually helping.

Here’s the honest part. I spent 31 days writing about how AI makes you faster and more productive. And when I actually measured my output, my features-shipped-per-week, bugs-in-production, and time-from-issue-to-deploy were… about the same as before.

I felt faster. The moment-to-moment experience of coding with AI feels incredible. Code appears instantly. Features take shape in minutes instead of hours. But the total cycle time, including prompt crafting, output review, fixing hallucinations, and debugging unexpected changes, often washed out the speed gains.

Where AI genuinely helped: boilerplate generation, code review, exploring unfamiliar APIs, enumerating edge cases, and writing documentation. Where it consistently hurt: novel problems with no clear pattern, subtle bugs that required deep context, and any situation where it over-engineered a simple solution. If you’re not tracking which category your work falls into, you’re flying blind.

10. Document what you learn, because AI won’t remember (yet).

AI’s context degrades within a single session and vanishes completely between sessions. Around message 30 or 40 in a long conversation, I’d start seeing Claude reference models that didn’t exist, import from paths that were never created, and contradict decisions it made 20 messages earlier.

The fix is aggressive documentation. Progress docs that summarize what was built, what decisions were made, and what’s next. A mistakes file that records patterns AI keeps getting wrong (with “wrong” and “right” examples) so you can reference it in future sessions. Proactive compaction at natural breakpoints, not after quality has already collapsed.

Your configuration files, your mistakes file, and your progress docs are the substitute for the institutional knowledge a human teammate would accumulate over months. AI doesn’t learn from working with you–at least not yet. But your documentation can simulate that learning for every future session.

How I changed over 31 days

After 31 days and nearly 49,000 words, the biggest shift was in how I think about what I’m building. I plan more carefully because the cost of planning is low and the cost of a bad AI-generated implementation is high. I commit more often. I monitor everything. I write better specs than I ever did when I was the one writing every line.

AI didn’t make me a faster coder. It made me a better architect.

The post 10 things I learned writing 49,000 words about vibe coding appeared first on Dynatrace news.

An exception does not always mean that something in your systems failed, but they can indicate current performance problems or issues that could cause failures in the future. For developers, investigating exceptions has traditionally been slow and tedious, requiring you to juggle different tools to assess the impact of an exception.

The new Exception Analysis in the Dynatrace Distributed Tracing app is designed to make this part of your job easier. It offers a new way to spot, group, and understand exceptions across the full trace, with readable stack traces, aggregated insights, and visual markers to highlight problematic spans. In minutes, it can help take you from “something looks odd,” to “this is actually important; it happens 1,000 times an hour; and here is the root cause.”

In this article, we’ll dive into a demo of exception analysis and explore how to investigate and analyze the exceptions over time.

But first, let’s take a closer look at why we care about exceptions in the first place.

Why investigate exceptions?

Exceptions are often the real reason a trace fails or slows down. When you scroll through spans trying to spot the problem, you may find a slow call—but the real issue is an exception somewhere else.

If you do find an exception, you still must figure out:

• Which span threw it?
• Is it happening all the time or just once?
• Is it the same error repeating?
• Which service is triggering it?

This is why Exception Analysis comes in handy. Having an aggregated view of all exceptions over a specific time frame helps you to see and investigate them clearly. It allows you to quickly answer questions like: What broke or slowed down? Where? How often? What is the impact?

Even if an exception hasn’t broken anything yet, issues like unsupported versions of dependencies, deprecated functions, etc. could cause headaches further down the line. An aggregated view helps you see clearly over time which exceptions caused specific failures, and by investigating exceptions that are “only” slowing the system down, you can proactively prevent major incidents in the future and spot slowdowns that would otherwise go undetected.

An example of exception analysis investigation

Let’s take a look at the new Exception Analysis perspective in the Distributed Tracing app. It offers a streamlined way to analyze exceptions over time and understand if they are directly related to failed requests of your services. This also allows users to understand technical exceptions and errors early before they lead to failures or outages later.

We’ll start at the time window of the last 24 hours to get an overview of what is happening in the environment lately. A PHP exception catches our eye. It looks a little bit awkward, and we see it happens quite often, but it’s not really leading to failing errors.

The interesting information here is that it seems like there is a deprecated function used within the application. In the future, this could lead to breaks and real failures when this function is removed or cannot be used in a way as it is used right now.

For developers, Dynatrace provides immediate access to related stack traces with all frames, making it easy to identify where and why an exception occurs. You can also view relevant logs and requests in context at the same location.

Back to our investigations, we also see that this exception is obviously happening on a specific PHP service on the endpoint /like. From there, we can also jump to specific instances of this exception by clicking on View Trace.

We’re now at the Explorer perspective, getting it filtered down to the specific endpoint on the specific service that we care about. And we also see the exception analysis across the trace. We see all exceptions that happen in the context of this trace, together with the trace.

We also see another reason why we had this high number of exceptions. It seems it is happening three times for this specific transaction. We now have a single occurrence of this exception, with a view of the exception message and the exception stack trace.

It also works the other way around. If you have a specific trace and you want to understand whether there’s more examples of a specific exception you can always drill up to the exception analysis to take a closer look.

For example, we can now examine this exception specifically, see only its occurrences, and identify exactly where it happens repeatedly over time.

Investigating a failure caused by an exception

Sometimes an exception isn’t just a slowdown—it’s a real failure. When that happens, Dynatrace links the exception directly to the underlying failure and guides you to a detailed failure analysis, including the full stack trace captured in the context of the failed service call.

Key takeaways about exception analysis

Exception analysis enables developers to gain insights into exceptions and their behavior within the environment and their code so you can resolve issues more quickly.

And, Exceptions Analysis also works for OpenTelemetry. By following semantic conventions, any exceptions in OpenTelemetry spans will appear in Exceptions Analysis.

Top 3 takeaways from this demo:

• Exceptions are often the real reason a trace fails or slows down—and now you know how to view them easily with Dynatrace.
• Dynatrace shows exceptions across the whole trace, not just inside one span, and it supports both OpenTelemetry and OneAgent collection.
• An exception does not always mean that something failed, therefore you can quickly determine whether something broke or slowed down and if so where and what the impact is.

To learn more, check out the following resources.

• Documentation
• Failure detection example
• Data in context: How Dynatrace solves the OpenTelemetry analytics challenge

The post Why exceptions matter: Elevating your distributed tracing investigations appeared first on Dynatrace news.

As organizations accelerate their cloud-native transformations, the relationship between DevOps and platform engineering has become critical to sustainable software delivery at scale. While DevOps provides the cultural framework and practices for continuous delivery, platform engineering creates the foundational infrastructure that enables these practices to scale effectively across the enterprise. Understanding how these disciplines complement each other is essential for IT leaders navigating modern software delivery challenges.

The current state: DevOps at scale

DevOps has fundamentally transformed how organizations deliver software. By breaking down silos between development and operations teams, implementing continuous integration and delivery pipelines, and embedding observability throughout the software lifecycle, enterprises have achieved deployment frequencies measured in minutes rather than months.

However, as organizations scale their DevOps initiatives, new challenges emerge. A recent analysis of enterprise DevOps implementations revealed consistent patterns: Teams operating at scale face increased cognitive load, infrastructure inconsistencies across teams, and compliance complexities that traditional DevOps practices struggle to address.

Consider a typical scenario: A financial services organization with more than 200 developers across 15 teams discovered that each team has implemented different continuous integration and delivery (CI/CD) pipelines, monitoring solutions, and security controls. The result is operational inefficiency, increased security risk, and developer frustration.

This complexity gap is where platform engineering enters the equation — not as a replacement for DevOps, but as its essential complement for enterprise-scale operations.

Understanding DevOps fundamentals

DevOps represents both a cultural shift and a set of technical practices designed to accelerate software delivery while maintaining reliability. At its core, DevOps encompasses:

• Continuous integration and delivery (CI/CD). Automated pipelines that move code from development through testing to production, reducing manual intervention and human error.
• Infrastructure as code (IaC). Programmatic infrastructure management that promotes consistency and repeatability across environments.
• Observability and monitoring. Comprehensive telemetry collection and analysis to understand system behavior and preempt issues before they affect users.
• Security integration (DevSecOps). Embedding security practices directly into the development pipeline, rather than treating security as a separate phase.
• Cross-functional collaboration. Breaking down organizational silos to create shared ownership of software delivery and operations.

These practices are consistently associated with stronger business outcomes. Organizations that invest in mature DevOps capabilities generally report faster delivery, higher quality, and more resilient systems — while also seeing more predictable, repeatable value delivery to customers. In short: better software delivery tends to correlate with better business performance.

Platform engineering: The infrastructure product approach

Platform engineering emerged from the recognition that infrastructure itself should be treated as a product. Rather than each development team solving the same infrastructure challenges independently, platform engineering provides standardized, self-service capabilities through internal developer platforms (IDPs).

Key characteristics of effective platform engineering include the following:

• Self-service infrastructure. Developers can provision environments, deploy services, and access tools through automated interfaces without requiring deep infrastructure expertise.
• Standardization with flexibility. Common patterns and best practices are encoded into the platform while still allowing teams the flexibility to meet specific requirements.
• Built-in compliance and security. Regulatory requirements and security controls are automatically enforced through the platform, reducing the compliance burden on individual teams.
• Developer experience focus. The platform is designed with developer productivity as a primary metric, reducing cognitive load and eliminating repetitive tasks.

Organizations with mature platform engineering practices see significant reductions in time spent on infrastructure management and improvements in deployment frequency compared to those without such platforms.

How DevOps and platform engineering complement each other

The relationship between DevOps and platform engineering is symbiotic. DevOps provides the practices and culture, while platform engineering provides the infrastructure and tooling that makes those practices sustainable at scale.

Consider how they reinforce each other across key dimensions:

• Automation evolution. Where DevOps automates individual pipelines and processes, platform engineering automates the creation and management of those pipelines themselves. This meta-automation enables organizations to maintain consistency while scaling rapidly.
• Observability at scale. Both disciplines prioritize visibility, but platform engineering helps to keep observability tools and practices standardized across the organization. This standardization can help reduce mean time to detection (MTTD).
• Cognitive load management. DevOps practices can inadvertently increase developer cognitive load as teams take on more operational responsibilities. Platform engineering addresses this by abstracting infrastructure complexity behind well-designed interfaces.
• Compliance and governance. Platform engineering enables DevOps teams to move fast while supporting compliance by embedding policies and controls directly into the platform layer.

Distinguishing between DevOps, SRE, and platform engineering

While DevOps, site reliability engineering (SRE), and platform engineering overlap, each has distinct focus areas that complement the others.

DevOps establishes the cultural foundation and practices for continuous delivery, emphasizing collaboration, automation, and rapid feedback loops across the entire software lifecycle.

SRE applies software engineering principles to operations challenges, focusing specifically on system reliability through error budgets, service-level objectives (SLOs), and automated incident response.

Platform engineering builds and maintains the internal platforms that enable both DevOps and SRE practices to function effectively at scale, providing the technical foundation for the entire engineering organization.

In mature organizations, these disciplines work in concert: SREs define reliability standards, platform engineers encode those standards into the platform, and DevOps practices help teams meet those standards while delivering features rapidly.

Implementation challenges and solutions

Organizations implementing DevOps and platform engineering face several common challenges:

• Cultural resistance. Traditional organizational structures often resist the collaborative model that DevOps requires. Success requires executive sponsorship and clear communication about the benefits of transformation.
• Tool proliferation. The cloud-native landscape includes thousands of tools and technologies. Platform engineering helps by curating and standardizing the toolchain, reducing decision fatigue and integration complexity.
• Security and compliance integration. Maintaining security in high-velocity environments requires fundamental shifts in approach. Successful organizations embed security checks directly into platforms and pipelines, making secure practices the path of least resistance.
• Measuring success. Organizations must establish clear metrics for both DevOps outcomes (deployment frequency, lead time, and MTTR) and platform effectiveness (developer satisfaction, platform adoption rate, and time to provision resources).

The role of AI and automation

AI is transforming both DevOps and platform engineering. Large language models (LLMs) now assist with code generation, documentation, and incident response. AI-powered observability platforms can predict and prevent issues before they affect users. In platform engineering, AI enables natural language interfaces for infrastructure management, making platforms more accessible to developers without deep technical expertise.

Organizations that integrate AI into their DevOps and platform engineering workflows can see faster documentation workflows, quicker incident investigation, and higher code quality due to AI-supported reviews.

Building a platform engineering practice

For organizations ready to implement platform engineering alongside their DevOps initiatives, consider this structured approach:

• Assess current state. Evaluate existing DevOps maturity, identify pain points, and understand where platform engineering can provide the most value.
• Define platform product vision. Treat the internal platform as a product with clear users (developers), requirements, and success metrics.
• Start with high-impact use cases. Begin with capabilities that address the most pressing developer pain points, such as environment provisioning or deployment automation.
• Measure and iterate. Continuously gather feedback from platform users and iterate based on actual usage patterns and developer needs.
• Scale gradually. Expand platform capabilities incrementally, helping each new feature to deliver measurable value before moving to the next.

Future outlook and continued evolution

The convergence of DevOps and platform engineering will accelerate as organizations embrace cloud-native architectures and AI-driven development. Key trends shaping the future include the following:

• GitOps adoption. Managing all infrastructure and application configuration through Git repositories provides auditability, rollback capabilities, and familiar workflows for developers.
• “Everything as code.” Beyond infrastructure, organizations are codifying policies, compliance rules, and operational procedures, enabling version control and automation across all aspects of IT.
• Developer experience as a competitive advantage. Organizations recognizing that developer productivity directly affects business outcomes are investing heavily in platform capabilities that improve developer experience.
• Serverless and edge computing. As computing models evolve, platform engineering must adapt to support new deployment patterns while maintaining consistency and control.

Practical recommendations for enterprise leaders

For IT leaders navigating the DevOps and platform engineering landscape, consider these actionable recommendations:

• Invest in both disciplines. DevOps and platform engineering are complementary, not competitive. Successful digital transformation requires both the cultural shift of DevOps and the technical foundation of platform engineering.
• Prioritize developer experience. Measure and optimize for developer productivity and satisfaction. Platforms that developers want to use drive adoption and deliver value.
• Establish clear metrics. Define success metrics for both DevOps practices and platform effectiveness. Track these metrics consistently and use them to drive continuous improvement.
• Build cross-functional teams. Platform teams should include diverse expertise, such as developers, operations engineers, security specialists, and product managers who understand user needs.
• Embrace incremental progress. Both DevOps transformation and platform engineering implementation are iterative journeys. Start small, demonstrate value, and scale based on success.

The path forward

The relationship between DevOps and platform engineering represents the natural evolution of software delivery practices in cloud-native enterprises. While DevOps provides the cultural foundation and practices for continuous delivery, platform engineering creates the scalable infrastructure that enables these practices to thrive across large, complex organizations.

For enterprises committed to digital transformation, the question isn’t whether to adopt DevOps or platform engineering, but how to implement both effectively. Organizations that successfully combine DevOps practices with robust internal platforms position themselves to deliver software faster, more reliably, and at scale — turning IT from a cost center into a competitive advantage.

The path forward requires a commitment to both cultural change and technical excellence. With proper implementation of DevOps practices supported by well-designed platforms, enterprises can achieve the agility, reliability, and innovation speed that modern markets demand.

The post DevOps and platform engineering: Building scalable software delivery in cloud-native enterprises appeared first on Dynatrace news.

With growing multicloud complexity and the need for organization-wide scalability, self-service and automation capabilities have become increasingly essential for developer productivity.

In response to this shift, platform engineering is rapidly growing in popularity. Many consider it an effective solution for improving efficiency and overall satisfaction for developers across a variety of organizations and industries.

The practice of platform engineering has evolved alongside the increasing complexity of cloud environments. Platform engineering is a practice that outlines how development teams build internal developer platforms (IDPs) to create self-service capabilities for software engineering teams. The result is a cloud-native approach to software delivery. A platform encompasses a set of tools, services, and infrastructure that enables developers to build, test, and deploy software applications. Platform engineers design and implement these platforms, as well as ensure their security, scalability, and reliability.

In what follows, we’ll cover the importance of platform engineering, the role of a platform engineer, and where the practice is heading in the future.

How does platform engineering work?

Platform engineering works by addressing common developer issues and streamlining software delivery to expedite the development processes. Self-service capabilities reduce complexity and allow developers to freely use the platform’s provided tools, workflows, services, and automation. As a result, developers can focus on the end product of the development process rather than its logistics and underlying infrastructure.

While self-service capabilities promote flexibility, platforms still help maintain compliance and synergy across development processes through centralized and predefined frameworks. Platforms provide a “paved road” for development teams, minimizing common obstacles and catering to needs to empower developers to easily navigate software delivery.

Platforms are an excellent way to scale development processes across an organization. As such, they’re typically most suitable for larger organizations but can also have their utility in smaller organizations. Maintaining coherence and compliance across multiple developers and teams may require a great deal of time and effort, especially without the aid of centralized infrastructure, toolchains, and templates. Fortunately, appropriately designed platforms provide these aids.

Why is platform engineering important?

With platform engineering, a development team can deliver a frictionless, self-service developer experience and provide maximum value with minimum overhead. Some of the primary advantages that the discipline provides include the following:

Accelerated software development

Platform engineering offers resources that foster efficiency, such as reusable components. These components are specific, predefined resources, such as libraries and templates, that are made available to all developers using the platform. Other aspects of the discipline — such as infrastructure as code, automation, and standardization — reduce extraneous manual processes to increase developer productivity.

Increased security

Secure coding practices are built into internal developer platforms (IDPs) from their inception. These practices include working with secrets and key management, vulnerability management and remediation, penetration testing, and OWASP. Platform engineering can automate many of these functions, making it easier to maintain a strong organizational security posture.

Reduced operational complexity

The self-service portals inherent to platform engineering greatly simplify operational processes. With these portals, developers do not need to rely on or coordinate with other teams that may not have the bandwidth to properly assist them. In turn, this reduced complexity fosters greater developer satisfaction and leads to less employee burnout.

Consistency in development processes

Platform-engineered, self-service portals involve standardized practices, which help to maintain consistency throughout the entire software delivery process. Centralized development practices, security protocols, and operational procedures make this consistency possible. In turn, consistency reduces errors, mean time to resolution, and silos, resulting in improved software quality and performance overall.

Scaling capabilities

Platform engineering offers scalability through its standardization and consistency. As a digital ecosystem expands, development teams must keep up with its evolution. The flexible and scalable nature of IDPs allows developers to seamlessly adapt and respond to these infrastructure changes.

“Platform engineering is increasingly becoming the focal point for organizations seeking to advance the maturity of their DevOps automation practices,” says Anita Schreiner, vice president of delivery at Dynatrace, in the 2023 DevOps Automation Pulse report. “This shift is accompanied by a rise in technical debt and coordination efforts among teams. Without a central and integrated platform, scaling automation to drive further impact becomes an insurmountable challenge.”

In response to these increasing demands, the report found that a staggering 54% of organizations are investing in platforms to enable easier integration of tools and collaboration between teams involved in automation projects.

Internal developer platforms

Internal developer platforms (IDPs) are the “platform” in platform engineering. Developers use IDPs to efficiently deliver software at scale. Most commonly, platforms consist of tools, templates, libraries, services, and other resources that developers can leverage to accelerate and streamline software delivery.

IDPs can also provide automated workflows that assist with repeatable tasks and boost developer productivity. Additionally, platform teams can bake security and compliance measures into IDPs. Through their centralized use, IDPs help ensure development processes are consistent and do not introduce vulnerabilities.

Platform teams are essentially product teams: their product is the IDP and their customers are internal developers. By treating the IDP as a product, platform teams are incentivized to create the best user experience possible, with the ultimate goal of achieving the highest user satisfaction. Platform teams thus strive to fine-tune all of the IDP’s components to best suit the developers using them.

Because needs vary greatly from organization to organization, there is no singular correct formula to create an effective IDP. IDPs may look and operate very differently across organizations. Ultimately, an effective IDP is specifically tailored to the developers using it, ensuring a frictionless delivery process and the utmost user satisfaction.

DevOps and the platform engineer role

In the world of DevOps, the role of platform engineers is relatively new. To better comprehend this role’s function, one must first understand how the discipline of platform engineering relates to DevOps as a whole.

DevOps methodology encourages collaboration between development and operations teams. To aid this collaboration, platform engineering offers DevOps teams a centralized platform for their tools and workflows. To some extent, the two practices complement each other. Like DevOps, successful platform engineering requires collaboration between development, security, and operations teams.

But beyond simply fostering collaboration, a central purpose of platform engineering is to support DevOps teams with tools, platforms, and workflows for effective software development. This realization has led to an increased organizational use of microservices to shift away from traditional product teams in favor of teams that apply platform engineering principles.

Platform engineering cannot stand alone, however. DevOps teams are still required because each application may require a unique DevOps pipeline. To attend to this need, platform teams provide the centralized infrastructure and tooling so DevOps teams may build their own pipelines independent of other teams.

The future of platform engineering

Platform engineering is at an evolutionary point as it matures alongside other DevOps practices. Overall, the future of the discipline entails working with product managers, designing based on internal development team requirements, and simplifying the DevOps process.

Platform engineers will see their purpose as creating infrastructure (as a product) to better understand the software delivery cycle’s requirements. Their metric of success will relate to how easily developers can self-service their requirements and own their code in production.

Platform engineering FAQs

What is the purpose of platform engineering?

Platform engineering is the creation and maintenance of internal developer platforms (IDPs) that offer self-service capabilities. Its core purpose is to provide software engineering teams with streamlined tools and workflows. This frees developers to focus on writing code and building features.

How is platform observability different from traditional infrastructure monitoring?

Traditional monitoring focuses on system health, including CPU, memory, and uptime. Platform observability adds visibility into developer usage patterns, CI/CD pipeline health, self-service adoption, compliance posture, and business impact.

Why is observability essential for platform engineering?

Because an internal development platform (IDP) touches every application and service, blind spots can stall deployments, reduce developer productivity, and delay releases. Observability ensures the platform actually accelerates development, rather than slowing it down.

What benefits do internal developer platforms (IDPs) offer to development teams?

IDPs reduce operational complexity and cognitive load by providing self-service access to standardized tools, services, and infrastructure. IDPs also ensure consistency, enforce security protocols, and accelerate software delivery while maintaining compliance across an organization.

When is an organization ready to implement platform engineering?

Organizations should consider implementing platform engineering and Internal Developer Platforms (IDPs) once their development teams grow beyond approximately 20-30 developers. At this scale, managing consistency, compliance, and infrastructure across multiple teams becomes increasingly complex without centralized aid. Before you implement a platform engineering program, it helps to assess existing infrastructure and finalize your budget.

What are the key roles within a platform engineering team?

• The Head of Platform Engineering is responsible for strategic oversight and resource allocation
• The Platform Product Manager defines the platform’s roadmap based on user feedback
• DevEx platform engineers focus on optimizing the developer experience
• Infrastructure platform engineers ensure the underlying infrastructure is robust and compliant

The post What is platform engineering? How does it work? appeared first on Dynatrace news.

When people first started saying they were using AI to build full apps, I was wildly skeptical. You’ve heard these stories too, right? “I built a complete SaaS platform in one weekend using ChatGPT!” Sure, you did.

But I kept hearing it. Over and over. Whole apps. Entire startups. Just prompts. So, I decided to test the hype. I’ve had the idea to build an app to help collectors track and manage their sports card collections for years. I’ve tried Excel, Google Sheets, Airtable, and even Retool. They are all excellent tools but weren’t the right ones for the job I was trying to accomplish. But after a friend showed me how he was using Claude Code in his CLI, the light bulb went on.

Two weeks later, I had a working site. Authentication. A database. A clean interface. All built with AI tools, a little stubbornness, and an embarrassing number of “let’s try that again” moments.

That’s when it hit me: It’s not vibe coding if you know what you’re doing.

The CLAUDE.md rulebook

The first lesson I learned: AI needs boundaries. So, I made a file called CLAUDE.md. Think of it like an employee handbook for a very confident robot. It spells out how I want things done — naming conventions, frameworks, the tone of my responses; even how to handle uncertainty. Without it, Claude will take creative liberties. With it, it’s like working with someone who mostly listens and only occasionally decides your database schema needs “personality.” You don’t need to go all in on “spec-driven development” when you’re first starting out, you just need some guide rails.

Second, design consistency is not AI’s strong suit. One minute it’s using Material UI, the next it’s gone rogue with pastel buttons and drop shadows from 2007. I started a design guide just to keep it on the rails. It made things infinitely easier to describe and control, all in one place.

An excerpt from the rulebook

# Claude Development Notes

## 🚨 CRITICAL: HOW TO WORK WITH THIS USER (READ FIRST - EVERY SESSION)

### Core Working Principles - NEVER FORGET THESE

1. **BE A SYSTEMATIC CODE ANALYST, NOT A GUESSER**

- ALWAYS search for existing code patterns, dependencies, and conflicts BEFORE attempting fixes

- Use grep, find, and comprehensive code analysis to understand root causes systematically

- Don't apply "band-aid" fixes - identify and solve the underlying architectural issue

- Leverage your file search and cross-reference capabilities instead of making the user debug manually

- This applies to CSS, JavaScript, database queries, API endpoints, configuration - EVERYTHING

2. **THINK LIKE AN EXPERT WITH DEEP SYSTEM KNOWLEDGE**

- Consider how changes affect the entire system: dependencies, imports, inheritance, scoping

- Look for naming conflicts, architectural patterns, and existing conventions

- Analyze the broader codebase structure and established patterns before making changes

- Understand the user is building maintainable, scalable, isolated components

- Apply this expertise to ALL aspects: styling, logic, data flow, security, performance

You can view the full rulebook here.

Don’t give AI the keys to the kingdom

Those initial guard rails will get you started, but they aren’t enough. You’re going to need reliable source control. Badly. AI can (and will) make sweeping changes in seconds. Whole sections of your project — just gone. It’s not malicious, it’s just eager. Commit early, commit often, and keep your fingers hovering over the ESC key to interrupt bad ideas.

Next: Write tests. I know. You won’t want to. Neither did I. But AI code that “works” can still be deeply wrong. I can’t tell you how many times I’ve seen it confidently try to pass data through functions that don’t even exist.

Perhaps most importantly: Never — and I mean never — let AI near your production database or environment. That’s not a metaphor. Twice, my AI coding partner has seen differences in our ORM and our database schema, and twice I have seen it decide to drop all of the database tables to create something that matches the ORM. Thankfully, it was only the development database, but if it had access to production, it would have dropped those tables too.

I have a rule: Staging is for the robots; production is for adults.

“AI forgets. Teammates inherit.”

This is painfully true. AI forgets everything. Context, logic, variable names. All of it. And when you come back to that project later (or someone else does), there’s no memory of why anything was done the way it was. That’s why documentation still matters. Probably more than ever. Because you’re not just documenting for other people anymore — you’re documenting for yourself when your future self wonders, “Why did past me let the robot do this?”

Observability, or “Please tell me what just happened”

This is where tools like Dynatrace come in. I know, I work there, but I’d say this either way. If you’re going to let AI write your code, you need a way to see what it’s doing. Not just logs — observability. Dynatrace tells me what’s happening across the system: slow API calls, inefficient queries, the occasional “why is this endpoint melting the CPU?” moment. It’s not about catching mistakes — it’s about catching surprises. And AI delivers plenty of those.

“Don’t asume corectness”

The typo’s intentional. Mostly. But the point stands: AI code looks right more often than it is right. I’ve had it produce entire components that look perfect and fail silently. It’s confident. It’s articulate. It’s wrong. So, check everything. Run it. Test it. Review it. Don’t just asume corectness.

The big takeaway

Here’s what surprised me the most: Building with AI doesn’t feel like cheating. It feels like collaborating. You’re still making all the decisions — the AI just types faster than you do. It’s like pairing with someone who’s read every Stack Overflow thread but still can’t quite tell when it’s about to create a security hole.

You’re not outsourcing the work. You’re accelerating it. AI doesn’t replace developers. It amplifies them. The people who’ll thrive in this new era aren’t the fastest typists — they’re the clearest thinkers. They’re the best communicators.

I don’t think “vibe coding” is bad. It’s just unstructured. And once you’ve got a plan — a CLAUDE.md file, a solid process, some observability, and a healthy dose of skepticism — it stops being “vibe coding” and starts being modern engineering.

AI can write code. But you still have to lead.

It’s not vibe coding if you know what you’re doing. It’s just engineering with better tools.

The post Is it vibe coding if you know what you’re doing? appeared first on Dynatrace news.

Software quality isn’t just about clean code. Bartek Pisulak, Director of Cloud Quality Engineering at Pegasystems, says it’s also about architecture, documentation, and processes working in harmony. But today’s systems are so complex that even small failures can ripple into outages across your entire stack. Understanding those interactions—and testing them—has become nearly impossible without help. That’s where AI comes in.

In this episode of the PurePerformance podcast, Bartek joins hosts Andi Grabner and Brian Wilson to explore how artificial intelligence is transforming chaos engineering, making it faster, smarter, and more effective at uncovering weaknesses before they become disasters.

How AI can enhance the five stages of chaos experiments

Pisulak walked through each of the stages of chaos experiments, and explained how AI fits into each one:

1. Defining steady state. AI learns your system’s “normal,” tapping into observability systems to detect patterns. Traditionally, this might be done by simply setting thresholds for different metrics. But Pisulak suggests using AI to analyze historic data to learn normal system behavior and predict failures before they happen. This has been possible using causal AI systems since before generative AI hit the scene, but remains a key starting point.
2. Generating hypotheses. Instead of hunting for weak spots manually, Pisulak recommends feeding your system’s architecture diagrams, logs, and documentation to AI-powered tools like Chaos Recommendation for Kraken or chaos eater that can surface edge cases, single points of failure, or unusual dependencies.
3. Running experiments. This is where AI-coding tools come in. They make it much quicker and easier to write scripts to run your experiments.
4. Verifying results. After experiments run, AI can sort through the avalanche of data and analyze your dependencies and software bill of materials (SBOM) to help prioritize fixes or note which ones are most likely to be false positives.
5. Improving the system. AI can propose code changes or configuration improvements. In advanced use cases, it helps create a feedback loop, automatically fixing issues, re-running previously failed tests, and driving continuous improvement.

In short, the value of AI in chaos engineering is about making the entire process more intelligent and robust, freeing engineers to innovate and build stronger systems.

Our perspective: Organizations are under pressure to move from AI proofs-of-concept to demonstrating real value. Using AI in resilience testing, as described by Pisulak, could be an easy win for operations teams. As Dynatrace VP and Chief Technology Strategist Alois Reitbauer recently said on the CUBE, AI presents real potential to help operations teams move from firefighting mode to start thinking about making bigger-picture improvements that they just don’t have time to focus on.

The post AI’s surprising role in chaos engineering appeared first on Dynatrace news.

Every organization is adopting GenAI across its infrastructure and application stacks. It’s important that IT operations teams seek a seat at the table because large swaths of models will be deployed across every technology. For example, the use of cloud migrations, GenAI large language models, small language models, and specialized models will drive productivity, cost savings, and business returns. Every customer is considering and attempting to measure their business returns from their AI investments; transparency into the data, system and model performance and drift, security, and quality are critical areas where IT operations, DevOps, SREs, and platform engineering teams can play a critical role in optimizing business returns and reducing business risks. So, where should you start the conversation?

Executives can use observability to reduce business risks and increase AI ROI by understanding how observability capabilities play a role in delivering across the core AI value categories of productivity, customer impact, cost optimization, innovation, and quality. For example, observability improves customer satisfaction by reducing the mean time to resolution and mean time to understanding. In addition, it can improve cross-team collaboration and data access to deliver cost efficiencies.

To reduce business risks and increase ROI in GenAI use cases, technology executives should plan to manage rising complexity, and, as part of continuous evaluation, executives should consider GenAI performance across the following dimensions:

• System performance: Monitoring the system performance of GenAI applications encompasses measuring operational performance characteristics similar to those of traditional applications, including at the software and infrastructure layers and the model. Model system performance monitoring includes the measurement of metrics such as model response latency, error rates (including failure to respond), and API failures.
• Quality performance: It is crucial for organizations to monitor the output quality of GenAI and AI applications. Quality includes accuracy of responses and model drift, where data used to train models no longer produces accurate or relevant results.
• Governance: Model governance of GenAI often encompasses monitoring and enforcing legal requirements and the organization’s ethics policies. Ongoing monitoring is necessary, including the adoption of guardrails to prevent the delivery of outputs that don’t comply with laws or company policies.
• Security: In addition to the theft of private information or loss of intellectual property, organizations must protect against security risks that are specific to GenAI applications. Prompt injection and jailbreaks are two emerging attacks. Monitoring tools that detect these and other security issues are critical to risk management.
• Cost: Monitoring the cost of delivering a GenAI application is a multitiered undertaking. Depending on the application, organizations may incur costs for each query and response to a model, in addition to costs associated with the underlying infrastructure required to deliver the application. The ability to collect the right cost information and analyze it on a per-application basis will be key to the ability of an organization to determine ROI.

Organizations must base the measurement of each performance dimension on its ability to derive outcomes that drive business value. Each GenAI application should support a targeted outcome, such as improved productivity, increased revenue, new revenue streams, or enhanced customer satisfaction. Connecting the dots between GenAI performance dimensions and business value requires defining measurements that matter to the business and collecting, correlating, and analyzing the data to understand the app’s ability to deliver that value.

For technology executives, AI observability is fast becoming essential for managing the operational complexity and business outcomes from AI initiatives. It provides the visibility needed to demonstrate ROI, ensure reliable AI applications, and make informed decisions based on critical data that supports every AI use case.

The post Optimizing AI ROI from DevOps and IT Operations: The rising need for AI/LLM observability appeared first on Dynatrace news.

From the personal computer to the internet to mobile and cloud native, transformative technologies bring new challenges and opportunities. While every innovation is different, Pini Reznik says there are patterns that can be applied when adopting any new technology.

In the latest PurePerformance podcast, Reznik talks to hosts Andi Grabner and Brian Wilson about his new book From Cloud Native to AI Native: Catching the Next Wave of Innovation, and how organizations can take a pragmatic approach to AI adoption.

The AI Native transformation process

Here’s how Reznik describes the process of adoption AI, or any other transformational technology:

• Experiment: Start with a small, skunkworks-style team operating in a sandbox. Their mission isn’t to deliver production-ready systems but to experiment, learn, and identify viable business cases.
• Find a small win: Once you find a promising use case, build a minimal viable product that demonstrates tangible value. Success here justifies incremental investment.
• Build a foundation: Build the infrastructure, develop the team structure, and foster the new culture necessary to adopt the technology at scale.
• Scale up: Expand as you grow, transitioning from legacy systems to new solutions carefully.

The biggest mistake organizations make is skipping the first two phases and jumping straight to large-scale initiatives. That’s why you hear so much about failed AI pilots: Organizations try to scale before they validate their use cases.

“Transformation isn’t a one-time project; It’s a way of thinking.”

— Pini Reznik, CEO and Co-Founder, re:cinq

AI for the little guy

In the previous episode of PurePerformance, Laura Tacho made the case for AI’s true potential in software development being not in code generation but in speeding up feedback loops and helping ensure that developers build the right things. Where Tacho focused on developer experience and the software development lifecycle, Reznik focuses on organization-wide potential, particularly for companies that haven’t traditionally built much, if any, software in-house. AI could make it affordable for smaller companies to build custom software based around their unique value propositions.

Our perspective: Start small, validate value early, and ensure every step is measurable and observable. When teams can see the impact of AI in real time—on performance, cost, and outcomes—they make smarter decisions and scale with purpose.

The post Want to catch the AI native wave? Learn the lessons of the cloud-native shift appeared first on Dynatrace news.

Observability isn’t just about collecting data. It’s about connecting the dots across your stack to answer why something is broken, not just what is broken. For developers, this means the ability to ask ad-hoc questions about live systems and get answers fast enough to change code with confidence.

Modern observability tools can help you catch issues before they become incidents, validate deployments, and understand how your code behaves in the real world. This excerpt from our new Developer’s Guide to Observability, walks you through how to build an observability workflow that works for you, not against you.

Bring observability directly into your IDE

Modern integrations—like the Dynatrace Live Debugger for VS Code and JetBrains IDEs—make it possible to inspect live workloads, trace requests, and debug production issues without leaving your editor.

Here’s what a good IDE integration should let you do:

• Live debugging breakpoints: You can set breakpoints in your code that apply to running instances in selected environments. These are non-breaking and won’t interrupt runtime behavior.
• Environment filtering: You choose which environments and instances to debug, so you’re not overwhelmed by irrelevant data.
• Snapshots: You should be able to view snapshots displaying:
  • Local variables
  • Stack traces
  • Process metadata
  • Tracing data
• Debug without redeploys: Get instant access to code-level debug data in production so you can pinpoint issues faster, avoid service disruption, skip redeployments, and eliminate the need to recreate costly defect environments.
• Bring agentic AI into your IDE: Use MCP to integrate your observability platform’s AI capabilities into your AI coding agent to get immediate performance and security insights about your code base without ever leaving your IDE.

Build a launchpad that works for your team

Start by creating a simple, centralized view that gives you quick access to the tools and data you use most. This could be a dashboard in your internal developer portal, a pinned tab in your IDE, or even a custom homepage in your observability platform.

Include links to:

• Your service’s health and performance metrics
• Logs and traces for recent deployments
• CI/CD status
• Source code and issue tracking

Why it matters: You shouldn’t have to dig through menus or memorize URLs to find what you need. A personalized launchpad saves time and keeps you focused.

Surface observability in your service catalog

If your team uses an internal developer portal like Backstage, Port, or Humanitec, make sure observability data is embedded directly into the service catalog. When you look up a component, you should see:

• Where it’s deployed
• Whether it’s healthy
• Any recent problems or vulnerabilities

For example, for Kubernetes-based services, observability should surface deployment status, pod health, and cluster-level metrics directly in the catalog view.

Why it matters: You already use the catalog to find ownership and repo links—why not also see how the service is performing? To learn more, checkout our Backstage spotlight.

Automate validations in CI/CD

Every time you deploy, your pipeline should automatically verify that your service meets basic observability standards. Are logs and traces being captured? Are synthetic tests passing? Are performance thresholds being met?

Set up automated validation checks such as Quality Gates that run on every code check-in, flagging issues before they reach production. This will provide a continuous feedback loop on the health of your platform. Just remember: The value of that loop depends on the quality of the checks you put into it.

Why it matters: You don’t want to find out after the fact that your service shipped without telemetry or broke a key performance metric.

Surface observability in pull requests

When you open a pull request, you should get feedback not just on code quality, but on how the change affects your service’s behavior. Did it introduce a regression? Did it break a test? Did it exceed latency thresholds?

Integrate observability validations or automated feedback directly into your Git workflow.

Why it matters: You spend a lot of time in PRs—this is the perfect place to catch issues before they merge. Learn more about SDLC Observability.

The post How to build workflows that catch bugs early and keep code moving appeared first on Dynatrace news.

Developer experience (DevEx) is more than ping pong tables and free snacks. It’s the foundation for building great software. As AI reshapes the way we code, the real opportunity lies not in writing code faster, but in creating environments where developers can do their best work. In the latest episode of the PurePerformance podcast, hosts Andi Grabner and Brian Wilson interview Laura Tacho, CTO at DX, for a candid discussion on DevEx and AI’s true potential in software engineering. Hint: It’s not about writing code faster.

The impact of DevEx

Tacho reminds us that excellent DevEx is about removing friction from daily work. But measuring DevEx isn’t simple. It’s often about trying to measure an absence. Enter the DX Core 4 framework, co-authored by Tacho and leading software researchers. It focuses on four actionable metrics:

• Speed: How quickly teams can deliver, measured by merge frequency.
• DevEx: Engineers’ self-reported experiences of focus and feedback.
• Quality: Change Failure Rate, or how often production deployments go wrong.
• Impact: The ratio of time spent on innovation versus maintenance.

The major takeaway: Most engineers aren’t great at selling the business impact of improved tooling and better DevEx. But when you improve DevEx, the other three metrics will rise as well. Whether it’s reducing build waits, making information easier to find, or reducing the number of meetings, reducing developer pain points unleashes business value.

Use AI to tackle friction

That tees up Tacho’s other major insight: AI’s biggest impact won’t be in merely cranking out more code—after all, typing speed has never been the bottleneck in software development. The majority of developers’ time is spent on tasks other than coding, like meetings. There’s room for AI to make a bigger difference in developer productivity by speeding up prototyping and tightening feedback loops, which can reduce the amount of time developers spend in meetings discussing what to build, or wasting time building the wrong things.

She says the real return on investment comes from using AI to improve the essentials. “Back to basics is a great headline for what makes companies successful with AI,” Tacho says.

“When we look at what makes agentic workflows work really well, it’s clearly defined services, really robust testing, the ability to detect anomalies in the system and fix them quickly, production debugging, observability. All of these things are core components to developer experience.”

— Laura Tacho, CTO at DX

Rather than just bolting AI onto existing processes, AI presents the opportunity to fundamentally rethink the software development lifecycle from first principles to get these basics right. Tacho points out that the boom in AI and agents is an opportunity to “make a lot of the investments that we’ve been wanting and advocating for, but maybe couldn’t secure a budget for.”

Our perspective: We’re already starting to see the first glimpses of AI boosting DevEx and enabling new workflows, as MCP integrations make it easy for developers to run tests, file pull requests, observe application performance, and more without ever leaving the comfort of their IDE or terminal.

The post AI’s biggest impact isn’t cranking out more code: Why DevEx matters appeared first on Dynatrace news.

As organizations and platform engineers increasingly embrace DevOps and CI/CD pipelines, features such as GitLab Pipelines have emerged as a powerful tool for automating development and delivery processes. But as with many other automation tools, it’s difficult to maintain the performance and visibility of these pipelines. That’s where Dynatrace, and its Software Development Lifecycle (SDLC) Events come into play to provide a full view into your CI/CD pipelines. This blog post shows how GitLab Webhooks and Dynatrace SDLC Events can be used to monitor pipelines and merge requests. But first, let’s explore some of the advantages of monitoring your CI/CD pipelines using Dynatrace.

Maximizing CI/CD efficiency

1. Enhanced observability and release validation

Dynatrace already excels at delivering a comprehensive end-to-end view of your systems and user journeys. Extending this visibility into your CI/CD pipelines offers even greater value. By using Dynatrace, organizations can proactively monitor for potential issues or slowdowns in their delivery processes. Additionally, it enables validation of releases to ensure quality and reliability. This integration empowers teams to detect, confirm, and resolve problems faster by correlating new issues directly to updates deployed by a pipeline, streamlining, troubleshooting, and minimizing downtime.

2. Improving collaboration across your organization

By surfacing actionable insights and centralized monitoring data, Dynatrace fosters collaboration between development, operations, and business teams. Everyone involved in the software delivery lifecycle can work together more effectively with a single source of truth and a shared understanding of pipeline performance and health.

3. Optimizing resource utilization

Whether you’re using self-hosted or cloud-hosted runners, their resource demands can significantly impact your organization. Inefficient or resource-intensive runners can lead to increased costs and underutilized infrastructure. With Dynatrace, you can monitor runner resource usage, enabling organizations to monitor consumption patterns, identify inefficiencies, and optimize runner performance. This allows you to allocate resources more effectively, reducing costs while ensuring your CI/CD pipelines operate smoothly and efficiently.

Now, on to the implementation.

Implementation process

Disclaimer: This blog post demonstrates pipeline observability for GitLab. The detailed description of this best practice is maintained here. The approach is currently in Preview and will be soon available for Azure DevOps, GitHub, and ArgoCD. If you are interested in testing the preview and providing feedback, please follow this link.

Prerequisites

1. Install Dynatrace Configuration as Code via Monaco.

2. Create an OAuth client with the following permissions.

• Run apps: app-engine:apps:run
• View OpenPipeline configurations: openpipeline:configurations:read
• Edit OpenPipeline configurations: openpipeline:configurations:write
• Create and edit documents: document:documents:write
• View documents: document:documents:read

3. Store the retrieved client ID, secret, and token endpoint as an environment variable.

• export OAUTH_CLIENT_ID='<YOUR_CLIENT_ID>'
• export OAUTH_CLIENT_SECRET='<YOUR_CLIENT_SECRET>'

4. Clone the Dynatrace configuration as code sample repository, then go to the gitlab_pipeline_observability directory.

• git clone https://github.com/Dynatrace/dynatrace-configuration-as-code-samples.git
• cd dynatrace-configuration-as-code-samples/gitlab_pipeline_observability

5. Edit the manifest.yaml by exchanging the <YOUR-DT-ENV-ID> placeholder with your Dynatrace environment ID.

Configure Dynatrace using Monaco

With the prerequisites set up, we can now use `monaco` to upload the two dashboards and the configurations for our GitLab ingest endpoints in OpenPipeline. If you already have any configurations in your OpenPipeline besides the default settings, start at step 1 to avoid overwriting your configs. If you do not, then you can skip to step 3.

1. Download your OpenPipeline configuration

• monaco download -e <YOUR-DT-ENV-ID> --only-openpipeline

2. Merge the content of download_<DATE>_<NUMBER>/project/openpipline/events.sdlc.json into the file pipeline_observability/openpipeline/events.sdlc.gitlab.json

3. Run Monaco deploy

• monaco deploy manifest.yaml

To confirm that it worked, you can go to the OpenPipeline app and check out the newly deployed configurations under Events > Software Deveolpment Lifecycle. There should be a new custom ingest source, three dynamic routes, and three pipelines as shown in the images below.

Configure GitLab to send webhook events to Dynatrace

Now that Dynatrace is ready to transfer GitLab webhooks into SDLC events, we need to setup a webhook that allows GitLab to send the data to Dynatrace. To do that we will first need an Access Token from Dynatrace. You can navigate in Dynatrace to Access Tokens, then generate a new token using the following scopes:

• openpipeline.events_sdlc.custom
• openpipeline.events_sdlc

Save that token as we will need to use it in the next steps to configure the webhook.

1. In GitLab, select your group or project and go to Settings > Webhooks

2. Click Add new webhook, use the following settings:

• URL: Please exchange the placeholders with your Dynatrace environment ID and access token, respectively. https://<YOUR-DT-ENV-ID>.live.dynatrace.com/platform/ingest/custom/events.sdlc/gitlab
• Select the following triggers:
  • Merge Request Events
  • Job Events
  • Pipeline Events
• Add custom header to your webhook with the name Authorization and value Api-Token <YOUR-ACCESS-TOKEN>.
• Click on Add webhook

And just like that, you are all set. Whenever a merge request is created, closed, assigned, etc., or whenever a job is run, completed, queued, etc., the events will be pushed automatically to Dynatrace. And because of the OpenPipelines configured in the step prior, those events will be processed and transferred into SDLC events, which are then stored in Grail.

To test out, have your developers create some merge requests or run some jobs. Then open the GitLab Pipeline Pulse and the GitLab Merge Requests Dashboard to see your information visualized. It will look something like this:

Next steps: Unlocking the potential of GitLab data in Dynatrace

And with that, we now have our GitLab repository and pipelines monitored by Dynatrace. Visualizations such as the ones above are only just the beginning. The Dashboards are fully customizable with more information that the images show in this blog, but it’s not the end goal. With SDLC events, you can directly influence and enhance your DevOps and DevSecOps processes with Dynatrace Workflows or directly improve your flaky and failed tests resolution with code-level debug snapshot from the Live Debugger, for instance.

Below is an example of a workflow that triggers from our merged merge requests, using the Site Reliability Guardian to validate performance and vulnerabilities, and finally to either create a Jira ticket on failure, or auto merge the changes to the next stage if they pass.

The examples provided were designed to be straightforward and easy to implement, offering a foundation for integrating GitLab data into Dynatrace. However, these are just the beginning. Now that your data is within Dynatrace, the possibilities for analysis and visualization are virtually limitless.

Here are some next steps to consider:

• Visualizing job success trends
• Identifying pipeline performance bottlenecks
• Correlating runner activity with job execution times

Discover the possibilities

With the flexibility of DQL and the powerful visualizations from Dynatrace, you can create customized dashboards and reports that deliver actionable insights tailored to your needs. The only limit is your imagination—experiment with new queries, uncover hidden trends, and continually refine your monitoring setup to maximize the value of your GitLab data. If you are interested in testing and providing feedback to improve upon the preview, go to this community post and share you experiences and any suggestions you may have. And if you want to read more about Dynatrace and DevSecOps, give this blog post a quick read.

The post Unlock enhanced CI/CD insights in GitLab for pipeline visibility appeared first on Dynatrace news.

You know that feeling when you’re deep in the zone? Your fingers are flying across the keyboard, and everything is clicking into place. Then, boom — a performance or availability issue pops up. Your beautifully curated flow shatters, and now you’re bouncing between logs, traces, dashboards, and Stack Overflow, trying to piece together what went wrong.

This is the context-switching trap, and it’s a silent productivity killer for developers. Debugging isn’t just about fixing problems; it’s about rebuilding mental context every time you step away from your IDE.

Google Gemini Code Assist can help to fix that. Together with the upcoming Dynatrace plugin for Gemini Code Assist, it keeps developers inside their editor and surfaces real-time performance and availability problems with their root cause — all without breaking focus. This means less tool-hopping and fewer distractions — just more time coding.

Context-switching: The hidden productivity killer

Writing code is like constructing a house of cards. It’s delicate, precise, and one wrong move sends everything tumbling. But unlike a physical house of cards, your brain doesn’t let you instantly pick up where you left off. Consider the following:

• A small interruption — checking logs or sifting through performance dashboards — can take 10-plus minutes to recover from.
• Constantly switching between tools forces teams to rebuild mental context every time.
• Debugging across multiple platforms turns into a time sink, slowing down feature development.

The irony is the more time you spend finding the problem, the less time you have to actually solve it. And that’s where Gemini Code Assist and the upcoming Dynatrace plugin change the game.

Google Gemini Code Assist: Debug without leaving your IDE

Imagine catching a performance bottleneck before users complain or spotting an availability issue without scrambling through external dashboards. That’s what the Dynatrace plugin for Gemini Code Assist (coming soon) does — it keeps your observability where you code.

• Performance and availability insights surface inside the editor — no need to check observability tools.
• AI-powered root-cause analysis helps teams understand and fix issues faster.
• Real-time anomaly detection means teams can act before things spiral.

It’s like having an ultra-efficient debugging co-pilot with a Ph.D. in SRE. Instead of bouncing between tools, teams get immediate context on what’s wrong, right where they’re working.

Why it’s important to stay in the zone

Developers don’t just write code — they live in it. The more time developers spend in their IDE, the better their focus, flow, and ability to ship high-quality software.

Less distraction, more deep work

Every time developers shift from coding to investigating an issue, they lose momentum. Gemini Code Assist and the Dynatrace plugin minimize distractions, letting developers debug in place and maintain deep focus.

More time solving, less time searching

Traditional debugging is a scavenger hunt. Gemini shortens the loop by bringing relevant insights to the editor, eliminating the need for multiple context shifts.

Better team velocity and code quality

When developers spend more time coding and less time firefighting, teams move faster. Bugs get fixed sooner. Features ship quicker. Software runs smoother.

Getting started with Google Gemini Code Assist

Ready to spend more time coding and less time context-switching? Gemini Code Assist is available for leading IDEs, such as Visual Studio Code and JetBrains.

• Setup is simple. Just install the Gemini Code Assist extension and configure the Dynatrace plugin to connect to your tenant.
• Performance insights appear directly inside your IDE.
• No need to change your workflow. Gemini adapts to how you already work.

Keep your focus and fix faster

Debugging should be about solving problems — not wasting time tracking them down. Google Gemini Code Assist keeps developers in the zone, and the Dynatrace plugin surfaces real-time performance insights without pulling you out of your flow.

The less time teams spend hunting for problems, the more time they have to write great code.

For more information about Google Gemini Code Assist and the Dynatrace plugin, contact us today.

Dynatrace and the Dynatrace logo are trademarks of the Dynatrace, Inc. group of companies.  All other trademarks are the property of their respective owners.

The post Stay focused, code faster: How Google Gemini Code Assist keeps developers in the zone appeared first on Dynatrace news.

In this blog post, we guide you through configuring a project to visualize real-time CI/CD build and release data for your Azure DevOps pipelines. The resulting visibility enhances collaboration with transparent data, increases productivity by automating monitoring tasks, and enables teams to detect issues proactively. With insights into your Azure DevOps pipelines, you can continuously improve processes, ensuring smoother and more reliable deployments over time.

A notebook version of the blog is also available on the Dynatrace GitHub repository. Download the AzureDevOps - Dynatrace Integration.json file and upload it to your Notebooks app in Dynatrace.

Prerequisites

Before we begin, ensure you have the following:

• Access to your Dynatrace Tenant and permission to create tokens.
• Your tenant ID, which can be found in your environment URL: https://<YOUR_TENANT_ID>.live.dynatrace.com/.
• A token with Ingest Logs v2 scope.
• A token with Write Settings scope.

Create webhooks in Azure DevOps

First, we need to create two service hooks subscriptions in Azure DevOps: one for Builds Completed and one for Release Deployment Completed.

1. Navigate to https://{orgName}/{project_name}/_settings/serviceHooks.
2. During the configuration, do not apply any filters.
3. In the settings page of the subscription, fill in the following fields:
   • URL: https://<YOUR_TENANT_ID>.live.dynatrace.com/api/v2/logs/ingest
   • HTTP Headers: Authorization: Api-token <YOUR_LOG_INGEST_TOKEN>
   • Ensure the text above is copied exactly, replacing only the token.
   • Change “Messages to send” and “Detailed Messages to send” to Text.

Add a new Grail logs bucket

Follow these steps to create a new logs bucket in Dynatrace. Note: This step is optional. You’re welcome to use an existing Grail logs bucket.

1. Open the Storage Management app in your tenant: Select CTRL/CMD + K and enter Storage.
2. Create a new bucket by selecting + in the top right corner.
3. Name the bucket azure_devops_logs.
4. Set the retention time as desired.
5. Set the bucket type to logs.

Configure OpenPipeline with log processing rules

Using OpenPipeline™, you can easily define a rule that routes all relevant log lines you created in the previous step into the bucket. This process also performs the necessary processing steps, such as renaming fields or transforming log data into dedicated events.

1. Open the OpenPipeline app and select Logs in the left pane.
2. Select the Pipelines tab and create a new one by selecting + Pipeline.
3. Name the new pipeline AzureDevOps.
4. Go to Dynamic Routing and create the following new rule:

matchesPhrase(eventType,"ms.vss-release.deployment-completed-event") OR matchesPhrase(eventType,"build.complete")

5. From the Pipeline dropdown, select “AzureDevOps”.
6. Return to your pipelines and open “AzureDevOps”.
7. Under the Storage section, add a new processor > Bucket assignment, set a name and select the azure_devops_logs bucket from the dropdown.

8. Next, open the Processing tab and define a couple of rules.
   1. First, create a new Rename Fields rule and call it “Rename Build Fields” where the left value is the new field name and the right value is the existing field name.

1. resource.buildNumber: buildNumber
2. resource.result: result

1. 2. Second, create another Rename Fields rule called “Rename Release Fields” where the left value is the new field name and the right value is the existing field name.

1. resource.stageName: stageName  
2. resource.project.name: projectName 
3. resource.deployment.release.name: releaseName 
4. releaseStatus:resource.environment.status: releaseStatus

Use the following sample data to verify your rules are working as expected.

Release event sample data:

{ 
       "timestamp": "2024-11-11T15:14:51.104000000-05:00", 
       "loglevel": "NONE", 
       "status": "NONE", 
       "createdDate": "2024-11-11T20:14:50.6300269Z", 
       "detailedMessage.text": "Deployment of release Release-946 on stage Staging succeeded. Time to deploy: 00:14:14.", 
       "dt.auth.origin": "dt0c01.YFMJ6LUO43SFFDW2SF7EW5YZ", 
       "eventType": "ms.vss-release.deployment-completed-event", 
       "id": "1862ab11-c0d4-451a-8b9b-0dfe7f517297", 
       "message.text": "Deployment of release Release-946 on stage Staging succeeded.", 
       "resource.environment.status": "succeeded", 
       "resource.project.name": "devlove-alpha", 
       "resource.stageName": "Staging", 
       "resource.deployment.release.name": "Release-946" 
    }

Create an Azure DevOps dashboard and visualize log data

Now that we have ingested the logs coming from AzureDevOps, let’s visualize the data to get better and quicker insights into our CICD pipelines.

1. Go to the AzureDevOps Git Repository and download the AzureDevOps Dashboard (on Logs).json file.
2. Within Dynatrace, open the Dashboards app and select Upload at the top left corner.
3. Upload the JSON file to start visualizing your Azure DevOps data.

Extract “release” and “build” events

Taking this a step further, we can convert the ingested log data to SDLC (Software Development Lifecycle) events in case we detect a new release or build and discard the related log line afterward.

This helps reduce the number of stored log data and supports further platform engineering use cases, such as calculating DORA metrics, automating development processes, or observing the health of your engineering pipeline.

Disclaimer: The following instructions extract Business events from log data. Once supported by OpenPipeline we propose to extract Software Development Lifecycle Events (SDLC events), which are the preferred way of storing the extracted information.

Note: You may need to request a Log Content Length (MaxContentLength_Bytes) increase depending on how many steps your Release Events have. The integration generates ingest costs for logs and metrics (according to your rate card), depending on how many build/release events you ingest.

1. In Dynatrace, open OpenPipeline:
   • Go to OpenPipeline > Logs > Pipelines > AzureDevOps.
   • Navigate to the Data Extraction section.
2. Next, create a Business Event Processor rule, for all build events, using the following parameters:
   • Name: Build Result
   • Matching condition: matchesPhrase(eventType,"build.complete")
   • Event type: field name eventType
   • Event provider: Change to Static String: AzureDevOps
   • Fields to extract: result, buildNumber, resource.reason

1. Finally, we use another Business Event Processor rule, to extract release events:
   • Name: Release Result
   • Matching condition: matchesPhrase(eventType,"ms.vss-release.deployment-completed-event")
   • Event type: field name eventType
   • Event provider: Change to Static String: AzureDevOps
   • Fields to extract: stageName, projectName, releaseName, releaseStatus, resource.deplyoment.startedOn, resource.deployment.completedOn

Extract Davis® AI events (optional)

Besides transforming the log line into SDLC events, you can also extract Davis events in case something goes wrong. These events can be used to create an alert or trigger a (remediation) workflow.

1. First, add an event if a build has failed. Add a new “Davis event” processor using the following data:
   • Name: Build Complete Failed
   • Matching condition: matchesPhrase(eventType,"build.complete”) AND result== “build”
   • Event description: Unable to generate build {buildNumber}

Note: You can change the event.type in case you want to increase the severity level.

2. Next, extract a Davis event if the deployment is rejected:
   • Name: Release deployment rejected
   • Matching condition: matchesPhrase(eventType,"ms.vss-release.deployment-completed-event”) AND releaseStatus== “rejected”
   • Event description: Unable to deploy release {releaseName}

Discard logs (optional)

Now that we have successfully converted the log event into a SDLC (Business) and a Davis event, you can disable the storage assignment rule. This will reduce the amount of data stored in Grail and help you saving some money (and consequently speeding up your log queries). Go to OpenPipeline > Logs > Pipelines > AzureDevOps.

1. Open the OpenPipeline app and select the pipeline we created before.
2. Select the tab Storage and change the matching condition to false.

Analyzing data

After deleting the logs events we need to adapt our dashboard to consume business instead of log data. To speed up things you can upload a ready-to-use dashboard into your environment:

1. Go to the AzureDevOps Git Repository and download the AzureDevOps Dashboard (on BizEvents).json file.
2. Within Dynatrace, open the Dashboards, select Upload at the top left corner, and select the JSON file.

Additionally, we recommend that you create a segment to filter all of your monitored entities across different apps.

1. Go to the Segments app and create a new segment by selecting + in the top right corner.
2. Rename the segment to AzureDevOps.
3. Select + Business events and add the following filter: event.provider = AzureDevOps
4. Select + Logs and add the following filter: dt.system.bucket = azure_devops_logs
5. Select Preview to validate the filters and Save once you’re done.

What’s next

By following these steps, you’ll be able to seamlessly integrate Azure DevOps with Dynatrace, enabling efficient log management and insightful data visualization.

Happy monitoring! 🚀

The post Insights into your Azure DevOps pipelines appeared first on Dynatrace news.

Traditional monitoring approaches often require manual scripting and integration to get alerted about production-threatening issues in pre-production environments.
Dynatrace Simple Workflows make this process automatic and frictionless—there is no additional cost for workflows. By offering a single trigger and a single task, you can rapidly set up an action (like Slack or email notifications) to detect specific exceptions in your services. This means fewer surprises when deploying to production and more time spent delivering valuable features.

Why manual alerting falls short

As your product and deployments scale horizontally and vertically, the sheer volume of data makes it impossible for teams to catch every error quickly using manual processes. Your teams want to iterate rapidly but face multiple hurdles:

• Increased complexity: Microservices and container-based apps generate massive logs and metrics.
• Unstructured overview: Manually scanning logs or waiting for someone to notice an error in staging is time-consuming.
• Siloed tooling: Stitching multiple tools and scripts together can create friction and decrease your deployment velocity.

As a result, minor issues in staging can slip into production, leading to potential downtime and a poor user experience. Developers need a way to quickly set up alerts for targeted pre-production exceptions without incurring steep costs or heavy overhead.

Introducing Dynatrace Simple Workflows for early alerting

Dynatrace Simple Workflows helps your team overcome the challenges of manual processes by offering easy, no-cost automation for single-step tasks.

Go to Workflows and start creating a new workflow. By default, the Simple Workflow will be selected to give you the most cost-effective experience.

You can select any trigger that’s available for standard workflows, including schedules, problem triggers, customer event triggers, or on-demand triggers.

After you’ve selected + Workflow, you can name your workflow and select a specific trigger.

Here, you can select a specific event or a timed trigger like a cronjob. Additionally, with an on-demand trigger, you can trigger the workflow through REST API from your CI/CD, scripts, or any other automation flows.

After specifying your trigger, you can select a specific action. This action will be executed each time an event occurs, a timer kicks in, or an on-demand request triggers the action. You can easily send Slack/email messages to your teams, create JIRA issues, or trigger PagerDuty alerts. 

Safeguard your pre-production environments.

Imagine you’re running a busy e-commerce platform composed of multiple containerized microservices running on Kubernetes. Each microservice is responsible for a specific and critical business function—managing user sessions, processing payment and authentication, and tracking inventory.

To orchestrate the different logging services, you use Fluent Bit to forward these logs to your centralized logging system, like Dynatrace.

Recently, in production, your team encountered an out-of-memory error exception that killed all the processes for Fluent Bit. This caused you to lose complete visibility of your containers’ logs, performance, and error data, and you could not tell if the system was down or not.

kubernetes.event.message": "Memory cgroup out of memory: Killed process 1146778 (fluent-bit) total-vm:952432kB, anon-rss:303872kB, file-rss:1108kB, shmem-rss:0kB, UID:1000 pgtables:1424kB oom_score_adj:-997",
kubernetes.event.reason": "OOMKilling",

The error message indicates that the Linux cgroup assigned to your Fluent Bit container has reached its memory limit. Because Kubernetes enforces memory constraints for each pod, the kernel OOM (OutOfMemory) killer forcibly terminates the Fluent Bit process once memory usage exceeds the threshold set in the container/pod specification.

You have fixed the error, and as a follow-up to your RCA documentation, you want to ensure you’re alerted of these errors early on staging, so you want to set up a quick alert on staging for your feature branch.

For this example, we go to Simple Workflows and select Trigger > Davis® event trigger to find these out-of-memory errors. You can learn more about event triggers in Dynatrace Documentation.

When Davis AI event triggers find these, we will set a simple Slack or Email notification for our team so the team can ensure the fix is working and other future changes are caught early.
If you ever need more advanced capabilities—like custom code, multi-step logic, or conditional tasks—you can seamlessly upgrade to standard workflows with just a few clicks.

This ensures you’re never locked into an overly complex or expensive solution before you’re ready. It’s as simple as that!

Deep dive into Simple Workflows

How Simple Workflows work:

• Simple Workflows provide core Dynatrace automation capabilities
• You can use any trigger type, problem-event triggers, schedule-based triggers, or external webhooks.
• They trigger a single, out-of-the-box action: for example, Sending a Slack Notification, Creating a Jira Issue, Sending an Email, or Executing an HTTP Request.
• Unlike multi-step workflows, these don’t consume workflow hours.

Limitations:

• You can’t add more than one task.
• JavaScript actions, task conditions, and options are not allowed.

What’s next for Workflows?

Looking ahead, Dynatrace aims to expand the usability of Simple Workflows with more out-of-the-box actions and deeper integrations.

Both simple and standard workflows will benefit from future improvements like:

• A growing catalog of out-of-the-box actions
• Introduction of draft workflows, enabling you to work on your workflows without impact until you’re satisfied with your changes
• Watch Workflows: Get notifications whenever a workflow fails, is updated, or throttled.

For now, Simple Workflows delivers a fast way for developers and SREs to receive automated alerts—exactly when needed—at no extra cost.

Ready to try Simple Workflows?

Check out the Simple Workflows documentation to explore more use cases. For advanced functionality—like multi-step actions or running JavaScript—it’s free to upgrade to a standard workflow and take advantage of the full Dynatrace AutomationEngine capabilities.

With Simple Workflows, you can quickly eliminate manual monitoring steps, reduce time-to-detection, and keep staging errors where they belong—out of production.

The post Create simple workflows to automate alerts during development appeared first on Dynatrace news.

Dynatrace is proud to be the first AWS global tech partner to offer ready-to-use CloudFormation templates for validating the Well-Architected pillars. The Dynatrace CloudFormation templates are now available in the AWS CloudFormation Public Extensions Registry, which makes Well-Architected validation even more accessible for AWS users.

Dynatrace and the AWS Well-Architected Framework ensure continuous optimization of cloud architecture, aligning with the key pillars of operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability. Our previous blog post discussed the importance of integrating Dynatrace with the AWS Well-Architected Framework to enhance your software development lifecycle (SDLC). By leveraging Dynatrace Workflow Automation and the Site Reliability Guardian, organizations can ensure that their applications meet AWS’s best practices across all pillars.

The Dynatrace CloudFormation templates provide a powerful, easy-to-deploy approach that helps AWS users automate and integrate Dynatrace into their environments with minimal effort. It accelerates the process of validating and optimizing cloud infrastructure.

A quick start for AWS users

AWS users can now benefit from ready-to-use CloudFormation templates that allow for the rapid deployment of Dynatrace workflows designed to validate your cloud architecture against the AWS Well-Architected Framework. These templates are available directly from the AWS CloudFormation Public Extensions Registry, enabling any AWS user to integrate Dynatrace’s observability and release validation capabilities into their infrastructure in just a few steps.

This quick-start approach is especially beneficial for organizations looking to streamline their SDLC and ensure their applications align with the AWS Well-Architected Framework before production deployment. The templates also serve as a foundation for extending workflows, allowing you to tailor the solution to specific business needs and requirements.

Key features of the Dynatrace CloudFormation templates

• Out-of-the-box validation for AWS best practices: These CloudFormation templates automatically provision the necessary Dynatrace resources to continuously validate your infrastructure against AWS Well-Architected Framework pillars. This means you can automatically review your applications for performance efficiency, security, cost optimization, and more.
• Seamless deployment: Once you download them from the AWS Public Extensions Registry, you can deploy these CloudFormation templates with minimal effort. They help teams automate best practice checks and validations in minutes, reducing manual intervention and ensuring faster, more reliable deployments.
• Automation at scale: Using Dynatrace Workflow Automation available through these templates, you can automate the release validation process across your entire AWS environment. This includes vital capabilities such as continuous release validation, automated rollback mechanisms for failed validations, and integration with your CI/CD pipelines for full automation throughout the SDLC.
• Extensible for custom needs: While the templates provide a robust foundation, they’re also extensible. Whether you need to integrate additional validation criteria or customize workflows for specific services, you can easily modify the templates to fit your unique requirements.

Dynatrace CloudFormation templates accelerate the path to production

Implementing the Well-Architected Framework for organizations using AWS is critical to building secure, reliable, and cost-efficient cloud applications. However, this can often be a time-consuming process involving manual validations and checks at multiple stages of the SDLC.

By using the new Dynatrace CloudFormation templates, AWS users can automate the validation of their cloud infrastructure, vetting every release against the core pillars of the AWS Well-Architected Framework before it reaches production. This reduces the risk of performance or security issues and helps organizations adopt cloud-native practices faster by automating tedious manual tasks.

Moreover, because the Site Reliability Guardian is included in these templates, you can continuously monitor and validate essential application metrics like response times, CPU usage, and error rates to verify your application meets its service level objectives (SLOs) before every deployment. This drastically reduces the likelihood of post-release issues and provides peace of mind for development teams.

How to get started with the Dynatrace CloudFormation templates

Getting started with these new CloudFormation templates is easy:

• Access the templates: Head to the AWS CloudFormation Public Extensions Registry and search for the third-party extensions of Dynatrace.
• Deploy the solution: Use the CloudFormation console to deploy the templates in your Dynatrace environment.
• Extend as needed: Once deployed, you can customize the Dynatrace workflow to fit your specific SDLC requirements, adding additional validation criteria or integrating with other AWS services like Lambda, S3, or EC2.
• Monitor and optimize: With Dynatrace now fully integrated, you can continuously monitor application performance, detect anomalies in real- time, and optimize your infrastructure on AWS based on actionable insights.

Streamlining the SDLC

Adding Dynatrace CloudFormation templates in the AWS Public Extensions Registry is a game-changer for organizations looking to streamline their SDLC according to the AWS Well-Architected Framework pillars. With ready-to-use automation workflows, seamless integration into AWS, and the ability to extend and customize the solution, these templates provide a fast, powerful way to improve your cloud applications’ reliability, security, and efficiency.

By leveraging this new capability, AWS users can now automate what was once a manual, error-prone process, confidently accelerating their path to production.

Check out the AWS CloudFormation Public Extensions Registry to get started today and bring Dynatrace-powered validation into your AWS SDLC.

The post Automating AWS Well-Architected Framework validations with Dynatrace CloudFormation templates appeared first on Dynatrace news.

The growing popularity of open source software presents new risks associated with vulnerable libraries. In response, organizations have adopted additional security tools, such as software composition analysis, that scan code libraries for vulnerabilities. These tools enable organizations to mitigate risk earlier in the software development lifecycle (SDLC).

Traditionally, companies tracked these vulnerabilities manually or sifted through volumes of code. Both approaches resulted in lost time and resources. To handle the increasing complexity of open source software, software composition analysis (SCA) has become an important tool. SCA scans software dependencies for security vulnerabilities with speed and reliability.

What is software composition analysis?

Software composition analysis is an application security methodology that tracks and analyzes open source software components. Fundamentally, SCA tools provide insight into open source license limitations and possible vulnerabilities in your projects. These tools help organizations stay abreast of critical tasks, including security, license compliance, and code quality, to minimize risk.

Software composition analysis provides three core capabilities:

1. Build a software bill of materials (SBOM) to establish a detailed inventory of your open source software packages.
2. Verify license compliance requirements by determining what open source software you’re using and where it originated.
3. Discover detailed information about key vulnerabilities in your source code and provide applicable remediation suggestions.

How does software composition analysis work?

SCA tools work by running scans on a code base and creating a vulnerability analysis. The analysis outputs an SBOM that lists software components and their respective licenses. In addition, the scan inspects files to find vulnerable third-party libraries and provides insight into open source dependencies. The technology then compares the SBOM with other vulnerability databases to pinpoint critical vulnerabilities. Finally, an SCA tool offers remediation suggestions to resolve harmful vulnerabilities. As part of the process, SCA provides a full analysis of open source project health metrics.

For example, an organization that needs to establish a comprehensive security and compliance baseline can use software composition analysis to attain baseline license compliance and reveal security vulnerabilities. As teams further develop their code, they can use SCA to maintain license compliances and ensure consistent security.

Why is software composition analysis important?

Software composition analysis is an essential practice for IT professionals tasked with securing complex software ecosystems. Modern software development relies heavily on open source components and third-party libraries, which bring efficiency and robustness to the development process. However, they also introduce unique security, compliance, and risk management challenges.

1. Identifying vulnerabilities:  

Open source components often have inherent vulnerabilities due to their wide usage and public availability of their source code. This makes them attractive targets for bad actors. Without SCA, organizations risk unknowingly deploying software with vulnerabilities and exposing their systems. SCA tools provide automated scans to identify known vulnerabilities in third-party components.

2. Ensuring license compliance:  

Understanding the legal implications of open source software is critical. Many open source licenses come with obligations that organizations must adhere to—like attribution requirements or restrictions on commercial use. Non-compliance can lead to legal disputes, fines, or even the need to re-engineer software. SCA tools help by automatically flagging license issues, ensuring organizations remain compliant.

3. Managing supply chain risks:  

Using external dependencies in software increases the likelihood of inheriting risks from upstream sources. Compromised dependencies can ripple through an organization’s entire software stack. SCA offers visibility into an SBOM, enabling teams to monitor which components are in use and quickly address risks when vulnerabilities are discovered.

By embedding SCA into their development and DevSecOps practices, IT professionals can proactively mitigate risks, maintain compliance, and safeguard their software supply chain. SCA isn’t just a tool—it’s a vital part of protecting modern software systems in an increasingly interconnected world.

The benefits of software composition analysis

Software composition analysis (SCA) offers invaluable benefits to developers and IT professionals committed to creating secure, high-quality software.

Enhanced security

One of SCA’s primary advantages is its ability to enhance software application security. SCA tools automatically scan your codebase to identify open source components and check them against known vulnerability databases.

License compliance

Open source components often come with specific licensing requirements that, if not adhered to, can lead to legal and financial repercussions. SCA tools help ensure compliance by analyzing the licenses of all components within your application, providing insights into potential intellectual property risks.

Improved development efficiency

By integrating SCA into the development lifecycle, teams can automate the vulnerability detection and license compliance process, freeing up valuable resources. This allows developers to focus more on building features and less on manual checks or patching insecure components.

Risk mitigation and quality assurance

SCA contributes to the overall quality assurance of software products. Organizations can ensure their applications are secure and reliable by effectively managing the risks associated with open source components.

The challenges of software composition analysis

Despite its advantages, SCA presents several challenges that must be addressed to utilize its full potential effectively.

1. Managing the volume of open source components

The exponential growth of open source components in software development has led to a significant challenge in cataloging and managing these components within applications. With thousands of new open source libraries being added daily, SCA tools must possess robust indexing and update capabilities to ensure that they provide accurate and up-to-date information.

2. Understanding license compliance

Open source software often comes with complex licensing terms, and noncompliance can lead to legal issues or intellectual property conflicts. Developers and IT professionals must carefully analyze and comply with these licenses, yet navigating the multitude of open source licenses remains daunting. SCA tools must be comprehensive and adept at identifying potential compliance risks.

3. Identifying vulnerabilities

A critical function of SCA is the detection of security vulnerabilities within open source components. However, the sheer volume of potential vulnerabilities makes it challenging to prioritize which issues need immediate attention. False positives can divert resources away from actual threats, necessitating an efficient system for triaging alerts.

4. Integration with CI/CD pipelines

For SCA to be effective, seamless integration into CI/CD pipelines is needed. The process requires careful planning and execution to ensure that SCA tools provide real-time insights without hindering development velocity.

How to implement SCA in your development pipeline

Understanding SCA

Software composition analysis is a methodical approach to managing open source components within a codebase. It identifies vulnerabilities and licensing issues, providing developers with a comprehensive overview of their software’s security posture.

Key steps in implementing SCA

1. Integration into CI/CD pipelines: This allows for real-time monitoring and identification of vulnerabilities as new code is committed.
2. Automated scanning and reporting: These tools analyze the codebase for known vulnerabilities against databases and immediately alert developers to potential risks.
3. Policy management and governance: SCA tools often provide governance features that allow teams to enforce dependency management policies, ensuring compliance with organizational standards and legal requirements.
4. Continuous monitoring and updates: The dynamics of software development mean that vulnerabilities can appear at any time. Continuous monitoring and regular updates to the SCA tool’s vulnerability database guarantee that your security measures stay ahead of emerging threats.

How security can “shift left” in a DevSecOps lifecycle

One of SCA’s major benefits is that security pros can implement it into the initial stages of the SDLC. Teams can test projects for vulnerabilities in the early stages of development before those issues reach the build stage. This saves overall production costs and valuable resources.

Moreover, IT pros can use SCA to gain a better understanding of the open source software the organization uses and to track licenses. Accordingly, SCA tools can streamline the license management process and enforce security and license policies across the different stages of the SDLC.

Finally, SCA tools bridge the gap between detection and remediation by showing the location of vulnerabilities, assessing their impact, and suggesting remediation actions.

But software composition analysis tools alone are not enough

Despite their benefits, SCA tools don’t cover the entire security surface area. For one, SCA tools primarily focus on pre-production environments. This means you’re unable to scan for vulnerabilities exposed in production.

Additionally, although software composition analysis provides remediation suggestions for critical vulnerabilities, it does not prioritize them. As a result, IT pros are left to determine which issue to address first based on the current vulnerabilities and risk priority order. With limited time and resources, it can be difficult for security teams to prioritize vulnerabilities without deeper analysis.

Lastly, SCA tools don’t provide information about which pending issues are the most critical to your business assets. They also provide no context surrounding a vulnerability’s point of origin.

How to pair SCA with runtime application security

Although software composition analysis tools are limited, you can enhance their value by pairing them with another layer of security at runtime.

The Dynatrace Software Intelligence Platform analyzes the full impact and risks of vulnerabilities, in context, at runtime. The Dynatrace Application Security module not only delivers remediation suggestions but also eliminates false positives, prioritizing which critical issues to address first. Dynatrace OneAgent automatically discovers vulnerabilities in both production and pre-production environments, capturing the entire range of possible issues.

By incorporating key contextual information surrounding software vulnerabilities into the Davis Security Score, Dynatrace allows you to filter and prioritize issues to determine which ones your team must remediate immediately. Dynatrace Application Security eliminates blind spots and proactively identifies critical production risks earlier in the process, all to ensure your organization’s SDLC runs seamlessly.

Software composition analysis FAQ

1. What is the difference between SCA and SAST? 

While both improve software security, SCA analyzes third-party and open source dependencies to find vulnerabilities and licensing information. On the other hand, SAST examines your proprietary code to detect flaws such as insecure coding practices or logic errors.

2. What are the benefits of using SCA tools?  

SCA tools provide several benefits, including:

• Automatically detecting open source vulnerabilities
• Ensuring compliance with licensing obligations
• Speeding up the identification of security risks in software
• Offering continuous monitoring for newly reported vulnerabilities

3. What industries require SCA?  

Any industry using open source software can benefit from SCA. However, industries like finance, healthcare, and government, which rely on software for highly sensitive processes, prioritize SCA to reduce security risks.

4. How often should I run SCA scans?  

SCA scans should be integrated throughout the software development lifecycle. Regular scans during development, testing, and maintenance phases are critical to identifying new risks as they emerge.

5. Can SCA help with compliance requirements?  

Yes, SCA helps organizations comply with legal standards and regulations, such as GDPR or intellectual property laws, by validating that open source component licenses align with business requirements.

6. What is the difference between SCA and DAST? 

While SCA examines your software’s dependencies for vulnerabilities, Dynamic Application Security Testing (DAST) tests your application dynamically in a runtime environment to find security weaknesses like injection attacks or misconfigurations.

7. What is an SCA vulnerability? 

An SCA vulnerability is a recognized weakness in third-party or open source components that attackers could exploit.

8. What is “composition” in software testing? 

Composition refers to understanding and managing all dependencies (libraries, frameworks, packages) your software relies on. This involves identifying their origin, versions, and known risks.

9. What is the purpose of SCA? 

The purpose of SCA is security, compliance, and efficiency. It ensures that vulnerabilities in dependencies are mitigated, license risks are addressed, and the software supply chain is safe.

10. How to do a SCA analysis? 

SCA is typically done using specialized tools. These tools automate scanning your dependencies, mapping them to known vulnerabilities, and providing actionable insights for remediation.

The post What is software composition analysis? appeared first on Dynatrace news.

An at-a-glance view of your system’s health and performance

Dynatrace guides you in quickly getting the most valuable service level objectives (SLOs) set up in just a few clicks. To provide maximum freedom in selecting the service-level indicators that matter most to your business, Dynatrace combines SLOs with the power of Dynatrace Grail™ data lakehouse, the central data platform with heterogeneous and contextually linked data. Service-level objectives now utilize highly flexible Dynatrace Query Language (DQL) for all Grail data sources. This lets you build your SLOs around the indicators that matter to you and your customers—critical metrics related to availability, failure rates, request response times, or select logs and business events.

Heterogeneous services require heterogeneous indicators

Metrics, logs, and traces are the core ingredients for making your environment observable. Depending on the environment, the different information types provide indicators that reveal potential problems for your customers.

Having insights into the context and dependencies of such heterogeneous data is essential for seeing the forest, not just the trees. This is where Grail, the Dynatrace central data platform, excels. Grail provides access to contextually linked information with just a few query lines.

It doesn’t matter if you need typically used failure-rate or response-time metrics to ensure your system’s availability and performance or if you need to rely on abnormal log drops to gain insights into raising problems—SLOs leveraged with Grail provide all the information you need.

Are you defining SLOs based on the four golden signals of a critical service? No problem—out-of-the-box templates simplify the setup of time series data based on service requests, and templates can quickly be adapted for more fine-grain needs, for example, to consider only single endpoints.

Do you need to see if selected logs or loglines are missing over time? It’s easy—just use log data, extract the desired information, and create an SLO based on the log format.

Are you experiencing an increase or degradation in certain events that indicate a rising problem? It doesn’t matter if the events are ingested business-related events like deal closures or simple login numbers automatically captured by Dynatrace OneAgent®. Fetch your events, target critical components in your environment, and get notified proactively if your required objectives are at risk.

If you can query something using DQL, you can use it as an indicator for your SLO. The only prerequisite is that the result of the SLI needs to be a time series named sli. The make time series command handles how time series are created from other data types.

Grail, the Dynatrace central data platform, provides the needed information and adds context. With the recently released new SLO capability, you can use Grail and all its information to specify selected SLOs to ensure your critical components meet your expectations now and in the future.

Having service-level objectives for leading and lagging indicators provides a more holistic picture of the status of emerging issues. Setting the SLO on the data types that matter provides a more tailored view of the performance stats and helps limit the number of SLOs to critical items and the most impactful indicators.

SLOs on events, metrics, and logs: How to bring SLOs to the next level

Leveraging Grail, SLOs offer an immersive opportunity to focus your SLOs on user expectations, business goals, and core user journeys. When getting started, this can seem overwhelming, and it’s easy to get lost in the sea of opportunities.

With the latest release, Dynatrace introduces convenient ways to give you a head start with SLOs on all data types. If you have already worked with classic Dynatrace SLOs, most steps will be familiar and easy to follow.

The latest Dynatrace SLO implementation relies on the existing SLO creation wizard templates and provides guided workflows for setting up SLOs with the most commonly used SLIs: service availability, service performance, and CPU utilization.

In the coming weeks and months, we will add to the current collection of templates for synthetic monitoring, digital experience management measures, Kubernetes resource optimization, and infrastructure monitoring. However, all of these can be created today using DQL queries. Simply extract and manipulate your desired time series from Grail within a notebook and copy the query into the SLO definition to get your customized SLO.

Service-level objectives come with a dedicated management overview page, where existing SLOs can be reviewed and modified as needed.

The SLO wizard can be called directly from the management overview or the dashboard using a dedicated shortcut.

An added tagging option simplifies how you interact with your SLOs. Adding ownership information or relevant application boundaries as additional metadata to your SLOs makes it easier for all stakeholders to react or reach out to the appropriate teams in case performance degradations or dependencies are identified.

Dedicated management makes it easy to maintain and run your SLOs, while highly customizable dashboard tiles allow you to integrate SLOs with your health and performance overview stats.

SLOs provide immediate information about critical services’ long-term performance and experiences. Hence, having a dedicated dashboard tile visualizing the key parameters of each SLO simplifies the process of evaluating them.

Automate your SLOs

To manage and evaluate your SLOs at scale, Dynatrace allows you to create, manage, and evaluate your SLOs either via the Dynatrace web UI or API. To implement SLOs in your software delivery cycle and consistently add observability measures from the beginning, Dynatrace configuration as code (Monaco and Dynatrace Terraform) will soon support the new API.

The next step will be improved error-budget burn rate alerting, which Dynatrace Davis® AI root cause analysis can recognize, detecting potential threats to your SLOs before they affect your customers. Additionally, the Dynatrace Automation Engine will leverage SLO alerts to create event-triggered workflows to inform relevant stakeholders, provide reports, or automatically kick off remediation activities.

What’s next

Dynatrace SLOs leverage the power of Grail, providing dedicated SLO management, a user-friendly creation wizard with templates, improved dashboarding options, and an API to interact with the new generation of SLOs. While the SLO management web UI and API are already available, the dashboard tile will be released within the next weeks.

Subsequent improvements will include improved error-budget burn rate alerting and a notification option to proactively inform you when an SLO is at risk. Furthermore, SLOs will find their place within all areas in Dynatrace, making it even easier to create SLOs on demand. At the same time, dedicated configuration-as-code support in Monaco and Terraform will provide a scalable, automated solution.

Get started

Measure what matters most to your business and end-users. Set up your first SLOs and gain insights into relevant and important processes.

We’re eager to hear your experience, feedback, and ideas for improvement. A dedicated feedback channel is set up in the Dynatrace Community. We look forward to hearing from you. Feedback channel for the new service-level objectives app – Dynatrace Community

The new SLOs are available within all Dynatrace SaaS environments and ready for you to try out, beginning with Dynatrace SaaS version 1.303. The new dashboard tiles will be available with version 1.304.

Start setting up your SLOs on indicators that matter to you and your customers

We created a few examples on our Dynatrace Playground tenant so that you can experience the potential and flexibility of SLOs leveraging DQL. You’ll find SLO examples for different data types, such as metrics, events, or logs. You’ll also find examples for entity types like services, synthetic monitors, Kubernetes clusters, and namespaces, and you’ll learn how to use DQL to filter for a selected group of entities or remove specific time periods from SLO-status calculations. Additionally, we set up a sample dashboard that presents an overview of selected critical services and their combined health and performance status aggregated over time.

The post Reliability indicators that matter to your business: SLOs for all data types appeared first on Dynatrace news.

Today, development teams suffer from a lack of automation for time-consuming tasks, the absence of standardization due to an overabundance of tool options, and insufficiently mature DevSecOps processes. This leads to frustrating bottlenecks for developers attempting to build and deliver software. For multinational enterprises, the cost of all that toil, complexity, and frustration multiplies exponentially due to the size of those organizations. In such contexts, platform engineering offers a compelling solution to enable business competitiveness in a manner that significantly enhances the developer experience. A central element of platform engineering teams is a robust Internal Developer Platform (IDP), which encompasses a set of tools, services, and infrastructure that enables developers to build, test, and deploy software applications.

Treating an Internal Developer Platform (IDP) as a product is an emerging paradigm within platform engineering communities. Similar to the observability desired for a request being processed by your digital services, it’s necessary to comprehend the metrics, traces, logs, and events associated with a code change from development through to production. The end-to-end observability of the engineering process becomes essential when building software under product safety legislation, such as medical devices. It’s nearly as crucial as the final product itself when high-frequency releases are critical to the business.

This blog post focuses on pipeline observability as a method for monitoring the software delivery capabilities of an organization’s IDP. This process begins when the developer merges a code change and ends when it is running in a production environment. In other words, pipeline observability encompasses Continuous Integration (CI) and includes Continuous Delivery (CD), as depicted in the following image.

Unlocked use cases

Gaining insights into your pipelines and applying the power of Dynatrace analytics and automation unlocks numerous use cases:

• Make data-driven improvements: Invest in those software delivery capabilities that provide the most significant payoff. To make the right decision, pipeline KPIs can reveal areas for improvement, protect your long-term investment in development, and present stakeholders with the benefits of sustained funding.
• Automate delivery processes: Ideally, an improvement entails introducing automation to eliminate manual tasks, foster collaboration, or speed up processes.
• Ensure pipeline compliance/governance: By obtaining an end-to-end view of the pipeline activities that a code change progresses through, you can identify blind spots that require monitoring and ensure compliance across the entire organization.

Software Development Lifecycle (SDLC) events

The Software Development Lifecycle (SDLC) is similar to the DevSecOps loop as it outlines the various phases a product idea undergoes before it is released into production. These phases must be aligned with security best practices, as discussed in A Beginner`s Guide to DevOps. While the lifecycle starts with a ticket specifying a new product idea, an actual code change often triggers various automated tasks kicking off the next phase. These automation tasks process the code change to build a deployable and create new artifacts accompanying the change throughout the delivery process.

In Dynatrace, examples of such tasks and resulting artifacts include the following, visualized in the below diagram:

• Plan: A ticket for enhancing a platform service is created in Jira.
• Code: The branch for the new feature in a GitHub repository is merged into the main branch.
• Build: GitHub builds the code changes and creates a deployable image.
• Test: Playwright executes end-to-end tests.
• Release:
  • The image is published on Harbor, and the Helm Chart is updated.
  • BlackDuck performs a security and vulnerability check, returning a scan result.
• Deploy:
  • ArgoCD deploys the Helm Chart in a development environment.
  • Synthetic HTTP monitors are executed in the hardening stage.
  • An automation updates a GitOps repository to roll out the artifact to production
• Operate: FlagD switches a feature flag from OFF to ON.

Given these examples, which are a subset of many others, crucial information about a software change and the related component is generated before monitoring begins. Consequently, Dynatrace defines the semantics of essential data points and stores them in a normalized manner. For instance, the Git commit, ticket ID, artifact version, release version, deployment stage, etc., are data points that require special attention. When the semantics of this metadata are well-defined, you can build insightful analytics and robust automation.

The specification defines the new event type SDLC_EVENT, which covers the event category for pipeline and task events. A pipeline can be the parent of multiple tasks to group the resulting events logically. A task event, however, represents the state of a single lifecycle activity like a build, test, deployment, scan, etc. Dynatrace Documentation maintains a list of events, which will grow as we unlock new use cases.

Defining an event standard succeeds through adoption within the ecosystem. This is why we’re aligned with open source initiatives and compatible with the CI/CD specification in OpenTelemetry driven by the CD Foundation. Consequently, your efforts into OpenTelemetry for pipeline observability will be natively supported by Dynatrace.

Generic SDLC event ingest endpoint

Dynatrace introduced a generic SDLC event ingest endpoint that enables data ingestion directly from any third-party CI/CD tool. While this endpoint accepts any JSON payload and adds default properties of the SDLC specification,  OpenPipeline™ is leveraged to process vendor-specific data and extract those properties defined by the specification. GitHub and ArgoCD are the first two tools to receive an OpenPipeline configuration.

The endpoint, together with OpenPipeline, opens a range of use cases, such as:

• Pipeline anomaly visualization on custom dashboards tailored within Dynatrace.
• In-depth analysis of delivery tasks using tools like Notebooks.
• Automated release validation using Dynatrace Site Reliability Guardian.
• Contextualization of third-party CI/CD activities with Dynatrace monitored entities.

Stay tuned

Currently, the API allows for the configuration of an event processing pipeline. Support for managing configuration in the OpenPipline app is a high priority. This will be accompanied by the above-mentioned GitHub and ArgoCD configurations and others to follow.

In some cases, a CI/CD tool’s log line contains important data points that, on their own, eliminate the need to additionally send an event to Dynatrace. Therefore, we’re working on a log processor to automatically extract relevant metadata and generate SDLC events from log lines.

Lastly, we’re working on a ready-made dashboard for the DORA metrics based on GitHub and ArgoCD metadata.

What’s next

• Explore: See the analytics sample in our documentation, which is executable in the playground environment.
• Adopt: Identify your most critical pipelines and make them visible. In other words, leverage the available event ingest endpoint and send pipeline activities to Dynatrace. In many cases, this is possible by leveraging webhook capabilities.
• Fine-tune: Perform data normalization by creating an OpenPipeline configuration that extracts properties according to the SDLC specification.

The post Observability throughout the software development lifecycle increases delivery performance appeared first on Dynatrace news.

Understanding that the first mile of getting data in can often be the hardest, Dynatrace continues to invest in log ingest, offering a range of out-of-the-box solutions within the Dynatrace Platform and apps. We’re excited to announce several log management innovations, including native support for Syslog messages, seamless integration with AWS Firehose, an agentless approach using Kubernetes Platform Monitoring solution with Fluent Bit, a new out-of-the-box ingest dashboard, and OpenPipeline ingest improvements.

These developments open up new use cases, allowing Dynatrace customers to harness even more data for comprehensive AI-driven insights, faster troubleshooting, and improved operational efficiency.

Let’s delve deeper into how these capabilities can transform your observability strategy, starting with our new syslog support.

Native support for Syslog messages

Syslog messages are generated by default in Linux and Unix operating systems, security devices, network devices, and applications such as web servers and databases. Native support for syslog messages extends our infrastructure log support to all Linux/Unix systems and network devices. The more data ingestion channels you provide to the Dynatrace Davis® AI engine, the more comprehensive Dynatrace automated root cause analysis becomes.

Customers can also proactively address issues using Davis AI’s predictive analytics capabilities by analyzing network log content, such as retries or anomalies in performance response times.

Dynatrace natively supports Syslog using ActiveGate (preferred method) or the OpenTelemetry (OTel) collector. Many syslog producers lack authentication and have varying security capabilities, such as TLS encryption. Dynatrace ActiveGate addresses these issues by enforcing configurable security settings and ensuring data uniformity. It also enhances syslog messages with additional context and optimizes network traffic, improving overall system resilience and security. This enhancement lays the foundation for the broader, more integrated observability that Dynatrace continues to expand with each new feature.

Customers have had a positive response to our native syslog implementation, noting its easy setup and efficiency. A $20 billion Germany-based financial services company told us they found the process of pushing Syslog messages to Dynatrace natively to be seamless. Another customer based in Germany, a $23 billion medical technology company, told us they appreciate the value of using a native channel to push syslog messages from network devices directly to Dynatrace, bypassing the need for FluentD or a standalone OpenTelemetry collector.

This streamlined approach enhances both usability and integration, making syslog management simpler and more effective.

Seamless integration with AWS Firehose

Dynatrace is also enhancing our observability logs offerings for AWS services for cloud-native applications. By integrating AWS Firehose into the Dynatrace platform, you can address high-impact issues quickly through real-time, high-frequency log analytics.

This integration with AWS Firehose simplifies observability by removing intermediary components, which allows seamless log capture and analysis directly in the Grail data lakehouse. Logs are immediately available for troubleshooting, security investigations, and auditing, becoming integral to the platform alongside traces and metrics.

Dynatrace supports scalable data ingestion, ensuring your observability infrastructure grows with your cloud environment. The setup is straightforward, using API keys, CloudFormation templates, or the AWS web console.

Dynatrace also provides contextual insights by linking logs to problems detected by Davis AI, enabling quick access to relevant details. The platform also offers proactive analysis through Notebooks for visualizing log data and exploring error rates. Dynatrace support for AWS Firehose includes Lambda logs, Amazon virtual private cloud (VPC) flow logs, S3 logs, and CloudWatch. This seamless integration not only enhances AWS observability but also ties into the greater context of how Dynatrace unifies cloud-native observability across multiple platforms.

Customers have responded enthusiastically to our AWS Firehose implementation. Our approach provides seamless cloud log integrations you can configure directly in the AWS console or through provided CloudFormation templates. This setup eliminates the need for additional middle-layer components, making it straightforward and efficient.

A key advantage of this integration is its high throughput aligned with Grail, ensuring optimal performance. What’s more, logs ingested using AWS Firehose are enriched with cloud context, enabling in-context analysis within the platform. This capability enhances the overall observability and insights that customers can gain from their cloud environments.

Kubernetes Platform Monitoring using Fluent Bit for cloud-native environments

One of the log management innovations we’re excited to share is the new Kubernetes platform monitoring solution with Fluent Bit, offering a cloud-native, API-based deployment model. With this innovation, Dynatrace makes it easier for teams to stream logs from Kubernetes environments into Dynatrace through a more lightweight and streamlined setup, accelerating time to value. Customers get advanced health analytics out of the box and automated root cause analysis by Davis® AI when they ingest Kubernetes workloads, traces, logs, and metrics into the Dynatrace Grail data lakehouse.

For organizations who already use Fluent Bit as part of their tech stack to configure pipelines and enrich log data, this modern approach enables teams to gain answers in context based on logs, powered by the Dynatrace platform’s automation and problem detection. With all data in one place and in context, the new Kubernetes platform monitoring solution provides easy filters by namespace, cluster, workloads, nodes, services, pods, and containers. Integrating with Fluent Bit for Kubernetes log ingestion is important for ensuring teams are capturing critical data for troubleshooting and issue remediation.

Dynatrace enhances Fluent Bit’s log management by integrating observability signals like traces, events, and metrics, providing a complete view of cloud-native application performance. It automates log analysis, eliminates manual correlation, and offers broader visibility through ready-made dashboards and health checks. Log configuration is simplified, while advanced analytics powered by Davis AI bubbles up critical health signals, and provides automated root cause analysis, predictive AI for remediation, generative AI for query writing, performance baselining, and anomaly detection. This innovation ties into the broader effort to simplify and enhance log management across diverse environments, further integrating Kubernetes observability into the Dynatrace ecosystem.

Out-of-the-box logs ingest dashboard

Coming soon is an out-of-the-box logs ingest dashboard that enables you to easily manage your ingest channels.

The dashboard tracks a histogram chart of total storage utilized with logs daily. It also tracks the top five log producers by entity. You can see in a table retention periods by the number of logs and storage they consumed.

The dashboard also breaks down log volume by Grail buckets, showing you what buckets consume the most storage. Grail buckets can help enterprises categorize their logs by retention periods, types of logs such as audit logs, or by organizations that utilize the logs. Think of it like individual bookshelves in a library, where each shelf is dedicated to a specific genre or topic. Just as books are organized on these shelves for easy access and retrieval, data log records are stored in buckets based on their type or purpose, allowing for efficient management and quick querying. This organization ensures that when you need specific information, you can go directly to the relevant shelf or bucket, saving time and effort in finding what you need.

This final piece of the puzzle ensures that your log data is not only easily ingested but also effectively managed, tying together the full spectrum of observability enhancements in the Dynatrace platform. The logs ingest dashboard is currently in tech preview, with GA expected soon. Please follow up with your account team to get early access.

OpenPipeline ingest improvements save money and improve query performance

Lastly, the Dynatrace feature OpenPipeline unifies how we ingest, transform, enrich, and process all observability signals, including logs. This is a significant upgrade to our log processing pipeline capabilities. We now support the following for log ingest:

• Log content up to 512K each
• Log metric counts up to 1000
• Log attributes up to 2.5KB
• Number of log attributes up to 250
• Logs ingestion API payload up to 10MB
• Converting logs into Business Events saves money
• Masking sensitive data
• Setting security context
• Extracting metrics from logs and business events saves money
• Parsing JSON before storing logs in Grail for faster analytics

Customers can save money by converting logs into metrics and business events, which are ingested into predefined buckets, making queries faster without needing to span the entire Grail dataset. This approach also enhances security by allowing customizable security contexts for each log and masking sensitive data before ingestion, while simplifying analytics by pre-parsing JSON. With OpenPipeline, customers can add, remove, rename fields, parse, and mask all incoming logs.

Building on these ingest improvements, these innovations further enhance data analytics and precision by introducing advanced features like OpenPipeline.

Dynatrace log management innovations expand data analytics and precision

Dynatrace continues to lead the way in log management and observability with its latest advancements. By introducing support for syslog messages, AWS Firehose integration, the agentless Fluent Bit setup for Kubernetes environments, a powerful out-of-the-box ingest dashboard and our new OpenPipeline, our customers can achieve deeper insights, faster troubleshooting, and more efficient operations across their hybrid cloud ecosystems. These innovations not only expand the breadth of data available for analysis within the Dynatrace platform but also enhance the precision and effectiveness of our AI-driven capabilities, which results in more actionable, automatable outcomes.

Each of these developments interconnects to create a more comprehensive and powerful observability solution, designed to meet the evolving needs of our customers. As we continue to refine and expand our offerings, our commitment remains focused on empowering organizations to proactively manage their infrastructure and applications with unparalleled clarity and confidence.

We encourage our customers to explore these new capabilities and see how they can further optimize their observability practices.

Try out these new Dynatrace log management innovations

If you’re a customer, go to Dynatrace Playground to check out the new capabilities. If you’re looking into Dynatrace, check out our free trial.

To learn more about these technologies, see details in the following blogs:

• AWS Firehose
• Syslog with AG
• Syslog with OpenTelemetry
• FluentBit logs from Kubernetes
• OpenPipeline

The post From syslog to AWS Firehose: Dynatrace log management innovations that enhance observability appeared first on Dynatrace news.

As recent events have demonstrated, major software outages are an ever-present threat in our increasingly digital world. From business operations to personal communication, the reliance on software and cloud infrastructure is only increasing.

Outages can disrupt services, cause financial losses, and damage brand reputations. Understanding the causes of these outages is crucial for preventing them and ensuring smoother, more reliable tech operations. It’s also critical to have a strategy in place to address these outages, including both documented remediation processes and an observability platform to help you proactively identify and resolve issues to minimize customer and business impact.

How software outages happen

Outages can occur for many reasons, ranging from internal mishaps to external attacks. They may stem from software bugs, cyberattacks, surges in demand, issues with backup processes, network problems, or human errors. Each of these factors can independently cause a major disruption, but often, outages result from a combination of issues. Let’s explore each of these elements and what organizations can do to avoid them.

1. Software bugs

Software bugs and bad code releases are common culprits behind tech outages. These issues can arise from errors in the code, insufficient testing, or unforeseen interactions among software components.

Possible scenarios

• A new software update contains a bug that causes a critical application to crash, disrupting business operations.
• A poorly tested feature release leads to incompatibility issues, resulting in downtime for users.

To prevent outages caused by software bugs, organizations should implement thorough testing procedures, including automated testing and continuous integration practices. Regular code reviews and a robust quality assurance process are also vital to help identify issues before they reach production.

2. Cyberattack

Cyberattacks involve malicious activities aimed at disrupting services, stealing data, or causing damage. These attacks can be orchestrated by hackers, cybercriminals, or even state actors.

Possible scenarios

• A Distributed Denial of Service (DDoS) attack overwhelms servers with traffic, making a website or service unavailable.
• Ransomware encrypts essential data, locking users out of systems and halting operations until a ransom is paid.
• Remote code execution (RCE) vulnerabilities, such as the Log4Shell incident in 2021, allow attackers to run malicious code on a remote system without requiring authentication or user interaction.

To cope with the risk of cyberattacks, companies should implement robust security measures combining proactive preventive measures such as runtime vulnerability analytics, with comprehensive application and perimeter protection through firewalls, intrusion detection systems, and regular security audits. Employee training in cybersecurity best practices and maintaining up-to-date software and systems are also crucial.

3. High demand

Sudden spikes in demand can overwhelm systems that are not designed to handle such loads, leading to outages. This often occurs during major events, promotions, or unexpected surges in usage.

Possible scenarios

• A retail website crashes during a major sale event due to a surge in traffic.
• An online streaming service experiences downtime during the premiere of a highly anticipated show, as too many users try to access it simultaneously.

To manage high demand, companies should invest in scalable infrastructure, load-balancing, and load-scaling technologies. Conducting performance testing and having contingency plans for peak times can help ensure systems remain operational during spikes in usage.

4. Backup process

Failures in the backup process can lead to outages, especially when primary systems fail, and backups do not activate as expected. This can result from improperly configured backups, corrupted data, or insufficient testing.

Possible scenarios

• A data center experiences a power failure, but the backup generators fail to start, leading to prolonged downtime.
• A company tries to restore a system from backups after a cyberattack, only to find the backups are corrupted or incomplete.

It’s critical to regularly perform backup and recovery tests to ensure that systems are properly configured. Companies should ensure they have a range of recovery options in place, including snapshots, replication, and backups to provide a range of RTO and RPO options. A comprehensive DR plan with consistent testing is also critical to ensure that large recoveries work as expected.

5. Network issues

Network issues encompass problems with internet service providers, routers, or other networking equipment. These can be caused by hardware failures, or configuration errors, or external factors like cable cuts.

Possible scenarios

• A major network provider experiences an outage, causing disruptions to services that rely on its infrastructure.
• Misconfigured network settings result in lost connectivity, impacting cloud services and online applications.

To mitigate network issues, organizations should ensure robust network monitoring and management practices. Redundant network paths and automated failover systems can help maintain connectivity during disruptions.

6. Human error

Human error remains one of the leading causes of tech outages. This can include mistakes made during routine maintenance, misconfigurations, or accidental deletions.

Possible scenarios

• An IT technician accidentally deletes a critical database, causing a service outage.
• Incorrectly applied configuration changes lead to system failures and downtime.

Comprehensive training programs and strict change management protocols can help reduce human errors. Automated systems for routine tasks and thorough review processes for critical actions can also minimize the risk of mistakes.

Mitigating the causes of software outages

Understanding the diverse causes of tech outages is essential for developing strategies to prevent them, but it’s just the start. An effective mitigation strategy requires an observability solution that provides a complete end-to-end view of all applications and services. A platform such as Dynatrace enables companies to proactively identify issues, prioritize remediation, and validate that implemented fixes address the underlying issues. This approach minimizes the impact of outages on end users and maximizes the efficiency of IT remediation efforts.

The unfortunate reality is that software outages are common. However, by understanding the root causes of outages and implementing an observability platform, organizations can enhance the reliability and resilience of their technology infrastructure, ensuring continuity and maintaining trust in an increasingly digital world.

Contact us to learn how you can mitigate the causes of software outages in your IT environment to maintain business resilience.

The post Six causes of major software outages–And how to avoid them appeared first on Dynatrace news.