ABSOLUTELY!!!! Especially if it had a once a day update feature.
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] > Sent: Thursday, May 11, 2006 1:51 PM > To: Servers Alive Discussion List > Subject: [SA-list] RE: [SA-list] RE: [SA-list] RE: [SA-list] > RE: [SA-list] Re: [SA-list] RE: [SA-list] Re: [SA-list] RE: > [SA-list] Re: [SA-list] RE: [SA-list] Re: [SA-list] > Enterprise level data storage (was Skype Alerting) > > IF we get to doing this it will be in several steps. > The first being will be like an "export" option were you would "ask" > (manualy that is) to export the entries file to a db. Would > that already help? > > > Dirk Bulinckx. > -----Original Message----- > From: Servers Alive Discussion List [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 11, 2006 7:41 PM > To: Servers Alive Discussion List > Subject: [SA-list] RE: [SA-list] RE: [SA-list] RE: [SA-list] > Re: [SA-list] > RE: [SA-list] Re: [SA-list] RE: [SA-list] Re: [SA-list] RE: > [SA-list] Re: > [SA-list] Enterprise level data storage (was Skype Alerting) > > I'm not promising that we will do this. > I still think it's a HUGE thing for a little use. > > > Dirk Bulinckx. > -----Original Message----- > From: Servers Alive Discussion List [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 11, 2006 7:00 PM > To: Servers Alive Discussion List > Subject: [SA-list] RE: [SA-list] RE: [SA-list] Re: [SA-list] > RE: [SA-list] > Re: [SA-list] RE: [SA-list] Re: [SA-list] RE: [SA-list] Re: > [SA-list] Enterprise level data storage (was Skype Alerting) > > Since we're (or least I am) talking about situations in an > enterprise environment, the answer is yes, absolutely. If you > can get it to work for SA, we can report off of it. Provided, > of course, we know what data is where and how you link it all > together. The most important thing to remember with > relational dbs like that, is that every record in every table > HAS to be unique. Even if that means you add an > Auto-Incremented ID field to each table. > > 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] > > Sent: Thursday, May 11, 2006 12:40 PM > > To: Servers Alive Discussion List > > Subject: [SA-list] RE: [SA-list] Re: [SA-list] RE: [SA-list] > > Re: [SA-list] RE: [SA-list] Re: [SA-list] RE: [SA-list] Re: > > [SA-list] Enterprise level data storage (was Skype Alerting) > > > > SA could do that, but could your report writer do that? As > that seems > > to be THE reason for the db, writing reports from it. > > > > > > Dirk Bulinckx. > > -----Original Message----- > > From: Servers Alive Discussion List [mailto:[EMAIL PROTECTED] > > Sent: Thursday, May 11, 2006 6:15 PM > > To: Servers Alive Discussion List > > Subject: [SA-list] Re: [SA-list] RE: [SA-list] Re: [SA-list] > > RE: [SA-list] > > Re: [SA-list] RE: [SA-list] Re: [SA-list] Enterprise level data > > storage (was Skype Alerting) > > > > WHy would have to be 1-1 or 1-many. Why couldn't you just > check each > > table for the uid and consolidate (depending on table type). > > > > Jason Passow > > Mississippi Welders Supply > > [EMAIL PROTECTED] > > ph: (507) 494-5178 > > fax: (507) 454-8104 > > > > "If you do everything right, nobody will realize you've > done anything > > at all." > > > > > > > > Servers Alive Discussion List wrote: > > > That just the whole point. We could indeed have a table for each > > > check type. But how to link that in a proper way to a > > table with the > > > host > > info? > > > The UID is indeed the column to use. But for a report > you need to > > > have a clear 1-to-1 or 1-to-many relationship (between the > > tables) and > > > in this example (with a table for each check type) you > > don't have that. > > > You get a 1-to-(1 in one of these tables) relationship. > > > > > > > > > > > > > > > Dirk Bulinckx. > > > -----Original Message----- > > > From: Servers Alive Discussion List [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, May 11, 2006 5:40 PM > > > To: Servers Alive Discussion List > > > Subject: [SA-list] Re: [SA-list] RE: [SA-list] Re: [SA-list] RE: > > > [SA-list] > > > Re: [SA-list] Enterprise level data storage (was Skype Alerting) > > > > > > Perhaps I just didn't understand your last post, but why > > not just take > > > the text file and move it to a DB with appropriate > columns and more > > > readable data (instead of 555555555 for schedules etc.) > Again I am > > > not going to say it is simple as I have not taken the time > > to figure > > > out the host file format. Or perhaps several tables, one > with the > > > hostname/ip, pretty name, and uid (maybe dependencies). Then the > > > others can lead with uid and Check table, Alert table, and > > Schedule/priority table. > > > > > > The alert table would have one record per alert (what, > > when, where, etc). > > > The check table would have on record per check (I think) > with type > > > criteria, timeout, second knock etc. (I guess this table > > could get a > > > bit complicated with different check types.) > > > > > > Just some thoughts. I know nothing about the com Check but > > it seems > > > perhaps we would have to have a table for each type of com > > check (i.e. > > > SMTP2POP3, ODBC, etc). It seems if it can all be put in > > flat file it > > > could all be put in a database. Perhaps it would be as simple as > > > documenting the host file so that those who wish can put > it in a DB. > > > I know others have figured out the structure. Maybe the database > > > could simply export the flat file you require. I wish I > knew my way > > around the host file a bit better. > > > > > > From my ramblings above you can probably tell that I know > > very little > > > about the host file structure, and perhaps I am way off. > > If so tell > > > me I have no idea and go on about your business. If not > then I am > > > happy to provide any input. > > > > > > Jason Passow > > > Mississippi Welders Supply > > > [EMAIL PROTECTED] > > > ph: (507) 494-5178 > > > fax: (507) 454-8104 > > > > > > "If you do everything right, nobody will realize you've > > done anything > > > at all." > > > > > > > > > > > > Servers Alive Discussion List wrote: > > > > > >> We can put it in a DB by using about 5 fields. > > >> Or by using about 5000 fields. > > >> Neither of the 2 would help you. > > >> > > >> Let me use a small example: > > >> ping host1 > > >> The check itself has a couple of parameters: > > >> checktype (ping) > > >> number of frames to send > > >> % that has to respond > > >> > > >> > > >> url check <url> > > >> parameters: > > >> checktype (url http/https check) > > >> url > > >> get/post/head > > >> IF it's a POST then data_to_post > > >> should contain/should not contain > > combined with this > > >> > > > exact > > > > > >> phrase/any of these words combined with <the_words> > > >> or > > >> CRC with "reset CRC after each check or not" > > >> or > > >> Site SSL Cert or CA SSL cert combined with a > > >> number of days > > >> > > >> use authentication > > >> if yes then USERNAME & PASSWORD > > >> > > >> use proxy (and what proxy) > > >> HTTP version to use > > >> > > >> > > >> An even worse example in an external check (COM based), > here it's > > >> simple SA doesn't know what the syntax of the parameters > > are and as > > >> such not much data to show except something like "*NIX DISKSPACE > > >> CHECK", what mount and on what space we're checking, SA > > doesn't know > > >> (the > > >> > > > COM knows, not SA). > > > > > >> So what we could do is create a different table for each > checktype > > >> (or maybe even SUB checktype) and then for each entry > "link" to an > > >> entry in a > > >> > > > table? > > > > > >> Or we could have one large table with all different check > > options in it. > > >> (could well be that we get to the limit of some DBS). > > >> > > >> I suppose this give a better view on why a DB isn't that > simple.... > > >> > > >> > > >> Dirk Bulinckx. > > >> -----Original Message----- > > >> From: Servers Alive Discussion List [mailto:[EMAIL PROTECTED] > > >> Sent: Thursday, May 11, 2006 4:51 PM > > >> To: Servers Alive Discussion List > > >> Subject: [SA-list] Re: [SA-list] RE: [SA-list] Re: [SA-list] > > >> Enterprise level data storage (was Skype Alerting) > > >> > > >> Seems to me if you put it a database, their XML gurus > > could get the > > >> data and create their own XML. > > >> > > >> Jason Passow > > >> Mississippi Welders Supply > > >> [EMAIL PROTECTED] > > >> ph: (507) 494-5178 > > >> fax: (507) 454-8104 > > >> > > >> "If you do everything right, nobody will realize you've > > done anything > > >> at all." > > >> > > >> > > >> > > >> Servers Alive Discussion List wrote: > > >> > > >> > > >>> "One thing that I do not think can be done (albeit I > > haven't tried > > >>> very > > >>> hard) is putting the actual check properties into a > > report (aside from > > >>> HTML). If the check details including , host name/ip, > > pretty name, > > >>> dependencies, alerts, check type,/criteria, schedule, etc were > > >>> stored in a database then I could create whatever > reports I want" > > >>> => those are indeed not in the DB. But as XML seems to > > be what some > > >>> want, it can be done by creating an HTML template and have that > > >>> generate the XML format. > > >>> What I would propose, is that someone on the list that > wants that > > >>> XML, gives me an example of what should be in the XML > > file (make one > > >>> with 2 > > >>> entries) and I'll try to make a template for it. And if > > changes are > > >>> needed to v6 (upcoming release that) for the template to be > > >>> possible, I'll make those changes. How does that sound? > > >>> > > >>> Dirk Bulinckx. > > >>> -----Original Message----- > > >>> From: Servers Alive Discussion List [mailto:[EMAIL PROTECTED] > > >>> Sent: Thursday, May 11, 2006 3:31 PM > > >>> To: Servers Alive Discussion List > > >>> Subject: [SA-list] Re: [SA-list] Enterprise level data > > storage (was > > >>> Skype > > >>> Alerting) > > >>> > > >>> I export the check results to a database each cycle and > > store it in > > >>> a database. I can the pull up my web page and see the > > last 30 days > > worth > > >>> of checks using graphs etc. I also have on that page a > > table showing > > >>> down cycles and length time before it recovered. I could > > certainly > > >>> create the same report as an XML (if I knew anything > > about XML that > > >>> is) or Excel (I know not an enterprise level App). I > > would think I > > >>> could export the data and import into Crystal Reports > or whatever > > >>> and > > >>> > > >>> > > >> create a > > >> > > >> > > >>> report. Although I empathize with your struggle here I > > do not think > > >>> that Salive should be a reporting app. > > >>> > > >>> One thing that I do not think can be done (albeit I > haven't tried > > >>> very > > >>> hard) is putting the actual check properties into a > > report (aside from > > >>> HTML). If the check details including , host name/ip, > > pretty name, > > >>> dependencies, alerts, check type,/criteria, schedule, etc were > > >>> stored in a database then I could create whatever > reports I want. > > >>> > > >>> Again I reiterate thank you Dirk for your patience and > > this kind of > > >>> continued dialog is unique and what makes SA far and away > > the best > > >>> app around. Thank you for not stifling the discussion > > and allowing > > >>> ideas to flow. On the other side of this discussion > > (maybe months > > >>> from now) I see some great things being added to SA. > > >>> > > >>> > > >>> Jason Passow > > >>> Mississippi Welders Supply > > >>> [EMAIL PROTECTED] > > >>> ph: (507) 494-5178 > > >>> fax: (507) 454-8104 > > >>> > > >>> "If you do everything right, nobody will realize you've done > > >>> anything at all." > > >>> > > >>> > > >>> > > >>> Servers Alive Discussion List wrote: > > >>> > > >>> > > >>> > > >>>> Your method of creating HTML on the fly is VERY unique > when you > > >>>> look at all of the software in use in the enterprise > > environment. > > >>>> That means, that I (in the singular, me) have to code > > ALL reports, > > >>>> for all conceivable requests of my Sr. Management, and > there is > > >>>> little ability to have a method of my up chain being > > able to ad-hoc > > >>>> browse through how tests are being done with out risk of > > injuring the > > setup. > > >>>> Also, have you tried to print an HTML page that's more > > than a page > > >>>> long? It looks like crud compared to the reports my > managers are > > >>>> used to seeing from all of our other systems which > typically use > > >>>> Crystal Reports for both text reporting and charting. On > > the other > > >>>> hand, if it was in a database, I can hand to any of a > > dozen people > > >>>> a table schema and say "write XYZ report" and actually > have the > > >>>> report experts do their thing, rather than myself > > fumbling through it. > > >>>> > > >>>> A true enterprise solution has to have it's > > configuration data and > > >>>> historical data stored on a standardized data platform, > > preferably > > >>>> a DBMS such as MS SQL, DB2, Oracle, etc., so that the > > data can be > > >>>> protected and managed at the enterprise level through > > clustering, > > >>>> load balancing and Disaster Recovery techniques. This > would mean > > >>>> that SA should not load any data internally or on the host PC > > >>>> running SA, but all would be in a DB server repository. > > Each check > > >>>> cycle would dynamically load each check's config from the DB > > >>>> server, and write back to the server the ongoing status > > of the check > > cycle. > > >>>> It sounds like this is going to be database intensive, > > but at the > > >>>> level I play at > > >>>> > > >>>> > > >>>> > > >>> it's not. > > >>> > > >>> > > >>> > > >>>> We have several systems that routinely write millions of data > > >>>> changes to our servers over the course of a 'light' day, and I > > >>>> suspect that's small compared to a lot of enterprises using a > > >>>> standard > > >>>> > > > DBMS. > > > > > >>>> Servers Alive and it's output is becoming incredibly > tied to our > > >>>> contractual obligations to our customers, and it is > > becoming harder > > >>>> to defend a product developed at such a "personal" > > level. I can't > > >>>> WAIT until our customer charges us for server down time, and I > > >>>> can't prove him wrong because SA wiped out the uptime > > data during a > > >>>> server > > >>>> > > >>>> > > >> re-boot. > > >> > > >> > > >>>> You mostly see in the list where it's a dedicated > individual who > > >>>> has chosen SA, but I also get the sense that it's hard > > for them to > > >>>> get others at their organization to work on it. Possibly > > because it > > >>>> is a unique product both in function and > organizational concept. > > >>>> > > >>>> Don't get me wrong, I LOVE what you do, it's the how > > that I would > > >>>> like to see brought up to a true enterprise level. > > >>>> > > >>>> 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] > > >>>>> Sent: Thursday, May 11, 2006 8:31 AM > > >>>>> To: Servers Alive Discussion List > > >>>>> Subject: [SA-list] RE: [SA-list] RE: [SA-list] RE: [SA-list] > > >>>>> RE: [SA-list] RE: [SA-list] RE: [SA-list] RE: [SA-list] RE: > > >>>>> [SA-list] Skype alerting > > >>>>> > > >>>>> Is HTML a unique interface? > > >>>>> We can make reports in HTML. You have to make an > HTML template > > >>>>> for it, based on HTML tags (standard stuff for the > layout part) > > >>>>> and specific tags for the actual data part. > > >>>>> With whatever reportwriter it would be the same, it > > would need to > > >>>>> have access to the "format" and based on the format it > > could show > > >>>>> you what "vars" you can use. We use tags. > > >>>>> > > >>>>> > > >>>>> Dirk Bulinckx. > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>> -------------------------------------- > > >>>> 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] > > >>> > > >>> > > >>> > > >>>> > > >>>> > > >>>> > > >>> To unsubscribe send a message with UNSUBSCRIBE as subject to > > >>> [email protected] To unsubscribe send a message with > > UNSUBSCRIBE > > >>> as subject to [email protected] > > >>> > > >>> > > >>> > > >>> > > >> To unsubscribe send a message with UNSUBSCRIBE as subject to > > >> [email protected] To unsubscribe send a message with > > UNSUBSCRIBE as > > >> subject to [email protected] > > >> > > >> > > >> > > > To unsubscribe send a message with UNSUBSCRIBE as subject to > > > [email protected] To unsubscribe send a message with > > UNSUBSCRIBE as > > > subject to [email protected] > > > > > > > > To unsubscribe send a message with UNSUBSCRIBE as subject to > > [email protected] To unsubscribe send a message with > UNSUBSCRIBE as > > subject to [email protected] > > > > > > > -------------------------------------- > 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] To unsubscribe send a message with > UNSUBSCRIBE as subject to [email protected] To unsubscribe > send a message with UNSUBSCRIBE as subject to [email protected] > > -------------------------------------- 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]
