Server monitoring agent

Launching July 15

See inside your servers, not just from the outside.

External checks tell you customers can reach your service. The Opsentry agent runs on your hosts and tells you why one is about to fall over — high CPU, a filling disk, a saturated database, swap thrashing, a stalled backup, errors piling up in the logs. Configure every check centrally; the agent does the watching and alerts you the moment a threshold trips.

Start Monitoring — Free Agent vs external checks

The agent launches July 15. Create your account now and you'll be ready to roll it out on day one.

How the agent works.

1 · Install

Drop a single lightweight Go binary on each server — bare metal, VM, or container. No runtime, no dependencies. It schedules its checks with cron-style intervals and runs them locally.

2 · Configure centrally

Define what each host should watch right here in Opsentry — thresholds, paths, credentials, intervals. Host-local checks run on the agent; network checks can run from Opsentry's regional probes instead.

3 · Get alerted

When a check crosses its threshold, the agent reports it and Opsentry opens an incident and notifies you by email, webhook, Slack, Teams, Discord, or Telegram — the same pipeline as your external checks.

Everything the agent can watch.

Every check type below is configurable per host. The Remote badge marks checks that can also run from Opsentry's external probes; Agent checks read host-local state and run on the installed agent.

HTTP & API

REST Remote

REST endpoint check with response validation

SOAP Remote

SOAP service check

GraphQL Remote

GraphQL endpoint query check

Network

Socket Remote

TCP/UDP socket check with optional message exchange

DNS Remote

Hostname resolves

TLS Certificate Remote

Certificate expiry with warning window

Port Reachability Remote

Multiple ports accept connections

Service Banner Remote

Protocol greeting check (SMTP/IMAP/FTP/SSH)

NTP Drift Remote

Clock offset against an NTP server

Databases

Redis Remote

Redis PING + latency

PostgreSQL Remote

PostgreSQL reachability

MySQL Remote

MySQL reachability (handshake)

MongoDB Remote

MongoDB reachability

Caches & Queues

Memcached Remote

Memcached stats

Elasticsearch Remote

Cluster health (green/yellow/red)

RabbitMQ Remote

Queue depth via management API

Host & System

CPU Agent

CPU usage

Memory Agent

RAM and swap usage

Disk Agent

Disk space usage

Load Average Agent

Load average per core

Network I/O Agent

Interface throughput and errors

Disk I/O Agent

Per-device read/write throughput

Inodes Agent

Inode usage

Temperature Agent

Hardware sensor temperatures

Uptime Agent

Reboot detection

File Descriptors Agent

System FD usage (Linux)

Processes Agent

Process resource overview

Process by Name Agent

Named process liveness

Systemd Service Agent

systemd unit active state

Logs & Files

Log Scan Agent

Scan a log file for patterns

Log Growth Agent

Log file growth rate

File Check Agent

Existence, freshness and size (backups)

Containers

Docker Agent

Container states via local socket

Two vantage points, one source of truth.

Agent checks and external checks answer different questions, and reliable teams run both. External probes travel the same path your users do and catch DNS, TLS, load-balancer, and regional failures. The agent sees the things no outside probe can — the disk that's 98% full, the replication lag building on a read replica, the OOM killer about to strike. Together they turn "the site is down" into "the database host ran out of memory at 02:14," before your customers ever notice.

Configured as code, managed in one place.

Each check is a small, declarative config — a target, an interval, and a threshold. Set it once and the agent enforces it on every run.

memory:
  threshold_percent: 90
  swap_threshold_percent: 80

disk:
  path: "/"
  threshold_percent: 90

postgresql:
  host: "db.internal:5432"
  connection_usage_percent: 80

logscan:
  path: "/var/log/app.log"
  patterns: ["(?i)error", "(?i)panic", "(?i)fatal"]

Frequently asked questions

Do I need the agent if I already have external checks?

They cover different failure modes. External checks confirm customers can reach you; the agent explains degradation from the inside — CPU, memory, disk, database health, logs. Most teams run both and correlate them in one timeline.

What does the agent run on?

A single static Go binary with no external dependencies. It runs on Linux servers, VMs, and containers, scheduling each check on its own interval. Some checks (like file-descriptor and systemd status) are Linux-specific and degrade gracefully elsewhere.

How are host-local checks different from external ones?

A regional probe has no way to read a server's CPU or scan its log files, so those checks run on the agent itself. Network-reachable checks — HTTP, databases, queues, certificates — can run either from the agent or from Opsentry's external probes, whichever vantage point you want.

Can I get the data and alerts the same way as external checks?

Yes. Agent results flow into the same incidents, notifications, and HTTP API as external checks, so your dashboards, status pages, and on-call routing all work without anything new to learn.