Your network stays yours.
The Observer Agent runs in your infrastructure, reads your metrics where they live, and pushes only verdicts outbound. Open source, Apache 2.0, with no inbound connections.
Most monitoring asks you to ship your data somewhere. Observer inverts that. The agent evaluates metrics where they already are and sends out only the answer: operational, degraded, down. Your raw data stays on your side of the wire, by design rather than by promise.
A small process with one job.
Read locally, decide locally, send the decision. Everything the agent does serves that single shape.
- Runs in your environment
- Kubernetes, a VM, bare metal, or your laptop while you test. Wherever your metrics are, the agent can sit next to them.
- Reads every source
- Prometheus, OTLP, CloudWatch, SQL databases, HTTP endpoints, and log systems, all from one process.
- Evaluates locally
- Thresholds and dwell are applied where the data lives. The verdict is computed before anything is sent.
- Pushes verdicts, not data
- Only the precomputed status crosses the boundary. Raw metric values and query results never leave your network.
- Outbound only
- The agent opens the connection. There is no inbound port to expose and no firewall hole to justify.
- Apache 2.0
- Fork it, audit it, modify it, run your own build. The data plane is open source, end to end.
Three reasons it works this way.
The outbound-only, evaluate-locally design is not an accident. It is the answer to the objections that usually block monitoring.
Compliance
Internal metrics never leave your infrastructure. The thing that crosses the boundary is a verdict, not a measurement, so there is far less to put in scope for an audit.
Security
An outbound-only agent means no inbound firewall rules, no exposed listener, no public surface for someone to find. The connection is initiated from inside.
Trust
The agent is open source. You do not have to take a vendor's word for what it sends. Read it, build it yourself, and run exactly what you reviewed.
Deploy once, configure forever after.
The agent is deployed a single time. Everything about what it measures lives in the console and updates without a redeploy.
- 01
Deploy the agent
A single binary, a Docker image, or a Kubernetes manifest. Pick whichever fits the environment you already run.
- 02
Register with a token
The agent authenticates to Observer Cloud with an HMAC-signed token. That handshake is the only credential it needs.
- 03
Configure in the console
Define metrics, thresholds, and services in Observer. The agent does not need redeploying when you change them.
- 04
Evaluate and push
The agent fetches its definitions, evaluates on schedule, and pushes the resulting verdicts outbound.
- 05
Transitions surface
Confirmed state changes become status updates and, when you want them, draft incidents for review.
Wherever you already run things.
One binary, a handful of well-worn shapes. The agent does not care which one you pick.
- Kubernetes
- A single deployment, multi-replica for high availability.
- Virtual machine
- A systemd unit around one binary. Nothing else to install.
- Multi-region
- One agent per region, each labelled with its location.
- Local for testing
- Runs on a Mac or Linux laptop during development.
The agent is Apache 2.0 and developed in the open. Read the code, file an issue, or send a pull request.
github.com/useobserver/agent