InfluxDB Data Forwarding
Relevant source files
The following files were used as context for generating this wiki page:
Kuberhealthy supports InfluxDB metric forwarding as a primary integration method for external monitoring and alerting systems. While Kuberhealthy automatically creates metrics for Prometheus and serves a JSON status page, the InfluxDB data forwarding feature allows cluster health states and check results to be pushed directly to an InfluxDB instance for long-term storage and integration into custom alerting solutions.
Sources: README.md:38-42, deploy/helm/kuberhealthy/README.md:14-16
Architecture and Configuration
The InfluxDB forwarding system is built around a specialized metric client that communicates with remote InfluxDB instances. The configuration is managed via Kuberhealthy's global configuration object, which provides the necessary connection strings and credentials.
Configuration Components
Configuration is handled through the configureInflux function, which initializes the metric client using environment-supplied variables.
This diagram shows the initialization flow of the InfluxDB client using configuration parameters.
Sources: cmd/kuberhealthy/influx.go:10-29
Connection Parameters
| Parameter | Source Variable | Description |
|---|---|---|
| URL | cfg.InfluxURL | The parsed URL of the InfluxDB server. |
| Username | cfg.InfluxUsername | Authentication username. |
| Password | cfg.InfluxPassword | Authentication password. |
| Database | cfg.InfluxDB | The target database for metric storage. |
Sources: cmd/kuberhealthy/influx.go:14-28
Data Model and Metric Generation
Kuberhealthy transforms internal health states into a format compatible with InfluxDB's line protocol or API. The system tracks multiple types of metrics including global cluster state, specific check statuses, and execution durations.
Metric Types
Kuberhealthy generates the following metric categories that are forwarded to InfluxDB:
- Kuberhealthy Status: Indicates if the Kuberhealthy operator itself is running error-free.
- Cluster State: A gauge representing the overall health of the Kubernetes cluster (0 for Unhealthy, 1 for Healthy).
- Check Status: Individual results for every configured
KuberhealthyCheck. - Job Status: Results for configured
KuberhealthyJobresources. - Duration Metrics: Time taken (in seconds) for checks and jobs to complete.
Sources: pkg/metrics/exporter.go:50-130
Metric Transformation Logic
The forwarding logic parses through the health.State object, which contains CheckDetails and JobDetails.
This sequence illustrates how internal state is processed and forwarded to the database.
Sources: pkg/metrics/exporter.go:70-110, cmd/kuberhealthy/influx.go:10-20
Implementation Details
The core implementation resides in pkg/metrics and cmd/kuberhealthy. The InfluxClient interface defines how data points are transmitted.
Client Initialization
The configureInflux function (Line 10, cmd/kuberhealthy/influx.go) serves as the entry point for the forwarding system. It validates the URL and returns a metrics.Client interface. If the URL is malformed, it returns a descriptive error preventing the system from starting with a broken forwarder.
Sources: cmd/kuberhealthy/influx.go:10-29
Status Formatting
Metrics are mapped to gauges where a value of 1 represents a success (OK) and 0 represents a failure. For durations, the system parses strings like "22.512278967s" into float64 seconds to ensure numerical compatibility within InfluxDB.
Sources: pkg/metrics/exporter.go:74-90, README.md:143-160
Summary
InfluxDB Data Forwarding in Kuberhealthy provides a robust mechanism for exporting synthetic monitoring results beyond the Kubernetes cluster. By leveraging the configuration-driven Influx client, developers can maintain historical records of cluster health, calculate reliability trends, and trigger external alerts based on the forwarded health states of various Kubernetes components and custom applications.