Title: Future Product Feature
I'm still not convinced that using a database is any
improvement over the current configuration. I'm not sure what you mean
about changing without stopping. I make changes via the GUI all the
time. If you mean bulk changes via the host file then you are doing things
that are outside of the scope of the product design and unsupported. At
that point you have to live with the situation. If you want the
config file stored on a highly available system what is wrong with a file share
on a SAN or clustered server? Why must it be SQL
based?
I have a truly enterprise level system, HP Openview and
Concord E-Health, that we spent well over 200k on between licenses and
hardware. For ~200.00 I get 80% of that functionality and don't have to
babysit the system. If you need more features and have money to spend then
maybe another product is a better fit.
That isn't a slight of SA but a reality check for
your situation. Forcing SA to fit your enviroment may be the best
solution.
So far I have been very pleased at the additions Dirk has
made to make SA more usable in my environment. The testing being done with
threading will make a huge difference for me. However, I cannot forget
that the core market for Servers Alive is the small and medium size
networks. Adding cost, complexity, and support issues to SA will move it
out of that market unless Dirk is willing to maintain and support two different
products and codebases. Then we as a community can probably expect the
level of support to decrease. We can only expect Dirk and Woodstone to do
so much.
I'd like the level of support to remain the same and will
stay the course with the incremental upgrade path the SA has been
on.
-Kevin
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
Well that's just an almost complete rewrite
:-(
Dirk.
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
