routerarchitects/ra-wlan-cloud-analytics

Purpose and entry points

OWANALYTICS is a C++ OpenWiFi/Mango Cloud microservice that ingests AP telemetry, derives device/venue/client metrics, persists historical analytics, and exposes them through REST APIs. Build and process entry wiring are centered on CMakeLists.txt, src/Daemon.cpp, and src/framework/MicroService.cpp. Its public contract is openapi/owanalytics.yaml.

Service runtime and network boundary

The daemon runs three configurable interfaces: public REST (default 16009), internal REST (17009), and ALB health checks (16109). The framework separates public/internal servers and load-balancer health handling in src/framework/RESTAPI_ExtServer.cpp, src/framework/RESTAPI_IntServer.cpp, and src/framework/ALBserver.cpp. Configuration is supplied through owanalytics.properties (with template owanalytics.properties.tmpl).

Telemetry ingestion and event coordination

Kafka is the primary asynchronous integration boundary for device telemetry and microservice coordination. src/framework/KafkaManager.cpp and src/framework/EventBusManager.cpp provide messaging infrastructure; topic definitions reside in src/framework/KafkaTopics.h. Domain receivers—src/DeviceStatusReceiver.cpp, src/HealthReceiver.cpp, and src/StateReceiver.cpp—consume and interpret AP status, health, and state streams.

Analytics aggregation and lifecycle

src/APStats.cpp is the core AP-statistics aggregation model. src/Dashboard.cpp and src/VenueCoordinator.cpp organize telemetry into operational/venue-level views, while src/VenueWatcher.cpp tracks venue-related changes. A likely primary flow is: Kafka telemetry → receivers → AP/client/venue aggregation → storage and API-visible summaries.

Client telemetry and historical persistence

Wi-Fi client association and radio/bandwidth history are maintained through src/WifiClientCache.cpp and persisted by src/storage/storage_wificlients.cpp. Device and time-series persistence are separated into src/storage/storage_boards.cpp and src/storage/storage_timepoints.cpp; src/StorageService.cpp coordinates the storage layer. PostgreSQL and MySQL are material build/runtime integration points, indicated by cmake/FindPostgreSQL.cmake and cmake/FindMySQL.cmake.

API composition and downstream integrations

Analytics REST routing is centralized in src/RESTAPI/RESTAPI_routers.cpp. Board/device, timepoint, and client-history query handlers live in src/RESTAPI/RESTAPI_board_handler.cpp, src/RESTAPI/RESTAPI_board_timepoint_handler.cpp, and src/RESTAPI/RESTAPI_wificlienthistory_handler.cpp. Typed request/response models for peer OpenWiFi services are in src/RESTObjects/, while src/framework/AuthClient.cpp enforces intra-service authentication via OWSEC tokens and src/sdks/SDK_prov.cpp integrates provisioning context.

Deployment and operations

The service is containerized by Dockerfile and docker-entrypoint.sh, with PostgreSQL startup coordination in wait-for-postgres.sh. Kubernetes deployment is packaged as a Helm chart, primarily helm/templates/deployment.yaml, helm/templates/service.yaml, and helm/templates/ingress.yaml. The system runs within the broader OWSDK ecosystem, notably OWGW as telemetry/controller source, OWSEC for auth, and OWPROV for provisioning/venue relationships.