|
OK, I appreciate your help, but so you know, what you
suggest is exactly what I do now. As I have for a couple of years now. And I
wholeheartedly agree with your (and everyone else's) sentiments of the product
itself.
Michael D. Shook
Technical Analyst
[EMAIL PROTECTED]
863 668 4477
(work)
863 860 4070 (cell)
863 665 1261 (fax)
www.saddlecrk.com
A lot of that can be accomplished using the enterprise version (or
the standard with special code) by logging everything to a database.
You can log the check results to a database. Then create a query against
that database to report on Customer X's equipment only and show the down time
percentages, a 30 day log of all activity. The only thing you would have
to do manually is to add what happens when it goes down and who gets the
alerts. In this sense it would be nice to have a more open
host file. At this point (and I will certainly admit my ignorance
here), there is no easy way to extract the data you need. There are other
people on the list who have more knowledge of the host file structure and could
probably help you pull the information your require. This is
unsupported by Woodstone but I think if you ask nicely and privately Dirk would
maybe even help you.
I currently am using the standard
version and a custom program to log all of the results to a database. I
then publish web pages showing me graphs of the last 1 day, 1 week, 1 month, and
I think 1 year results. It also shows me the last thirty days of down
conditions and how long the check was down.
After researching many
products in the monitoring field. SA is unmatched for price, quality,
capabilities, and service. I do not think you will find a product (even if
you are willing to spend many thousands of dollars) that will monitor everything
SA can monitor with the flexibility SA has and the reporting you require.
Your best bet is to find a way to get what you want out of SA. I think it
can all be accomplished all be it with a little work and development on your
part.
Michael D. Shook wrote:
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
--
Jason Passow
Mississippi Welders Supply
[EMAIL PROTECTED]
ph: (507) 454-5231
fax: (507) 454-8104
To unsubscribe from a list, send a mail message to [EMAIL PROTECTED] With
the following in the body of the message: unsubscribe SAlive
|
