are there any plans to support the custom extensions 2.0 (incl. code extensions) in the containerized versions of the ActiveGate?
We have a big OpenShift environment and it would be nice to use the container technology for extension ActiveGates.
Solved! Go to Solution.
@Lukasz_BeWhat is the current status on this? Is it on the roadmap and if so, when will we see a first release?
It has been a year since your replay and still there is no support for Extensions 2.0 for containerized ActiveGates. Will we have to install environment ActiveGates beside of installing a containerized ActiveGate if we want to monitor Prometheus in Kubernetes-environments?
@mbrunn could you please share more details about the use case, please? What is the technology you want to monitor? What is the setup you have (or may have) available?
The use case is to use the Extension 2.0 to monitor Prometheus Exporters. We want to leverage both the included dashboards as well as the topology-model provided by extensions 2.0.
One example for why you would want to have the extension in the Kubernetes-cluster is rbac. Or strikter security rules. It also seems unneccesary to have both an environment activegate and a containerized activegate doing essential the same thing.
The K8s module does not support the same things like extensions 2.0 mainly the included dashboards, alarms and above all the missing abillity to define a topology.
Specificly we want to monitor HA Proxy via Prometheus and the Dynatrace Extension 2.0.
Also the documentation states: "Your extensions are executed by the Extension Execution Controller module (EEC), either remotely from an ActiveGate or locally from OneAgent."
Extensions built on EF2.0 doesn't necessarily have to be used to collect data. K8s module can be used to scrape the data, and then an EF2.0 extension can provide all the assets, like: dashboard, UA screens, alerting configuration, or topology. In such case the EEC isn't used, since the extension only provides cluster-side configuration.
We already planned a first step to have a consistent metric naming across K8s and non-K8s scenarios, which will help us retain the same user experience. Based on that we plan to introduce extensions supporting both these scenarios, but there's still no agreed ETA for that.