Dynatrace’s ActiveGate framework lets you extend its monitoring capabilities by writing custom extensions, but most people don’t realize these extensions run as separate Java processes, not directly within the ActiveGate itself.
Let’s see what a custom extension looks like in action. Imagine we have a simple extension that polls a custom HTTP endpoint for metrics.
# extension.yaml
name: MyCustomHTTP
# ... other configuration ...
remote:
- ip: 127.0.0.1
port: 8080
protocol: http
metrics:
- name: my_custom_metric
type: gauge
value: /metrics
group: my_group
description: A custom metric from my HTTP endpoint
# ... other configuration ...
When this extension.yaml is deployed to the ActiveGate, the framework spins up a dedicated Java process for MyCustomHTTP. This process reads the extension.yaml, establishes a connection to http://127.0.0.1:8080/metrics, and parses the response for the my_custom_metric.
The problem this solves is obvious: Dynatrace has a vast catalog of out-of-the-box integrations, but what if you have a proprietary application or a unique piece of infrastructure that isn’t supported? Custom extensions bridge that gap. They allow you to ingest metrics, logs, and even traces from virtually any source that can expose data via HTTP, JMX, or other protocols.
Internally, the ActiveGate framework acts as a manager for these extension processes. It handles their lifecycle: starting them, stopping them, and routing their collected data back to the main Dynatrace backend. Each extension is essentially a self-contained plugin. You define what data it collects, how it collects it (e.g., polling an endpoint, querying a database), and how it should be structured as metrics in Dynatrace.
The core levers you control are in the extension.yaml file. You define the name of your extension, the remote endpoint(s) to connect to, the protocol (HTTP, JMX, etc.), and crucially, the metrics you want to extract. For each metric, you specify its name, type (gauge, counter, sum), the path or query to retrieve its value from the source, and a group for organization. You can also define logs and traces sections to ingest other types of data.
The framework abstracts away much of the complexity of inter-process communication and data serialization. You focus on defining what data to collect and where to find it, and the framework handles the plumbing. This makes it accessible even for engineers who aren’t deep Java experts, as extensions are often written in Python, Go, or even simple shell scripts that are then executed by the framework.
When defining your metrics, the value field in the extension.yaml is more powerful than just a simple URL path. For HTTP-based extensions, it can be a JSONPath expression or a regular expression to extract specific values from the response body. For JMX extensions, it’s a JMX Object Name and attribute. This fine-grained control allows you to pinpoint exactly the data points you need from complex data sources.
You might be tempted to think that if your custom extension needs to access sensitive information, like API keys or database credentials, you’ll have to embed them directly in the extension.yaml. However, the ActiveGate framework supports a robust secrets management system. You can securely store credentials in Dynatrace and reference them as environment variables within your extension configuration, keeping sensitive data out of plain text configuration files.
The next logical step after collecting metrics is to analyze their behavior and trigger alerts based on them.