NethVoice: Monitor service availability #8093

Description

Add built-in service availability alerts as the first implementation of #8066, so administrators can detect service interruptions before users report them.

NethVoice publishes its own alert rules through the module-provided rules interface from #8100. The metrics module evaluates them for the publishing instance and uses its existing portal and email notification settings.

Scope

• Export systemd service states from the NethVoice and NethVoice Proxy module instances, with automatic registration and cleanup of their monitoring targets.
• Define NethVoice alerts for expected services that remain non-active or missing for five minutes, with critical severity.
• Report an unavailable systemd exporter separately and suppress individual service alerts while the exporter cannot be reached.
• Use built-in defaults without adding alert configuration screens or settings.

The NethVoice Proxy contribution currently provides metrics export only. The service alert rules described below belong to the NethVoice module.

This work covers systemd service availability. Checks inside running containers, call quality, external AI services and configurable alert thresholds belong to the broader parent issue.

Monitored services

Acceptance criteria

• A monitored service that is inactive, failed, activating, deactivating or missing raises a critical alert after five continuous minutes while the exporter is reachable. Short interruptions do not raise an alert.
• Exporter scrape failures raise a separate critical alert after five minutes. Service alerts recover when the corresponding service becomes active again.
• Each service has a distinct alert identity. Alerts identify the service, module instance and node in English and Italian, and recovery of one service or instance does not clear another's alert.
• CTI and Satellite monitoring follows the conditions in the table. If CTI readiness cannot be read, existing CTI rules are retained and previously unmonitored CTI services wait for a successful readiness check or startup request.
• Creation, configuration, integration changes, upgrades, restores and clones refresh the applicable rules. Module removal cleans up its monitoring targets and owned rules without deleting unrelated rules.
• After cloning, the published scrape target matches the running exporter's address and path.
• Alerts use the existing metrics notification flow. Evaluation requires metrics support for module-provided rules.

Verification

Automated coverage includes rule publication and cleanup, optional-service conditions, five-minute timing, missing units, recovery, exporter outages and separation between services and module instances. The integration test setup installs a compatible metrics image, and the live alert suite waits for rule evaluation after metrics startup.

Live checks have verified rule loading and instance scoping, Tancredi and exporter outage/recovery, CTI readiness handling, and Satellite enable/disable transitions. Complete NethVoice image installation, upgrade, backup/restore, cloning and removal workflows still require end-to-end QA, including clone scrape-path consistency. Notification delivery should also be checked through the configured portal or email channel.

References

• Parent issue: NethVoice: Configurable Alerting for Critical NethVoice Events #8066
• Module-provided alert rules: Allow applications to provide their own alert rules #8100
• NethVoice implementation: Add systemd Prometheus exporter nethesis/ns8-nethvoice#907
• NethVoice Proxy exporter: feat(metrics): add systemd exporter nethesis/ns8-nethvoice-proxy#194
• Metrics rule support: feat(alerts): allow module-provided rules ns8-metrics#91