ODBC Logging
From ServersCheck Wiki
The ODBC logging feature stores all outages, all values returned by each check and/or status changes into an ODBC compliant database.
A sample database is provided with the installation of the software and is installed in the c:\ root directory (serverscheck.mdb)
Setup scripts for some databases are installed with the software in the \add-ons subdirectory
Contents |
Description
The ODBC logging feature stores all outages and/or status changes into an ODBC compliant database. The way it logs is defined by the alert rule of each check. With this you can define on a per check basis how logging should be performed. (Check in the Help for section: Define Alerts)
Definition
Go to the ADMIN button, and click at the ODBC Logging link. After that you will get new screen where you should configure options related to the ODBC Logging Feature in the ServersCheck.
You need to define a connection string to the ODBC database. For this you can use an existing template from the setup. Upon installation a sample database is installed on the root of the C:\ drive; the database name is serverscheck.mdb. ServersCheck will only store values when the Store Values flag is set in the Configuration Settings.
Database Structure
The database needs to have following structure:
table name: SERVERSCHECK
Fields names and types:
TimeStampsDate/Time Field (value is MM/DD/YYYY) Versions prior to 4.4.3 the field is Text Char(50) - this is the time when the status change occured
UNIXTimeStamps Number: same as previous field but holds the time in EPOCH UNIX time
Type Text Char(50) : Which type the monitor belongs to
Label Text Char(50) : This is the UNIQUE IDENTIFIER of the rule and is the link to any of the 2 other tables
Groups Text Char(50) : This is the GROUP a rule (monitor) belongs to
Status Text Char(50) : This is the status to which the rule changed
Errors Text Char(255) : If the rule changed to a DOWN or WARNING state, then this is the error causing it
This table holds all status changes for a specific rule (=check or monitor).
table name: SERVERSCHECK_CHECKS
Fields names and types:
Label Text Char(50) : This is the UNIQUE IDENTIFIER of the rule and is the link to any of the 2 other tables
Groups Text Char(50) : This is the GROUP a rule (monitor) belongs to
Type Text Char(50) : Which type the monitor belongs to
Status Text Char(50) : This is the current status of the rule (monitor)
Upcounter Smallint : The number of times the check returned an OK status
Downcounter Smallint : The number of times the check returned a DOWN status
ServiceLevel Smallint : Service level in percentage
Errors Text Char(255) : Last known error returned
CheckVal Text Char(50) (only if flag Store values is checked) : This is the last value returned by the monitor
This table holds the current status of all the monitors defined.
table name: SERVERSCHECK_DATA (only if flag Store values is checked)
Fields names and types:
Label Text Char(50) : This is the UNIQUE IDENTIFIER of the rule and is the link to any of the 2 other tables
Type Text Char(50) : Which type the monitor belongs to
CheckVal Text Char(50): This is the last value returned by the monitor
TimeDate Date/Time (note: make sure to give it a default value. In Microsoft Access, the default value is =Now()) : This is the time of the check
This table holds all the values returned whenever a monitor is executed.
All 3 tables can be linked through the LABEL field as this is a unique identifier for each record.
Debugging
If no data is stored in the database and the option has been enabled, then run the Monitoring Service in debug mode as per knowledge base. This will allow you to see SQL errors and statements sent. You can also turn on logging (if available) on your ODBC database to find errors in the database. Typically it is due to wrong data formats compared the INSERT statement ServersCheck tries to perform.
http://kb.serverscheck.com/index.php?page=index_v2&id=33&c=6
