Logging and monitoring
Logging and monitoring is a rather broad description of a lot of things that are crucial in a healthy middleware solution. Basically it is everything that prevents the middleware from becoming the victim in the “blame game”. It is also important to be the first to be alerted if anything is going wrong and not being the one that is notified by the business of issues.
When designing a process or message flow in the middleware a defencive approach is required and the faults should be visible in logging or in fault or rejection queues. This is an important basis for the monitoring. An error should never pass the middleware undetected.
A healthy middleware solution is crucial in the present time. The uptime of the middleware is maybe more important than the uptime of any connected system. All connected systems rely on the middleware to be up and running when they are.
A few guidelines on monitoring:
- number of messages on queues
All queues should be empty.
- availability of containers
All processcontainers should be up and running.
- content of logfiles
Logfiles should not contain any warning or error message.
And last but not least:
- An Exception should be an exception
An exception that is appearing regularly should correctly be dealt with by the middleware.
Although the monitoring can be done by hand a lot of other tools can help in notifying the right staff like gensys, zabbix and every comparable product. Sometimes a plugin is available to connect to the middleware and sometimes another tool or technique can be used to produce the indicators on which the monitoring tool can trigger a notification. It is important for the tool not to spam the users with too much false positives. Tools should be able to combine events for an escalation. So for example: if A and (B or C) then send alert D.
Below a few triggers that would make sense:
- create an alert if the number of messages on the queue is greater than 10 and the first message is on the queue for more than 2 minutes during “business” hours.
The biggest challange when starting with integration is the fact that developers often think that they should be able to connect their system to an external system. They also often assume that they can create such a connection in lesser time.
In my experience this is partly true. However if the requirements change and the number of connected aplications has grown the maintenance can become a nightmare. Developers of the backend/ERP systems should be able to concentrate on the business logic and not on trivial tasks related to connection issues, tracking and tracing messages, certificates and protocols and of course logging and monitoring of the connections. A middleware application is specialized in these tasks.