Well, since I am restricted to
using either groups or dependancies, I use dependancies so that when a
router goes down, I only get alerted to the router. Also, since
equipment that impacts Cust. X also includes equipment the Impacts
Customer Y, Z and H, I can't use the grouping effectively either.
And there still isn't any way of
getting the complete check config or people/team info out of SA itself.
Michael D. Shook
Technical Analyst
[EMAIL PROTECTED]
863 668 4477 (work)
863 860 4070 (cell)
863 665 1261 (fax)
www.saddlecrk.com
Mike,
The kind of reporting you would
like is not within Servers Alive as such. I also don't think that any
other product will have this. With any product (including Servers
Alive) you will have to do some "creative" reporting to get this kind
of data.
The know what equipment impacts
customerX you will probably have to work with groups. The
alerts/downtime %/checks can be within one output by using an HTML
template (<sa_alerts> shows the alerts). The "30 day log of all
activity" can be retrieved from the statistical logging. I suppose
that the "all equipment..." part is equipment that is related to the
customer so it also impacts the customer? So you already have that :-)
Dirk.
The issue could be summed up
quickly.
Mike's boss said, "Give me a
single report that has all of the equipment that impacts Customer X,
what happens when we see it go down, who gets the alerts. Oh, and be
sure to include the down time percentages, because we get charged for
that. And also include a 30 day log of all activity that we saw on the
checks. And don't forget to include ALL equipment that touches their
data or impacts their equipment."
Mike replied, "Well, I can give you some of
that, but this product doesn't allow for that level of data reporting.
It's doesn't use standard SQL databases to hold it's configuration, so
I can't write custom reports aginst for the checks themselves or the
alerting process."
Mike's Boss, "Well, we need to find a product
that will do what I need, so that I can show Customer X just how we are
meeting the contractual obligations that we agreed to."
Mike :-(
Michael D. Shook
Technical Analyst
[EMAIL PROTECTED]
863 668 4477 (work)
863 860 4070 (cell)
863 665 1261 (fax)
www.saddlecrk.com
I tend to agree with most of the
other responses I've seen on this. Multi-threading I'd kill for, but
having a separate db doesn't really float my boat. I grant you it would
be nice to be able to do things (e.g. mass change type stuff) directly
in the db via some sort of hack, and occasionally I curse mildly about
having to stop the checks to delete something. Having all the counters
reset to zero when you restart the service is annoying too. But all
that comes way down my list of priorities compared to multi-threading,
plus the stuff that's already part of the product (such as low
maintenance, low purchase cost, low spec requirements) which may be
lost if it goes too far down an "enterprise" route. Maybe I'm missing
your point Michael - you may be seeing something missing that I'm not
(for example I'm not sure what the problem is with the existing
teams/on-call stuff).
To be absolutely fair, it would be
wrong to see SA as a £200 solution (at least for us). We've invested
fairly heavily in time to configure it, set up HTML pages, paging
systems etc. Having said that I don't think a "big" system would be
much different in that respect.
Ian
Ian K Gray
OEL IS - European Infrastructure Support
Tel: +44 1236 502661
Mob: +44 7881 518854
OK, I can't resist...
How many people would be
willing to part with serious $$$ to have a version of SA that has NO
(ZERO, NONE) of it's configuration or check data stored locally, but
rather all stored in a SQL database (MSSQL, MySQL, etc....) with the
checks read from the database every cycle? This would allow seperating
the check processing from the check setup, giving people the option of
changing without stopping.
I know my company would be
willing to spend $$$ if we could have a truly Enterprise level version.
We're having to look at competitors products because of the more
advanced reporting of the checks, teams, on-call, alerting that are not
available in SA v5. Also, the lack of ability to have the configuration
on a highly available SQL Server is starting to be more and more of an
issue.
Michael D. Shook
Technical Analyst
[EMAIL PROTECTED]
863 668 4477 (work)
863 860 4070 (cell)
863 665 1261 (fax)
www.saddlecrk.com
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On
Behalf Of Dirk Bulinckx
Sent: Tuesday, May 17, 2005 9:07 AM
To: [email protected]
Subject: RE: [SA-list] Future Product Feature
Well that's just an almost
complete rewrite :-(
Dirk.
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On
Behalf Of Vogl, Tom
Sent: Tuesday, May 17, 2005 3:30 PM
To: [email protected]
Subject: [SA-list] Future Product Feature
Dirk,
We have had lots of discussion about
SA here, and overall we love the product. If we could ask for only one
feature in future releases it would be this:
The separation of the SA check engine
from the interface. This way the engine could be started as a service
and never touched while remote connections via Terminal Server, Citrix
or whatever could load the interface for adds/changes to the config.
The interface could be compiled or
web; based-doesn't matter. But the current remote access issues make
running in service mode challenging to work with SA in a "dark" or
remote computer room.
Ie: Remote connect to machine.
Stop SA Service. Start new desktop copy. Make Changes. Save file.
Exit local copy. Start SA service.
-Tom
