Glossary¶

A¶

Acknowledgement (ACK)¶

Operator confirmation that a problem has been seen. Suppresses further notifications until recovery or a new hard state. → Acknowledgements

Active check¶

Check executed by the Vesana server itself (e.g. ping, http from the API host). Deprecated for most use cases — collector is preferred.

Agent¶

Go single binary running on the monitored machine, executing checks locally. Push-based — reports results via HTTPS POST to the receiver. → Agents & collectors → Agent

Agent token¶

Token in format vesana_agent_<32 url-safe chars>. 1:1 bound to a host. Stored as SHA256 hash on the server. Shown exactly once at creation. → Security → Tokens

AI analysis¶

Service-specific diagnosis by an LLM with wiki RAG, web search, and state context. Built into error overview and host detail. → AI chat & analysis

Alert rule¶

Rule defining when a notification is triggered. Thresholds, patterns, escalation, grouping. → Alert rules

API key¶

Token for collectors. Format: custom prefix + 32 bytes. SHA256 hash in api_keys.key_hash. → Security → Tokens

Auto-discovery¶

Automatic detection of new hosts via nmap scan and SNMP sysOID match. Implemented in the collector. → Hosts → Discovery

B¶

Baseline¶

28-day mean + standard deviation per service, stored per 1-hour bucket (168 buckets). Foundation for anomaly detection. → Anomaly detection

Builtin¶

Profiles, profile-checks, or wiki articles shipped with Vesana. is_builtin = true. Updated via seed scripts (UPSERT); modified builtins (is_modified = true) are skipped.

C¶

Check¶

A single measurement — e.g. „CPU load" or „battery voltage". In Vesana realized as profile-check (definition) and host-service (instance). → Profiles & checks

Check mode¶

active (server runs check itself), passive (collector runs remote), agent (agent runs locally).

Check result¶

An incoming measurement with status, value, message, timestamp. Stored in check_results (TimescaleDB hypertable).

Collector¶

Linux VM in the customer network, running remote checks (SNMP, ping, SSH, HTTP). Push-based like the agent. → Agents & collectors → Collector

Compose profile¶

Optional service groups in docker-compose.prod.yml — ai, backup. Activated via --profile <name>.

Custom dashboard¶

Freely configured view from widgets. Variables, sharing, public links. → Custom dashboards

D¶

Dead-agent watcher / dead-collector watcher¶

Background job marking hosts NO_DATA when agent/collector is silent. Distributed lock via Redis ensures only one replica runs.

Dependency¶

Parent-child relationship between hosts or services. Foundation for inhibition. → Dependencies & inhibition

Discovery result¶

Result of a network scan per IP, with sysOID, sysDescr, service detection, suggested profile.

Distributed locking¶

Redis-based lock with 55 s timeout, so watchers run only once in multi-replica setups.

Downtime¶

Planned or unplanned maintenance window during which alerts are suppressed. One-shot or recurring via RRULE. → Downtimes

E¶

Effective config¶

Merge of profile-check default and host-service override. Computed via COALESCE and JSONB merge in SQL. → Profiles & checks → Effective config

Escalation¶

Multi-stage alert strategy: stage 1 (e.g. email to operator), after 15 min unack stage 2 (push to manager), after 60 min stage 3.

F¶

FCM (Firebase Cloud Messaging)¶

Google service for push notifications to Android devices. Vesana can use shared FCM (default) or own Firebase project. → Mobile app → Push

Field encryption¶

AES-256-GCM encryption of sensitive columns (e.g. hosts.snmp_community). Key in FIELD_ENCRYPTION_KEY. → Security → Encryption

H¶

Hard state¶

Status after max_check_attempts consecutive failures. Only hard states trigger alerts. → State model

Heartbeat¶

Regular liveness ping from agent to server (POST /api/v1/agent/heartbeat). Default: every 60 s. Updates agent_tokens.last_seen_at.

Host¶

Concrete monitored machine or device. Has exactly one profile. → Hosts

Host-service¶

Instance of a profile-check for a concrete host. With optional overrides. → Profiles & checks

Hypertable¶

TimescaleDB construct for time-series tables with automatic partitioning. In Vesana: check_results, logs, agent_metrics.

I¶

Inhibition¶

Suppression of alerts for dependent services when the parent host is CRITICAL. → Dependencies & inhibition

Instance UUID¶

Unique ID of an Vesana install, in system_settings.instance_uuid. Created at first phone-home or feedback, race-safe via INSERT ON CONFLICT.

L¶

License tier¶

Community, Pro, Enterprise. → License tiers

Log alert rule¶

Pattern matching on log entries with threshold, absence, or any-match trigger. → Logs

LLD (Low-Level Discovery)¶

Concept from Zabbix for dynamic item generation — e.g. „for each found filesystem, create a disk check". Currently not implemented in Vesana; workaround: agent_services_auto and SNMP picker.

M¶

MIB (Management Information Base)¶

SNMP data description. Vendor-specific (e.g. Cisco-ENVMON-MIB, APC-PowerNet-MIB).

MIB snippet¶

YAML file with vendor MIB knowledge — OIDs, status mappings, discovery hints. → MIB snippets

Mobile push¶

Push notification to the Android app via FCM. Severity filter, user targeting, recovery toggle per channel. → Mobile app

MSP (Managed Service Provider)¶

IT service provider monitoring multiple customer environments. Standard user of multi-tenant mode.

N¶

NO_DATA¶

Status value: no data within expected interval. Orange in UI. → State model

Notification channel¶

Configured output for alerts: email, mobile push, webhook, Slack, Teams. → Notification channels

NSCA¶

Nagios Service Check Acceptor. Legacy protocol on port 5667. Vesana can act as receiver — migration path for Nagios estates. → NSCA migration

O¶

OID (Object Identifier)¶

SNMP identifier, e.g. .1.3.6.1.2.1.1.5.0 for sysName.

Override¶

Host-specific deviation from a profile-check default. → Effective config

P¶

Passive check¶

Check run by a collector (check_mode = passive).

Permission¶

Access bit. Examples: host.create, alert_rule.edit, ai.query. → Roles & permissions

Pipeline health¶

System endpoint /api/v1/admin/health/snapshot with stream backlog, insert rate, DB+disk free, worker pool status. → System health

Profile¶

Device definition with capabilities and visual layout type. → Profiles & checks

Profile-check¶

Check definition per profile. → Profiles & checks

R¶

RAG (Retrieval-Augmented Generation)¶

Technique where an LLM is given relevant context from a database. Vesana uses pgvector + wiki embeddings as RAG source. → AI features

Receiver¶

Ingest service accepting agent and collector packets, writing them to the Redis stream. Fastest path — no DB writes.

Recovery¶

Transition from hard CRIT/WARN to OK. Optional dedicated notification.

Retry interval¶

Shorter interval in soft state, so hard states are detected faster without paying steady-state cost. → State model

S¶

Severity¶

Order: CRITICAL > WARNING > NO_DATA > UNKNOWN > OK.

Soft delete¶

Logical delete via deleted_at column. Items land in trash, physically deleted after 30 days. → Soft delete & trash

Soft state¶

Intermediate state where a check has failed but max_check_attempts isn't yet reached. No alerts. → State model

Status page¶

Publicly reachable page with selected component status. Branding per tenant. → Public status pages

sysOID¶

SNMP object ID identifying a device (.1.3.6.1.2.1.1.2.0). Foundation for profile auto-match.

T¶

Tenant¶

Tenant separator. Each host, alert rule, dashboard has a tenant_id. → Architecture

Tester mode¶

Env bypass for beta testers. All features without license key. → License

track_change¶

Audit helper that stores old_values and new_values of an update operation as JSONB in the audit log. → Audit log

U¶

UNKNOWN¶

Status value: check ran, result not unambiguous. Gray in UI. → State model

Updater sidecar¶

Container that runs GUI updates: pre-update backup, pull, migrations, restart, auto-rollback. → Updates

V¶

Variable (dashboard)¶

Placeholder like $host, $tenant for dynamic widget filtering. Multi-select possible. URL-persisted. → Custom dashboards

Visual type¶

Special hardware visualization per profile (switch_portmap, ups_panel, …).

W¶

Watchdog¶

Background job watching status transitions (dead-agent, dead-collector, service-overdue, downtime-expiry).

Wiki¶

Built-in knowledge base. Markdown, categories, tags, service linking, pgvector embeddings. → Wiki

Worker¶

Consumer service processing Redis stream messages, updating status, evaluating alerts. Multiple instances supported.

Z¶

Zstd¶

Compression algorithm for log packets. Agent compresses log entries before POST.