OpenMeter includes a Kubernetes integration that meters pod execution time and reports it to OpenMeter. Measuring execution time is useful if you want to bill based on CPU/GPU time or calculate unit economics for your Kubernetes containers.
The simplest method for installing the collector is through Helm:
With the default settings, the collector will report on pods running in the
default namespace to OpenMeter every 15 seconds.
Take a look at this example to see the collector in action.
To get start measuring Kubernetes pod execution time, create a meter in OpenMeter:Create meter
The collector accepts several configuration values as environment variables:
|The namespace to scrape (currently, only one is supported; see this issue).
|The interval for scraping in Go duration format (Minimum interval: 1 second).
|The minimum number of events to wait for before reporting. The collector will report events in a single batch (set to
0 to disable).
|The maximum duration to wait before reporting the current batch to OpenMeter, in Go duration format.
|If set to
true, every reported event is logged to stdout.
These values can be set in the Helm chart's
values.yaml file using
envFrom. For more details, refer to the Helm chart reference.
The collector maps information from each pod to CloudEvents according to the following rules:
- Event type is set as
- Event source is set as
- The subject name is mapped from the value of the
openmeter.io/subjectannotation. It falls back to the pod name if the annotation is not present.
- Pod execution time is mapped to
- Pod name and namespace are mapped to
pod_namespace, respectively, in the
- Annotations labeled
data.openmeter.io/KEYare mapped to
datasection, with previous data attributes being given higher priority.
The ideal performance tuning options for this collector depend on the specific use case and the context in which it is being used. For instance, reporting on a large number of pods infrequently requires different settings than reporting on a few pods frequently. Additionally, accuracy and real-time requirements might influence the selection of appropriate options.
The primary factors influencing performance that you can adjust are
SCRAPE_INTERVAL implies the need for more accurate information about pod execution time, but it also generates more events, leading to increased requests to OpenMeter.
To mitigate this, you can raise
BATCH_SIZE and/or set or increase
BATCH_PERIOD. This approach reduces the number of requests (and the potential for back-pressure) to OpenMeter.
However, this means that your more accurate data will be delayed in reaching OpenMeter, resulting in less real-time data.
Managing a large number of pods typically requires a higher
SCRAPE_INTERVAL to avoid overburdening the Kubernetes API and OpenMeter.
SCRAPE_INTERVAL, though, might lead to less accurate metering.
For additional options to fine-tune performance, please consult the Advanced configuration section.
The Kubernetes collector utilizes Benthos to gather pod information, convert it to CloudEvents, and reliably transmit it to OpenMeter.
The configuration file for the collector is available here.
To tailor the configuration to your needs, you can edit this file and mount it to the collector container. This can be done using the
configFile options in the Helm chart. For more details, refer to the Helm chart reference.
For additional tips on performance fine-tuning, consult the Benthos documentation.