Skip to content

Infrastructure Metrics

Your applications depend on managed services — databases, caches, message queues — that you didn't write but still need to watch. Collect their metrics by running an OpenTelemetry Collector with the matching receiver and forwarding to Hexcovery over OTLP/gRPC.

How it works

OpenTelemetry ships purpose-built receivers for common infrastructure. You run a collector next to (or with access to) the service, enable the receiver, and point the collector's OTLP exporter at the Hexcovery ingest endpoint (:4317) with your API key.

Hexcovery classifies the incoming metrics automatically by their metric-name prefix and stores them in a per-category table:

Category OQL table Example engines
Database database PostgreSQL, MySQL/MariaDB, MongoDB, SQL Server
Cache cache Redis, Memcached
Message queue mq Kafka, RabbitMQ

You query these as OQL tables, where each native metric name is a column (for example, postgresql.commits). Unknown metric prefixes are never dropped — they fall back to a generic table.

Graduation: from dependency to Service

Until a managed service emits its own metrics, Hexcovery only knows it as an External Service — a call-target that some Project depends on, with no home of its own. Once its metrics arrive carrying a service.namespace, it graduates into a first-class Service with its own metrics lens and its own place in the Project that owns it.

Graduation is automatic — there's no registry to edit. It hinges entirely on the resource attributes you set on the collector.

Identity and attribution (required)

To make a managed service fully identified and graduatable, set three resource attributes on its metrics with the collector's resource processor. This snippet is the same for every product:

processors:
  resource:
    attributes:
      - key: service.instance.id     # stable identity (host:port, cluster name, …)
        value: "db-prod-1:5432"
        action: upsert
      - key: service.namespace       # the Project this belongs to → graduation
        value: "superpippo"
        action: upsert
      - key: service.name            # display name (optional)
        value: "orders-db"
        action: upsert
  • service.instance.id gives the entity a stable identity. PostgreSQL, MongoDB, and SQL Server emit it natively, so they're keyed out of the box; for others, set it explicitly.
  • service.namespace attributes the entity to a Project — this is what triggers graduation. Without it, the metrics are stored but the entity stays edge-only (a dependency with no home).
  • service.name is the display name; it falls back to the instance identity if omitted.

Some receivers need identity enabled explicitly

A few receivers disable their identity attributes by default. Setting service.instance.id matters most for Redis (server.address disabled by default), Memcached (no identity attributes by default), Kafka (cluster alias disabled by default), and MySQL. For these, the resource snippet above is what makes them identifiable.

Example: PostgreSQL

A minimal collector that scrapes a PostgreSQL instance and forwards to Hexcovery:

receivers:
  postgresql:
    endpoint: db-prod-1:5432
    username: monitoring
    password: ${env:PG_MONITOR_PASSWORD}
    databases: [orders]

processors:
  resource:
    attributes:
      - key: service.instance.id
        value: "db-prod-1:5432"
        action: upsert
      - key: service.namespace
        value: "superpippo"
        action: upsert
      - key: service.name
        value: "orders-db"
        action: upsert

exporters:
  otlp:
    endpoint: ingest.hexcovery.com:4317
    headers:
      x-api-key: YOUR_API_KEY

service:
  pipelines:
    metrics:
      receivers: [postgresql]
      processors: [resource]
      exporters: [otlp]

The same shape applies to the other engines — swap the receiver (redis, kafkametrics, mysql, …) and keep the identical resource processor and exporter. Refer to the upstream OpenTelemetry Collector documentation for each receiver's connection options.

Exact endpoint value

Your organization's exact ingest endpoint is shown in the dashboard. Use that value rather than the placeholder above.

Query the metrics

Once metrics are flowing, query them by their native names in OQL:

SELECT postgresql.backends, postgresql.commits
FROM database WHERE engine = 'postgresql' AND db_name = 'orders'
EVERY 1m LAST 1h

Counters report their window increase by default and gauges report their average; you can override the aggregation with any standard OQL function. See the table reference for the full schema.

Next