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]
