This document explains how resource monitoring works on the Segura® Platform, which checks are performed by the Orbit Server Manager, and how administrators are notified when something is outside the expected range.
What is resource monitoring
The Orbit Server Manager continuously monitors the instance resources and the communication between cluster nodes. When a resource falls below the recommended threshold or a communication port stops responding, the system generates an incident in Orbit and notifies the responsible administrators.
The goal is to provide early visibility so that preventive actions can be taken before capacity or connectivity issues make the environment unavailable.
Types of checks
The system performs 4 types of checks periodically and independently.
Appliance minimum resources
The system verifies whether the machine meets the Segura® Platform minimum hardware requirements:
- 8 processors (CPU).
- 16 GB of RAM.
- 500 GB of total disk space, considering the sum of physical disks.
When any of these requirements is not met, an incident is generated in Orbit informing which resource is below the minimum, the current value, and the recommended value. The incident is closed automatically when the resource is adjusted and returns to the minimum recommended value.
The minimum resource thresholds are fixed and are part of the Segura® Platform requirements. They are not configurable in Orbit Web or Orbit CLI, to prevent legitimate alerts from being silenced with values below the supported minimum.
Available disk space
The available space on the session recording partition is continuously monitored. When it falls below 10 GB, a critical incident is generated and the start of new remote sessions is automatically blocked.
In this condition, when attempting to start a session, the user receives the message: "Insufficient disk space. Contact the system administrator."
Sessions already in progress at the time of the block are not affected. Only the start of new sessions is prevented.
When disk space is normalized, the incident is closed automatically and new session starts resume without any manual action.
Communication ports between nodes
In environments configured in cluster mode, the system periodically verifies whether the communication ports between nodes are responding. The list of checked ports is the same as documented in the firewall rules for cluster environments.
- For member nodes: all ports relevant to cluster operation and administration are checked.
- For the arbiter node: only a reduced set of ports is checked, considering that this role does not run the full stack.
When one or more ports do not respond on a node, a specific incident is generated for that node, listing the ports that failed and the service associated with each one. Each node with an issue generates its own incident.
When all ports respond again, the incident for the corresponding node is closed automatically. If the environment leaves cluster mode or the member configuration is changed, all previous port incidents are closed automatically.
In environments that are not in cluster mode, port monitoring between nodes is not executed.
Standalone environment checks
In standalone environments, the instance checks its own service ports: Web Proxy, Terminal Proxy, RDP Proxy, and application port 443. If a service is running but the port is not responding, this may indicate a network or firewall issue.
Notifications
When an incident is created or updated, notifications are sent to:
- Orbit incident panel.
- Email of the instance administrator configured in Orbit Server Manager > Settings > Application.
- SIEM via syslog.