Sharing a long-form write-up of a recent IBM Instana deployment we ran across an estate that combines IBM i (AS/400), DB2 batch, JBoss / Tagetik, SQL Server and IIS - with a focus on the OpenTelemetry pattern that brought batch DB2 jobs into distributed tracing. Three reusable lessons at the bottom. Curious to hear from anyone running similar setups.
The observability conversation in enterprise IT has a blind spot.
Most of the modern literature on application performance management assumes a Kubernetes-first, microservices-first world. Distributed tracing diagrams show OpenTelemetry spans flowing between containers; alerting demos are built around HTTP latency and error rates; the case studies cite tech companies whose entire estate is a few years old.
The reality of mid-to-large European enterprises is different. Modern web frontends and Kubernetes clusters live next to IBM i (AS/400) systems running mission-critical ERP logic that has been production-stable for fifteen years. Microsoft SQL Server transactional databases share the same datacenter as IBM Db2 backends serving batch jobs that nobody has touched since the original architects retired. JBoss application servers running CPM tools like Tagetik talk to all of them, and the integrations are where the failure modes hide.
Most APM tools struggle the moment you have an AS/400 in the picture, or batch jobs that don't have HTTP endpoints. The result is observability silos: one tool for the modern stack, another for the IBM i environment, a third for infrastructure metrics, and zero correlation between them. Mean time to detect anomalies stays high because no single team sees the full picture.
We recently deployed IBM Instana Observability across exactly this kind of estate - Windows, Unix, IIS, SQL Server, JBoss / Tagetik, IBM i, custom Java applications, and DB2 batch - and configured a specific extension that uses OpenTelemetry to bring batch DB2 jobs into the same distributed tracing view as the web layer.
This post is what we learned. Three lessons that I think are reusable for any partner navigating the same kind of legacy-rich enterprise estate.
The customer is a mid-to-large European enterprise running a representative hybrid stack - modern web frontends and Java applications coexisting with mission-critical legacy systems. Specifically:
- Web layer: Microsoft IIS with 13 publicly-facing or internal sites.
- Application layer: JBoss application server hosting CPM workloads (Tagetik / Wolters Kluwer CCH Tagetik 5.3.28.413) plus several custom Java applications.
- Database layer: Microsoft SQL Server as the transactional database for modern apps. IBM Db2 as the backend for legacy batch processes.
- Core systems: IBM i (AS/400) running the gestionale ERP - V7R5M0 with NVMe storage, structured ASP layout, hundreds of active jobs.
- Hosts: A mix of Windows and Unix application servers. Custom Java services and scheduled batch jobs running across them.
Posture pre-progetto: monitoring siloed across three different tools, four different consoles, zero correlation between them. MTTR for cross-layer issues was high because no single team had the full picture. Batch jobs running against DB2 were essentially invisible - only their start/end timestamps and error logs were captured, with no insight into what they actually did between those two points.
Why the obvious tools don't fit
Before settling on Instana we evaluated the alternatives, and I want to be honest about why each was ruled out - none of these tools is bad, they just don't fit this profile of estate.
Cloud-native APM platforms like Datadog, New Relic and Dynatrace - all excellent in modern Kubernetes and microservices contexts - have very limited or no native support for IBM i. OpenTelemetry instrumentation of batch DB2 workloads is not out-of-the-box on any of them; you can do it with custom engineering, but you lose the opinionated tracing UX that makes those platforms attractive in the first place. Pricing also tends to scale opaquely on host count plus telemetry volume, which makes long-term TCO unpredictable on legacy-heavy estates.
Pure infrastructure monitoring like Check_MK, Nagios or Zabbix is the historical answer for legacy-rich estates. It gives you good host metrics - CPU, memory, disk, processes - but no application-level tracing, no distributed correlation, no per-query database visibility. You learn that something is broken, not why it broke.
Best-of-breed mix - running an APM for modern apps, an infrastructure tool for legacy, and a database monitoring tool separately - is what most organizations end up with by accident. The problem isn't the monitoring per layer; it's the lack of correlation across layers. Three teams, three on-call rotations, three sets of dashboards, and no single source of truth when an incident spans the boundary.
Instana wins not because it's the only APM in the market, but because two specific gaps mattered for this estate: the IBM i bridge agent that brings AS/400 metrics into the same backend as everything else, and the OpenTelemetry Collector pattern that makes batch DB2 jobs traceable end-to-end without rewiring the network. Both of those existed in Instana, ready to use.
The architecture
Figure 1 - Full-stack observability architecture: IBM Instana + IBM i bridge + OpenTelemetry Collector
The deployed architecture is layered in the conventional way (hosts → database → applications → web edge), but every layer reports into a single Instana backend with one-second granularity. The pieces that make the architecture distinctive are three.
First, the Instana Agent. A lightweight agent installed on every target host. Auto-discovery brings up sensors for IIS, SQL Server, JBoss and the underlying OS without manual configuration - a real time-saver on Day 1. The agent forwards metrics, logs and traces to the backend, and on most platforms self-updates (a setting we keep enabled).
Second, the IBM i bridge. This is the unique piece. IBM i isn't a host where you can drop a modern Java agent and expect auto-discovery to work; it requires a dedicated bridge component installed on the AS/400 itself, with credentials configured, and a set of explicit metrics published from the OS, the storage subsystem (NVMe + ASP layout), the database (operations, plan cache, commit/rollback rates) and the active jobs. Once it's in, the IBM i side of the estate becomes a first-class citizen of the observability backend - visible, alertable, comparable to the modern stack. Without this bridge, IBM i monitoring stays in its own silo.
Third, the OpenTelemetry Collector for batch DB2. This is the pattern that solved our most painful blind spot. We installed an OpenTelemetry Collector on the same host that already runs the Instana Agent - same machine that launches the batch jobs. The Collector receives traces emitted from the batch processes via OTLP, and forwards them to the Instana Agent, which acts as a native bridge to the backend. No new ports opened to the network, no new firewall rules, no extra infrastructure. The result is that every scheduled job execution becomes a distributed trace in the Instana UI - duration, sequence, every DB2 query that was issued, status of each step.
------------------------------
Roberto Renna
------------------------------