Ouroboros

Somewhere in the sands of time that represent my association with Essbase, HP had something to do with a log analysis tool. Or maybe it was Dell. I don't remember. But the bottom line is that they decided that subjecting Essbase database logs to Essbase analysis - like a snake eating its own tail. 

The model has User, Action, Server, App/Database, Date, DayOfWeek, Hour of Day.

When you have 300 users of an application and logs going back several years you can make some awesome histograms.

One of the forgotten arts surrounding Essbase development is the use case approach to reporting. So often, the constraint of development resources and more importantly environmental constraints stop organizations from building specific data marts for specific use cases. When this happens IT teams overcommit to building a single cube for all users. This follows an unfortunate misinterpretation of 'a single version of the truth' when in fact it's more like 'too big to fail'. Enormous amounts of time, energy and frustration go into making sure that one cube doesn't disappoint, and yet it inevitably does. It's got one dimension that 70% of the users don't use. It's got a whole slew of old accounts in the dimension that are no longer active. It's carrying history that nobody actually queries. It's not ready for the crush of activity at month end close. And nobody wants to make any changes in production. 

All these problems can be solved by re-engineering the cube and our team is working to make all of that easy again. Ouroboros is our extended analytic tool that takes Essbase logs, both the database log and the Essbase agent log and convert them into two Essbase cubes that show user activity. This is nothing particularly earth shattering or novel, but it's part of a more comprehensive package of performance monitoring at the application level that lends itself to making more information available to everyone. This information is actionable because we are drastically reducing the cost of redesign, rearchitecture and our key attribute elasticity. Add this to performance monitoring and application migration at the system level and you gain the ability to add arbitrary amounts of capacity on demand. All with objective evidence generated by the platform itself. 

Comments

[Sébastien Roux]

Seems interesting, is or will this tool be available to the essbase community?
I'm sure you had a look at rightlog or jrightlog utilities available on google code hosting, hoping they inspired you...

[Cobb]

I have previously taken a peek at rightlog, and looked again this morning. 'Ouroboros' is a ruby re-implementation of a Perl script that Rohit Amarnath provided me which I understand to be soemthing reverse-engineered from an Essbase outline. From that code, I left in a concept that I don't really use which is a method to reduce the number of Essbase codes to consider. But much more of the system is managed on the Essbase side of things. Rightlog offers more control and embedded options and appears to me to be more suited as a standalone tool, no doubt owing to its ability to provide lookups for transaction codes.

It is very likely that as our product strategy matures in this and the next quarter, Full360 will host a number of Ruby projects open-sourced to Github and Sourceforge. I expect that will include, at long last, my hand-built ETL.