Currently we're looking at "moving" the entries-file to a db, not the setup. This means that people and teams will still be in the registry and not in the entries-db. If you would copy the alerts from one entry/host to another you would still have to adapt the uniqueID in order to reflect the new entry (and adapt the numberofalerts parameter for that host/entry). The last modification date/time is only available for the entry as such not for each record in the table. The content of the fields will still be the same as what it is within the entries-file that you currently have, so it will still be as cryptic as it is now....
Dirk Bulinckx Servers Alive - http://www.woodstone.nu (http://www.woodstone.nu/) StellarDNS (DNS Hosting) - http://www.stellardns.com (http://www.stellardns.com/) -------------------------------------------------------------------------------- From: Servers Alive Discussion List [mailto:[email protected]] On Behalf Of Vogl, Tom Sent: Wednesday, December 05, 2012 12:01 AM To: Servers Alive Discussion List Subject: RE: [SA-list] Servers Alive's database back-end Dirk, >From a database design standpoint, I think it really important that: HOSTS CHECKS ALERTS all be separate tables. Frequently i want to comparisons against checks set up on various hosts, who get's what alerts, etc. Schedules could be managed as attributes of the Check and Alert, or as their own table(s)... >From what I was thinking about, I could see the following tables: People Teams TeamPeople (assignment of People to one or more teams) Hosts Checks - Checks could be unique in the environment. or simply exist under a host. If they are unique, that means this is a "master list" of checks that can get assigned to various hosts and that a HostChecks table would be where Checks get Assigned to a Host. It would be at this HostChecks level that you would define the schedule(s). Schedules could be based on a schedule table (1 record = a specific schedule configuration) and linked to a host check, or schedules could just be data in the HostCheck table. I really haven't evaluated the pros/cons on either. Alerts would then exist under HostChecks. Alerts would also have schedules tied to them in whatever format you did for HostChecks. really really really am looking for the ability to report on Hosts, Checks and results. Types of things I hope to achieve with a db structure: * Copy all checks and Alerts from Server A to Server B. * Report on which servers aren't checked for "ping at 80% or better" * Report on what checks / alerts have been altered in the last 30 days. (PLEASE include last modified date/time in each table!) * Export results for free disk space for a server over time to determine disk consumption rates. * Sort ping response time results to find out which servers are slowest and when. * Create new alerts or checks for servers via sql scripts (that we write) that will just insert the correct records in to the db. Right now, one of the most time consuming processes of rolling out a new server for us is setting up all the SA alarms we need... hope this helps! -tom -------------------------------------------------------------------------------- From: Servers Alive Discussion List [[email protected]] On Behalf Of Dirk Bulinckx [[email protected]] Sent: Friday, November 30, 2012 11:30 AM To: Servers Alive Discussion List Subject: [SA-list] Servers Alive's database back-end Some time ago it seemed to be a hot-topic to have a database backend for Servers Alive opposed to having a flat-text file like we have now. We are currently working on such a db backend (and no you won't need a SQL server or mySQL or Oracle server to run SA, SA will have its own simple build-in DB with option to use a big db system too). Having this db backend will give us more management options too so we think that this is a good thing to do. BUT as always we're faced with some open questions. Internaly (in SA I mean) we store the info of an entry is several large chuncks of data host info check info alerts info output info schedule info custom fields info In the db we could have one large table that combined host, check, output, schedule , custom fields And a "linked" table for the alerts (as you have several alerts per entry) This would mean at least something like 50 fields in one table OR we could have a table for host info check info output info schedule info custom fields info (and ofcourse for the alerts) (where for each host-record you would have 1 check record, 1 output record, 1 schedule record, 1 custom fields record) I can see pro's and cons for both systems. I would like to get some info/feedback from our users on how they would prefer this and why :-) Dirk Bulinckx Servers Alive - http://www.woodstone.nu (http://www.woodstone.nu) StellarDNS (DNS Hosting) - http://www.stellardns.com (http://www.stellardns.com) To unsubscribe send a message with UNSUBSCRIBE in the subject line to [email protected] If you use auto-responders (like out-of-the-office messages), make sure that they are not sent to the list nor to individual members. Doing so will cause you to be automatically removed from the list. To unsubscribe send a message with UNSUBSCRIBE in the subject line to [email protected] If you use auto-responders (like out-of-the-office messages), make sure that they are not sent to the list nor to individual members. Doing so will cause you to be automatically removed from the list. To unsubscribe send a message with UNSUBSCRIBE in the subject line to [email protected] If you use auto-responders (like out-of-the-office messages), make sure that they are not sent to the list nor to individual members. Doing so will cause you to be automatically removed from the list.
