Page History
Include Page | _DcmArchitectureBetaLabel | _DcmArchitectureBetaLabel |
---|
Table of Contents |
Scaling/availability
Blueriq services
- For the beta version, delivered with Blueriq 15.0development versions, we support a single instance of each component described in the Blueriq DCM architecture overview.
- In the first non-beta version (release date not known yet)production versions, we will support two scalability aspects:
- Multiple runtimes for user interaction, with sticky sessions
- Execute automatic tasks in parallel on a single runtime AND use multiple runtimes for executing automatic tasks
- In the further future, we intend to support:
- Multiple runtimes for user interaction with external sessions (Redis)
- Multiple case enginesOnly when using Oracle as a database
Dashboarding
Using the DCM dashboard architecture scaling/availablity and failover is supported for all services and components. This approach is only supported by configuring services to use external sessions (redis).
Third party services
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:
Third party software | Link |
---|---|
RabbitMQ | https://www.rabbitmq.com/clustering.html |
MongoDB | https://www.mongodb.com/basics/scaling |
Oracle database | https://blogs.oracle.com/exadata/post/horizontal-scaling-with-oracle-database |
MSSQL | https://docs.microsoft.com/en-us/previous-versions/msp-n-p/dn589797(v=pandp.10) |
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