Hi, we are trying to implement a custom OpenTelemetry integration for ACU COBOL software. We want to sent traces and metrics to a Spunk Observability instance and visualize the data on APM. We already know there is no OpenTelemetry SDK for COBOL, so we are exploring the following options. Option 1: Manual Instrumentation via C-Interop (Traces & APM) The most robust approach to populate Splunk APM maps is to leverage ACUCOBOL’s ability to call external C/C++ libraries. Leverage the OpenTelemetry C++ SDK: Build a small, specialized intermediate shared library (.dll or .so) using the OpenTelemetry C++ SDK. Expose Lifecycle Functions: Create C functions inside your wrapper to initialize a tracer, start a span, add attributes (such as paragraph or program names), and close a span. Invoke via COBOL CALL: Use standard ACUCOBOL interop verbs or the CALL "C$SYSTEM" interface to call your custom C wrapper at critical entry/exit points of your COBOL programs. Export Telemetry: The OTel C++ wrapper will stream the generated trace spans directly to your local Splunk OpenTelemetry Collector. Option 2: Java Wrapper & Acu4GL Interfacing (Traces & Metrics) If your ACUCOBOL 10.5.1 application relies heavily on modern modernization extensions or database modules, you can route tracking through a Java subsystem: Use the Splunk Java OTel Agent: If you wrap or trigger your COBOL logic from a Java application (such as an enterprise web service), you can attach the standard Splunk Java OpenTelemetry agent to that JVM. Database Tracking via Acu4GL: If your COBOL logic interacts with a relational database using Acu4GL, ensure the database driver calls are monitored from the database/Java side. Splunk APM will automatically visualize the database dependencies as separate remote service spans. For anyone experienced in developing custom OTel integrations: How would you proceed to get started over those implementations? Can we contact you to talk about this?
... View more