Kubernetes and VM / Bare-Metal
This topic explains how to enable the Prometheus JMX Exporter for Fabric so that Fabric and JVM metrics are exposed on a Prometheus-format /metrics endpoint. The mechanism for enabling the exporter differs significantly between Kubernetes and VM / bare-metal deployments. Both paths are covered here.
In both cases, the end result is the same: the JMX Exporter runs as a Java agent inside the Fabric JVM, and metrics are available at:
http://localhost:7170/metrics # Fabric metrics
http://localhost:7270/metrics # iid_finder metrics
This how-to covers:
It does not cover Prometheus scrape configuration, dashboard creation, or alert setup. Those are covered in related topics.
The JMX Exporter is bundled with Fabric in both Kubernetes and VM deployments. It is located under the monitor directory of the Fabric installation:
$K2_HOME/monitor/jmx_exporter/
jmx_prometheus_javaagent-1.5.0.jar # The exporter JAR
fabric_config.yaml # Fabric exporter configuration
iidfinder_config.yaml # iid_finder exporter configuration
fabric_7_monitor.sh # Setup script that activates the exporter
The exporter JAR is the open-source Prometheus JMX Exporter. It is not a K2view-developed binary. K2view packages it with Fabric and provides the configuration and activation scripts around it.
The exporter configuration (fabric_config.yaml) is intentionally minimal. Fabric exposes all metrics it can by default. Filtering is applied at the Prometheus or Grafana Agent collection layer, not in the exporter itself.
Note: The -javaagent line that activates the exporter does not pre-exist in jvm.options. It is written to jvm.options at setup time by fabric_7_monitor.sh. The script includes an idempotency check — it only appends the line if it is not already present, so it is safe to run more than once.
[ K8s ] Kubernetes deployments on AKS, GKE, or EKS. Monitoring is enabled automatically through K2cloud Orchestrator and the space profile.
For K2cloud SaaS and K2cloud Self-hosted customers, the JMX Exporter is enabled through the space profile, which is managed by K2view. Recent space profiles have monitoring enabled by default — confirm with K2view that your space profile includes this setting. No manual editing of jvm.options is required. For air-gapped Kubernetes deployments, see the VM / bare-metal path in Section 3, or the dedicated air-gapped document.
The enablement chain is:
Monitoring is enabled in the space profile (confirm with K2view if unsure)
↓
K2cloud Orchestrator injects MONITORING=default
into the Fabric pod as a Kubernetes secret (common-env-secrets)
↓
docker-entrypoint.sh runs at container startup
calls init_monitoring() in cloud_common.sh
↓
init_monitoring() checks MONITORING == 'default' or 'true'
calls monitor_setup.sh
↓
monitor_setup.sh runs in sequence:
1. setup_monitor() — copies monitor/ dir to $FABRIC_HOME if needed
2. init_monitor() — calls fabric_7_monitor.sh
3. start_monitor() — starts Node Exporter and Promtail as background processes
↓
fabric_7_monitor.sh:
checks if javaagent line already in jvm.options (idempotent)
appends: -javaagent:.../jmx_prometheus_javaagent-1.5.0.jar=7170:.../fabric_config.yaml
appends: -javaagent:.../jmx_prometheus_javaagent-1.5.0.jar=7270:.../iidfinder_config.yaml
enables JMX remote management settings
↓
Fabric JVM starts with the exporter active metrics available at localhost:7170 and localhost:7270
The K2cloud space profile is the K2view-managed configuration that controls monitoring enablement for each Fabric space. Recent K2view space profiles have monitoring enabled by default. If you need to confirm or request that monitoring is enabled for your space, contact K2view. When monitoring is enabled in the space profile, Cloud Manager injects the MONITORING=default environment variable into the Fabric pod. This variable is what triggers the monitor setup chain at container startup.
When MONITORING=default, the following run inside the Fabric container or on the same host:
The following run outside the Fabric container on the worker node:
Note: The monitor directory inside the Fabric image contains node_exporter and promtail binaries. These are present due to legacy VM-era packaging. In Kubernetes, start_monitor() does attempt to start node_exporter as a background process inside the container. However, node-level metrics in Kubernetes are collected by the DaemonSet node-exporter on the worker node, which is the authoritative infrastructure metrics source. The in-container node_exporter should not be relied on for Kubernetes deployments.
To suppress monitoring for a specific pod or space, set the MONITORING environment variable to NONE. When MONITORING=NONE, monitor_setup.sh runs setup but does not start any monitoring processes.
[ VM / Bare-Metal ] Virtual machines or physical servers. Monitoring must be enabled manually or by running the monitor setup script.
On VMs and bare-metal hosts, there is no K2cloud Orchestrator automation. The JMX Exporter must be enabled manually or by running the setup script directly. There are two options.
If the monitor directory has been deployed to the Fabric host, run the setup script:
$K2_HOME/monitor/jmx_exporter/fabric_7_monitor.sh
This script performs all of the following automatically:
Alternatively, if running Fabric as a container on a VM (non-Kubernetes), set the MONITORING environment variable before starting the container:
MONITORING=default
This triggers the same monitor_setup.sh chain that runs in Kubernetes, including starting Node Exporter and Promtail as background processes on the same host.
If you prefer to edit jvm.options directly, add the following line:
-javaagent:$K2_HOME/monitor/jmx_exporter/jmx_prometheus_javaagent-1.5.0.jar=7170:$K2_HOME/monitor/jmx_exporter/fabric_config.yaml
For iid_finder metrics, also add:
-javaagent:$K2_HOME/monitor/jmx_exporter/jmx_prometheus_javaagent-1.5.0.jar=7270:$K2_HOME/monitor/jmx_exporter/iidfinder_config.yaml
Important: Fabric must be restarted after either option. The exporter is loaded at JVM startup — changes to jvm.options have no effect on a running Fabric process.
On VMs, Node Exporter and Promtail are not managed by Kubernetes. They must be started separately on each Fabric host. The monitor_setup.sh script handles this when MONITORING=default is set, or you can start them manually:
# Node Exporter
nohup $K2_HOME/monitor/node_exporter/node_exporter >/dev/null 2>&1 &
# Promtail (only if LOKI_HOST is set)
$K2_HOME/monitor/promtail/promtail_config.sh -lk <LOKI_HOST> -s fabric
Validation is the same for both Kubernetes and VM deployments. From inside the Fabric runtime context (inside the pod in Kubernetes, or on the host on VMs):
curl http://localhost:7170/metrics
A successful response returns Prometheus-format text. The output includes:
To validate iid_finder metrics:
curl http://localhost:7270/metrics
Kubernetes note: Run the curl command from inside the Fabric pod. The exporter binds to localhost, so it is not accessible from outside the pod without port-forwarding. Use: kubectl exec -it
-- curl http://localhost:7170/metrics
After successful enablement:
Kubernetes: Check that the MONITORING environment variable is present in the Fabric pod: kubectl exec
VM: Run fabric_7_monitor.sh manually, or add the javaagent line to jvm.options directly. Restart Fabric after.
This means the Fabric-side exposure is working correctly. The problem is in the collection layer:
Kubernetes:
VM / Bare-Metal:
Kubernetes and VM / Bare-Metal
This topic explains how to enable the Prometheus JMX Exporter for Fabric so that Fabric and JVM metrics are exposed on a Prometheus-format /metrics endpoint. The mechanism for enabling the exporter differs significantly between Kubernetes and VM / bare-metal deployments. Both paths are covered here.
In both cases, the end result is the same: the JMX Exporter runs as a Java agent inside the Fabric JVM, and metrics are available at:
http://localhost:7170/metrics # Fabric metrics
http://localhost:7270/metrics # iid_finder metrics
This how-to covers:
It does not cover Prometheus scrape configuration, dashboard creation, or alert setup. Those are covered in related topics.
The JMX Exporter is bundled with Fabric in both Kubernetes and VM deployments. It is located under the monitor directory of the Fabric installation:
$K2_HOME/monitor/jmx_exporter/
jmx_prometheus_javaagent-1.5.0.jar # The exporter JAR
fabric_config.yaml # Fabric exporter configuration
iidfinder_config.yaml # iid_finder exporter configuration
fabric_7_monitor.sh # Setup script that activates the exporter
The exporter JAR is the open-source Prometheus JMX Exporter. It is not a K2view-developed binary. K2view packages it with Fabric and provides the configuration and activation scripts around it.
The exporter configuration (fabric_config.yaml) is intentionally minimal. Fabric exposes all metrics it can by default. Filtering is applied at the Prometheus or Grafana Agent collection layer, not in the exporter itself.
Note: The -javaagent line that activates the exporter does not pre-exist in jvm.options. It is written to jvm.options at setup time by fabric_7_monitor.sh. The script includes an idempotency check — it only appends the line if it is not already present, so it is safe to run more than once.
[ K8s ] Kubernetes deployments on AKS, GKE, or EKS. Monitoring is enabled automatically through K2cloud Orchestrator and the space profile.
For K2cloud SaaS and K2cloud Self-hosted customers, the JMX Exporter is enabled through the space profile, which is managed by K2view. Recent space profiles have monitoring enabled by default — confirm with K2view that your space profile includes this setting. No manual editing of jvm.options is required. For air-gapped Kubernetes deployments, see the VM / bare-metal path in Section 3, or the dedicated air-gapped document.
The enablement chain is:
Monitoring is enabled in the space profile (confirm with K2view if unsure)
↓
K2cloud Orchestrator injects MONITORING=default
into the Fabric pod as a Kubernetes secret (common-env-secrets)
↓
docker-entrypoint.sh runs at container startup
calls init_monitoring() in cloud_common.sh
↓
init_monitoring() checks MONITORING == 'default' or 'true'
calls monitor_setup.sh
↓
monitor_setup.sh runs in sequence:
1. setup_monitor() — copies monitor/ dir to $FABRIC_HOME if needed
2. init_monitor() — calls fabric_7_monitor.sh
3. start_monitor() — starts Node Exporter and Promtail as background processes
↓
fabric_7_monitor.sh:
checks if javaagent line already in jvm.options (idempotent)
appends: -javaagent:.../jmx_prometheus_javaagent-1.5.0.jar=7170:.../fabric_config.yaml
appends: -javaagent:.../jmx_prometheus_javaagent-1.5.0.jar=7270:.../iidfinder_config.yaml
enables JMX remote management settings
↓
Fabric JVM starts with the exporter active metrics available at localhost:7170 and localhost:7270
The K2cloud space profile is the K2view-managed configuration that controls monitoring enablement for each Fabric space. Recent K2view space profiles have monitoring enabled by default. If you need to confirm or request that monitoring is enabled for your space, contact K2view. When monitoring is enabled in the space profile, Cloud Manager injects the MONITORING=default environment variable into the Fabric pod. This variable is what triggers the monitor setup chain at container startup.
When MONITORING=default, the following run inside the Fabric container or on the same host:
The following run outside the Fabric container on the worker node:
Note: The monitor directory inside the Fabric image contains node_exporter and promtail binaries. These are present due to legacy VM-era packaging. In Kubernetes, start_monitor() does attempt to start node_exporter as a background process inside the container. However, node-level metrics in Kubernetes are collected by the DaemonSet node-exporter on the worker node, which is the authoritative infrastructure metrics source. The in-container node_exporter should not be relied on for Kubernetes deployments.
To suppress monitoring for a specific pod or space, set the MONITORING environment variable to NONE. When MONITORING=NONE, monitor_setup.sh runs setup but does not start any monitoring processes.
[ VM / Bare-Metal ] Virtual machines or physical servers. Monitoring must be enabled manually or by running the monitor setup script.
On VMs and bare-metal hosts, there is no K2cloud Orchestrator automation. The JMX Exporter must be enabled manually or by running the setup script directly. There are two options.
If the monitor directory has been deployed to the Fabric host, run the setup script:
$K2_HOME/monitor/jmx_exporter/fabric_7_monitor.sh
This script performs all of the following automatically:
Alternatively, if running Fabric as a container on a VM (non-Kubernetes), set the MONITORING environment variable before starting the container:
MONITORING=default
This triggers the same monitor_setup.sh chain that runs in Kubernetes, including starting Node Exporter and Promtail as background processes on the same host.
If you prefer to edit jvm.options directly, add the following line:
-javaagent:$K2_HOME/monitor/jmx_exporter/jmx_prometheus_javaagent-1.5.0.jar=7170:$K2_HOME/monitor/jmx_exporter/fabric_config.yaml
For iid_finder metrics, also add:
-javaagent:$K2_HOME/monitor/jmx_exporter/jmx_prometheus_javaagent-1.5.0.jar=7270:$K2_HOME/monitor/jmx_exporter/iidfinder_config.yaml
Important: Fabric must be restarted after either option. The exporter is loaded at JVM startup — changes to jvm.options have no effect on a running Fabric process.
On VMs, Node Exporter and Promtail are not managed by Kubernetes. They must be started separately on each Fabric host. The monitor_setup.sh script handles this when MONITORING=default is set, or you can start them manually:
# Node Exporter
nohup $K2_HOME/monitor/node_exporter/node_exporter >/dev/null 2>&1 &
# Promtail (only if LOKI_HOST is set)
$K2_HOME/monitor/promtail/promtail_config.sh -lk <LOKI_HOST> -s fabric
Validation is the same for both Kubernetes and VM deployments. From inside the Fabric runtime context (inside the pod in Kubernetes, or on the host on VMs):
curl http://localhost:7170/metrics
A successful response returns Prometheus-format text. The output includes:
To validate iid_finder metrics:
curl http://localhost:7270/metrics
Kubernetes note: Run the curl command from inside the Fabric pod. The exporter binds to localhost, so it is not accessible from outside the pod without port-forwarding. Use: kubectl exec -it
-- curl http://localhost:7170/metrics
After successful enablement:
Kubernetes: Check that the MONITORING environment variable is present in the Fabric pod: kubectl exec
VM: Run fabric_7_monitor.sh manually, or add the javaagent line to jvm.options directly. Restart Fabric after.
This means the Fabric-side exposure is working correctly. The problem is in the collection layer:
Kubernetes:
VM / Bare-Metal: