ASE Monitoring in the Age of Big Guns…

ASE Monitoring has been once a daunting task.  Not many tools supported ASE.  Those that did did it for a price that cooled enterprise enthusiasm to monitor it at all. Native tools that came with ASE were conspicuously missing.  DBAs (and IT departments harbouring them) were largely left with an option to craft things by themselves, feeding opensource monitoring platforms with custom data which was either polled and displayed or polled, stored and then polled and displayed.

A lot of things changed today.  There are more tools on the market one may point at ASE.  SAP itself continues to diligently craft its SC(C) descendant(s):  ASE Cockpit starts to look as a tool one might indeed want to incorporate into one’s monitoring arsenal.   ASE get’s more and better attention.  The prospects look optimistic.  Technologies evolve.  Tools blossom.

And yet, there are some basic things that did not change in this sphere still:

1. Enterprise tools supporting ASE are still pricey – usually marketed on per-core basis with entry price quickly crossing 1K$ watermark + yearly support fees.

2. Majority of tools (all?) present user with a pre-defined UI which is hard to adjust to one’s need.

3. Raw monitoring data is hidden, you get what you get the way you get it.

4. DBA’s are usually not satisfied by having at their hands only the information enterprise tools provide them.

Quite a while ago – some 5-7 years in fact – while working in a company that embedded ASE (and other Sybase products) into its product I’ve been challenged by an idea to be able to construct server profile and to build a framework that will enable to raise alerts if any metric of interest has passed some threshold. Today it sounds like a trivial thing.  Any monitoring tool worthy of its name is capable to set up alerts – even write custom SQL to support these – and provide API to connect to it from other enterprise monitoring tools, either opensource or not.

And yet there is still something I as a practising DBA lack.

What if I face hundreds of servers and I have to see all of them from a particular perspective.  I want to monitor things that make sense to me and to me alone AND what if I want to be able to investigate events retrospectively by inspecting every single metric MDA has to offer me in case I miss the fun of being there when things happen?

On the face of it, it does not sound like a big deal to set up:  Configure ASE scheduler.  Craft a set of parameters you want to collect into your profile.  Persist them.  Probe periodically.  Fire MDA collection when any cool stuff happens.  Easy.  It’d be a good guess that many of us (majority?) already have some sort of MDA repository where we bury our MDA data collected from time to time.  Myself included.

I began to develop a sharp feeling that I need to introduce some sort of order into this hap-hazard repository when I faced a site with hundreds of ASEs calling for constant attention.  Lots of cool things happening all the time.  You miss things more often then not – even though you do have some of the enterprise heavy-weights on board.  And you also keep collecting data from time to time (when you are lucky to be in the right place in the right time).  However, if you don’t collect things in a systematic manner you very soon find yourself facing tones of data, spread all over the place, hard to analyse, hard to present.

That’s when the idea to craft a tool that will standardise this was born in my head.  Instead of messing up with disperse scripts, data files, local MDA tables, more scripts to fire alerts, more tool to see MDA data or monitor my ASE servers I decided to build a unified framework that will make my life easier.

Although I know of the value any tool that keeps things in order does to me I though about probing the community with this.

Given there is a tool that:

1.  Collects predefined performance profiles for all your ASEs which you will be able to study over time.

2.  Lets you see how your ASEs fare – from the perspective that interests you in particular, and adjust it as your interest changes.

3.  Allows you to collect MDAs for any server you choose into your own standardized MDA repository – regardless of ASE version.

4.  Allows you to mine into MDA data for any server you choose from the same focal point.

5.  Allows you to fire alerts based on some idiosyncratic parameters you‘ve decided to monitor.

6.  Allows you to collect MDAs when anything that interests you happens on any of your ASEs.

7.  Allows you to monitor your ASEs performance if you choose to – from the perspective of any metric you have collected into your profile.

How useful do you think this tool will be in your environment?

On the scale of 1 to 10, how likely it is that you’ll want to grab it and put on your desktop?

Comments are welcome.

Andrew.