Operating System Service Monitoring with Entuity: Architecture and Technical Details
OS Service Monitoring With Entuity: Architecture And Technical Details. From the whitelist logic that prevents Tomcat from accidentally triggering "not running" alerts on 90 servers, to the directory permissions required for Solaris SMF — a closer look at how Entuity designs OS Service Monitoring.
Entuity approaches OS Service Monitoring not as a single generic "service check", but through four distinct, platform-specific monitoring models (systemd, Windows Service, Solaris SMF, IBM i Subsystem). The services to be monitored are filtered via whitelist rules, View-Based profiles precisely control which service is applied to which server group, and the entire mechanism can be managed programmatically via a RESTful API.
Why Generic Service Monitoring Falls Short
A classic service monitoring approach checks a service name (e.g., Tomcat) against all servers in the network. However, if only 10 out of 100 servers actually run Tomcat, this approach generates meaningless "service not running" events and incidents on the remaining 90 servers. Entuity's architecture solves this problem with a two-layered filtering model: Whitelist Rules and View-Based Profiles.
Platform-Based Monitoring Models
Entuity specifically uses the term "OS Service" to distinguish it from its own internal service concept (Entuity Services). As of v20.0 P03, this scope spans four platforms:
| Platform | Monitored Unit | Minimum Version |
|---|---|---|
| Linux | systemd Services |
v20.0 P03 |
| Windows | Windows Service | v20.0 P03 |
| Solaris | SMF (Service Management Facility) | v23.0 |
| IBM i | Subsystem | v23.0 P01 |
Each platform communicates using its native service management model; meaning Entuity relies on systemd's unit state model in Linux, and SMF's own state machine in Solaris — without forcing them into a single abstraction layer.
Authorization Architecture
The permission model is two-tiered: rule management and data viewing are separated.
-
Rule Mgmt.
Rule Management Only the Administrator role can access the
OS Service Managementpage to create/edit whitelist rules. -
Viewing
Data Viewing All users can view the generated Service State and Service Status attributes and events — without needing rule authoring permissions.
Solaris-Specific Requirement: If a non-admin account is to be used for SMF monitoring, this account must have Read access under /usr and /etc, and must be assigned to the Service Management or Service Operator profile (or directly granted solaris.smf.manage and solaris.smf.modify authorizations). This is a requirement that aligns with SMF's own RBAC (Role-Based Access Control) model — Entuity ties its own permission layer to Solaris's native authorization system.
Whitelist Rule Engine
The OS Service Management page creates a set of filtering rules for the service/server combinations to be monitored. This is not a "monitor everything and filter the noise later" model, but a "monitor only what is explicitly defined" model — meaning it is closed by default (Deny-By-Default), and only explicitly added services are monitored. This design choice aims to prevent event noise at its source in large-scale environments.
View-Based Profiles: Precision Targeting
Introduced in v21.0 P03, this layer adds a second filtering dimension on top of the whitelist. The logic works as follows:
Servers covering all servers, and Webservers covering only web servers.Web) is created; the Webservers View is added to this profile, and the Tomcat OS Service is associated with this profile.Tomcat rule is restricted to run only against Views tagged with the Web profile.The result: The Tomcat check is now applied only to the 10 servers that actually host Tomcat; the other 90 servers are entirely unaffected by this rule. The ability for a device to be in multiple Views and therefore multiple profiles provides flexibility in mixed environments (e.g., a server hosting both web and database services) — this is a Many-To-Many mapping model.
Visualization Layer: The Difference Between Dashboard And Dashlet
Two different views serve two different use cases:
-
Dashboard
OS Services Dashboard Focused on a single server — lists all services and their statuses on that specific server.
-
Dashlet
OS Services Dashlet Displays all monitored services according to the whitelist in a single table; clicking a service leads to that object's Summary Dashboard.
Programmatic Management: RESTful API
Rule management can be done via the API just as well as through the UI — this allows rules to be managed in a version-controlled manner using an IaC (Infrastructure As Code) approach, or integrated into bulk server deployment processes:
The Outcome Of Architectural Choices
Entuity's OS Service Monitoring can be read as a combination of three design decisions: platform-specific native monitoring (instead of forcing abstraction), Deny-By-Default whitelist (to cut noise at the source), and View-Based profiles (for targeting precision). Together, these three ensure that the term "service monitoring" remains practically meaningful and manageable across large and heterogeneous server fleets.
Frequently Asked Questions
Q: Which Operating System Service Types Does Entuity Monitor?
It monitors systemd services on Linux, Windows Services on Windows, SMF services on Solaris (v23.0+), and subsystems on IBM i (v23.0 P01+).
Q: Who Can Manage OS Service Rules?
Only users with the Administrator role can access the OS Service Management page to create or edit rules; other users can only view the results.
Q: What Is The Purpose Of View-Based Profiles?
By ensuring an OS Service rule runs only against a specific server group, it prevents the generation of false-positive events on irrelevant servers.
Noiseless, Precise, And Manageable Monitoring
Discover the next-generation service monitoring architecture that eliminates false positives and operates with platform-specific models using Entuity.
Explore Our Entuity Solutions →