- Service configuration structure
- Default configuration
The DCX loads configuration data from a file (typically backed by a Kubernetes config map). The location of the configuration file is sourced from an environment variable. If the service is unable to retrieve the configuration data, it will not start. Refer to the configuration for details.
Service configuration structure
The recommended configuration format is YAML. The below sections describe the officially supported configuration options that influence various aspects of the service functionality. The service may support options other than the ones listed below, but those are not a part of the public API and may be changed or deleted at any time.
DCX uses its service instance name and replica ID for communication with other services and load balancing across replicas (for example, see 3/ISM). You can control the values with the following configuration options:
service: instance: name: <string> # Service instance name, should be unique cluster-wide. "dcx" by default. replica.id: <string> # Service instance replica ID, should be unique cluster-wide. Random string by default. graceful-shutdown: <uint> # Allowed service graceful shutdown period in seconds. 30 seconds by default.
Reliable data receivers
DCX broadcasts data samples received from endpoints to data receivers using 13/DSTP. You can configure DCX to treat some receivers as reliable.
In case there are reliable receivers configured and the client data contains a non-empty
requestID, DCX waits for processing confirmation from each reliable receiver before responding back to the communication service.
If any of the reliable receivers do not respond until the timeout or respond with a failure, DCX delivers an appropriate error code back to the communication service.
If no reliable receivers are configured, DCX immediately responds to the EP with a success status. It also ignores error processing responses from non-reliable receivers.
To configure reliable receivers, use the following options:
kaa: dcx: data-receivers: reliable: # List of service instance names of reliable receivers - <service instance name> confirmation-timeout: <integer> # Maximum duration in milliseconds to wait for response from all reliable receivers. 5 seconds by default.
Many Kaa services can be configured for different behavior depending on the application version of the endpoint the processed data relates to.
This is called appversion-specific behavior and is handled in service configurations under
Alternatively, the application-specific configuration can be sourced from Kaa Tekton.
See the Tekton configuration section to find out how to configure such integration.
Though DCX currently does not support any appversion-specific configurations, it uses the application and appversion names to validate the API calls and protocols data.
kaa: applications: <application 1 name>: # Kaa application name versions: <application 1 version 1 name>: # Kaa application version name
Resource path relaxed validation
DCX expands 2/DCP by handling the extension-specific resource path that starts with
/json instead of fully match to it.
So the devices that automatically append random values to the MQTT topic can communicate with DCX without restrictions.
E.g. the resource path
/json/random_string is handled as the
To enable the relaxed resource path validation follow the below configuration.
kaa: applications: <application 1 name>: # Kaa application name resource-path: relaxed-validation: <boolean> # Enables relaxed resource path validation (when enabled, data collection resource path does not have to match "/json"). False by default.
Endpoint metadata enrichment
During processing 13/DSTP data samples, they can be enriched with endpoint metadata.
Endpoint metadata key-value pairs can be appended to the data sample events under the specified path (
"~ep-metadata" by default).
kaa: epmmp: client: repository: service-instance-name: <string> # Service instance name to access endpoint metadata. "epr" by default. applications: <application 1 name>: data-samples: metadata-enrichment: enabled: <boolean> # Enables enriching data samples with EP metadata. False by default. path: <string> # Non-empty path under which the EP metadata will be placed in the data sample. "~ep-metadata" by default.
DCX supports integration with Kaa Tekton for centralized application configuration management. The below configuration options set up the integration interface.
kaa: tekton: enabled: <boolean> # Enables Tekton integration. False by default. Also can be set with the KAA_TEKTON_ENABLED environment variable. url: <string> # URL of the Tekton service. "http://tekton" by default. Also can be set with the KAA_TEKTON_URL environment variable. scmp.consumer: provider.service-instance-name: <string> # Service instance name of the Tekton service. "tekton" by default. queue-length: <uint> # Maximum queue length for 17/SCMP messages from Tekton. 256 by default.
For the Tekton integration to function, there must be no
kaa.applicationskey in the configuration file. Such configuration, when present, takes precedence over the Tekton-supplied application-specific configs.
Endpoint metadata cache
DCX uses Redis for caching endpoint metadata.
kaa: redis: url: <string> # Redis URL. "redis://redis-dcx:6379/0" by default.
The below parameters configure DCX’s connection to NATS broker, as well as the NATS message adapters used by DCX. Note that for security reasons NATS username and password are sourced from the environment variables.
nats: urls: <comma separated list of URL> # NATS connection URLs kaa: esp.server: concurrency: <uint> # Number of concurrent workers to read messages from communication service. 16 by default. queue-length: <uint> # The maximum amount of messages in the ESP server queue. When the queue is full, new messages will be dropped. 64 * `kaa.esp.server.concurrency` by default. dstp.transmitter: concurrency: <uint> # Number of concurrent workers to read messages from data receivers. 16 by default. queue-length: <uint> # The maximum amount of messages in the DSTP transmitter queue. When the queue is full, new messages will be dropped. 64 * `kaa.dstp.transmitter.concurrency` by default.
Consider configuring concurrency options to at least match the number of CPUs available on your infrastructure.
Authentication, authorization, and multi-tenancy
DCX uses OAuth2 for authentication and authorization when making REST API calls to other services. Authentication and authorization is handled within the scope of a given Kaa tenant. Each tenant has a separate OAuth 2.0 issuer, managed by [the Kaa Tenant Manager][Tenant Manager]. When multi-tenancy is disabled, all authentication and authorization is conducted in the default system tenant (“kaa”).
DCX security is controlled with the following configuration options (for security reasons it is advised to set these via environment variables).
kaa: security: enabled: <boolean> # Enables authentication and authorization. False by default. issuer: <string> # OAuth 2.0 issuer URL for the system tenant ("kaa"). client-id: <string> # Client ID for making requests in the system tenant scope. client-secret: <string> # Client secret for making requests in the system tenant scope. multitenancy: enabled: <boolean> # Enables multitenancy via integration with the Kaa Tenant Manager. Only effective when kaa.security.enabled is set to true. False by default. tenant-manager: url: <string> # URL of the Kaa Tenant Manager that provides security configurations for tenants. "http://tenant-manager" by default.
To control the DCX management interface, use the following configuration options.
service.monitoring: disabled: <boolean> # Disables the monitoring interface entirely. False by default. port: <uint> # TCP port to expose the monitoring server on. 8080 by default.
DCX writes logs to
By default, the service only produces logs at startup, shutdown, or in case of errors.
To enable debug level logging, use the following option:
service: debug: <boolean> # Enables debug level logging, false by default
Keep in mind that enabling debug level logging will produce significantly more log output and degrade the service performance.
Summarizing the above, the default DCX configuration is as follows. Note that no Kaa applications are defined by default—you have to configure those for any specific Kaa-based solution.
service: instance: name: "dcx" replica.id: "<random string generated on boot>" monitoring: disabled: false port: 8080 graceful-shutdown: 30 # seconds kaa: esp.server: concurrency: 16 queue-length: 1024 dstp.transmitter: concurrency: 16 queue-length: 1024 epmmp: client: repository: service-instance-name: epr dcx: data-receivers: reliable: # none confirmation-timeout: 5000 # milliseconds applications: # none nats: urls: nats://nats:4222