From 59ac7231888428d57040edde83b3a910fb74ed55 Mon Sep 17 00:00:00 2001 From: Sven Slootweg Date: Wed, 18 Dec 2013 18:14:27 +0100 Subject: [PATCH] Spec out components --- todo.txt | 49 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 49 insertions(+) diff --git a/todo.txt b/todo.txt index 22ac92a..0ba481f 100644 --- a/todo.txt +++ b/todo.txt @@ -3,3 +3,52 @@ * separate alarm and IRC logic * monitor inodes * watchdog on slave and master +* notifications (text, arbitrary-serialized-data as attachment, DEBUG/INFO/WARN/ERR/CRIT) +* consider redundancy - can already connect multiple masters through pubsub, how to deal with duplicate processing checking? + +cprocessd: + -> subscribe to ccollectd + -> debug switch for outputting all to terminal + -> keep up/down state + -> keep last-value state (resource usage) + -> keep track of persistent downtimes (down for more than X time, as configured in config file) + -> alarms (move this from the IRC bot to cprocessd) + -> classify message importance + -> cprocessd-stream socket, PUB that just streams processed data + -> cprocessd-query socket, REP that responds to queries + -> server-status + -> down-list + -> last-value + -> server-list + -> service-list + +cmaild: + -> use marrow.mailer + -> receives data from cprocessd-stream + -> sends e-mails for configured importance levels + +cbotd: + -> currently named 'alert' + -> receives data from cprocessd-stream + -> IRC bot + -> posts alerts to specified IRC channels, depending on minimum severity level configured for that channel (ie. INFO for #cryto-network but ERR for #crytocc) + +csmsd: + -> sends SMS for (critical) alerts + -> receives data from cprocessd-stream + -> Twilio? does a provider-neutral API exist? might need an extra abstraction... + +cwebd: + -> offers web interface with streaming status data + -> publicly accessible and password-protected + -> streaming data from cprocessd-stream + -> on-pageload state from cprocessd-query (including 'current downtimes') + -> tornado+zmq ioloop, http://zeromq.github.io/pyzmq/eventloop.html + -> web dashboard + -> AngularJS + -> fancy graphs (via AngularJS? idk if a directive exists for this) + -> show downtimes as well as live per-machine stats + -> also show overview of all machines in a grid, color-coded for average load of all resources + -> historical up/down data + -> sqlite storage? single concurrent write, so should work + -> perhaps letting people sign up for e-mail alerts is an option? to-inbox will be tricky here