Skip to main content

​
Overview

Monitoring is composed of multiple service layers that collect, transport, store, and serve observability data to operators and automation systems. Understanding the architecture helps administrators plan deployments, troubleshoot ingestion issues, and optimize resource allocation for the monitoring platform itself.
Administrator Access Required — This operation requires the admin role. Contact your Polystack administrator if you do not have sufficient permissions.
Monitoring services are enabled and configured through the deployment console Configuration panel:

Open Configuration

Navigate to the deployment console → Configuration and select the Monitoring tab.

Enable monitoring components

Toggle the monitoring services your deployment requires:

Save and deploy

Click Save Configuration, then navigate to the deployment console → Operations and run a Deploy or Reconfigure for the monitoring services.
Monitoring stack is deployed and collecting data.

​
Architecture Diagram

​
Service Components

​
Component Deep Dive

The Metric Agent runs as a systemd service (monitoring-agent) on every managed node. It scrapes metrics from:
  • Local node exporters (CPU, memory, disk, network)
  • Service-specific exporters registered as scrape targets
  • Application endpoints exposing metrics in the standard format
Agents authenticate to the Monitoring collector using per-node tokens. Tokens are generated during node registration and rotated on a configurable schedule.Default scrape interval: 30 seconds
The Log Collector tails configured log file paths and forwards events to the Log Index. It handles:
  • Multi-line log entries (stack traces, long SQL queries)
  • JSON-structured log parsing for service logs
  • Syslog reception for services that write to syslog instead of files
Log collector configuration is defined in /etc/monitoring/log-sources.yaml on each managed node and managed by the deployment console.
The Alert Engine evaluates all active alert rules against the metric and log streams on each collection cycle. When a rule’s condition is met for the full evaluation period:
  1. An alert event is created and stored
  2. Notifications are sent to all configured channels
  3. The alert remains active until the condition is no longer met (resolution event)
The engine supports inhibition rules and silence matching to reduce notification noise during major incidents or maintenance windows.

​
Deployment Topology

For environments up to ~50 monitored nodes, all Monitoring services can run on a single dedicated node:
  • Metric Store, Log Index, Flow Store co-located
  • Query API and Dashboard on the same node
  • Alert Engine evaluates all rules
  • Estimated resources: 8 vCPU, 32 GB RAM, 2 TB SSD storage

​
Next Steps

Agent Configuration

Deploy and configure monitoring agents on managed nodes

Metric Endpoints

Configure scrape targets and metric namespaces

Log Collection

Set up log source paths and syslog forwarding

Retention Policies

Configure how long metric and log data is retained