Skip to content
Docs

Services

On this page
  1. Why organize sensors into services
  2. Create and manage services
  3. Health of a service
  4. Dependencies
  5. The service page
  6. Related

A service is a part of your system as your team talks about it — Checkout & Payments, Public API, Notifications, Core Database — rather than a technical check. Each sensor belongs to one service, and the service sums up their state: when something fails, you see at once which part of the product is affected.

Services also depend on each other. Those dependencies feed the Service Map and incident propagation.

Why organize sensors into services#

Corvane has seventy sensors. When Notifications — SMS gateway fails at 07:53, the question is not "which sensor?" but "what does it break?". Grouped into services:

  • the Notifications service turns Degraded;
  • the Service Map shows that Mobile Backend depends on it and is impacted;
  • the team knows that push and SMS notifications are affected, but checkout is not.

A useful rule: one service per component that can fail on its own and that someone owns.

Create and manage services#

Services are managed in Configuration → Services. Creating, renaming and deleting services require the Manager role.

Services settings: the list of Corvane's services (General, Authentication, Back-office, Cache & Sessions, Checkout & Payments…) with their description and creation date.
Each service names a part of your architecture; General is the default service.
  1. Click New service.
  2. Enter a Name (Checkout & Payments) and an optional Description (Cart validation, payment orchestration, fraud checks).
  3. Save.

Every organization has a default service, General, marked Default. New sensors are placed in it unless you choose another one, and it cannot be deleted. A service that still has sensors cannot be deleted either: move them to another service first.

To move a sensor, Edit it and change Service in the General section.

Health of a service#

A service's health is computed from the sensors it contains:

Health Meaning
Healthy All its sensors are up.
Degraded Some of its sensors are failing.
Down All its sensors are failing.
Unknown It has no sensor, or none has reported yet.

On the Service Map, a service whose own sensors are healthy but which depends on a failing service is also shown as degraded — see Incident propagation.

Dependencies#

"Mobile Backend depends on Notifications" means that Mobile Backend needs Notifications to work. Declare the dependencies that matter: they explain incidents.

  • From the list — the Dependencies button of a service opens its panel: Add dependency to choose a service it depends on; Depends on lists them, each with a remove button; Used by shows the services that depend on it.
  • On the map — in Link mode, drag from one service to another. See Service Map.

A service cannot depend on itself, and the same dependency cannot be added twice. Adding and removing dependencies requires the User role.

The service page#

Click a service — in the list, on the map or in a sensor's page — to open it.

Notifications service page: degraded health with 4 resources, the services it depends on and the services that use it, and its monitored resources with their state.
A service page shows its health, its upstream and downstream services, and the resources behind it.
  • its health, the number of Monitored resources, Resources up and Resources with issues;
  • Depends on and Used by, with links to those services;
  • Monitored resources — its sensors, with their environment, schedule, last check and state.