Mistral is a lightweight tool that can be run in production, so you can run Mistral across all your unit tests to look for bad I/O patterns. The easiest way to do that is with a wrapper script that will let you toggle Mistral on and off as needed within Jenkins.
You can run Mistral all the time on your whole test suite, configure it differently for different tests or turn it on and off at random to regression test I/O patterns from time to time.
The goal with any Mistral deployment within Jenkins is to set up Mistral so that it generates no I/O alerts when I/O behaviour is good. Mistral is configured with a contract that specifies what is bad I/O.
We would recommend setting up an I/O monitoring contract with high thresholds for shared resources and strict limits for areas of the file system that applications should not be using in production. This sort of set up would have a very low overhead, whilst providing useful information.
What to do about I/O issues once they have been detected?
If Mistral detects an I/O contract violation you can configure Jenkins to automatically create a Breeze Healthcheck report to help the developer find the cause of the undesirable I/O. This report contains a lot more detail about I/O patterns and dependencies, while being simpler to use.
If that still isn’t enough, Breeze can be used to zoom in on the data and find the exact cause.
We also recommend running more detailed checks with Breeze on realistic use cases prior to a release. This lets you gather more information and check for more problems than you would normally include in your unit tests.
These extra tests can form part of your continuous integration framework and can be used to make sure that specific I/O issues do not return, that no extra dependencies in the application have been introduced and that everything is behaving as it should.
Get in touch if you have any more questions about integrating Mistral with Jenkins.