What kind of check info and people/team info would you
want?
Dirk.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael D. Shook
Sent: Wednesday, May 18, 2005 4:14 PM
To: salive@woodstone.nu
Subject: RE: [SA-list] Future Product Feature
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)
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dirk Bulinckx
Sent: Wednesday, May 18, 2005 8:59 AM
To: salive@woodstone.nu
Subject: RE: [SA-list] Future Product Feature
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.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael D. Shook
Sent: Wednesday, May 18, 2005 2:39 PM
To: salive@woodstone.nu
Subject: RE: [SA-list] Future Product Feature
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)
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Wednesday, May 18, 2005 2:35 AM
To: salive@woodstone.nu
Subject: RE: [SA-list] Future Product Feature
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
| "Michael D. Shook"
<[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 17/05/2005 17:35
|
|
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: salive@woodstone.nu
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: salive@woodstone.nu
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
