Grassfish’s monitoring and oberservability strategy includes the following processes:
Infrastructure monitoring
Monitoring differs based on the deployment model:
Container setup (standard): The container setup uses Alloy, Grafana, Loki, Prometheus, Tempo, and Zabbix for metrics collection and visualization. Azure-native metrics are also available.
VM setup (legacy): The classic VM setup uses Zabbix for infrastructure and service-level monitoring.
Typical monitoring includes:
CPU and memory utilization
Disk usage
Service and endpoint availability
Node and pod health (Kubernetes)
 Monitoring stack |  Example: Prometheus metrics |  Example: Loki logs |
Application monitoring
Dashboards provide visibility into core application components:
Player status (online/offline)
Health of core services and scheduled jobs
Status of imports, feeds, and data pipelines
Errors are logged in a structured way. A built-in changelog records key actions in the CMS, such as configuration changes and deployments.
Business monitoring
Business-level monitoring focuses on operational KPIs, including:
Number of offline players
Bookings without assigned content
Feeds or data sources not updated within a defined timeframe
These metrics help detect issues that directly affect content delivery and operational performance.
Logging and alerts
Logging and alerts work in the following way:
WAF logs: WAF logs are ollected in Azure Log Analytics.
System logs: System logs can be aggregated using tools such as Grafana and Loki.
Common alerts include:
Players offline for extended periods
Missing or malfunctioning feeds
Elevated error or timeout rates in core services
Integration with external monitoring or security information and event management (SIEM) platforms is supported through standardized interfaces, supporting both pull and push models depending on the target system.