In all cases you described we're back to the question but how to store such difference in data into a db. A table per check type? IF not then you won't get the flexibility you want.
I agree that if we support ODBC that we can support "all" databases. The issue that I have with ODBC compared to using something like SQLAPI is that ODBC is slow compared to SQLAPI. And SQLAPI does give me the ability to use its own API that writes directly to Oracle, mySQL, msSQL, sqlLite, … and also ODBC. Dirk Bulinckx. Network Monitoring by Servers Alive - http://www.woodstone.nu DNS Hosting with ipv4 and ipv6 on http://www.stellardns.com From: Servers Alive Discussion List [mailto:[email protected]] On Behalf Of Vogl, Tom Sent: Friday, March 09, 2012 3:16 PM To: Servers Alive Discussion List Subject: RE: [SA-list] Next version Dirk, There are a whole lot of reasons to have a database behind the configuration for alerts and checks. 1) Less management overhead: Would allow for a simplified creation and management of this information of users so inclined to approach it from this direction. 2) Ability to query check configuration and use it with reporting against the SA Status log table for additional information about the check. 3) Security auditing: Did a check get changed? When? With a database I can capture those events via triggers and report on it immediately, or cause other external actions to occur. Trying to parse your existing configuration is almost impossible. I can tell if the file changed – but it’s really hard to report on WHAT changed. 4) Quality control: Are all my PING checks set to 80% response levels? Which ones aren’t? Try asking that of your current config file. 5) Reporting flexibility: I can report on my check and alert configurations in whatever format I want, because I can get access to the information. For example: What servers do I have disk space checks on that I don’t have a ping check for? 6) Increases the value/usability of SA. If the entire config is more open and accessible, then people will find more ways to integrate to it and use it. 7) It’s data – and data should live in a database. Personally, I think your arguments about “which database” and who wants which one are bogus. Just write to the ODBC standard and use it. Anyone with enough skills to want the DB can easily link their db to and ODBC connection. You can fight off the “it should X” in exactly the same way you’ve fought the “it should be a db” issue. Include an empty ACCESS db with table structures and that would be all we would need to port to SQL, MySQL, or anything else. Please give us an option to switch between your existing flat file, or an ODBC-compliant database. -Tom (Standard disclaimer: Opinions are my own and not necessarily that of my company). From: Servers Alive Discussion List [mailto:[email protected]] On Behalf Of Dirk Bulinckx Sent: Thursday, March 08, 2012 1:01 PM To: Servers Alive Discussion List Subject: RE: [SA-list] Next version If I don't look at the "cost" of dev…then I'm not convinced it will realy add something to Servers Alive. First of all if I "decide" to make it db-based then there is the question of what database. I could use some kind of engine that allows you to use mySQL, msSQL,Oracle, Sybase, DB2, Informix, SQLite or "just" ODBC. But then you get the point of migrating it from db_type_1 to db_type_2 and yes we will get that question :-( Then the question of support, now it's often easy to "just" get the entries file and test with that…how to do when you're using db_base_system_something, then we need to have that too OR have a way to migrate that to another db_type (same issue as above) Now let's asume that all of the above is a none-issue. Most people that want a db is for easy management of the entries, right? Well looking at the different checks for example, how to put that in an easy to use db? A ping check for example uses totally different parameters then a URL check. I could just "throw-in" the parameters in the same way as I do in the current text file, but then you loose the main part, ease of mangement. So why use a db? And IF we use a db, maybe that some DBA can answer this part, would this mean one "table" for all the checks or one "table" per checktype? And what to do if we add a new check type, we will have to supply a script to change the db? Add a new table or add fields? Dirk Bulinckx. Network Monitoring by Servers Alive - http://www.woodstone.nu (http://www.woodstone.nu) DNS Hosting with ipv4 and ipv6 on http://www.stellardns.com (http://www.stellardns.com) From: Servers Alive Discussion List [mailto:[email protected]] On Behalf Of Jason Passow Sent: Thursday, March 08, 2012 6:16 PM To: Servers Alive Discussion List Subject: RE: [SA-list] Next version I think that the issue is that some admins in small shops do not have the database know-how. In shops where we do have the know-how we would really like it in order to make changes and write reports on what checks are run. Some applications offer to use your own SQL server (perhaps an enterprise feature ;) or a local "db" which could just be the flat text you have today. That way a user who is uncomfortable or unfamiliar with databases could stick with the same old. However it the template model existed as was discussed earlier this week changes would be easier and perhaps a database is less necessary. It would be good to hear from the advocates of the database model what EXACTLY it is they hope to accomplish with a database backend for configuration. >From a lay person stand point (non-programmer), it seems that if you can >define the database structure the rest would be relatively easy. You can read >the database on startup (if that is what is selected in the config). Perhaps >in the interface you need a save (to text) and a save (to database) option >unless the save command has a check for whether the config was read from a >database or a text file. The checking engine would not need to be tied to the >database live (if it makes it easier). Maybe the database is just a holding >tank and the live config is read from a text file every time. At startup, you >create the text file from the database. There would have to bea save running >config to database option. A restart of the checking engine would allow the >changes to be read and a new file created. I don't mean to suggest that this >task would be easy. If it was tied to enterprise licensing it would bring >some additional revenue perhaps. Or perhaps you need to add an enterprise >plus license to recoup the costs of development. Jason Passow Network Administrator Mississippi Welders Supply http://www.mwsco.com (http://www.mwsco.com) [email protected] (mailto:[email protected]) ph: (507) 494-5178 fax: (507) 454-8104 -------------------------------------------------------------------------------- From: Dirk Bulinckx [mailto:[email protected]] To: Servers Alive Discussion List [mailto:[email protected]] Sent: Thu, 08 Mar 2012 10:46:28 -0600 Subject: RE: [SA-list] Next version It's not sure IF we get to that. In the past it looked like "everyone" wanted this, now it seems that it's 50/50..... Dirk Bulinckx. Network Monitoring by Servers Alive - http://www.woodstone.nu (http://www.woodstone.nu) DNS Hosting with ipv4 and ipv6 on http://www.stellardns.com (http://www.stellardns.com) -----Original Message----- From: Servers Alive Discussion List [mailto:[email protected] (mailto:[email protected])] On Behalf Of Viktor Sokol Sent: Thursday, March 08, 2012 5:17 PM To: Servers Alive Discussion List Subject: Re: [SA-list] Next version Hello Dirk, Im still looking forward for entries file in data base. Any progress/estimates on that? Monday, March 5, 2012, 6:01:06 PM, you wrote: > About 5: > so basicly you would want an entry that is "exactly like entry <something-else>" > EXCEPT for the hostname and prettyname and remark? > and if <something-else> has a change then automaticly the entry gets the change > too? -- Best regards, Viktor mailto:[email protected] (mailto:[email protected]) To unsubscribe send a message with UNSUBSCRIBE in the subject line to [email protected] (mailto:[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] (mailto:[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] (mailto:[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] (mailto:[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.
