Use multiple metric sources
Mix Prometheus, HTTP, TCP, DNS, and TLS certificate probes in one Observer organisation.
Observer's agent supports several probe runtimes within one deployment. Pick the source that produces the most reliable signal for what you want to assert about the system.
Source types
| Source type | Returns | Typical use |
|---|---|---|
prometheus | scalar from a PromQL query | latency / error rate / saturation against existing series |
http | response time in ms | reachability + body match against an endpoint |
tcp | connect time in ms | reachability for non-HTTP services (Redis, Postgres) |
dns | resolve time in ms | DNS resolution path with optional record-value match |
tls_cert | days until certificate expiry | leaf-cert validity for a hostname |
Stubbed in the schema and reserved for future runtimes:
icmp, grpc, websocket, mtls_http, database. Definitions
using these source types are accepted by the cloud and stored, but
the agent returns no_data until the runtime ships.
Configure a non-Prometheus metric
Open Metrics, then New metric, and pick the source type. Each source has its own configuration form:
- HTTP: URL, expected status code(s), optional body match, optional headers, timeout, follow-redirects, verify-TLS toggle.
- TCP: host, port, timeout.
- DNS: domain, record type (
A,AAAA,CNAME,MX,TXT,NS,SRV,CAA,PTR), optional expected value, optional resolver. - TLS cert: host, port (default
443), warn-days, critical-days.
The thresholds remain consistent: each metric has healthy_* and
unhealthy_* operators applied to whatever value the source
returns.
Mixing sources on one page
A status page can carry metrics from any combination of sources. The page renders each metric using its threshold band, regardless of the runtime that produced the value. Operators viewing the page see one consistent green / amber / red signal across heterogeneous checks.
Agent reach
The agent must be able to reach each source from its host. For Prometheus, that is your internal Prometheus URL. For HTTP probes, the URL must be reachable from wherever the agent runs (for example, an internal endpoint on a private network). The cloud never reaches your endpoints directly: the agent collects, computes status, and pushes the verdict.