Instead of minutes I'll keep seconds. Why seconds? If you run a small config and have a small checking interval then you could get timings below 1 minute.
Also I added the unavailable checks too. Dirk Bulinckx. -----Original Message----- From: Servers Alive Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Michael Shook Sent: Monday, July 10, 2006 2:51 PM To: Servers Alive Discussion List Subject: RE: [SA-list] Uptime stats & DB So you are talking about a 3rd db table then? If so, and the minutes were kept, then that would work. Also, you should keep in mind that due to dependencies, you should have the unavailable and unchecked cycles (and times) kept. There are some conflicting ways of calculating uptimes where some simply say "if it ain't up, it's down", while others throw out any time where the actual status of the individual check is unknown (this being what my company currently uses). This of course raises questions about how whether time spent in a "maintenance due to schedule" should be treated the as time spent in a normal maintenance (where there's a problem that's being worked on) which would count against your uptimes, or should it be .... :-) Michael D. Shook Technical Analyst Saddle Creek Corporation [EMAIL PROTECTED] 863 668 4477 (work) 863 860 4070 (cell) 863 665 1261 (fax) www.saddlecrk.com > -----Original Message----- > From: Servers Alive Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Dirk Bulinckx > Sent: Monday, July 10, 2006 8:26 AM > To: Servers Alive Discussion List > Subject: RE: [SA-list] Uptime stats & DB > > In "my way" it's not resetting anything. > It's keeping data for days/weeks/months/... > If you want to have the uptime for 5 days, then do a query for those 5 > days. > > Tracking minutes is also possible....(in addition to cycles), that > would "just" add 4 columns to the db. > > Making a recap, is something that can be done by any scripts as the > data is in the db. > > > Dirk Bulinckx. > -----Original Message----- > From: Servers Alive Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Michael Shook > Sent: Monday, July 10, 2006 2:11 PM > To: Servers Alive Discussion List > Subject: RE: [SA-list] Uptime stats & DB > > Since the "coin of the realm" in uptime reports is a percentage > (99.982% up for the last xx days), what you are tracking will not > work. You need to track these values as minutes. > > Personally, I would suggest moving towards the direction as I have > done (a 3rd DB table) (as described in the new Users > Group) and let the user decide when to reset the time values (daily, > monthly, yearly, > sesquicentennially) after they produce the report. > Alternatly, you could have a 3rd "build table" (like mine) that is > then used to generate values for a 4th recap table with the period > values for long term reports. > > Michael D. Shook > Technical Analyst > Saddle Creek Corporation > [EMAIL PROTECTED] > 863 668 4477 (work) > 863 860 4070 (cell) > 863 665 1261 (fax) > www.saddlecrk.com > > > > -----Original Message----- > > From: Servers Alive Discussion List > > [mailto:[EMAIL PROTECTED] On Behalf Of Dirk Bulinckx > > Sent: Sunday, July 09, 2006 10:36 AM > > To: Servers Alive Discussion List > > Subject: [SA-list] Uptime stats & DB > > > > I've been thinking some more about the questions we get > around uptime > > stats and db logging and have been "playing" > > with an idea about it. > > > > If we would have the following extra DB logging would that help? > > > > SAID(string) > > UNIQUEID (numeric) > > nYEAR (numeric) > > nMONTH (numeric) > > nDAY (numeric) > > UPCYCLES (numeric) > > DOWNCYCLES (numeric) > > MAINTENANCECYCLES (numeric) > > TOTALCYCLES (numeric) > > > > For each record in the list we would create/update the > record with the > > up/down/maintenance/total cycles AFTER each cycle (or just > after the > > check). > > And each day would generate a new record. The update will take the > > value from the DB and add 1 to the correct columns > > (up/down/maintenance and total). This means that if you > stop SA for a > > couple of hours during that day that you would this have/get rather > > correct info. > > > > > > > > MYSYSTEM 1 2006 07 08 167 > > 1 1 > > 169 > > MYSYSTEM 1 2006 07 09 67 > > 1 1 > > 69 > > > > > > We could also "attached" some extra HTML tags to this. > > For example > > sa_stats_up_today > > sa_stats_up_yesterday > > sa_stats_up_currentmonth > > sa_stats_up_previousmonth > > ... > > > > And to get the value of it we can then query the db (ODBC) > > > > > > > > And as always my thinking resulted in some coding too :-) > The logging > > to db part is already written and "seems" to work. For the moment > > it's done after the check, could be that this will be changed to > > "after the cycle" for performance reasons. > > > > Would this logging (and HTML tags) resolve some/most of the uptime > > stats issues? > > > > > > > > > > > > Dirk Bulinckx. > > > > To unsubscribe send a message with UNSUBSCRIBE as subject to > > [email protected] If you use auto-responders (like > out-of-the-office > > messages), then make sure that they are not send to the list nor to > > the individual members of the list that send a message. Doing this > > will get you removed from the list. > > > > > > > -------------------------------------- > The information contained in this message is intended only for the use > of the addressee. If the reader of this message is not the intended > recipient or agent of the intended recipient, you are hereby notified > that any dissemination, distribution, or copying of the message is > strictly prohibited. > > To unsubscribe send a message with UNSUBSCRIBE as subject to > [email protected] If you use auto-responders (like out-of-the-office > messages), then make sure that they are not send to the list nor to > the individual members of the list that send a message. Doing this > will get you removed from the list. > > To unsubscribe send a message with UNSUBSCRIBE as subject to > [email protected] If you use auto-responders (like out-of-the-office > messages), then make sure that they are not send to the list nor to > the individual members of the list that send a message. Doing this > will get you removed from the list. > > -------------------------------------- The information contained in this message is intended only for the use of the addressee. If the reader of this message is not the intended recipient or agent of the intended recipient, you are hereby notified that any dissemination, distribution, or copying of the message is strictly prohibited. To unsubscribe send a message with UNSUBSCRIBE as subject to [email protected] If you use auto-responders (like out-of-the-office messages), then make sure that they are not send to the list nor to the individual members of the list that send a message. Doing this will get you removed from the list. To unsubscribe send a message with UNSUBSCRIBE as subject to [email protected] If you use auto-responders (like out-of-the-office messages), then make sure that they are not send to the list nor to the individual members of the list that send a message. Doing this will get you removed from the list.
