Skip to content
Docs

Core concepts

On this page
  1. Sensor
  2. Incident
  3. Alerting and integrations
  4. Agent and Hub
  5. Service
  6. Environment
  7. Maintenance window
  8. Template
  9. Next step

A handful of ideas explain all of Onagre. This page introduces each one with an example from a fictional online shop, Corvane.

What a sensor is connected to A sensor belongs to one service and one environment, is run by an agent, opens incidents when its check fails and notifies the integrations linked to it. SensorWhat to check, how often,what counts as healthyServiceThe part of your systemit watchesEnvironmentProduction, Staging…variables and secretsAgentPublic or private:where the check runsIntegrationsWho is notified:Slack, e-mail, webhook…IncidentsOpened and resolvedby its resultsbelongs tobelongs toruns onalertsopens
A sensor belongs to one service and one environment, is run by an agent, opens incidents when its check fails and notifies the integrations linked to it.

Sensor#

A sensor describes one thing to check: what to check (a URL, a database query, a port…), how often, and what counts as healthy. Every time it runs, it produces a result: up or down, with the response time and, for some types, a measured value.

Corvane's Storefront — Homepage sensor requests https://www.corvane.example/ every minute and expects an HTTP status between 200 and 399.

In the app, sensors are created with New monitor and listed under Resources: "monitor" and "monitored resource" are the names the interface uses for sensors. Each sensor type is described in Sensors.

Incident#

An incident records a problem detected by a sensor. It opens on the first failed check and is resolved automatically on the first successful check. In between, a team member can acknowledge it to say they are on it.

At 07:53 the SMS provider starts answering degraded_performance: the Notifications — SMS gateway sensor fails and an incident opens.

See Incidents.

Alerting and integrations#

An integration is a notification channel: a Slack channel, a Teams channel, a webhook, a phone through Pushover or the Onagre mobile app, a team member's e-mail. Alerting is the list of integrations linked to a sensor: when that sensor opens or resolves an incident, those integrations are notified.

From a failed check to a notification A failed check opens an incident at once; the integrations linked to the sensor are notified. The first successful check resolves it and notifies them again. Run by an agent, on its scheduleSensorA check failsIncidentOpened at onceAlertingLinked integrationsNotificationsSlack, e-mail…First successful check → incident resolved → recovery notification to the same integrations
A failed check opens an incident at once; the integrations linked to the sensor are notified. The first successful check resolves it and notifies them again.

The SMS gateway sensor alerts Slack #ops-alerts and the on-call phone. Both receive a message when the incident opens, and another one when it is resolved.

See Alerting and notifications.

Agent and Hub#

An agent is the program that actually runs the checks. Onagre provides a public agent on the internet: it checks public websites and APIs with nothing to install. To check something that is not reachable from the internet — a database, an internal API — you install a private agent inside your network. It connects out to Onagre and never needs an inbound port.

The Hub is the Onagre service agents connect to: it tells each agent what to check and when, and receives the results. You never configure it; it is mentioned when you open your firewall for an agent.

See Public and private monitoring.

Service#

A service groups the sensors that watch one part of your system — Checkout & Payments, Public API, Notifications — and shows its overall health. Services can depend on each other: Mobile Backend depends on Notifications. The Service Map draws these dependencies and shows how a failure spreads.

See Services.

Environment#

An environment — Production, Staging, Development — separates sensors that watch different copies of your system. Each environment holds its own variables (plain values reused in sensors, such as ${API_HOST}) and secrets (encrypted connection strings for databases and brokers).

See Environments.

Maintenance window#

A maintenance window pauses checks during planned work, so that a server update does not open incidents or wake anyone up. See Maintenance windows.

Template#

A template starts from a need — Website availability, Nightly backup, PostgreSQL availability — and prepares the matching sensor: you complete what is specific to your environment and create it in a few clicks. See Templates.

Next step#

Monitor your first website →