Sending Data

There are four ways to get telemetry into Hexcovery. They cover everything from the servers your software runs on to the applications themselves and the managed services they depend on. Pick the ones that match what you want to observe — you can combine them freely.

Method	What it sends	Best for
Agent	Infrastructure metrics + host logs	Linux servers and Kubernetes nodes
OpenTelemetry SDKs	Application traces, logs, metrics	Your own instrumented code
OTel receivers	Managed-service metrics	PostgreSQL, Redis, Kafka, …
Cron heartbeats	Scheduled-job run status	Backups, batch jobs, periodic tasks

One endpoint, one key

Everything you send arrives over OTLP (OpenTelemetry Protocol) on gRPC at the ingest endpoint on port :4317, and everything authenticates with a tenant-scoped API key. The key identifies your organization and routes the data to your storage — there is nothing else to configure for tenancy.

OTLP is the protocol, gRPC is the transport

OTLP defines the data format (traces, logs, metrics); gRPC is how it travels over the wire. When you point an OpenTelemetry SDK or collector at Hexcovery, you're using OTLP-over-gRPC. The Hexcovery agent uses a tighter typed-gRPC protocol of its own, but you never see that difference — both land in the same per-tenant storage.

The API key is passed as the x-api-key header (or gRPC metadata) on every request. Create and manage keys from the dashboard — see API keys and Authentication.

The four methods

The agent — infrastructure metrics and host logs

The Hexcovery agent runs on the machines your software lives on and collects system-level signals you can't get from inside an application: CPU, memory, disk and disk I/O, network, filesystem, load, processes, and host logs. It ships in two forms:

Linux daemon — a single static binary run as a systemd service on a server.
Kubernetes DaemonSet — a Helm-installable pod that runs on every node and collects node, pod, container, and cluster metrics plus container logs and Kubernetes events.

Both share the same configuration model: an API key, an endpoint, what to collect, and local buffering.

OpenTelemetry SDKs — application traces, logs, and metrics

Instrument your applications with the standard, off-the-shelf OpenTelemetry SDKs (Go, Java, Python, Node, .NET, and more — many with zero-code auto-instrumentation) and point them at the OTLP gRPC endpoint. Set service.name and service.namespace on your resource — the namespace becomes the Project the entity belongs to. See Services and Projects for the model.

OTel receivers — managed-service metrics

For software you didn't write but depend on — PostgreSQL, Redis, Kafka, and others — run an OpenTelemetry Collector with the matching receiver and forward its metrics to Hexcovery. They land in the database / cache / mq tables, queryable in OQL, and the external service graduates into a first-class Service once it carries its own metrics. See Infrastructure metrics.

Cron heartbeats — scheduled-job monitoring

Wrap any scheduled job — a backup, a nightly batch, a periodic sync — with the heartbeat API so Hexcovery knows when it started, finished, succeeded, or went missing. Jobs appear on the Cron Jobs dashboard page.