topic UnityBase (native ELF + SpiderMonkey) + Dynatrace OneAgent: Technology=Other, no deep monitoring - any supported approach? in Open Q&A

UnityBase (native ELF + SpiderMonkey) + Dynatrace OneAgent: Technology=Other, no deep monitoring - any supported approach?

M_Lishafaiev — Tue, 27 Jan 2026 07:35:44 GMT

Hi community,
We’re trying to monitor UnityBase (UB) with Dynatrace and looking for advice / similar cases.

What is UB (short): Enterprise backend/application platform. Runs as a native Linux executable (ELF) and executes server-side business logic via an embedded SpiderMonkey JavaScript engine (not Node.js).

Setup

UB runs as native Linux ELF, started via systemd
OneAgent Full-stack installed; injection into the UB process is confirmed
Data is sent via ActiveGate (works)
UB in production talks to Oracle

Issue

UB process group is detected as Technology: Other
Deep monitoring shows: “No OneAgent modules are currently connected…”
We only get host/process metrics; no automatic services/requests/transactions

Goal
APM-like visibility: requests/operations, errors, and ideally end-to-end tracing UB → Oracle.

Questions

Has anyone monitored UnityBase (or a similar native server with embedded JS runtime) with Dynatrace?
Is there any Dynatrace-supported way to get request/transaction visibility for such “Other” processes without major refactoring?
Would you recommend OpenTelemetry (OTLP ingest to Dynatrace) or Dynatrace OneAgent SDK (native) here? Any best practices?
If OpenTelemetry is the path: preferred architecture — OTel Collector next to the app vs ActiveGate OTLP ingest?

Thanks!

Re: UnityBase (native ELF + SpiderMonkey) + Dynatrace OneAgent: Technology=Other, no deep monitoring - any supported approach?

t_pawlak — Sun, 25 Jan 2026 12:24:46 GMT

Hi,

As far as I know, with a native ELF server running an embedded SpiderMonkey JS engine (not Node.js), Dynatrace usually has no supported code module for automatic APM. That’s why the process shows up as Technology: Other, and you only get host/process metrics. To get requests/transactions/traces, you need explicit instrumentation.

In my opinion, you have two options:

1. SDK - Dynatrace’s supported option for technologies without a code module, but it requires code changes (in UB or a request-handling layer). You create tracers (for example, custom service tracers) around request entry points, key operations, and DB calls.
OneAgent SDK
Specifically for C:
OneAgent-SDK-for-C

2. OpenTelemetry instrument the app (for example with OTel C/C++) and export spans/metrics/logs via OTLP into Dynatrace. Dynatrace documents OTel ingest and OTLP endpoints, including routing through an Environment ActiveGate.
If you use OTel, a local OpenTelemetry Collector next to the app is usually preferred (buffering, retries, processing/transformations), and then you export to Dynatrace/ActiveGate
OpenTelemetry and Dynatrace and you mainly need to allow the OTLP endpoints in the firewall:l https://docs.dynatrace.com/docs/ingest-from/opentelemetry/otlp-api
Without code instrumentation inside UB, you won’t get true APM-style request visibility—only indirect approaches (like logs and derived metrics) are feasible.