Hi Brad, we wanted to use O11y for this POC, here is what we are evaluating for this use case: 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. [7] 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. [8, 9] What do you think about those options?
... View more