Apica

The Infrastructure Debt Agentic AI Is About to Call In

Andi Mann — Wed, 03 Jun 2026 12:00:05 +0000

I’ve spent more than 20 years building enterprise software, at BMC Software, CA Technologies, Splunk, and now Apica, and one pattern holds across all of it: You do not find out your foundation is wrong during the crisis. You find out when the technical debt comes due. Agentic AI is about to call in a very large debt for a lot of organizations. This week, Apica released findings from a new Omdia research study, commissioned by Apica and fielded by Omdia/Informa TechTarget, surveying 300+ enterprise IT decision-makers across North America and Western Europe. I want to share what the data told us and more importantly, what it means for every organization that has committed to making agentic AI work in production.

The Crisis Is Already Present-Tense

The headline that should stop every CIO in their tracks: 54% of enterprises saw their telemetry data volume triple in the past 12 months. Not in two years. Not as a projection. Right now, in the environments these organizations are running today. The estimated average growth is 3.7x year over year. AI and machine learning workloads now account for approximately 43% of that expansion, making AI the single largest driver of telemetry volume in enterprise environments. And 83% of enterprises rank AI observability as a top priority for 2026, scoring it an 8 or higher on a 10-point scale.

“This is just the beginning of the growth curve. We are at the beginning of the hockey stick.” — Keir Walker, Senior Market Research Analyst, Omdia

Walker is right. The 3.7x growth of the past 12 months is not the peak. It is the warm-up. Because agentic AI hasn’t even arrived at scale yet.

Agentic AI Is the Accelerant. The Numbers Are Staggering.

The finding I keep coming back to, the one that I think every technology leader needs to sit with: Survey respondents anticipate an average 9.5x increase in telemetry data from agentic AI workloads within two years. And 44% expect growth of 6x to 100x. I want to draw your attention to that range, not the average, but the spread. Six times to one hundred times. That is not a forecast; it is an honest admission that nobody can accurately bound this problem. When your most sophisticated enterprise IT leaders cannot put a ceiling on the data volume they expect, that tells you the architecture has to be built for extremes, not averages. Here is what makes it worse: Despite this anticipated surge, nearly two-thirds of organizations are only “somewhat prepared” or worse for the data volumes agentic AI will generate. More than one in five haven’t even considered the data implications.

35% of enterprises report widespread agentic AI deployment — despite the technology having existed as an enterprise category only since 2024.

When I see that number, I think about what it actually means. The Omdia analysts flagged it directly: Organizations claiming broad deployment are reflecting competitive pressure, not genuine infrastructure readiness. Every CEO is saying their company has to be agentic. But the pipelines underneath those agents — the systems that route, filter, govern, and contextualize the telemetry those agents produce — were not built for this moment. The gap is measurable. Organizations unfamiliar with agentic AI are 4.5x less likely to be prepared for the data volumes it generates. The organizations most at risk are the ones least likely to know it.

Observability Costs Have Already Crossed a Line

I have been in technology long enough to know that cost surprises do not come from where you expect them. For agentic AI projects, the surprising cost is not compute. It is not talent. It is observability. The research confirms: In 69% of agentic AI projects, observability costs already exceed compute and infrastructure costs combined. The average enterprise spends $3.17M annually on observability. Nearly 20% exceed $5M. And 81% are actively looking for cost-cutting alternatives — not because they want less visibility, but because legacy platforms cannot sustainably absorb AI-scale data volumes at their current pricing models.

Organizations with 10,000+ employees are 2.8x more likely to spend $5M or more annually on observability, with an estimated average spend of ~$5M at that scale.

Observability budgets are growing 28% year over year on average. For more than a third of enterprises, that growth exceeds 52% annually. Combined with the anticipated 9.5x agentic AI data surge, you have a cost trajectory with no natural ceiling, unless you change the architecture underneath it. The business consequences are already materializing: 59% of organizations have terminated or delayed at least one agentic AI deployment because monitoring costs were too high. The agents most likely to be shelved are not experimental ones — cybersecurity, legal and compliance, and fraud detection top the list of paused use cases, meaning the cost of leaving them unmonitored is measured in business risk, not just IT budget. This is no longer an IT budget conversation. When uncontrolled observability costs are causing organizations to leave AI agents unmonitored or undeployed, you have an enterprise risk management problem. And Torsten Volk from Omdia put it as plainly as I’ve heard it said:

“Scalability is the main reason why people can’t have agentic projects. They have no way of deploying them without exposing themselves to operational, legal, and security risk.” — Torsten Volk, Principal Analyst, Omdia

The Solution Is Already Validated. The Market Just Needs to Move.

Here is what gives me optimism alongside the urgency: The industry has already identified the answer. 54% of enterprises have already implemented a telemetry pipeline solution, and 97% have implemented or are actively evaluating one — confirming the pipeline not as an emerging concept, but as the market’s consensus response to the telemetry data crisis. The performance advantage of pipeline adoption is measurable:

Pipeline adopters are 50% more likely to anticipate, and be prepared for, the scale of data growth agentic AI will demand within 24 months.

Pipeline adopters are 80% more likely to have avoided the operational cost challenges that constrain organizations still in earlier stages of agentic AI deployment.

That second number is the one I find most important. Pipeline adoption is not correlated with readiness by coincidence. It is a defining characteristic of the organizations that have successfully scaled agentic AI. The mature cohort got there, in large part, because they built the pipeline layer first. Pipeline solutions are also delivering across every dimension enterprises care about: multi-cloud and hybrid support (78%), cost reduction (77%), performance at scale (76%), and data quality (76%). These aren’t soft benefits. They are measurable outcomes from architectural decisions that the most advanced enterprises in this study made before the wave hit. The top capabilities buyers are prioritizing in their pipeline evaluation: multi-destination routing (47%), data reduction and sampling (43%), and content-based routing (41%). Every one of those is a core capability of Apica Flow. And nearly 25% of buyers say existing vendor relationships are not a significant factor in their decision. The pipeline evaluation market will be won on capability and thought leadership, not on incumbency.

What Organizations Need to Do Now

The action window is open. 68% of enterprises plan to evaluate changes to their observability solutions within six months. 70% plan to evaluate telemetry pipeline solutions in the same window. The organizations reading this are, in large majority, already in or entering an active evaluation cycle. Based on what the data tells us, and what I’ve seen across 20+ years of enterprise infrastructure, here is what I would tell any technology leader right now:

Audit your current telemetry architecture against the anticipated 9.5x surge. Most legacy architectures were not designed for this. The audit will tell you where the debt is.
Treat observability cost as an enterprise risk metric, not just an IT line item. If cost growth is forcing trade-offs on AI agent coverage, that is a risk conversation for the C-suite.
Evaluate pipeline-first architecture before the action window closes. The data is clear: Organizations that build the pipeline layer first are materially better positioned for the agentic AI scale-up. The 68–70% evaluation window is six months. That is your planning horizon.
Look for vendor-neutral, multi-destination routing capability. The organizations that are winning are not locking themselves to a single observability platform. They are building an intelligent layer that routes, filters, and governs telemetry before it reaches any downstream system.

The Foundation Comes First

In more than 20 years of enterprise technology, the pattern holds: Organizations that pull ahead in transformative technology cycles are the ones that solve the infrastructure problem before it becomes a budget crisis. They build the foundation that lets them scale without re-platforming. For agentic AI, that foundation is a telemetry data pipeline. An intelligent, vendor-neutral layer that routes, filters, enriches, and governs telemetry data before it reaches any observability or analytics platform. Not an alternative to observability investment — the mechanism that makes continued observability investment viable at agentic AI scale. The research we’re releasing today is not a warning about a future problem. It is a measurement of a present one. 300+ enterprise IT decision-makers told us exactly where the gap is, how large it is, and how fast it’s growing.

The window to build the right foundation is open. The data shows it will not stay open long.

Download the full Omdia/Informa TechTarget research report to benchmark your organization’s agentic readiness and see how leading enterprises are closing the gap: https://www.apica.io/state-of-agentic-ready-observability-infrastructure-report-2026/

Why We’re Doubling Down on SI Partners (And What We’re Actually Giving Them)

Matt Wilkinson — Wed, 20 May 2026 12:00:30 +0000

I’ll be honest — when we started building out our partner program, the thing I kept coming back to wasn’t features or pricing. It was a simpler question: what does an SI need to be able to walk into a customer conversation and win?

Because that’s the job, right? Our partners aren’t just resellers. They’re the ones sitting across from a CTO or a VP of Engineering, trying to figure out what’s broken and whether they have something that fixes it. If what we’re giving them doesn’t hold up in that room, none of the rest of it matters.

So when we expanded our SI network — we’re at 10 partners now across North America and Europe — we built the program around two products we genuinely believe fit that test. Flow and Wayfinder.

Flow is the one I get asked about most.

The short version: it’s a telemetry pipeline. But the reason it resonates with SIs is that it isn’t a narrow solution. It works whether a customer is trying to cut their Splunk bill, move off a legacy platform without downtime, route security logs to their SIEM, or get their AI agents clean observability data. Same product, different problem, and it handles all of it.

That’s what makes it repeatable for partners. You’re not selling something that works for one type of customer. You’re bringing something into a conversation that almost always applies.

The OpenTelemetry piece matters too, more than it might sound. OTel is the open-source standard the whole industry is converging on. It’s backed by Google, Microsoft, AWS — basically everyone. Because Flow is OTel-native, it plugs into whatever a customer already has. Our partners don’t have to talk them out of their existing infrastructure. They’re not coming in and saying, “You need to rip this out.” They’re saying, “Here’s how you get more out of what you’ve already got.” That’s a much easier conversation.

We’ve got 200+ integrations built in — Splunk, Datadog, Elastic, Kafka, Prometheus, Loki — and new ones can go live in about a week. The data loss guarantee is real: we call it Never Block, Never Drop. InstaStore handles the spikes. When customers are running AI workloads and telemetry volume is jumping 10x overnight, that stuff matters a lot.

Wayfinder is the second practice area we’re giving partners, and I think it’s underappreciated.

Test data is genuinely painful for enterprise development teams. They wait days, sometimes weeks, for test data from centralized data teams. Their non-production environments are full of production copies that create compliance exposure. The cycle slows down right where it needs to move fast.

Wayfinder fixes that. Self-service, AI-assisted, provisions synthetic data with real referential integrity. No coding required. Teams get what they need in minutes instead of weeks, and you’re not dragging a full production copy into a non-production environment in the process. Storage costs drop 60–80%. Compliance exposure shrinks dramatically.

For an SI, that’s a repeatable story across almost any enterprise running complex testing environments — financial services, healthcare, retail, it doesn’t matter. Any customer running pre-production at scale is a Wayfinder conversation.

The commercial structure is simple. Partners earn commissions on new ACV, renewals, and professional services. Annual subscription model, so there’s recurring revenue, not just a one-time close. We’ve set it up to be as frictionless as possible to build a practice around, with dedicated partner managers and technical enablement included.

We’re not asking partners to take a bet on something speculative here. The use cases are real, and the ROI numbers hold up under scrutiny. Up to 40% TCO reduction on observability costs is a number we stand behind, and the products work in production environments at scale.

The reason we keep growing this network is because the demand is there. Enterprises are trying to figure out how to manage exploding telemetry volumes without their costs exploding with them. That’s the problem we built for. And the right way to reach those customers at scale is through partners who are already in those rooms.

If you’re an SI thinking about where to invest in building a practice, I’d genuinely like to have that conversation. Start at apica.io/partners or reach out directly.

Matt Wilkinson is Chief Operating Officer at Apica.

How Apica Flow Dramatically Reduces Your Splunk Costs in 2026

Apica Marketing — Tue, 12 May 2026 10:18:40 +0000

Your telemetry volume is rising. Your Splunk bill is rising faster.
If this sounds familiar, you’re not alone.

As enterprises scale cloud workloads, microservices, and security instrumentation, Splunk’s pricing complexity has continued to grow under Cisco, with multiple licensing tiers — ingest-based, workload-based, and entity-based — creating ongoing budget uncertainty for customers. Meanwhile, teams are sending more logs, metrics, and traces than ever before. The result? Cost overrun, surprise invoices, and tough decisions about what telemetry you can afford to keep.

But there’s a better way: optimizing your Splunk footprint before data ever reaches the platform.

That’s exactly what Apica Flow was built for.

Apica Flow sits between your data sources and your observability backends, giving you control over what gets sent where.

The Core Problem: You’re Paying Splunk for Data Ingestion You Don’t Need

Most Splunk cost pain comes down to:

1. Too much data is ingested

Developers turn on verbose logging; security adds more instrumentation; every new microservice emits new data streams. Before long, you’re ingesting everything.

2. Splunk’s pricing model punishes unoptimized data, regardless of license type

Whether you’re on ingest-based, workload-based, or entity pricing, the economics are the same: more unfiltered data means more compute, more storage, and higher costs. Under Splunk’s workload model, which measures compute capacity consumed during search and analytics, every noisy log and redundant event burns through your licensed capacity. Flow intercepts data before it reaches Splunk, reducing what gets indexed and processed, which lowers costs across all pricing models.

Even with workload‑based pricing, more data = more indexers, more storage, more compute.

3. You’re sending raw, unfiltered telemetry straight into Splunk

Anything unnecessary—debug logs, duplicate data, redundant fields—costs money.

4. You lack a centralized control plane for telemetry

Different teams ship data independently, with no unified governance.

Apica Flow solves all four.

How Apica Flow Cuts Splunk Costs by up to 40%

Apica Flow is an intelligent telemetry pipeline that reshapes, reduces, routes, and refines your observability data—before it ever hits Splunk.

Here’s how it saves money immediately and ongoing:

1. Intelligent Data Reduction (Without Losing Signal)

Flow processes data at the pipeline layer, before data reaches its destination and applies precision filtering:

Remove duplicate or redundant log lines
Drop noisy event patterns
Exclude rarely used fields
Downsample high‑volume metrics
Apply dynamic filtering rules for peak traffic windows

You send only the data that matters—not everything your systems can produce.

This alone can reduce Splunk ingest by 25–60% depending on your environment.

2. Transform Raw Logs into Cleaner, Cheaper Formats

Splunk charges significantly for heavy, verbose logs. Flow transforms them:

Normalize logs into compact, structured formats
Extract only meaningful fields
Enrich data at the pipeline, eliminating downstream processing
Convert multi‑KB log entries into lightweight, structured events

Cleaner data = smaller ingest footprints = lower Splunk bills.

Flow’s S2S ingest and forward capabilities let you route Splunk traffic intelligently across indexers, with no agent reconfiguration.

3. Route Non‑Critical Data to Cheaper Storage

Not all telemetry needs to land in Splunk.

Flow lets you route data intelligently:

High‑value security and application logs → Splunk
Low‑value logs → object storage like S3 or OCI
Debug or verbose logs → cheaper observability tools
AI/ML telemetry → your data lake or vector database

Splunk becomes a premium destination for only the data that deserves it.

4. Eliminate Agent Sprawl and Shadow Telemetry

When different teams send logs independently, Splunk ingest balloons.

Flow solves this by acting as a central control plane:

Unified pipeline for logs, metrics, and traces
Standardized configurations
Organization‑wide data governance
Enforcement of retention + routing policies

This prevents accidental ingest bloat—one of the top causes of Splunk overages.

5. Full OpenTelemetry Support Future‑Proofs Your Stack

Instead of relying on proprietary Splunk agents, Flow embraces OpenTelemetry, letting you:

Standardize instrumentation across environments
Avoid vendor lock‑in
Reuse telemetry for multiple backends
Migrate or offload Splunk workloads over time

You gain more flexibility and significantly lower long‑term cost exposure.

What This Looks Like in Practice

Before Apica Flow

Splunk invoice growing 25–40% annually
Teams ingesting everything “just in case”
No visibility into data volume drivers
Massive noise in logs, hard to detect real issues
Duplicate ingest across multiple observability tools

After Apica Flow

Up to 40% reduction in Splunk ingest
Predictable spending with guardrails
Unified view of all telemetry dataflows
Better-quality logs with less noise
Freedom to route telemetry anywhere—not just Splunk

Why This Matters in 2026

Splunk’s ecosystem has become more complex and more expensive as organizations move toward AI‑driven security and observability workloads.

At the same time:

Data volumes are increasing exponentially
Teams need real-time insights without paying for unnecessary storage
AI observability models require clean, structured, enriched data
Compliance requirements demand precise data documentation

Apica Flow is the bridge between runaway telemetry growth and sustainable Splunk usage.

It gives you control over your data, cost, and architecture—without compromising visibility, security, or reliability.

A Modern Telemetry Strategy: Splunk + Flow, Not Splunk Alone

Flow doesn’t replace Splunk.

It supercharges it.

You get:

Better signal-to-noise ratio
Lower ingestion and storage costs
More flexible workflows
Faster search performance
Cleaner, more structured data
A future-proofed observability strategy rooted in open standards

If you’re looking to cut Splunk costs without losing observability quality, Flow is the most efficient way to do it.

Ready to See Your Savings?

We can model your Splunk cost reduction in minutes.

Avg daily ingest volume
Storage retention period
Types of data sources
Current Splunk licensing model

We’ll calculate your estimated savings and create a tailored optimization plan.

Is Your Observability Infrastructure Agentic-Ready? What Every IT Leader Needs to Know Now

Mathias Thomsen — Tue, 07 Apr 2026 12:00:21 +0000

AI agents are no longer a pilot program. They’re running in production, shipping code, handling customer interactions, orchestrating workflows, and making operational decisions around the clock. And every one of those agents generates telemetry. Continuously. At machine speed.

Here’s the problem: Your observability infrastructure was built for humans, developers who type queries, engineers who check dashboards, teams that investigate one incident at a time. It was never designed for what’s coming. When you have dozens or hundreds of agents running in parallel, you’re not dealing with a data management challenge. You’re dealing with a data crisis.

The question for IT leaders isn’t whether AI agents will reshape your infrastructure. It’s whether your infrastructure is ready for them.

The Telemetry Explosion Is Already Happening

Traditional observability was architected for a world where humans drove the workload. Engineers queried dashboards. Alerts fired. Humans investigated. That model worked when software changes were measured in weeks and data volumes grew predictably.

Agentic AI breaks every assumption in that model. Agents don’t wait for dashboards. They interrogate data continuously, correlate signals across systems, and execute dozens to hundreds of hypotheses simultaneously, generating orders of magnitude more queries and telemetry output in the process. Research from MIT and the University of Pennsylvania found that generative AI tools are already driving a 13.5% increase in weekly code commits.¹ More code. More deployments. More things to monitor. Multiply that across autonomous agents operating 24/7, and the math becomes uncomfortable quickly.

The enterprise IT community is starting to face this honestly. Legacy observability platforms were optimized for humans typing search terms, not machines running continuous, high-concurrency queries. AI ambition is everywhere. Agentic-ready infrastructure is not. Those two facts are on a collision course.

Why Legacy Observability Breaks at AI Scale

Most organizations running AI workloads today are already straining their observability infrastructure, and they haven’t yet reached full agentic scale. The problems are structural:

Ingest-everything economics. Traditional platforms ingest, index, and store every byte of telemetry. That model was expensive before AI agents. At agentic scale, it’s unsustainable. You end up paying to store massive volumes of low-value data while the signals that matter, model performance, agent decision traces, inference latency, get buried in the noise.
No visibility into agent behavior. AI agents are probabilistic, not deterministic. Without proper instrumentation, you have no way to understand what an agent decided, why it decided it, or what downstream systems it affected. You need feedback loops between what’s happening in production and what you believe is happening. Without observability built for agents, you’re not in control, you’re just hoping.
Data lock-in blocks adaptation. Agentic AI ecosystems are evolving fast. The platforms and models that win today may not be the ones you’re running in 18 months. Closed data formats and proprietary agents mean switching isn’t a procurement decision; it’s a multi-quarter engineering project. Enterprises that lose data control lose the ability to experiment with or adopt rapidly evolving AI models. That’s not a vendor risk. That’s a strategic risk.
Infrastructure at its limits. Most enterprise IT organizations are already running analytics infrastructure near capacity. Telemetry data is growing at roughly 30% annually while budgets remain flat. There is no headroom for the query volume that agentic workloads will generate. Systems that aren’t purpose-built for this scale won’t bend gracefully, they’ll break.

“The time to build the right telemetry infrastructure is before the problem becomes a crisis.”

What “Agentic-Ready” Actually Means

Being agentic-ready isn’t a feature you buy. It’s an architectural posture your organization either has or doesn’t. There are three dimensions that matter:

Pipeline control, not platform dependence. Agentic-ready organizations intercept, enrich, and route telemetry before it reaches expensive platform ingestion. They decide what gets indexed at full cost, what gets tiered to lower-cost storage, and what gets discarded, based on actual value, not default behavior. A vendor-neutral pipeline built on open standards (OpenTelemetry, 200+ integrations) means you’re never beholden to a single destination. You control the data. The platform serves you.
Observability designed for agents, not just humans. Your monitoring infrastructure needs to instrument agent behavior, not just system health. That means tracing agent decision chains, capturing model inputs and outputs, tracking inference latency and error patterns, and correlating agent actions with downstream business impact. Adopting agentic workflows isn’t an overnight transformation. Teams must build the observability scaffolding before they can safely reach autonomous operations.
A switchable stack. The agentic AI landscape is moving faster than enterprise procurement cycles. The organizations that will adapt aren’t the ones who picked the right vendor, they’re the ones who architected so they could swap vendors in days, not quarters. That means open data formats, decoupled storage, and a telemetry pipeline that’s genuinely portable. When your data isn’t trapped inside any single platform, switching is a configuration change, not a migration project.

The Apica Approach: Agentic-Ready Telemetry Management for the AI Era

Apica’s Agentic-Ready telemetry management is built for this moment. It inverts the traditional observability model: Rather than ingesting everything and letting platforms decide what to do with it, Apica processes, transforms, and enriches telemetry in the pipeline, before it reaches expensive platform ingestion. The result is 100% pipeline control with zero data loss.

For AI workloads specifically, this means your agent telemetry, decision traces, model performance signals, inference metrics, gets routed intelligently. High-value signals go to indexed storage for real-time analysis. The rest gets archived at object storage prices using Apica InstaStore. Nothing is lost. Nothing is over-ingested. And your costs scale with value, not volume.

Unlike legacy platform-centric approaches that store everything indiscriminately and charge at every step, Apica’s pipeline-first architecture processes, transforms, enriches, and governs telemetry before it reaches expensive platform ingestion, giving enterprises clean, governed, real-time data without vendor lock-in. Route intelligently. Store cost-efficiently. Enable real-time access for both your human operators and the AI agents that depend on high-quality telemetry to act with confidence.

Four Key Steps to Get Your Observability Agentic-Ready

You don’t have to rebuild everything at once. But you do need to start. Here’s where to focus:

Implement a telemetry pipeline if you don’t have one. A pipeline-first architecture that processes, enriches, and governs telemetry before it reaches expensive platform ingestion is the foundational requirement for operating at agentic scale. Without it, you have no mechanism to control costs, normalize data quality, or give AI agents the clean, real-time signals they need to act with confidence.
Audit your telemetry pipeline for AI readiness. Map where your agent telemetry is going today and how much it’s costing you to get there. Look for proprietary agent dependencies, ingestion-based pricing with no volume ceiling, and closed data formats. These are the chokepoints that will break under agentic scale.
Instrument for agent behavior, not just system health. Add distributed tracing to your AI agent workflows using OpenTelemetry. Capture model inputs, outputs, decision paths, and downstream effects. Build the feedback loops that let you understand and trust what your agents are doing.
Decouple your data from your destinations. A vendor-neutral pipeline built on open standards gives you the flexibility to adopt new AI platforms, swap observability tools, and evolve your stack without engineering heroics. The enterprises succeeding with agentic AI aren’t the ones with the biggest observability budgets, they’re the ones who own their data and control what happens to it at the lowest possible cost.

The Window Is Narrowing

Agentic AI adoption is accelerating faster than most enterprise planning cycles can accommodate. The organizations building agentic-ready infrastructure now will have a structural advantage when the next wave of agents comes online. Those building it reactively will be managing a migration and a production incident at the same time.

The telemetry pipeline is where agentic readiness lives or dies. It’s the connective tissue between your AI ambitions and the infrastructure that has to make them real. Get it right before the agents arrive at scale, not after.

See how Apica’s Agentic Infrastructure gives you 100% pipeline control, built for the scale, speed, and complexity of AI agents. → apica.io

Footnote

Noy & Zhang, “Experimental Evidence on the Productivity Effects of Generative Artificial Intelligence,” MIT/University of Pennsylvania, 2023.

Why Datadog Users Are Turning to Telemetry Pipelines and How Apica Flow Cuts Costs

John Ward — Fri, 27 Mar 2026 15:00:58 +0000

The problem is not Datadog. The problem is what you’re sending to it.

Most engineering teams ingest everything because filtering feels risky. What if you drop something important? So logs flow in unfiltered, labels pile up, and Datadog ingestion costs climb quarter over quarter. The data is there. Your team just won’t use most of it.

That volume problem compounds fast. As your observability stack grows, so does the number of sources, services, and platforms generating telemetry. Without a central point of control, every new integration adds more noise and more cost. Apica Flow gives you that central point. One place to set rules, one place to manage what flows where, one place to keep the whole stack from getting away from you. That kind of control gets harder to build later. Teams that establish it early spend less time firefighting their own data and more time using it.

Apica Flow sits between your log sources and your observability platform, letting you decide what actually gets ingested before the cost is incurred. For Datadog users specifically, that distinction matters. Datadog pricing is tied directly to ingested data volume. Every label you don’t need, every cart service log you don’t read, every Kafka event you’ve never once opened in a live investigation is costing you money.

Filtering after ingestion is too late. Apica Flow filters before.

Apica was named a Visionary in the Gartner® Magic Quadrant for Observability Platforms, 2025 — recognition that reflects both the breadth of the platform and where the market is heading.

[Recognized as a Visionary in the 2025 Gartner Magic Quadrant for Observability Platforms. Learn more at www.apica.io or visit docs.apica.io.]

What a Pipeline Actually Does

The concept is simple. A telemetry pipeline intercepts your log data in motion, applies rules to it, and then forwards only what you want to your downstream platform. Apica Flow handles that process with a visual pipeline builder that does not require custom code or deep infrastructure expertise.

You create a pipeline, give it a name, and then attach rules. The most direct rule for cost reduction is the filter rule. It lets you drop specific labels from individual log entries or exclude entire log classes by service name, severity, message type, or any field using a regular expression. If your cart service logs or Kafka events are not part of your active alerting or investigation workflow, you can exclude them entirely before they reach Datadog.

The pipeline preview feature gives you a real-time view of how your rules affect log output before anything goes live. Fields marked for removal appear crossed out, so you can confirm the effect of your configuration before applying it to production data. You see the output before you commit.

Once the rules are set and the pipeline is active, you attach a forwarder. Apica Flow supports 200+ pre-built integrations, and for Datadog, setup takes a few minutes. Navigate to the integrations tab, add a new forwarder, paste your Datadog API key, and map the forwarder to your active pipeline. Data starts flowing immediately.

What the Numbers Actually Look Like

The difference shows up fast. In testing, applying a filter pipeline to otel demo logs and routing the results to Datadog produced a visible and immediate drop in ingestion volume. The Datadog log ingestion dashboard, viewed over a 24-hour window, showed a clear inflection point the moment pipeline rules were applied. Ingestion volume dropped significantly, not gradually.

That’s what upstream filtering produces at small scale. Apply the same logic to an environment generating hundreds of thousands of logs per day and the savings multiply accordingly. Apica customers who apply pipeline filtering consistently see observability spending drop by 40%. The mechanism is not complicated: you stop paying to store data you were never going to use. The pipeline makes that choice deliberate instead of accidental.

In Apica-observed deployments, teams using upstream filtering have reduced log volume anywhere from 40 to 70 percent depending on how aggressively they configure their rules and how noisy their original data stream was. Most teams start conservative and tighten from there as they build confidence in what they’re dropping.

Cleaner Data, Better Signals

Cost reduction is the obvious win, but cleaner data has a downstream effect worth naming. Noisy telemetry creates problems for any tool that sits on top of it — monitors, alerts, and dashboards all perform better when what they’re reading is accurate and relevant. Filtering upstream with Apica Flow improves the quality of what reaches Datadog, not just the volume. That means fewer false positives, faster root cause analysis, and less time tuning alerting thresholds against data that should never have been ingested in the first place.

Compliance and Data Ownership

One more factor that Datadog-heavy organizations increasingly raise: data sovereignty.

When you route all telemetry directly to a third-party platform, you lose visibility into what data left your environment and when. For organizations subject to the EU Data Act, GDPR, or internal data governance policies, that matters. Apica Flow keeps you in control of what gets forwarded and what stays internal. You own the pipeline configuration. You decide what crosses the boundary.

Compliance requirements around telemetry data are tightening, not loosening. Building a pipeline layer now means you have a governance checkpoint you can audit and adjust as requirements change, rather than scrambling to retrofit controls after the fact.

What Engineers Are Actually Doing With This

The practical use cases coming out of Apica Flow deployments follow a pattern.

Teams start by auditing their most expensive Datadog log sources. They identify which services generate high volume with low investigation value: cart service logs, background job outputs, verbose health check events, Kafka consumer logs for topics that rarely cause incidents. These become the first filter targets.

Then they drop labels. Not every field in a structured log is useful for every downstream purpose. If a label was added for debugging months ago and the issue is long resolved, it does not need to live in Datadog storage. Dropping it reduces per-log weight and ingestion cost without touching the underlying service.

After that, teams refine by severity and message type. Filtering out debug-level events from services that run cleanly is a straightforward way to reduce volume without any risk to incident detection.

The result is a leaner data stream, a lower Datadog bill, and a cleaner environment for every tool that depends on that data.

The Setup Is Not a Project

One thing worth saying directly: this is not a complex infrastructure initiative. Creating a pipeline in Apica Flow, applying filter rules, and routing results to Datadog takes mintes for a single log source. The visual interface does not require scripting. The forwarder setup is a form fill and an API key.

Teams that have been putting off telemetry pipeline work because it seemed like a platform migration are often surprised by how contained the initial implementation is. Start with one log source. See the ingestion drop in your Datadog dashboard. Then expand.

For Datadog users paying on ingestion volume, the math is immediate.

Citations

Apica Flow product page: apica.io/flow/ — 200+ integrations, 40% observability spend reduction
Volume reduction figures reflect Apica-observed customer outcomes, not third-party benchmark
Gartner Magic Quadrant for Observability Platforms, 2025 — Apica named Visionary.

The AI Disruption Your Business Actually Needs to Worry About (And It’s Not Unemployment)

Andi Mann — Wed, 11 Mar 2026 13:11:25 +0000

(And It's Not Unemployment) 9">Last week, a Substack research note from Citrini Research triggered a genuine market selloff. The scenario, a fictional 2028 post-mortem on AI-driven economic collapse, with unemployment at 10% and the S&P down 38%, dominated headlines, investor calls, and LinkedIn feeds for days.

The workforce displacement story is real and worth taking seriously. But if you’re a CIO or CTO sitting with a growing portfolio of AI agents, deployed and in-flight, there’s a more immediate disruption you should be losing sleep over: You probably have no idea what those agents are actually doing.

Meet Your New Blind Spot: Ghost Telemetry

(And It's Not Unemployment) 10" srcset="https://www.apica.io/wp-content/uploads/2026/03/Apica-blog-AI-Disruption-on-page-graphic-3-10-26-300x169.png 300w, https://www.apica.io/wp-content/uploads/2026/03/Apica-blog-AI-Disruption-on-page-graphic-3-10-26-768x432.png 768w, https://www.apica.io/wp-content/uploads/2026/03/Apica-blog-AI-Disruption-on-page-graphic-3-10-26.png 1024w" sizes="(max-width: 300px) 100vw, 300px" />Traditional IT monitoring was designed for a world where applications behave predictably, generate consistent telemetry, and fail in ways your tools were built to detect. AI agents don’t work that way.

A production AI agent executing a multi-step workflow can generate more telemetry in an hour than an entire application stack produced in a day. But volume isn’t the problem. The problem is what we call Ghost Telemetry: Observability data that exists somewhere in your stack, but isn’t governed, indexed, routed, or retained in any useful way. It’s the signal buried in the noise. The audit trail that wasn’t captured. The inference trace that timed out before it reached your monitoring platform.

“When your AI agent makes a decision that affects a customer, a transaction, or a system state, can you replay exactly what it did and why?”

For most enterprises right now, the honest answer is no. And that’s the disruption that keeps operational leaders up at night.

The Ungoverned Pipeline Problem

The Citrini scenario focuses on AI replacing workers. The operational risk facing enterprise IT today is subtler and more immediate: AI agents multiplying across the stack faster than the infrastructure governing them can keep up.Prometheus Tutorial: A Guide for Beginners

Traditional observability platforms weren’t built for this. They ingest everything, charge for everything, and still can’t give you the millisecond-level context that agentic systems demand.

The result is an ungoverned telemetry pipeline, one where:

AI agents generate telemetry that exceeds platform ingestion capacity, forcing teams to drop data
Cost controls kick in and sacrifice visibility into the exact systems that need it most
Compliance obligations around data retention collide with per-GB pricing that makes retention unaffordable
Incidents happen in production AI systems that can’t be investigated because the trace data was never captured

This isn’t a hypothetical. It’s the architecture most enterprises are running into right now as agentic workloads go live.

What “Agentic Ready” Actually Means

Being ready for agentic AI isn’t about having the right model or the right agent framework. It’s about having the infrastructure that can observe, govern, and control what your agents are doing at AI-scale data volumes, in real time, without a platform tax that makes it economically irrational to retain the data you need.

That requires three things:

A control plane that intercepts telemetry from apps, agents, and LLMs before it reaches expensive storage, shaping, filtering, and routing it based on business value rather than ingesting everything blindly.

A safety net that continuously validates agentic workflows end-to-end, catching failures before they reach users or compound across multi-agent systems.

A storage model that makes complete retention economically viable so when something goes wrong with a production AI agent, the audit trail exists and is queryable.

“The real risk isn’t that AI takes your team’s jobs. It’s that AI takes actions in production that you can’t explain, audit, or reverse because the telemetry was never captured.”

The Urgency Is Now

The Citrini scenario describes disruption arriving slowly, then all at once. The same pattern applies to observability debt. AI workloads in POC generate manageable telemetry volumes. Production AI agents generate 10–100x more. The enterprises that wait until the cost and governance crisis is visible will be making architectural decisions under pressure, with limited options.

The time to build the right telemetry infrastructure is before the problem becomes a crisis not after your first ungoverned agent incident ends up in a board-level conversation about AI risk.

See how Apica makes your enterprise Agentic Ready: Control plane, safety net, and zero vendor lock-in. → apica.io

Apica 2.15.2: Sharper Signals, Smoother Workflows

Lori Bertelli — Thu, 26 Feb 2026 13:00:21 +0000

A reliable telemetry pipeline is what makes observability trustworthy and with the release of Apica 2.15.2, we’ve focused on strengthening both. From new forwarding capabilities in Flow to workflow refinements across Synthetics and Observe, this release is about making sure the Apica product suite keeps pace with how your team actually works.

Meet your data where it lives

Apica Flow now supports forwarding filtered data directly into Grafana Loki. If Loki is already part of your stack, you can route exactly the data you need, filtered and refined through Flow, into your existing Grafana environment. No redundant pipelines, no forced consolidation.

More signal, less noise

Precision in your telemetry pipeline starts with data integrity. OTel formatted data now maintains its original structure all the way through ingest so what you send is exactly what Apica works with. Status indicators in the ingest actuator now give you a more precise, real-time view of system state, and search in Observe has been refined to surface more relevant results faster. The pipeline dashboard also loads more consistently, so your metrics are there when you need them.

Workflows that stay out of your way

On the Synthetics side, several improvements make the check creation and management experience more fluid. The scenario debug button is now fully integrated into the browser check creation flow, so you can test as you build without switching contexts. Search and filtering in Manage Checks perform more reliably and legacy private locations display correctly during check management, keeping your full environment visible at a glance.

In Observe, public dashboards have received meaningful UX polish. Headers now sort and interact consistently, navigation between public dashboards and the explorer is seamless, and public viewers see a cleaner, more appropriate interface. In Logs & Insights, pipeline actions are more accessible directly from the pipeline view.

Built for how you work, every release

Not every release introduces a headline feature. Some of the most valuable work is cumulative, refining the experience, tightening consistency, and making sure the Apica product suite keeps pace with the demands of your environment. That’s what Apica 2.15.2 is about.

View the full release notes →

10 Critical Principles for Successful Observability Platform Migrations

John Ward — Mon, 09 Feb 2026 14:30:16 +0000

By John Ward, Solutions Engineer at Apica

Recently, I attended a technical webinar hosted by Datadog and their migration partner NoBS that explored the realities of observability platform migrations. While the session focused on migrating to Datadog, the principles discussed apply universally to any observability platform transition.

Here are the ten critical principles that emerged from the discussion, along with my perspectives on how these insights apply to real-world implementations.

1. Migration Strategy Depends on Your Environment

There’s no one-size-fits-all approach to migration. The webinar outlined three common migration strategies:

Phased Migration (6-12 months): Best for large environments and risk-averse organizations. You migrate one domain at a time, validate functionality, and then proceed to the next. This approach minimizes disruption but extends the timeline.

Big Bang Migration (2-4 months): Requires intensive planning followed by rapid execution. While you run systems in parallel during transition, the actual cutover is swift. This works well for small to medium environments with strong internal teams.

Hybrid Approach (4-8 months): Learn on non-critical systems first, then apply those lessons to critical domains. This strikes a balance for organizations with mixed criticality across their infrastructure.

The key takeaway? Match your migration strategy to your organization’s risk tolerance, team capabilities, and infrastructure complexity.

2. Agent Deployment Should Be Automated

The webinar recommended Ansible for agent deployment, but the broader principle is automation. Manual agent installation across hundreds or thousands of hosts is error-prone and time-consuming.

For organizations already using configuration management tools or fleet management solutions, this phase should leverage existing automation infrastructure. The goal is consistency and speed while maintaining proper version control and rollback capabilities.

3. Auto-Instrumentation Is Your Friend

For APM instrumentation, the presenters recommended auto-instrumentation and noted it’s used about 90% of the time. This makes sense: Manual instrumentation is time-intensive and requires deep application knowledge. Auto-instrumentation gets you observability coverage quickly, and you can always fine-tune with manual instrumentation later for specific use cases.

4. Tagging Strategy Is Foundation, Not Afterthought

Create a comprehensive tagging strategy before you migrate and apply it consistently across all resources. The recommended baseline includes:

Environment (dev, staging, prod)
Service name
Version
Team ownership
Application

These tags enable easier correlation, troubleshooting, and cost allocation later. Retrofitting tags after migration is painful and often incomplete. Get this right from the start.

5. RBAC Setup Protects Your Migration

Role-Based Access Control isn’t just a security concern during migration; it’s a governance mechanism. Properly configured RBAC ensures that only the appropriate teams can make changes, migrate workloads, and access sensitive telemetry data. Set up RBAC rules early so your migration proceeds in a controlled, coordinated manner.

6. Logs Are a Cost Decision

This was the most important insight from the webinar. The presenters were explicit: With Datadog’s pricing model, you must actively decide which logs matter and create a strategy to keep costs under control. Not all logs are created equal, and indiscriminate log ingestion leads to budget overruns.

This represents a fundamental philosophical difference in observability solutions. Some vendors require you to be strategic about what you ingest because pricing is directly tied to data volume. Others, including Apica, offer flat-rate pricing models where you don’t need to agonize over every log line. If a prospect or customer is considering a volume-based platform, it’s worth highlighting this operational overhead: They’ll need to continuously manage which logs get ingested, create exclusion rules, and monitor costs—or risk unexpected bills.

But there’s a third approach that addresses cost concerns without sacrificing observability: Telemetry pipeline solutions like Apica Flow. Flow sits between your data sources and your observability tools, processing, optimizing, and routing data before it reaches its destination. This means you can:

Reduce data volume through intelligent filtering and sampling
Enrich and transform data to maximize value
Route different data types to the most cost-effective storage
Control costs without sacrificing visibility

With Flow, you optimize your data before it ever hits your observability platform, whether that platform charges by volume or offers flat-rate pricing. And when combined with Apica’s flat-rate observability solution, you get both predictable costs and complete control over your telemetry pipeline. No complex triage strategy required.

7. Dashboard Migration Requires Curation

Don’t automatically port every dashboard from your legacy system. This is an opportunity for a fresh start. Many dashboards fall into disuse over time; they were created for a specific incident, experiment, or project that’s no longer relevant.

During migration, ask: “Is this dashboard still necessary? Who uses it? What decisions does it support?” Migrate only what adds value. Your new platform will be cleaner and more useful as a result.

8. Alert Cleanup Is Migration’s Hidden Gift

Similar to dashboards, alerts accumulate over time. Teams create alerts that become noise, get ignored, and then persist because no one wants to be the person who deleted an alert that might have been important.

Migration forces you to evaluate each alert with fresh eyes:

Is this alert critical?
What action should someone take when it fires?
Does this alert still reflect current system architecture?

If an alert doesn’t meet the criteria for actionable, critical monitoring, leave it behind. Your on-call teams will thank you.

9. Legacy Monitoring Patterns May Not Translate

The webinar emphasized that many organizations install agents, recreate legacy dashboards and alerts, and assume their existing monitoring model will translate directly. In practice, this often leads to alert noise, higher costs, and an observability setup that doesn’t reflect how modern systems actually work.

Modern observability approaches offer different capabilities, dynamic baselines, distributed tracing, service maps, anomaly detection, that may render some legacy tools obsolete. Don’t just lift and shift your old patterns. Take advantage of your new platform’s strengths.

The AI Amplification Factor: This challenge is about to intensify dramatically. As organizations deploy AI agents, LLMs, and autonomous systems, these deployments generate 10-100x more telemetry data than traditional applications. According to Gartner, by 2027, 35% of enterprises will see observability costs consume more than 15% of their overall IT operations budget, driven largely by this AI-induced data explosion.

Your migration strategy needs to account for this shift. If you’re building your observability architecture today using patterns from five years ago, you’re not preparing for the scale challenges ahead. Modern telemetry pipelines need to intelligently process, optimize, and route data before it hits your observability platforms, whether you’re running traditional workloads, AI deployments, or (most likely) both.

The organizations that succeed in the agentic AI era won’t just have better observability tools, they’ll have fundamentally different telemetry architectures designed to handle AI-scale data volumes without spiraling costs.

10. Migration Is About Modernization, Not Just Movement

The overarching theme of the webinar was that successful migration isn’t just about moving tools; it’s about rethinking your observability practice. This is your chance to eliminate technical debt, adopt better practices, and align your monitoring with how your systems actually operate today.

Ask yourself:

What telemetry is worth migrating, and what should we leave behind?
How can we reduce noise and accelerate time to value?
What pitfalls exist across our cloud, Kubernetes, and hybrid environments?
How do we sequence tagging, dashboards, alerts, and SLOs correctly?
Are we building a telemetry architecture that can handle AI-scale data volumes?
Do we have a strategy to control costs as data volumes increase 10-100x?

That last question is critical. Migration projects often focus on the immediate technical transition, but the best migrations also prepare for what’s coming next. If your organization is deploying, or planning to deploy, AI agents, LLMs, or autonomous systems, your telemetry architecture needs to account for the data explosion these technologies create.

Final Thoughts

Migrating to a new observability solution is never trivial, but with the right approach, it becomes an opportunity for meaningful improvement. Whether you’re migrating to Datadog, Apica, or any other vendor, these ten principles provide a solid foundation for success.

The organizations that struggle with migration are those that treat it as a technical checkbox: Install the agent, recreate alerts, done. The organizations that thrive are those that use migration as a forcing function to modernize their observability practice, eliminate cruft, and build something better than what they had before.

And in 2025 and beyond, “building something better” increasingly means building something that can scale. The telemetry data volumes from AI deployments aren’t a distant future concern; they’re happening now. Organizations that design their telemetry architecture with this growth in mind will avoid having to migrate again in two years when their costs spiral out of control.

If you’re planning an observability migration and want to discuss strategies for your specific environment, I’d be happy to connect. Feel free to reach out.

About the Webinar: “Accelerate to Observability: Migration Modernized with Datadog & NoBS” was held on January 28, 2025, as a practitioner-level technical session for engineers and operators responsible for reliability, performance, or leading migrations.

About the Author: We’ll add John’s bio here.

Self-Assessment: Calculate Your Telemetry Pipeline Readiness Score

Bruno Murati — Tue, 27 Jan 2026 12:17:26 +0000

You’ve recognized the phases organizations go through. You understand the critical preparation steps. But how do you know if you’re actually ready for a centralized telemetry pipeline right now?

This self-assessment framework will help you gauge your readiness across six dimensions. Be brutally honest with your answers—the goal isn’t to justify a decision you’ve already made, but to understand where you actually are and what that means for your next steps.

How to Use This Assessment

For each of the six dimensions below, count how many statements are true for your organization. Each dimension is scored out of 8 points, for a maximum total score of 48 points.

The higher your score, the more you’re paying a “complexity tax” that a centralized pipeline could address. But remember: a low score doesn’t mean you’re doing something wrong—it means your current approach is still working.

1. Cost & Economics (Score: /8)

☐ Observability/telemetry is a top-5 infrastructure cost

☐ Costs are growing faster than we can explain

☐ Teams lack visibility into what their telemetry actually costs

☐ We’ve rejected instrumentation improvements due to cost concerns

☐ Cost attribution to teams or services is manual or impossible

☐ Finance regularly questions observability spending

☐ We’ve hit budget constraints that limit our ability to instrument new services

☐ Cost optimization requires engineering time we don’t have

2. Technical Complexity (Score: /8)

☐ Telemetry flows through multiple hops or transformations

☐ We run DIY routing, sampling, or enrichment logic

☐ Changes require coordination across multiple teams

☐ We maintain different pipelines for different signal types

☐ Multiple telemetry agents or collectors are deployed across infrastructure

☐ Data format transformations happen in multiple places

☐ Testing telemetry changes is difficult or impossible

☐ Our telemetry architecture is documented in multiple places (or not at all)

3. Knowledge & Maintainability (Score: /8)

☐ Only 1–3 people understand the full telemetry flow

☐ Config exists across many repos, files, or tools

☐ Onboarding new engineers to telemetry takes weeks

☐ The people who understand the pipeline are single points of failure

☐ Telemetry configuration lacks version control or review processes

☐ Troubleshooting telemetry issues requires deep tribal knowledge

☐ Changes to telemetry infrastructure feel risky

☐ Documentation is outdated or incomplete

4. Operational & Reliability Risk (Score: /8)

☐ Telemetry loss or delay has caused missed or delayed incident response

☐ Limited visibility into pipeline health itself

☐ Backpressure, queueing, or overload behavior is poorly understood

☐ During incidents, telemetry reliability is assumed, not verified

☐ We’ve experienced telemetry-related outages or degradations

☐ No SLAs or SLOs exist for telemetry delivery

☐ Rollback procedures for telemetry changes are unclear or untested

☐ Telemetry infrastructure lacks proper monitoring and alerting

5. Governance, Security & Compliance (Score: /8)

☐ We handle regulated or sensitive data and rely on teams to “do the right thing”

☐ Redaction, filtering, or enrichment rules differ across environments

☐ Proving compliance requires manual explanation, not enforced policy

☐ Security teams want stronger guarantees than “trust the config”

☐ Data residency or sovereignty requirements are difficult to enforce

☐ PII or sensitive data handling is inconsistent

☐ Audit trails for telemetry policy changes are incomplete

☐ Compliance teams have raised concerns about telemetry data handling

6. Change Velocity & Organizational Scale (Score: /8)

☐ Multiple teams independently change instrumentation

☐ Platform or SRE teams are asked to “just make telemetry work”

☐ Onboarding new teams or acquisitions into observability is slow

☐ We want more control without slowing teams down

☐ Telemetry decisions require extensive cross-team coordination

☐ Different teams use different instrumentation approaches

☐ Standardization efforts have stalled due to complexity

☐ We struggle to maintain consistency as the organization grows

Interpreting Your Score

0–15 points: Keep It Simple

DIY remains rational. You’re not yet paying a significant complexity tax. Resist the urge to over-engineer. Focus on standardizing data formats and basic governance before considering centralized platforms.

Recommended action: Revisit this assessment in 6–12 months or after major growth, tool changes, or M&A activity.

16–30 points: The Danger Zone

You’re in the danger zone. DIY still works, but friction is growing. This is when exploration makes sense—not necessarily buying, but understanding what’s available and what preparation would look like.

Recommended action: Start documenting hidden costs in engineering time, incident risk, and migration drag. Begin working through the 10-point checklist from our previous post. Talk to vendors or evaluate build options, but don’t commit yet.

31–45 points: Past the Threshold

You’ve crossed the complexity threshold. Telemetry is now infrastructure, not just tooling. The question isn’t whether you need pipeline abstraction, but whether to build it properly in-house or externalize it.

Recommended action: Invest serious time in the checklist. The quality of your preparation will determine success. Evaluate build vs. buy with ruthless ROI criteria. Consider the total cost of ownership, not just license fees.

41–48 points: Already Paying the Tax

You’re already running a homegrown pipeline company inside your company—the cost just isn’t on a single invoice. Every day you wait, you’re paying in engineering time, incident risk, and missed opportunities.

Recommended action: Evaluate whether externalizing this burden would reduce operational risk and increase change velocity. Make this a leadership priority, not just a technical project. Be ruthless about total cost of ownership comparisons.

Understanding Your Results and Next Steps

Your score provides a snapshot of where you are, but the real question is: what should you do next?

If you scored 0-15 points: You’re not yet paying a significant complexity tax. Focus on standardizing data formats and establishing basic governance practices before considering centralized platforms. Revisit this assessment in 6-12 months or after major organizational changes like rapid growth, M&A activity, or significant tool additions.

If you scored 16-30 points: DIY still works, but friction is growing. This is the right time to start documenting the hidden costs—engineering time spent on telemetry optimization, incident delays caused by pipeline issues, and the opportunity cost of not investing that effort into core business value. Begin exploring what’s available, but focus on solutions that optimize your existing tools rather than forcing you to replace them.

If you scored 31-40 points: You’ve crossed the complexity threshold where telemetry has become infrastructure, not just tooling. The question isn’t whether you need pipeline abstraction, but whether to build it properly in-house or externalize it. Prioritize solutions that offer vendor neutrality, complete data ownership, and proven cost reduction. Be ruthless about total cost of ownership comparisons—include engineering time, incident risk, and migration costs in your calculations.

If you scored 41-48 points: You’re already paying the tax. You’re running a homegrown pipeline company inside your company—the cost just isn’t on a single invoice. Every day you wait, you’re paying in engineering time, incident risk, and missed opportunities. Focus on solutions with elastic scaling, infinite buffering, and architectures designed to prevent data loss during migration and traffic spikes. Make this a leadership priority, not just a technical project.

The Bottom Line

A centralized telemetry pipeline is not about better technology; it’s about who carries the operational burden. The decision should be driven by clear pain points, quantifiable objectives, and an honest assessment of your organization’s readiness. If you’re not ready yet, don’t buy. Keep things boring and simple. The pipeline will still be there when complexity catches up. If you are ready, approach the decision with the rigor it deserves. A well-implemented pipeline reduces cost, increases reliability, and accelerates innovation. A poorly implemented one becomes yet another layer of complexity to manage. Use this assessment to make the right decision for your organization, at the right time, for the right reasons.

About This Assessment

This self-assessment framework is based on common challenges documented in observability industry research and patterns observed across hundreds of enterprise telemetry pipeline implementations.

Learn more about Apica Flow telemetry pipeline here: https://www.apica.io/flow/

The Telemetry Pipeline Buyer’s Checklist: 10 Critical Steps

Bruno Murati — Mon, 19 Jan 2026 11:07:38 +0000

So you’ve decided a centralized telemetry pipeline might be right for your organization. Before you start evaluating vendors or building an internal solution, there’s critical preparation work that will determine whether your implementation succeeds or becomes yet another layer of complexity.

This checklist covers the 10 essential steps organizations must take before implementing a telemetry pipeline. Skip these, and you’ll likely end up with an expensive piece of infrastructure that solves the wrong problems.

1. Define Clear, Quantifiable Objectives

Before evaluating vendors, get brutally clear on why you need a centralized pipeline.

Strong reasons include:

Reducing ingest and storage costs by a specific percentage, achieving vendor independence through OpenTelemetry adoption, establishing central governance over data policies, controlling telemetry volume and quality from one location, or enabling multi-destination routing without duplicating agents. Avoid vendor lock-in by maintaining complete data ownership and the flexibility to route to any destination.

Red flags to avoid:

“Everyone else is doing it,” “Our vendor recommended it,” or “We want to modernize.”

If you cannot quantify at least one outcome, adoption will likely stall.

2. Conduct a Comprehensive Telemetry Inventory

Treat this like a financial audit, not a technical exercise. Most organizations don’t know what data they generate, who owns it, why it exists, or who actually uses it.

For each signal type (logs, metrics, traces), document: source (service, platform, network, security, mainframe, IoT), daily volume, cost per destination, consumer (SRE, SecOps, application teams, compliance), retention requirements, and business criticality.

This inventory typically surfaces 20–40% of data that can be eliminated or reduced, though industry reports suggest as much as 75% of ingested telemetry goes unused in many organizations. If this exercise feels painful, that’s exactly why you need a pipeline.

3. Define Edge vs. Central Processing Boundaries

Centralized doesn’t mean everything flows through one box.

Determine upfront what stays at the edge (crash protection, minimal sampling, fail-safe buffering) and what moves to the central pipeline (policy-based reduction, routing, enrichment, normalization).

Trying to centralize everything immediately is how pipelines become single points of failure.

4. Standardize Data Formats, Not Tools

You don’t need to standardize vendors first; you need to standardize data shape.

Essential standards to establish:

Log structure (JSON, consistent field naming), metric naming conventions, trace attributes, and resource metadata (service.name, environment, region, owner).

OpenTelemetry provides an excellent baseline, but the key is schema discipline. If every team sends different shapes of data, your pipeline becomes a trash compactor. The goal is standardized data shapes and vendor-neutral formats that give you freedom to route telemetry anywhere without proprietary lock-in.

5. Establish Telemetry Policies as Code

Write explicit policies before adoption: What log levels are allowed in production? What sampling rates apply to different services? Which data contains PII and requires redaction? What routes to SIEM vs. observability vs. cold storage? What data is forbidden entirely?

Your policies must be:

Versioned in source control, reviewable through standard processes, testable before deployment, and rollback-safe.

If these rules live in tribal knowledge or Slack threads, a centralized pipeline will expose the chaos instead of fixing it.

6. Assign Clear Ownership and Accountability

A centralized pipeline will fail if ownership is fuzzy.

You need a designated platform owner (typically Platform Engineering or Observability team) and a clear RACI matrix between app teams, SRE, SecOps, Compliance, and Finance.

Someone must own cost outcomes, policy enforcement, pipeline reliability, and change management. If no one owns these responsibilities, the pipeline becomes “someone else’s problem.”

7. Prepare for Organizational Change

Central pipelines change power dynamics, and you need to prepare teams psychologically, not just technically.

Be transparent about changes:

Application teams will have less unlimited data freedom, security teams gain stronger enforcement leverage, finance will have visibility into cost drivers, and SRE becomes a gatekeeper for telemetry decisions.

Without early communication and clear visibility into decisions, teams will bypass the pipeline and reintroduce shadow agents. Adoption failure is usually political, not technical.

8. Build Observability Into the Pipeline Before Enforcement

The fastest way to lose trust: “We dropped your logs. Trust us.”

Before enforcing policies, implement visibility into what data is being dropped and why, clear attribution showing which policies are affecting which teams, self-service dashboards for teams to understand their telemetry flow, and feedback loops so teams can challenge or refine policies.

Transparency builds trust. Opacity breeds rebellion.

9. Start with Limited Scope and Iterate

Avoid the temptation to migrate everything at once.

Begin with a single team or service as a pilot, non-critical data types first, clear success criteria and feedback mechanisms, and documented learnings to inform broader rollout.

Gradual adoption allows you to refine policies, validate assumptions, and build organizational confidence before expanding scope.

10. Evaluate Total Cost of Ownership, Not Just License Price

Pipeline costs extend far beyond the vendor invoice.

Consider:

Engineering time for maintaining configurations, troubleshooting issues, and handling migrations. Incident risk—what happens when telemetry is lost or delayed? Knowledge concentration—how many people understand the full data flow? Migration drag—how difficult is it to change backends or adopt new tools? Compliance exposure—can you prove data handling meets regulatory requirements?

A DIY approach might appear free, but you’re already paying in hidden costs.

Modern purpose-built pipelines can reduce total observability costs by 30-40% while simultaneously increasing reliability through features like infinite buffering that prevent data loss during traffic spikes or destination outages. The question isn’t whether you can afford a pipeline solution—it’s whether you can afford to keep running a homegrown pipeline operation inside your organization.

What’s Next?

Now that you understand what preparation looks like, how do you know if you’re actually ready? In our final post, we’ll provide a comprehensive self-assessment scoring framework across six critical dimensions: cost and economics, technical complexity, knowledge and maintainability, operational risk, governance and compliance, and organizational scale.

This assessment will help you determine whether you should keep your telemetry infrastructure simple, start exploring options, or immediately evaluate alternatives. The scoring framework is designed to be brutally honest about where you are—and what that means for your next steps.

Learn more about Apica Flow and cost savings here: https://www.apica.io/cost-savings/