Links
Comment on page

KubeMQ Bridges

Configuration

KubeMQ Bridges loads configuration file on startup. The configuration file is a yaml file that contains definitions for bindings of Sources and Targets.
The default config file name is config.yaml, and KubeMQ bridges search for this file on loading.

Structure

Config file structure:
bindings:
- name: clusters-sources # unique binding name
properties: # Bindings properties such middleware configurations
log_level: error
retry_attempts: 3
retry_delay_milliseconds: 1000
retry_max_jitter_milliseconds: 100
retry_delay_type: "back-off"
rate_per_second: 100
sources:
kind: source.query # Sources kind
name: name-of-sources # sources name
connections: # Array of connections settings per each source kind
- .....
targets:
kind: target.query # Targets kind
name: name-of-targets # targets name
connections: # Array of connections settings per each target kind
- .....

Targets

Type
Kind
Configuration
Queue
kubemq.queue
Usage
Events
kubemq.events
Usage
kubemq.events-store
Usage
Command
kubemq.command
Usage
Query
kubemq.query
Usage

Sources

Type
Kind
Configuration
Queue
kubemq.queue
Usage
Events
kubemq.events
Usage
kubemq.events-store
Usage
Command
kubemq.command
Usage
Query
kubemq.query
Usage

Middlewares

In bindings configuration, KubeMQ Bridges supports middleware setting for each pair of source and target bindings.
These properties contain middleware information settings as follows:

Logs Middleware

KubeMQ Bridges supports level based logging to console according to as follows:
Property
Description
Possible Values
log_level
log level setting
"debug","info","error"
"" - indicate no logging on this bindings
An example for only error level log to console:
bindings:
- name: sample-binding
properties:
log_level: error
sources:
......

Retry Middleware

KubeMQ Bridges supports Retries' target execution before reporting of error back to the source on failed execution.
Retry middleware settings values:
Property
Description
Possible Values
retry_attempts
how many retries before giving up on target execution
default - 1, or any int number
retry_delay_milliseconds
how long to wait between retries in milliseconds
default - 100ms or any int number
retry_max_jitter_milliseconds
max delay jitter between retries
default - 100ms or any int number
retry_delay_type
type of retry delay
"back-off" - delay increase on each attempt
"fixed" - fixed time delay
"random" - random time delay
An example for 3 retries with back-off strategy:
bindings:
- name: sample-binding
properties:
retry_attempts: 3
retry_delay_milliseconds: 1000
retry_max_jitter_milliseconds: 100
retry_delay_type: "back-off"
sources:
......
Last modified 2yr ago