...

Scaling/availability for third party services (RabbitMQ, MongoDB, Oracle/MSSQL) needs to be configured in these applications. Each of them provides information on how to scale:

Backup strategy

Blueriq stores operational data in several databases. We strongly advise to back up this data, otherwise cases might get corrupt after e.g. a server crash.

...

We advise you to set up your network protection accordingly.

Logging

All of Blueriq's DCM services provide to possibility to configure logging options. Out of the box we use the Logback logging framework integrated via Spring, on which we have extensive documentation on how to configure it right here. 

Printing log statements

With Logback you must configure Log Appenders in order to let services output log statements. Some of Blueriq's services contain more than the default Log Appenders which Logback provides out of the box, however over the whole DCM architecture we only support Log Appenders which are delivered by Logback out of the box. A list of Log Appenders which can be used can be found here. 

Log aggregation

As Blueriq's DCM architecture provides multiple services, we highly recommend to think thoroughly about how log statements are safely stored and aggregated. Whether the DCM infrastructure is an fail-over setup or not, log statements should be stored in a centralized manner as they can provide essential information on how an application/services ended into a specific state.

Log storage

There are several tactics on how you can aggregate and store your log statements safely, it all depends on how the infrastructure is deployed. There are three default log configurations which all Blueriq services provide; Console-, File system-, and Socket transfer logging. All of these log configurations have there own benefits and drawbacks.

Console output

The log statements are printed to standard output and standard error (aka console) of the service, when using this configuration your statements are typically stored anywhere other the console of the service. This kind of log configuration can be used when running in a containerized infrastructure as these infrastructures usually provide log aggregation for statements which are directly printed to the console. 

Benefit

• Simple configuration and usually managed by the infrastructure

Drawback

•  Log statements are only available in the console of the service and are not stored out of the box

File system

The log statements are printed to a file on the configured location, when using this configuration your statements are stored in a file or multiple files on a preconfigured path. The configured path could be a path on the local machine, a network share or volume mount.

This kind of configuration can be used when running the service on a traditional infrastructure such as virtual machines or in a containerized infrastructure.

Benefit

• The log statements are directly stored in a file which can be scraped and uploaded to the desired log aggregator

Drawback

• Running out of disk space is a risk which could happen when stored log statements on a file system

Socket transfer

The log statements are send over TCP to the configured socket connection, when using this configuration are statements are not stored directly but can be consumed by an application which listens to a specific port. More information on how to setup a receiving application can be found here.

Benefit

• The log statements can be aggregated by a centralized application which is only responsible for aggregating logs

Drawback

• Another service to manage within your infrastructure