"and I can't prove him wrong because SA wiped out the uptime data during a server re-boot" => that's easy to change. But then again you won't be happy with that. The historical data is in a DB if you enable logging. The part that is indeed NOT in the db is the check/alerts definition. But again creating an XML file from it is not that hard to do. Create an HTML template for it.
Dirk Bulinckx. -----Original Message----- From: Servers Alive Discussion List [mailto:[EMAIL PROTECTED] Sent: Thursday, May 11, 2006 3:06 PM To: Servers Alive Discussion List Subject: [SA-list] Enterprise level data storage (was Skype Alerting) 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]
