I agree with this. If you can do it we could report on it and we a are a small shop supporting 80 or so users. Shops who are not able probably do not the same kind of reports.
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: > 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]
