Concepts¶
This page defines the vocabulary that shows up across the whole platform. Quick read (10 minutes), meant as a reference for the other docs.
If you have not signed in yet, start with First access.
The big picture¶
The platform spins around three ideas:
- You have resources (servers, databases, containers, devices) that need to be observed.
- Components called collector and agent carry data from those resources into SpecialOne.
- When something goes off, the platform raises an alert and routes it to the channels defined by your rules.
The rest of the page details each term.
Tenant¶
Isolated logical environment inside the platform. Each customer, business unit or environment (production, staging) usually sits in its own tenant.
Data from one tenant never bleeds into another: hosts, alerts, dashboards and rules stay scoped. When your user has access to more than one, the top bar shows the current tenant and lets you switch. See First access → Switching tenants.
Hub (Collector)¶
Lightweight service installed on the customer network that talks to SpecialOne on behalf of the local environment. Some screens call it Collector instead.
The hub is the single egress for monitoring data from your network to the platform. It:
- Receives metrics from agents installed on hosts.
- Connects directly to databases, APIs, storage and network devices that have no agent.
- Buffers locally if the link to SpecialOne is down, without losing readings.
Simple environments use a single hub. Segmented networks (DMZ, datacenters in different physical sites) usually run more than one.
Agent¶
Software installed inside a Linux or Windows host that collects local metrics (CPU, memory, disk, processes, services, logs) and ships them to the hub.
The agent is the standard way to monitor servers. Databases, APIs and network devices are collected directly by the hub through their native protocol (SNMP, JDBC, HTTPS), without an agent.
Host¶
Any resource monitored by the platform. The term covers several kinds:
- Physical or virtual servers (Linux, Windows).
- Databases.
- Containers (Docker nodes, Kubernetes clusters).
- Network devices (switches, routers, firewalls).
- DCIM equipment (UPS, air conditioning).
- Synthetic checks (public URLs).
Each host has a name, type, a set of metrics being collected and a set of alerts evaluating those metrics.
Metric¶
Each individual reading collected from a host. Average CPU over the last minute is a metric. Free space on /var is another. Average latency on the latest transaction in the database is another.
Metrics have a name, collection interval and unit. You rarely create metrics by hand: they come from the monitoring profiles applied to the host.
The list of active metrics on a host lives under Infrastructure → Hosts → (host) → Configuration → Collected Metrics.
Alert¶
The term alert has two senses on the platform:
- Alert definition: rule that combines one or more metrics with a condition (e.g. "CPU above 90% for 5 minutes"). This is what you create, edit and disable.
- Open alert (some screens call it problem): event generated when the definition's condition is met. This is what you handle day to day.
Every alert definition has:
- Message describing the condition (e.g. "High CPU utilization").
- Severity (information, medium, high, critical).
- Host it is bound to.
- Tags for routing and filtering.
- State: enabled or disabled.
When it fires, the open alert also gets a start time and, once resolved, an end time.
Open alerts show up in three main places: cards on the Cockpit, the Alerts page (currently open) and Alerts History (already resolved).
Severity¶
Level of seriousness for an alert. The platform uses four:
| Severity | When to use | Typical example |
|---|---|---|
| Information | Signal worth following without urgency. | Backup job finished. |
| Medium | Abnormal condition without immediate end-user impact. | Response time above average. |
| High | Real degradation, needs prompt action. | Database replica out of sync. |
| Critical | Outage or imminent risk. | Host down, queue stuck. |
Severity drives which channel receives the alert and at what time. That is decided by notification rules.
Monitoring profile¶
Reusable bundle of metrics and alerts applied to hosts of the same kind. "Linux server", "MySQL", "Cisco switch" are examples of profiles.
When you register a new host and assign a profile, it inherits metrics and alerts automatically. Changes to the profile flow into every host using it.
Local edits clone the profile
Editing a metric or alert from a specific host's page makes the platform create a local copy of that definition on that host. The copy stops receiving updates from the profile. Useful for one-off adjustments without affecting every host, but worth remembering to avoid leaving a host stuck on an outdated version of the profile.
Notification channel¶
Destination where alerts leave the platform. Each channel is an integration you configure: Slack, Microsoft Teams, Telegram, WhatsApp, email, webhook, mobile push.
You can have as many channels as you want. Teams usually keep separate channels per area (infra, database, network) to avoid drowning a single Slack with everything.
Notification rule¶
Defines which alert goes to which channel and when. A rule combines conditions (severity, tags, hosts, schedule) with one or more destination channels.
Examples:
- Anything critical on databases goes to Slack #db-oncall, no quiet hours.
- Anything medium on infra hits the team's email, business hours only.
- The ITSM webhook receives high and critical to open tickets automatically.
Rules are what prevents the classic "nobody saw the alert because it went to the wrong channel".
Maintenance¶
Time window in which alerts on a set of hosts are suppressed (no notifications). Useful for deploys, hardware swaps, planned tuning.
During maintenance the platform keeps collecting data but does not push notifications to channels. When the window ends, behavior returns automatically.
Dashboard¶
Custom visual panel with charts, counters and lists. The platform ships the Cockpit ready (overview of the environment), and each user can build their own dashboards under My Dashboards.
Discovery¶
Automatic process that finds new resources in the environment so you do not have to register them one by one. It can discover:
- Hosts within a network range.
- Databases inside an already monitored server.
- Containers in a Kubernetes cluster.
After discovery, resources show up for review before joining regular monitoring. You decide what to accept.
Audit trail¶
Record of what each user did on the platform: who created or edited a channel, who suppressed an alert, who changed a rule. Available under Administration → Audit Trail.
Where you find it in the UI¶
| Term | UI location |
|---|---|
| Tenant | Top bar, next to the user name. |
| Hub, Agent | Administration → Agents & Hubs. |
| Host | Infrastructure → Hosts, Applications → Databases and similar. |
| Metric, Alert | Inside a host's detail page, Collected Metrics and Configured Alerts sub-tabs under Configuration. |
| Open alert | Observe & Explore → Alerts (open ones) and History. |
| Channel, Rule | Notifications → Channels and Notifications → Rules. |
| Maintenance | Administration → Maintenances. |
| Dashboard | Cockpit and My Dashboards. |
Next steps¶
-
Quickstart
Put these concepts to work on a guided 15-minute tour of the interface.
-
Add a host
Install the agent on a server and watch the metrics show up on the panel.