Skip to Content
Author's profile photo Andrew Melkonyan

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.


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      I think this tool will be useful in our environment if it allows to monitor ASE15 and ASE16 from a centralised place (ASE Cockpit has way too many limitations). I'd say 9 out of 10, I'll grab it and test it.

      Before 're-inventing the wheel', I would suggest looking at existing open-source tools such as ASEMON, ASEBOX, ASETUNE to get inspiration and maybe get a few people on board.

      I would be interested in contributing.



      Author's profile photo Andrew Melkonyan
      Andrew Melkonyan
      Blog Post Author

      I'll leave it to the moderators to decide if what I write conflicts the spirit of SCN.  IMO this is the right place to probe communities interests. 

      Author's profile photo Avinash Kothare
      Avinash Kothare

      Any tool that minitors ASE from inside (i.e. based on connection(s) to ASE) is limited in some way to collect critical data when crunch comes.

      Some tools do this cleverly so you get almost at the edge-of-shutdown view of what was happening. Some tools themselves become a handicap when collecting the data during a crunch.

      I personally would prefer a "network sniffer" type of tool that meets DBA needs/expectation to a great extent.

      This tool can collect the SQL independentaly without ASE connection and complement the MDA matrix collected from within with connection(s) .

      Utilmately every DBA ends up rolling his/her sleeves and crafting something needed specifically for his/her situation.