On this page

Platform Overview

Mugnsoft is a distributed Application Performance Monitoring (APM) platform built from four core components that work together to monitor, alert, and integrate with third-party systems.

The Four Core Components

The Mugnsoft platform is composed of four independent, self-contained services. Each runs as a native system service (Windows or Linux) and communicates over HTTPS with mutual TLS (mTLS) authentication.

Component Default Port Role
Webserver 8050 (API) / 9090 (WebUI) Central management hub, web interface, and API gateway
Monitor 8051 Distributed monitoring probe that executes checks
Integrator 8052 Data aggregation hub and third-party forwarding engine
Sentinel Agent 8070 System and process metrics collector, service discovery

Component Roles

Webserver (Central Management)

The Webserver is the brain of the platform. It provides:

  • Web UI for managing all monitors, components, users, reports, and downtimes
  • REST API (Swagger-documented) for programmatic access
  • Component orchestration – registers and manages all remote components
  • Data visualization – dashboards, graphs, heatmaps, timeline views
  • Report generation – scheduled and on-demand performance reports
  • User management – role-based access control (Admin, User, Viewer) with tag-based scoping
  • SMTP, Slack, GitLab, and LDAP integration at the platform level

The Webserver does not execute monitors itself. Instead, it delegates execution to registered Monitor probes and pulls results from them.

Monitor (Monitoring Probe)

The Monitor is a distributed probe that executes monitoring checks. You can deploy multiple Monitor instances across different locations for distributed monitoring. Each Monitor supports:

  • 9 monitor types: Web UI (Selenium), HTTP/HTTPS URL, REST API, TCP Port, ICMP Ping, DNS Lookup, SNMP, Database Query, System Metrics
  • Cron-based scheduling with intervals from 1 minute to custom cron expressions
  • Browser automation via Selenium WebDriver (Chrome, Firefox, Edge)
  • Auto-thresholding using statistical analysis of historical data
  • Local storage in the embedded key-value store (no external database required)
  • Direct alerting via Email, Slack, Microsoft Teams, and PagerDuty
  • Vault integration for secret management (HashiCorp, Azure Key Vault, CyberArk)

Integrator (Data Hub)

The Integrator is a high-throughput data forwarding engine that receives monitoring results and dispatches them to third-party systems:

  • Push integrations: InfluxDB (v1/v2/v3), Splunk HEC, Elasticsearch, Kafka, Canopsis
  • Pull integrations: Zabbix (queries the Integrator’s KV store)
  • Data export: CSV and JSON file output
  • Worker pool architecture for high-throughput processing (configurable workers and queue size)
  • Multi-channel alerting: Email, Slack, Teams, PagerDuty, custom scripts
  • Connection pooling for all outbound integrations

Sentinel Agent (Infrastructure Discovery)

The Sentinel Agent monitors the host it runs on and discovers services:

  • System metrics: CPU, memory, load average, filesystem usage, TCP sockets, I/O wait
  • Process monitoring: per-process CPU, memory, swap, I/O, network traffic, threads, file descriptors
  • Network discovery: packet capture (pcap) for traffic analysis, connection mapping
  • Service discovery: process name matching, port monitoring
  • Threshold-based alerting: fixed or auto-calculated thresholds per metric
  • Network topology: Cytoscape-format graph generation for network visualization

High-Level Architecture Diagram

graph TD User["👤 User / Browser"] WS["Webserver
API :8050 | WebUI :9090"] MON1["Monitor Probe 1
:8051"] MON2["Monitor Probe 2
:8051"] INT["Integrator
:8052"] DA["Sentinel Agent
:8070"] INFLUX["InfluxDB"] SPLUNK["Splunk"] ELASTIC["Elasticsearch"] KAFKA["Kafka"] ZABBIX["Zabbix"] User -->|"HTTPS"| WS WS <-->|"mTLS"| MON1 WS <-->|"mTLS"| MON2 WS <-->|"mTLS"| INT WS <-->|"mTLS"| DA MON1 -->|"push results"| INT MON2 -->|"push results"| INT DA -->|"push metrics"| INT INT -->|"push"| INFLUX INT -->|"push"| SPLUNK INT -->|"push"| ELASTIC INT -->|"push"| KAFKA ZABBIX -->|"pull"| INT style WS fill:#4a90d9,stroke:#2c5ea0,color:#fff style MON1 fill:#5cb85c,stroke:#3d8b3d,color:#fff style MON2 fill:#5cb85c,stroke:#3d8b3d,color:#fff style INT fill:#d9984f,stroke:#b07830,color:#fff style DA fill:#9b59b6,stroke:#7d3c98,color:#fff

Key Design Principles

Databaseless Architecture

All components use an embedded key-value store. There is no external database to install, configure, or maintain. Each component manages its own local data files.

Self-Registration

Components self-register with the Webserver on installation. During registration, they exchange TLS certificates for mutual authentication and send their configuration for centralized management.

Distributed by Design

You can deploy multiple Monitor probes across different networks and locations. Each probe operates independently and the Webserver aggregates results from all of them.

Security First

All inter-component communication uses mTLS (mutual TLS). Authentication tokens use RS256 JWT with RSA key pairs generated at installation time. Sensitive configuration is encrypted at rest using AES-256-GCM.

Cross-Platform

All components compile to single native binaries for both Windows and Linux, with platform-specific optimizations (e.g., Windows service management via SCM, Linux systemd integration, platform-specific ICMP handling).

See also

Translations

Data Flow