Storwize Monitoring DIY

The whole thing started with some performance hits on a database application sitting on a iSeries system. Not having some ready to serve expertise in-house with these older systems and applications is a real drag, so when you pitch in to help, there is only so much you can do.

Nonetheless, we coordinated to trial and error it, until finding out that the problems were with our #IBM #Storwize #V7000 storage unit; when we set it to replicate to an off-site #V3700, it would lag a bit in some more demanding calls.

So, with most of our stuff we can easily correlate trends from various sources to paint a pretty good picture of what's used throughout the duration of any particular call. But the limited scope of performance monitoring in the storage systems became a serious problem.

So I started looking into it, and managed to get some good data up onto a free mysql database, and have been able to say that the performance impact is really not due to capacity limitations on the units. Which is good because further enhancing these things is a costly upgrade, and the folks in the iSeries world were not expecting it.

As it happened, these couple of weeks have been terrible in the trenches, and in providing some extra hands to help out dealing with some #bluekeep prevention and upgrading Cisco Call Managers and circuits, while some lengthier procedures were being done I found myself gravitating to this little code project.

It is yet to be a complete package, but it now has multiple device support, secured configuration and automation, and spits out some nice graphs that show me what's going on. There's still a ways to go, so let's see where it will go!