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.

DCX interfaces diagram

For inter-service communication, Kaa services mainly use REST APIs and messaging protocols that run over NATS messaging system.

Extension service protocol

DCX implements 2/DCP extension. It uses 4/ESP over NATS to exchange messages with endpoints via communication service.

DCX does not respond to communication service, unless:

  • request processing status is requested by setting non-empty requestID in 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.

Examples of data receiver services in Kaa: Endpoint Time Series service, Kafka Data Collection Adapter, MongoDB Data Collection Adapter.

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.

Tekton integration

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.

Management interface

DCX exposes an HTTP-based management interface with the following endpoints:

  • GET /health returns 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 /metrics provides service metrics in Prometheus text-based format.