Re: [SA-list] Next version Again you would get stuck on the same "structure" as the current textfile…with the same issues on updating …. so still I don't see a good reason for it
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 Viktor Sokol Sent: Thursday, March 08, 2012 11:17 PM To: Servers Alive Discussion List Subject: Re: [SA-list] Next version Hello Dirk, >>basicly what we have now in the textfile, so why then move to a db? Reason: * Add 85 http checks. Everything the same, only port number is different. * do multiple changes. It is not possible to use gui for that. Lets say I want to add gtalk alert to entires for server1 & server2 and all depended checks (200+) * I need to be able to read ServerAlive settings from 3rd party software. Lets say I have 50 websites on server1 and it is always up-to-date, `cause it is a monitoring system. Instead of having excell speadshit with all websites I could read all info from the database, I could automatically export it into xml format, I can do anything I want with data base. * With db backend I could integrate users authentication with any type of software by synchronizing with corporate LDAP server. Thursday, March 8, 2012, 2:46:22 PM, you wrote: Just thinking some more: having an entry_table with the uid (uniqueID) and the checktype can ofcourse point to a check-table based on the checktype. table PING table URL table NT-SERVICE For an app it's easy to say that IF entry_table.checktype="P" then get data from the PING table based on the uniqueID if entry_table.checktype="U" then get data from URL table based on the uniqueID Not sure however if you can do the same logic from a reportwriter that would use the database. And if we don't splitt the checktypes into different tables, then the check table would be rather "simple" uid (to link it to the entry) checktype (one letter to tell what type of check) params (one large string with all parameters) basicly what we have now in the textfile, so why then move to a db? 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 Goggins, Patrick Sent: Thursday, March 08, 2012 7:46 PM To: Servers Alive Discussion List Subject: RE: [SA-list] Next version With a DB backend there are two things that come to mind, first would be from the reporting aspect where Servers Alive provides all the raw data and any custom reporting massage the data in whatever form the user wants. The second would storage of the configuration where currently there is a text file plus the registry, a basic connection configuration file would exist and the rest would reside in the database…this would provide one (there are many) method for a potential web-based administration IFF (if and only if) desired. To be as generic as possible on the database ODBC would be the simplest to support multiple database types with defaulting to an some sort of internal database mysql, sql express, SQLite, ect. The question I would pose is IFF this were to be done would the users install into a centralized database? I would not, I would have a local install of the database engine as the product is used specifically for checking systems availability, if your network is having issues and a remote database is used then no logs would ever be generated. Database structure-wise you would want to spread across multiple tables where check information is stored separate from the entry data which would be separate key-wise from some of the unique identifiers. IFF interested in more I’d be willing to discuss off-list. With keeping with the non-traditional database style the three things that seem to come up are a separation of the data for either fully customized reporting and long-term analysis, direct querying from external systems to the data, and a separation which is commonly done for a multi-user system in which generally can be accessed to administrate the system remotely. From the administration aspect as was mentioned earlier the large number of clicks required to make some of the changes and setting multiple levels/intervals for checks comes up but doesn’t necessarily require any re-writes to adjust…sometimes a 20lb hammer isn’t always required. ~Patrick From: Servers Alive Discussion List [mailto:[email protected]] On Behalf Of Dirk Bulinckx Sent: Thursday, March 08, 2012 12: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]] (mailto:[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]] (mailto:[mailto:[email protected]]) To: Servers Alive Discussion List [mailto:[email protected]] (mailto:[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. -- Best regards, Viktor mailto:[email protected] (mailto:[email protected]) 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.
