.gitignore and README update.

This commit is contained in:
Johannes Findeisen 2023-02-21 02:33:39 +01:00
commit 41047b743a
3 changed files with 13 additions and 10 deletions

1
.gitignore vendored
View file

@ -1,4 +1,5 @@
# Linspector # Linspector
etc.local/
log/*.log log/*.log
log/*.log.* log/*.log.*

View file

@ -8,10 +8,10 @@ The idea is based on a software I developed around 2010 or so. The name of the s
[Linspector](https://linspector.org/) but the implementation was just too [Linspector](https://linspector.org/) but the implementation was just too
complicated. The idea still remains so here is the rebirth of Linspector. First commits complicated. The idea still remains so here is the rebirth of Linspector. First commits
of this rewrite where done as a new project named of this rewrite where done as a new project named
[monipy](https://git.unixpeople.org/linspector/monipy), but I moved to the name [monipy](https://github.com/linspector/monipy), but I moved to the name
Linspector because I believe it is the better and cooler name... Old Linspector code is Linspector because I believe it is the better and cooler name... Old Linspector code is
not available in this repository anymore, you can find it under not available in this repository anymore, you can find it under
[https://git.unixpeople.org/linspector/linspector-old](https://git.unixpeople.org/linspector/linspector-old). [https://git.hub.com/linspector/linspector-old](https://github.com/linspector/linspector-old).
Hope this project will become useful for someone at some day and not only for Hope this project will become useful for someone at some day and not only for
me. Just give me some amount of time for the first usable release... ;) me. Just give me some amount of time for the first usable release... ;)

View file

@ -7,14 +7,14 @@ DROP TABLE IF EXISTS log;
CREATE TABLE log ( CREATE TABLE log (
-- maybe do not use a autoincrement field because of limits. maybe just index more fields. since there is no -- maybe do not use a autoincrement field because of limits. maybe just index more fields. since there is no
-- relation to other tables a primary key makes no sense. -- relation to other tables a primary key makes no sense.
id BIGINT UNSIGNED AUTO_INCREMENT, -- maybe this could be the monitor id because they are unique and will not change after restart id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE,
date date, -- current date _date date, -- current date
time time, -- current time _time time, -- current time
timestamp timestamp, -- execution timestamp returned from the monitor's service (last_execution) _timestamp timestamp, -- execution timestamp returned from the monitor's service (last_execution)
status VARCHAR(5), -- NONE, OK, ERROR (maybe assign number to the codes for fast database searches?) status VARCHAR(5), -- NONE, OK, ERROR (maybe assign number to the codes for fast database searches?)
message VARCHAR(255), -- a short message returned by each monitor (max 255?) message VARCHAR(255), -- a short message returned by each monitor (max 255?)
monitor VARCHAR(255), monitor VARCHAR(255),
monitor_args LONGTEXT, -- kwargs passed to the monitor's service monitor_args VARCHAR(255), -- kwargs passed to the monitor's service
monitor_id VARCHAR(64), monitor_id VARCHAR(64),
service VARCHAR(255), service VARCHAR(255),
job_id VARCHAR(32), job_id VARCHAR(32),
@ -22,7 +22,9 @@ CREATE TABLE log (
host VARCHAR(255), host VARCHAR(255),
hostgroups VARCHAR(255), hostgroups VARCHAR(255),
job_threshold INT(128), job_threshold INT(128),
raw LONGTEXT, -- raw json response data from a monitor's service. maybe write this data to a different database optimized for json object storage and use the monitor_id for relation. raw LONGTEXT, -- raw json response data from a monitor's service. maybe write this data to a different database optimized for json object storage and use the id for relation.
PRIMARY KEY(id, monitor_id), PRIMARY KEY(id, _timestamp, monitor_id),
INDEX monitor_id(monitor_id) UNIQUE INDEX (id),
INDEX monitor_id(monitor_id),
INDEX _timestamp(_timestamp)
); );