Sorry, I've been away from email for a bit. Here's my thoughts: Since one of the gains of having a db backend is improving the "enterprise-ability" of the software, forcing it to use a non-enterprise level db via internal hard-wired data connections is not much better than where it is now. I cannot get permission to run any other db than IBM DB2 or MS-SQL. Also, ODBC is no longer considered to be a enterprise level data connection layer. This makes me raise this question: is it possible that the software could be written to use ODBC for all versions, but allow a OEM specific data connection to DB2, MS-SQL, Oracle, etc... for the most expensive version. The assumption here is that those people who are willing to pay for the top license probably have a db server they would put SA on. I know I have several that could host it. Those people who don't have Sr. Management breathing down they're necks to "bring the software in line with corporate system dependability and recoverabilty goals or it WILL BE GOTTEN RID OF" could still use ODBC to connect to the SQL server of their choice. I know this means that there is the possibility of vendor specific language differences casing coding issues, but I think the extra effort and testing will be worth it.
At a minimum, from my management's point of view, ODBC to MS-SQL is far better than where SA is now. Michael Shook | Omega Tower Design Partners | www.omegatower.com/otdp | mike.omegatower.com Vogl, Tom wrote: For what it's worth, I agree with Barry: "It works well and is priced right". That said, I would pay a premium to have a version of the SA "check engine" that ran against a SQL configuration set and used a separate GUI for management. Maybe it becomes a totally new product? -tom -----Original Message----- From: Servers Alive Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Barry George Sent: Thursday, September 04, 2008 4:31 PM To: Servers Alive Discussion List Subject: RE: [SA-list] Servers Alive and reporting Aggreed. I haven't had the time to review what SQLite can and can not do - but if it's easy to dump from SQLite to 'other' more robust DB's and it make manipulation of host files easier, then this seems like a good compromise, no? Not everyone needs the reporting power that some of the list seem to require. The attractiveness of SA is that it works well and it's priced right. The closer you move to one end of the scale the further away it gets from what I consider its original business model concept, or at least the reasons I chose it as our companies monitor of choice. I think you are the only one that can decide what that model should be in the future Dirk. Cheers Barry -----Original Message----- From: Servers Alive Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Dirk Sent: September 4, 2008 12:26 PM To: Servers Alive Discussion List Subject: RE: [SA-list] Servers Alive and reporting If we go for a db back-end then from my point of view it should be for all editions. BUT if we would go for a solution like SQLite then the user wouldn't even know what type of back-end there is as SQLite isn't using any type of DB-server, it's just 1 (or 2) DLL files and the db file itself. If we would go for a solution that would be using mySQL or MS-SQL then it would from my poiint of view a big oversizing that makes it for "Joe Average" much to large and complicated. Dirk Bulinckx. -----Original Message----- From: Servers Alive Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Barry George Sent: Thursday, September 04, 2008 6:10 PM To: Servers Alive Discussion List Subject: RE: [SA-list] Servers Alive and reporting Right - would it be possible to have what we have now (text based) and the option to 'turn-on' a full db backend? I'm trying to think from a new user point of view. Sure all the big players out there have all the resources they need at their disposal but an SMB doesn't and I would hate to see the very fabric of what make SA so great as a monitoring system be dumped for 'bigger is better' view point. Maybe this could be answered in the Standard vs. Enterprise versioning offers? Barry -----Original Message----- From: Servers Alive Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Dirk Sent: September 4, 2008 11:31 AM To: Servers Alive Discussion List Subject: RE: [SA-list] Servers Alive and reporting We're now talking about using a db backend for the configuration (instead of using the entriesfile and the registry) Dirk Bulinckx. -----Original Message----- From: Servers Alive Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Barry George Sent: Thursday, September 04, 2008 5:16 PM To: Servers Alive Discussion List Subject: RE: [SA-list] Servers Alive and reporting Why would you have to deliver sql? Could the option to not turn on logging still not be there and leave it up to the individual to down the be of choice? Mssql would be my choice also. Barry ***** Sent from my PocketPC. -----Original Message----- From: "Jason Passow" <[EMAIL PROTECTED]> Sent: 04/09/08 11:00:14 AM To: "Servers Alive Discussion List" <salive@woodstone.nu> Subject: RE: [SA-list] Servers Alive and reporting My vote is for MySQL with an option to use an existing MSSQL server. Jason Passow Mississippi Welders Supply http://www.mwsco.com [EMAIL PROTECTED] ph: (507) 494-5178 fax: (507) 454-8104 -------------------------------------------------------------------------------- From: Dirk [mailto:[EMAIL PROTECTED] To: Servers Alive Discussion List [mailto:[EMAIL PROTECTED] Sent: Thu, 04 Sep 2008 09:45:18 -0500 Subject: RE: [SA-list] Servers Alive and reporting MSSQL is clear not an option. As this would mean that with Servers Alive we would have to deliver MSSQL with it too (even the express version is just a too large "thing" for such a small task) Dirk Bulinckx. From: Servers Alive Discussion List [mailto:salive@woodstone.nu (mailto:salive@woodstone.nu)] On Behalf Of Vogl, Tom Sent: Thursday, September 04, 2008 4:26 PM To: Servers Alive Discussion List Subject: RE: [SA-list] Servers Alive and reporting MS SQL please. From: Servers Alive Discussion List [mailto:salive@woodstone.nu (mailto:salive@woodstone.nu)] On Behalf Of Dirk Sent: Wednesday, September 03, 2008 11:21 AM To: Servers Alive Discussion List Subject: RE: [SA-list] Servers Alive and reporting I suppose this would mean that you would want something like mySQL or MSSQL as db backend? Or would something like SQLite work too for you? (and for the others that want a db backend) Dirk Bulinckx. From: Servers Alive Discussion List [mailto:salive@woodstone.nu (mailto:salive@woodstone.nu)] On Behalf Of Michael D. Shook Sent: Tuesday, September 02, 2008 10:31 PM To: Servers Alive Discussion List Subject: Re: [SA-list] Servers Alive and reporting I think from my POV, if the checks were stored in a db table (not a hosts file), and the setup was stored in another db set of tables (not the registry), then I can do all my own reporting using any of dozens of SQL database report writers. Also, I could write custom web based interfaces to the alerts and the management. So, to me it would seem that while report writing is an excellent goal, it is a closed ended one. Spending the time to rewrite the app to a more enterprise geared back-end would have a larger open ended payoff. Nifty avenues that could be pursued would be allowing multiple SA "heads" write to and from the same alerts db allowing for a better DR fail over scenario. "Slave" clients could all output to the same db as the "master" which could send alerts based on new db entries from the slaves. The service running the checks could be separated from the service that looks for db entries it needs to alert on, which could be separated from the setup GUI (admin access), which could be separated from the maintenance GUI (helpdesk access), etc... Sorry, Dirk, I know you don't want to hear it, but I do think the model you're currently using is holding you (and us) back. Oh, and I still wouldn't recommend any other product!!!! Michael Shook | Omega Tower Design Partners | www.omegatower.com/otdp | mike.omegatower.com Dirk wrote: can we get back to the reporting as that was the subject of thisââ'¬Â¦. Dirk Bulinckx. From: Servers Alive Discussion List [mailto:salive@woodstone.nu (mailto:salive@woodstone.nu)] On Behalf Of Vogl, Tom Sent: Friday, August 29, 2008 7:56 PM To: Servers Alive Discussion List Subject: RE: [SA-list] Servers Alive and reporting If you want to build on this idea from Brett, here is what I would REALLY like to see: 1) Check configuration moved to a manageable database OR a full set of APIs so checks could be added/changed/deleted outside the app. 2) Separate the "checking engine" from the UI app. In other words, SA runs as a service and you fire up the UI to manage it or view current status. Close the UI and it still runs. -Tom -------------------------------------------------------------------------------- From: Servers Alive Discussion List [mailto:salive@woodstone.nu (mailto:salive@woodstone.nu)] On Behalf Of Brett Hanson Sent: Friday, August 29, 2008 11:41 AM To: Servers Alive Discussion List Subject: RE: [SA-list] Servers Alive and reporting Agreed, statistical logging is the basis of the data, but this is the kind of reporting we are looking for. As far as other kinds of reporting from Servers Alive goes, I would certainly like to know over the last x days what the up, down, and maintenance statistics were. I would also really like to have not just the html page export, but also a xml file export of the cycle data. I currently use an html template laid out as a xml file, then use xsl to present the data. I currently have to be careful with the naming of the checks and descriptions to not include any characters that would cause the xml file generated to be invalid. I know some people are asking for reporting of the configuration, but my preference would be to work on making it easier to manipulate the checks and alerts. I would really love having the configuration of the checks in a database as it would make it so much easier to look through and change the configuration for particular items. Right now, it takes about 8 hours to review the alerts for all the checks we have setup to ensure they are all configured correctly. Most of that time is spent clicking through the user interface. Regards, Brett Hanson "Dirk" <[EMAIL PROTECTED]> (mailto:[EMAIL PROTECTED]) 8/29/2008 9:10 AM >>> Now that I think about this logging is already done by Servers Alive, you just can't use Servers ALive to get a report of it. This is exactly what the statistical logging does. It tells you when the entry changed from status_A to status_B and how long it was in status_B before changing. Dirk Bulinckx. From: Servers Alive Discussion List [mailto:salive@woodstone.nu (mailto:salive@woodstone.nu)] On Behalf Of Brett Hanson Sent: Friday, August 29, 2008 4:41 PM To: Servers Alive Discussion List Subject: Re: [SA-list] Servers Alive and reporting One report we've been struggling with for the last couple years is an activity report. We'd like to see a report that shows outages detected by Servers Alive in the past 7 days. This report would show the check name, when the check went down, when it came back up and the duration. Any checks down when the report is run would show as 'Currently Down'. For example: Check Name Down At Up At Outage Duration LDAP Server 27-Aug 4:06 PM 27-Aug 4:32 PM 26 Minutes Service A 29-Aug 3:10 AM Currently Down 5 Hours 17 Minutes Our biggest issue is problems with accuracy that result when Servers Alive is restarted - a check that was down before Servers Alive was shut down and was up when Servers Alive started again is not detected as a status change, and no database record showing the transition exists. Regards, Brett Hanson Systems Analyst Agrium "Dirk" <[EMAIL PROTECTED]> (mailto:[EMAIL PROTECTED]) 8/29/2008 3:50 AM >>> One of the often returning question on Servers Alive is if it can do reporting. We always point to the HTML template based output and to the DB logging (using a 3rd party report writer). Still it seems that this is not what people are looking for. That's why we would like you to help us with some brainstorming around that reporting feature. I'll start by giving my own idea on it. * it's based on the HTML template based output * it can be set to be executed (generated) once a day and you can select what "entries" go on it * you can ofcourse have several output's and for several sets of entries * additional parameters are needed like % up cycles % down cycles % maintenance cycles and this per DAY, WEEK, MONTH, YEAR with "easy" access to the current (day/week/...) and the previous (day/week/...) and also access to other days/weeks/months/year. Example: <sa_stats_up_week{pervious}%>gives the up% of the previous week <sa_stats_up_week082008%>gives the up% of week 8 of 2008 <sa_stats_down_month082008%>gives the up% of month 8 of 2008 All ideas/comments/additions are MORE THEN WELCOME Dirk Bulinckx. To unsubscribe send a message with UNSUBSCRIBE in the subject line to salive@woodstone.nu (mailto:salive@woodstone.nu) If you use auto-responders (like out-of-the-office messages), make sure that they are not sent to the list nor to individual members. Doing so will cause you to be automatically removed from the list. _____________________________________________________________ IMPORTANT NOTICE ! This E-Mail transmission and any accompanying attachments may contain confidential information intended only for the use of the individual or entity named above. Any dissemination, distribution, copying or action taken in reliance on the contents of this E-Mail by anyone other than the intended recipient is strictly prohibited and is not intended to, in anyway, waive privilege or confidentiality. If you have received this E-Mail in error please immediately delete it and notify sender at the above E-Mail address. Agrium uses state of the art anti-virus technology on all incoming and outgoing E-Mail. We encourage and promote the use of safe E-Mail management practices and recommend you check this, and all other E-Mail and attachments you receive for the presence of viruses. The sender and Agrium accept no liability for any damage caused by a virus or otherwise by the transmittal of this E-Mail. _____________________________________________________________ To unsubscribe send a message with UNSUBSCRIBE in the subject line to salive@woodstone.nu (mailto:salive@woodstone.nu) If you use auto-responders (like out-of-the-office messages), make sure that they are not sent to the list nor to individual members. Doing so will cause you to be automatically removed from the list. To unsubscribe send a message with UNSUBSCRIBE in the subject line to salive@woodstone.nu (mailto:salive@woodstone.nu) If you use auto-responders (like out-of-the-office messages), make sure that they are not sent to the list nor to individual members. Doing so will cause you to be automatically removed from the list. To unsubscribe send a message with UNSUBSCRIBE in the subject line to salive@woodstone.nu (mailto:salive@woodstone.nu) If you use auto-responders (like out-of-the-office messages), make sure that they are not sent to the list nor to individual members. Doing so will cause you to be automatically removed from the list. To unsubscribe send a message with UNSUBSCRIBE in the subject line to salive@woodstone.nu (mailto:salive@woodstone.nu) If you use auto-responders (like out-of-the-office messages), make sure that they are not sent to the list nor to individual members. Doing so will cause you to be automatically removed from the list. To unsubscribe send a message with UNSUBSCRIBE in the subject line to salive@woodstone.nu (mailto:salive@woodstone.nu) If you use auto-responders (like out-of-the-office messages), make sure that they are not sent to the list nor to individual members. Doing so will cause you to be automatically removed from the list. To unsubscribe send a message with UNSUBSCRIBE in the subject line to salive@woodstone.nu (mailto:salive@woodstone.nu) If you use auto-responders (like out-of-the-office messages), make sure that they are not sent to the list nor to individual members. Doing so will cause you to be automatically removed from the list. To unsubscribe send a message with UNSUBSCRIBE in the subject line to salive@woodstone.nu (mailto:salive@woodstone.nu) If you use auto-responders (like out-of-the-office messages), make sure that they are not sent to the list nor to individual members. Doing so will cause you to be automatically removed from the list. To unsubscribe send a message with UNSUBSCRIBE in the subject line to salive@woodstone.nu (mailto:salive@woodstone.nu) If you use auto-responders (like out-of-the-office messages), make sure that they are not sent to the list nor to individual members. Doing so will cause you to be automatically removed from the list. To unsubscribe send a message with UNSUBSCRIBE in the subject line to salive@woodstone.nu (mailto:salive@woodstone.nu) If you use auto-responders (like out-of-the-office messages), make sure that they are not sent to the list nor to individual members. Doing so will cause you to be automatically removed from the list. To unsubscribe send a message with UNSUBSCRIBE in the subject line to salive@woodstone.nu If you use auto-responders (like out-of-the-office messages), make sure that they are not sent to the list nor to individual members. Doing so will cause you to be automatically removed from the list. To unsubscribe send a message with UNSUBSCRIBE in the subject line to salive@woodstone.nu If you use auto-responders (like out-of-the-office messages), make sure that they are not sent to the list nor to individual members. Doing so will cause you to be automatically removed from the list.= To unsubscribe send a message with UNSUBSCRIBE in the subject line to salive@woodstone.nu If you use auto-responders (like out-of-the-office messages), make sure that they are not sent to the list nor to individual members. Doing so will cause you to be automatically removed from the list. To unsubscribe send a message with UNSUBSCRIBE in the subject line to salive@woodstone.nu If you use auto-responders (like out-of-the-office messages), make sure that they are not sent to the list nor to individual members. Doing so will cause you to be automatically removed from the list.= To unsubscribe send a message with UNSUBSCRIBE in the subject line to salive@woodstone.nu If you use auto-responders (like out-of-the-office messages), make sure that they are not sent to the list nor to individual members. Doing so will cause you to be automatically removed from the list. To unsubscribe send a message with UNSUBSCRIBE in the subject line to salive@woodstone.nu If you use auto-responders (like out-of-the-office messages), make sure that they are not sent to the list nor to individual members. Doing so will cause you to be automatically removed from the list. To unsubscribe send a message with UNSUBSCRIBE in the subject line to salive@woodstone.nu If you use auto-responders (like out-of-the-office messages), make sure that they are not sent to the list nor to individual members. Doing so will cause you to be automatically removed from the list. To unsubscribe send a message with UNSUBSCRIBE in the subject line to salive@woodstone.nu If you use auto-responders (like out-of-the-office messages), make sure that they are not sent to the list nor to individual members. Doing so will cause you to be automatically removed from the list.
