X-Git-Url: https://git.xandkar.net/?a=blobdiff_plain;f=README.md;h=34247a12f6cfa89226c357d603c97e6a3a69d739;hb=b7601ee441ff57d0a88439dc9709cb4aa2f44744;hp=5381f906a12c6a4c956ccafd60e439982a4fefc6;hpb=de9eca200785574d9815196167448b2dfd8228e7;p=khatus.git diff --git a/README.md b/README.md index 5381f90..34247a1 100644 --- a/README.md +++ b/README.md @@ -54,10 +54,10 @@ now, is superfluous), so now it is essentially a pub-sub - parallel publishers subscribers that can filter-out what they need and then do whatever they want with the data. Status bar is one such subscriber: -`P1 > pipe&; P2 > pipe&; ... PN > pipe&; tail -f pipe | tee >(S1) >(S2) ... >(SN) > /dev/null +`P1 > pipe&; P2 > pipe&; ... PN > pipe&; tail -f pipe | tee >(S1) >(S2) ... >(SN) > /dev/null` The cool thing is that, because the pipe is always read (`tail -f ... > /dev/null`), -the publishers are never blocked, so we get a live stream of event to which we +the publishers are never blocked, so we get a live stream of events to which we can attach any number of interested subscribers (` ... tee ... `) and, because the pipe is named, if a subscriber needs to - it too can publish something to the pipe without being blocked. @@ -168,6 +168,12 @@ controller, which are in turn actualized as desktop notifications by the TODO ---- +- tests (design is starting to take shape, so it is time) +- show how many Debian package updates are available +- show how many Debian package security-updates are available +- monitor disk usage rate of change and alert if suspiciously fast +- bring back CPU usage monitor +- actual METAR parser, to replace the flaky `metar` program - status bar templating language - retry/cache for sensors fetching flaky remote resources (such as weather) - throttling of broken sensors (constantly returns errors) @@ -177,9 +183,98 @@ TODO - priority - snooze time (if already alerted, when to re-alert?) - text: subject/body +- monitor processes + - zombies + - CPU hogs + - memory hogs + - memory leaks (if some process consistently grows) +- report detailed status upon request (to a terminal) + - use color to indicate age of data Redesign notes -------------- - controller should not do formatting - need in-memory db for diskless feedback/throttling and cache +- decouple sensor execution from sleep, i.e. a sensor is blocked not by sleep + process directly, but by reading of a pipe, to where a sleep process will + write a message announcing interval completion and thus signaling execution. + This will allow us to manually signal a sensor to update (concretely - I just + openned my laptop from sleep and want to force the weather to update + immediately); likewise, the sleep process should be blocked on pipe-read + until sensor execution is complete - this will allow us to reconfigure + intervals at runtime (which seems like a better idea than the above in-memory + DB one). + +Ideas +----- + +- store data with rrdtool +- monitor tracking numbers (17track should be easiest to get started with) +- monitor stock prices +- monitor some item price(s) at some store(s) (Amazon, etc.) +- monitor eBay auctions (https://en.wikipedia.org/wiki/EBay_API) +- monitor PayPal (https://www.programmableweb.com/api/paypal) +- monitor bank account balance and transactions + - https://communities.usaa.com/t5/Banking/Banking-via-API-Root/m-p/180789/highlight/true#M50758 + - https://plaid.com/ + - https://plaid.com/docs/api/ + - https://plaid.com/docs/api/#institution-overview + - https://github.com/plaid + - https://www.bignerdranch.com/blog/online-banking-apis/ +- monitor/log road/traffic conditions + - travel times for some route over a course of time + - https://msdn.microsoft.com/en-us/library/hh441725 + - https://cloud.google.com/maps-platform/ + - https://cloud.google.com/maps-platform/routes/ + - https://developer.mapquest.com/documentation/traffic-api/ + - https://developer.here.com/api-explorer/rest/traffic/traffic-flow-bounding-box +- monitor news sources for patterns/substrings + - http://developer.nytimes.com/ + - https://news.ycombinator.com/ + - https://lobste.rs/ + - https://www.undeadly.org/ + - http://openbsdnow.org/ + - https://lwn.net/ +- monitor a git repository + - General + - total branches + - age of last change per branch + - change set sizes + - GitHub + - pull requests + - issues +- monitor CI + - Travis + - Jenkins +- pull/push data from/to other monitoring systems (Nagios, Graphite, etc.) +- monitor file/directory age (can be used for email and other messaging systems) +- monitor mailboxes for particular patterns/substrings +- monitor IRC server(s)/channel(s) for particular patterns/substrings (use `ii`) +- monitor iptables log + - auto-(un)block upon some threshold of violations +- monitor changes in an arbitrary web resource + - deletions + - insertions + - delta = insertions - deletions +- monitor/log LAN/WAN configurations (address, router, subnet) +- monitor/log geolocation based on WAN IP address +- correlate iptables violations with network/geolocation +- monitor vulnerability databases + - https://nvd.nist.gov/ + - https://vuldb.com/ + - http://cve.mitre.org/ +- browse https://www.programmableweb.com/ for some more ideas +- GC trick: instead of actually doing GC, do a dummy run of building a status + bar at `BEGIN`, to fill-in the atimes for keys we need, then use the atimes + keys to build a regular expression to accept messages only from keys we + actually use + +Many of the above will undoubtedly need non-standard-system dependencies +(languages, libraries, etc.), in which case - would they be better off as +separate projects/repos? + +With all these ideas, it is starting to sound very noisy, but no worries - to +quickly and temporarily shut everything up - just kill `dunst` and or toggle +the status bar (`Alt` + `B` in `dwm`). For a permanent change - just don't +turn-on the unwanted monitors/sensors.