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.
