Hey javier — your breakdown is solid, and you've landed on the right primary path. Option 1 (the C++ wrapper) is the one that actually gets you COBOL-level visibility in APM, because it's the only approach that creates spans from inside the ACUCOBOL runtime. Option 2 is real but complementary — the Java agent only sees the JVM boundary, so it captures a Java tier and its DB calls, not what's happening inside your COBOL programs. I'd build Option 1 and treat Option 2 as a bonus if you already have a Java front end.
A few things I'd lock in before writing much code:
- Export through a local Collector, not straight to Splunk. Point your C++ wrapper's OTLP exporter at a local Splunk OTel Collector (OTLP gRPC 4317 / HTTP 4318) and let the Collector hold the access token, batch, add resource attributes, and forward to APM. That's exactly your step 4, and it keeps secrets and retry logic off your COBOL hosts. You can bypass the collector and hit the ingest endpoint directly if you must, but I wouldn't for a first build.
- service.name is everything in APM. Whatever you set as the service.name resource attribute becomes the box on the APM service map, so set it deliberately (one service per COBOL app is a sane start), and add deployment.environment so you can filter prod vs test.
- Model spans to your code. Program = span, paragraph/section = child span or span event, transaction/batch id as attributes. Set span status to error on abends so failures surface. If this COBOL is called by or calls other instrumented services, propagate W3C traceparent so the spans stitch into the same distributed trace instead of standing alone.
One correction on the interop: CALL "C$SYSTEM" runs an OS command — it's not the hook for invoking your wrapper. What you want is ACUCOBOL-GT's C subroutine interface: expose your functions with a C ABI (extern "C" so the names aren't C++-mangled), make them callable from the runtime, then CALL "start_span" etc. from COBOL. The "Interoperating with C" section of the AcuCOBOL-GT (OpenText/Micro Focus) docs covers the linkage and parameter passing.
The gotcha that bites people: the batch span processor buffers, so on a short-lived batch run you'll lose spans unless you explicitly flush/shut down the tracer provider at program exit. Init the provider once per runtime process and shut it down cleanly on the way out. And don't span every paragraph if volume is high — instrument at meaningful boundaries (program entry/exit, transactions, DB calls) or you'll drown in overhead and cardinality.
How I'd actually get started, smallest provable steps first:
- Stand up the Splunk OTel Collector locally with OTLP receivers and confirm it forwards to your APM (send a throwaway test span with otel-cli first).
- Build a minimal extern "C" wrapper over the C++ SDK: init plus one start_span/end_span, service.name set, exporter pointed at the local collector. Prove a single hand-made span lands in APM.
- Wire the CALL interop from a tiny COBOL test program, one span per run. Confirm the service shows on the map.
- Expand: attributes, child spans, error status, then traceparent propagation if you're multi-service.
- Add metrics last. Traces are the APM payoff; the C++ metrics SDK works, but get tracing solid first, and you can always push metrics over OTLP to the same collector.
On Option 2: if any COBOL is already fronted by Java (web services, Acu4GL through a JVM), attaching the Splunk Java agent there is basically free APM for that tier and its JDBC calls. Just note APM only sees the DB dependency if the driver runs inside that instrumented JVM — if Acu4GL talks to the database natively from the COBOL runtime, the Java agent won't see it, so that visibility still has to come from your Option 1 spans.
Happy to keep going on the thread — better to keep it public so it helps the next person who tries this. For real-time back-and-forth there's the Splunk community #observability Slack, and for a production COBOL rollout it's worth looping in Splunk PS or a partner SE.
Docs:
What does the COBOL runtime look like — standalone batch, or fronted by a service tier? That changes whether you need traceparent propagation from day one.
