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]
