Operations Notes
In this section, we provide some notes that could be of interest for operations.
Important
As we have many different variations of the products, especially in operations, all examples here are provided in the barest way in form of docker commands. Please adapt that to whatever suites your environment.
Triggering loads
In all of those example, we assume that
- You deployed our application already
- Our application shares a network
app_network
- RabbitMQ is running as service
rabbitmq
and is reachable under that name in theapp_network
All examples run a new rabbitmq container, will send a message and then exit. As such, the exact version of RabbitMQ that
you use there is not really relevant - it is only used as a client to send a message. But feel free to change the latest
label to whatever you have running as a server.
You can also exec into a running rabbitmq container and just execute the relevant rabbitmqadmin
command.
Trigger actions through Graviton Messenger
Messenger is mainly a messaging middleware - many actions it does are mainly coordinated things that could triggered directly but through different means.
But we implemented a simple way to trigger the most common actions through queue messages, Messenger will then do whatever is needed in those cases.
Commands
Trigger a full “BSA load”:
docker run --rm \
--network app_network \
nexus.pub.swisscom.evoja.scbs.ch/evoja/rabbitmq:latest \
rabbitmqadmin --host=rabbitmq --username=guest --password=guest --vhost=/ publish exchange=messenger routing_key=messenger.load payload=BSA-FULL
Only download the new files from BSA:
docker run --rm \
--network app_network \
nexus.pub.swisscom.evoja.scbs.ch/evoja/rabbitmq:latest \
rabbitmqadmin --host=rabbitmq --username=guest --password=guest --vhost=/ publish exchange=messenger routing_key=messenger.load payload=BSA
Trigger a eVoja Data Load:
docker run --rm \
--network app_network \
nexus.pub.swisscom.evoja.scbs.ch/evoja/rabbitmq:latest \
rabbitmqadmin --host=rabbitmq --username=guest --password=guest --vhost=/ publish exchange=messenger routing_key=messenger.load payload=EVOJA
Trigger a Swissquant Data Load:
docker run --rm \
--network app_network \
nexus.pub.swisscom.evoja.scbs.ch/evoja/rabbitmq:latest \
rabbitmqadmin --host=rabbitmq --username=guest --password=guest --vhost=/ publish exchange=messenger routing_key=messenger.load payload=SWISSQUANT
Trigger actions through Graviton Loader
You can also send a message directly to Graviton Loader to just trigger load elements that are relevant to eVoja.
Graviton Loader takes JSON as message payload. You specify what to load through the parameters.load
element, and
you can control if dependencies should be loaded by the parameters.loadDeps
boolean element.
Commands
You can trigger the entire bulk load with the ALL
element:
docker run --rm \
--network app_network \
nexus.pub.swisscom.evoja.scbs.ch/evoja/rabbitmq:latest \
rabbitmqadmin --host=rabbitmq --username=guest --password=guest --vhost=/ publish exchange=ml3k routing_key=ml3k.load \
'payload={"loadId":1,"parameters":{"load":"ALL","loadDeps":true }}'
You can trigger a single element (and only that, without dependencies) with its name (like Customer):
docker run --rm \
--network app_network \
nexus.pub.swisscom.evoja.scbs.ch/evoja/rabbitmq:latest \
rabbitmqadmin --host=rabbitmq --username=guest --password=guest --vhost=/ publish exchange=ml3k routing_key=ml3k.load \
'payload={"loadId":1,"parameters":{"load":"Customer","loadDeps":false }}'
You can trigger multiple elements comma seperated without dependencies (like Customer and Account) like this:
docker run --rm \
--network app_network \
nexus.pub.swisscom.evoja.scbs.ch/evoja/rabbitmq:latest \
rabbitmqadmin --host=rabbitmq --username=guest --password=guest --vhost=/ publish exchange=ml3k routing_key=ml3k.load \
'payload={"loadId":1,"parameters":{"load":"Customer,Account","loadDeps":false }}'
RabbitMQ notes
Reactions to memory problems
There are (but should not) scenarios, where RabbitMQ allocated unusual amounts of memory.
This is mainly caused by the fact that temporary queues have been opened, received messages, but those messages were never collected (for whatever reason). This was
historically caused by Graviton Loader, but was optimized in version 3.1.0
which was included since release EVO20R1 BF2
.
In earlier releases, there could be situations where RabbitMQ reaches its memory high watermark (which defaults to 40%) and somes messages could be dropped or not be accepted for delivery.
As a workaround, you can either remove any container memory limit to a degree that 40% of that limit is sufficient, or you can
set a new memory high watermark by setting the environment variable RABBITMQ_VM_MEMORY_HIGH_WATERMARK
to a higher value
(like 0.8
or 0.9
) and redeploy.
Generally, if you have a Graviton Loader version older than 3.1.0
, you are advised to update to fix that problem.
Analysis
RabbitMQ offers some handy commands that gives you insights into what is going on.
Firstly, it’s easiest to just expose (or otherwise access) port 15672
of the RabbitMQ container - there, a nice Web interface
awaits you (default credentials guest
/guest
) where you can see everything. Just do that.
If for some reason you can not do that, exec
into the running RabbitMQ container. There, with the rabbitmqctl
command, you
can query everything that you may want to know.
Please check the official documentation for the tool for whatever you need to know.
Some examples here:
List all queues
bash-5.0# rabbitmqctl list_queues
Timeout: 60.0 seconds ...
Listing queues for vhost / ...
name messages
clan 0
ssp 0
ml3k-controller 0
statekeeper 0
amq.gen-wmcsW_6-Vu2jfqamtsF4Qg 0
notification-email 0
statekeeper-queue 0
ml3k-Stager 0
ml3k-TargetLoader 0
statekeeper-ml3k 0
ml3k-daemon 0
List all exchanges
bash-5.0# rabbitmqctl list_exchanges
Listing exchanges for vhost / ...
name type
amq.direct direct
amq.fanout fanout
direct
amq.rabbitmq.trace topic
amq.match headers
amq.headers headers
statekeeper topic
amq.topic topic
ml3k topic
List all consumers (connections)
bash-5.0# rabbitmqctl list_consumers
Listing consumers in vhost / ...
queue_name channel_pid consumer_tag ack_required prefetch_count active arguments
clan <rabbit@acde2b545329.1591648064.1087.0> amq.ctag-Y7gGaXAIYXGTXiHKWV6qSw true 0 true []
ssp <rabbit@acde2b545329.1591648064.1092.0> amq.ctag-9yODnfvJgvWb0XdFcS-rqQ true 0 true []
statekeeper <rabbit@acde2b545329.1591648064.1031.0> amq.ctag-RQUWPKSpUhpGpJ-O9bkBCg true 0 true []
amq.gen-wmcsW_6-Vu2jfqamtsF4Qg <rabbit@acde2b545329.1591648064.30675.1> ml3k false 0 true []
notification-email <rabbit@acde2b545329.1591648064.1063.0> amq.ctag-o6tjMxqlibGWqBr6SrAzCw true 0 true []
statekeeper-queue <rabbit@acde2b545329.1591648064.1043.0> amq.ctag-k6VdrVUBn2e6Nt6FRgQSoA false 0 true []
statekeeper-ml3k <rabbit@acde2b545329.1591648064.1047.0> amq.ctag-7VlxbdDByAT6rnafbHeyTw false 0 true []
ml3k-daemon <rabbit@acde2b545329.1591648064.30675.1> controller false 0 true []
Each command also allows you to pass a list of elements (in case you need more information).
So to list all queues with specific fields:
bash-5.0# rabbitmqctl list_queues name,pid,exclusive,messages_ready_ram
Timeout: 60.0 seconds ...
Listing queues for vhost / ...
name pid exclusive messages_ready_ram
clan <rabbit@acde2b545329.1591648064.1101.0> false 0
ssp <rabbit@acde2b545329.1591648064.1096.0> false 0
ml3k-controller <rabbit@acde2b545329.1591648064.2027.0> false 0
statekeeper <rabbit@acde2b545329.1591648064.1056.0> false 0
amq.gen-wmcsW_6-Vu2jfqamtsF4Qg <rabbit@acde2b545329.1591648064.30683.1> true 0
notification-email <rabbit@acde2b545329.1591648064.1079.0> false 0
statekeeper-queue <rabbit@acde2b545329.1591648064.1067.0> false 0
ml3k-Stager <rabbit@acde2b545329.1591648064.30661.1> false 0
ml3k-TargetLoader <rabbit@acde2b545329.1591648064.30647.1> false 0
statekeeper-ml3k <rabbit@acde2b545329.1591648064.1086.0> false 0
ml3k-daemon <rabbit@acde2b545329.1591648064.30678.1> false 0
You will find all possible values for the fields in the official documentation as referenced above.
Verbose log
If you need debug log output for the RabbitMQ container, you can do that during runtime as described in the official documentation.
exec
into the container and execute:
rabbitmqctl set_log_level debug