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.
