Bananaz

Observability Architecture · Mobile Casino Platform

Bananaz is a mobile casino platform running across multiple Kubernetes clusters on GCP. Each cluster originally had its own monitoring stack, resulting in three separate Grafana instances with no centralized visibility and no monitoring of PostgreSQL health. To address this, we redesigned the observability architecture by introducing a centralized Grafana instance, deploying Prometheus exporters across all clusters, building custom Cloud SQL dashboards, implementing endpoint monitoring with Uptime Kuma, and establishing a multi-layer alerting system with notifications delivered through Slack and Pushover.

3 → 1

Monitoring stacks consolidated

6 GiB

RAM reclaimed for application workloads

1.5 vCPU

Returned to production clusters

Challenge

The platform operated across three production environments, each with its own isolated Grafana instance. Besides consuming unnecessary cluster resources, these monitoring stacks provided no unified view of the infrastructure. In addition, PostgreSQL (Cloud SQL) lacked proper monitoring, meaning database-related issues were often discovered only after they had already impacted the application. There was also no dedicated solution for monitoring application availability, endpoint health, or SSL certificate expiration.

Objective

Centralize observability across multiple clusters, integrate monitoring for GCP-managed PostgreSQL, implement proactive alerting, and establish independent uptime monitoring capable of detecting service degradation before it affected end users.

What we delivered

Centralized Grafana hosted on a dedicated cluster
Prometheus exporters across production clusters
Cloud SQL datasource integration
Custom PostgreSQL monitoring dashboards
Prometheus-based alerting
Additional GCP-native alerting layer
Uptime Kuma for endpoint availability monitoring
SSL/TLS certificate expiration monitoring
Slack integration for team-wide alerting
Pushover integration to ensure monitoring alerts are delivered directly to engineers' mobile devices

Key advantage

Monitoring workloads no longer compete with production applications for cluster resources. Lightweight exporters run within production clusters, while the core observability stack is hosted separately. The platform now combines infrastructure metrics, database monitoring, endpoint health checks, certificate monitoring, and multi-channel alerting into a single operational workflow.

Outcome

We consolidated three independent monitoring stacks into a single observability platform, providing complete infrastructure visibility from one place while adding dedicated uptime and certificate monitoring.

Removed two full kube-prometheus stacks from production clusters
Reclaimed approximately 6 GiB of RAM and 1.5 vCPU for application workloads
Unified visibility across all Kubernetes clusters and PostgreSQL instances
Added independent endpoint and SSL certificate monitoring through Uptime Kuma
Added Pushover as a dedicated alert delivery channel, ensuring infrastructure and application issues are noticed even when engineers are away from Slack
Enabled proactive alerting, allowing engineers to respond to issues before users notice them

Technologies