Data Collection Extension service (DCX) extends the communication capability of Kaa Protocol (1/KP) by implementing Data Collection Protocol (2/DCP). DCX supports this extension protocol to receive endpoint data from a communication service and send it to data receiver services for storage and/or processing.
DCX supports a number of interfaces to perform its functional role. The key supported interfaces are summarized in the following diagram.
For inter-service communication, Kaa services mainly use REST APIs and messaging protocols that run over NATS messaging system.
Extension service protocol
DCX does not respond to communication service, unless:
- request processing status is requested by setting non-empty
requestIDin the Client Data message;
- DCX encounters a message processing error.
Data sample transmission protocol
DCX acts as a data transmitter service in line with 13/DSTP. All received data samples are transferred to the configured data receiver services using 13/DSTP.
You can configure Kaa to simultaneously send data to multiple receivers, including your custom ones.
DCX supports receiving acknowledgements from reliable receivers. When such receivers are configured, DCX waits for each of them to confirm a successful receipt of endpoint data before responding back to the communication service.
DCX is integrated with the Kaa Tekton for centralized application configuration management. It receives configuration update messages from Tekton over 17/SCMP and uses Tekton REST API to retrieve current configs.
See configuration for more information.
Kaa Tenant Manager integration
DCX supports multi-tenancy with each tenant using a separate OAuth 2.0 issuer for authentication, authorization, and resource management. The list of the existing tenants is managed by [the Kaa Tenant Manager][Tenant Manager], which provides REST API for retrieving tenant security configs.
See the security configuration for more details on how to enable multi-tenancy in DCX.
DCX exposes an HTTP-based management interface with the following endpoints:
GET /healthreturns 200 OK if the service is up and running properly, and 500 Internal Server Error otherwise. In case of errors, the response payload contains their human-redable descriptions. This endpoint can be used by Kubernetes for liveness and readiness probing.
GET /metricsprovides service metrics in Prometheus text-based format.