Given that we’ve been in business since 1997 some of our clients have been with us for a very long time.  We have a few significant sites that are still running on Iguana 3 and it can be quite a mental leap to cross the chasm from Iguana 3 into the modern version of Iguana. It’s almost a completely different product.

The good news is that all the important guts are there – Iguana 5 has all the same abilities as Iguana 3 to run the older vmd/chameleon/python based logic. So it’s no problem to upgrade and still be able to run all the same interfaces that you run on the older platform.

The bad news is that from Iguana 4 onwards there was a big change in how Iguana implemented queuing and logging.  In Iguana 3 queuing and logging was performed within a SQL database as provided by the user. The change made Iguana infinitely more robust since it removed a major potential point of failure so overall it was a big step forward for Iguana. However it posed a problem for some of our customers since some of them have put a lot of creativity into building custom monitoring solutions that were dependent on that original SQL database.

The problem is of course that these custom monitoring solutions need to re-done in a different manner.

It’s not all bad. Often we find that customers have often out-grown these custom monitoring solutions. Thing is of course is that everybody starts small and gradually grows to have a larger and larger set of interfaces. I always think of lobster sitting in a pot of water that slowly gets hotter and hotter… Email alerts seem great at the beginning but can become overwhelmingly confusing once you start to get dozens of false email alerts in your mailbox – alert fatigue sets in and so we often find clients can get value in re-doing these systems.

Taking time to rethink your monitoring strategy during the upgrade to Iguana 5 is a great time to do it. One of the odd ironies about Iguana is that we finding more and more of our customers are starting to use Iguana not just as an interfacing platform – but a monitoring platform! It’s actually way more flexible than most standard monitoring tools because:

1. It’s easy to grab data from all different kinds of sources with the translator – database queries, invoking command line utilities, web service calls etc. etc.
2. Manipulating that data and writing business and threshold handling logic is dead easy.
3. There are easy calls to send email, you can push tickets into tickets systems with HTTP calls etc.
4. You can nicely present the monitoring data in custom dashboards like this example and this one.

The simple high level strategy you want to aim for is to have your alert system work with this basic work flow:

1. Alerts via email etc. should only send out one email within say an hour.
2. The email content should have a summary of the issues that are present.  See ‘Artfull Integration’.
3. The email should preferably link to a nice web dashboard that shows a summary of the issues and allows drilling in deeper.

So with respect to the datasources in Iguana where should you get the information that you want to monitor on?  I’ll go through the various categories and explain what they are useful for.

To start with we have the monitor API which gives detailed status information on each channel and also on low level information about the operating system and Iguana process – memory usage, disk usage, open socket count, open file handles and other information.

Next you have complete random access to the content of the logs and queuing system though this RESTful API. That can be very useful for getting access to everything that Iguana logs. Once you remember that your code can also log whatever it likes to the iguana log using commands like iguana.logInfo and iguana.logWarning which allow you to write to the Iguana log.

The final technique which can be very useful is to have your scripts write out information to SQL databases on key events in the lifecycle of when a message is processed. SQLite is one easy option here since it comes embedded into Iguana itself – we tend to use it for our examples because it comes in Iguana but you can use your own database of choice.

The trick here is to leverage the fact that Iguana maintains a unique ID for every message which goes through the system – the refid number. You can get this number from iguana.messageId(). You can use this as a foreign key to record other events which happen during message process like:

• Confirming that a result reached an outbound channel and was transmitted.
• Flagging some type of rejection
• etc.

One small challenge with this is if you have using older style vmds and python scripts they may not have access to these Lua APis. However a simple solution path exists. Have a read of how you can embed such interfaces within the context of a Lua translator.

So putting these data sources together and using the techniques we show in the wiki allows one to implement any type of monitoring requirement.

You can also do cool things like have a link to a message in the Iguana log viewer from your own web screens – see this reference.

If you have any questions or want to learn more do feel free to ask. Monitoring is a big topic in the master classes I give on Iguana.