Commit | Line | Data |
---|---|---|
756b9d5a SK |
1 | khatus |
2 | ====== | |
a9038fad | 3 | ![mascot](mascot.jpg) |
756b9d5a | 4 | |
44fc2f3d | 5 | Experimental system-monitor and status (bar) reporter I use with |
61c33dc2 | 6 | [dwm](https://dwm.suckless.org/) on GNU/Linux. |
756b9d5a SK |
7 | |
8 | ![screenshot](screenshot.jpg) | |
55407653 | 9 | |
44fc2f3d SK |
10 | Usage |
11 | ----- | |
12 | ||
13 | In my `~/.xinitrc` I have something like the following: | |
14 | ||
15 | ```sh | |
16 | ( $BIN/khatus \ | |
17 | --wifi_interface 'wlp3s0' \ | |
18 | | stdbuf -o L tee \ | |
19 | >(stdbuf -o L "$BIN"/khatus_bar \ | |
20 | -v Opt_Mpd_Song_Max_Chars=10 \ | |
21 | -v Opt_Net_Interfaces_To_Show=wlp3s0 \ | |
22 | -v Opt_Pulseaudio_Sink=0 \ | |
23 | | "$BIN"/khatus_actuate_status_bar_to_xsetroot_name \ | |
24 | ) \ | |
25 | >(stdbuf -o L "$BIN"/khatus_monitor_energy \ | |
26 | | "$BIN"/khatus_actuate_alert_to_notify_send \ | |
27 | ) \ | |
28 | >(stdbuf -o L "$BIN"/khatus_monitor_errors \ | |
29 | | "$BIN"/khatus_actuate_alert_to_notify_send \ | |
30 | ) \ | |
31 | ) \ | |
32 | 2> >($BIN/twrap.sh >> $HOME/var/log/khatus/main.log) \ | |
33 | 1> /dev/null \ | |
34 | & | |
35 | ``` | |
36 | (where `twrap` is a simple script which prefixes a timestamp to each line) | |
37 | ||
38 | The idea is to support appending any number of ad-hoc, experimental monitors by | |
39 | giving maximum flexibility for what to do with the sensor outputs, while | |
40 | maintaining some uniformity of msg formats (again, to ease ad-hoc combinations | |
41 | (e.g. Does the CPU get hotter when MPD is playing Wu-Tang?)). `khatus_bar`, | |
42 | `khatus_monitor_energy` and `khatus_monitor_errors` are just some initial | |
43 | examples. | |
55407653 SK |
44 | |
45 | Design | |
46 | ------ | |
47 | ||
44fc2f3d SK |
48 | ### 2.0 |
49 | ||
50 | In an effort to simplify the components and their interfaces, I removed the | |
51 | concept of a global controller from the previous design (which, at least for | |
52 | now, is superfluous), so now it is essentially a pub-sub - parallel publishers | |
53 | (sensors) write to a pipe, which is then copied to any number of interested | |
54 | subscribers that can filter-out what they need and then do whatever they want | |
55 | with the data. Status bar is one such subscriber: | |
56 | ||
8acd36e8 | 57 | `P1 > pipe&; P2 > pipe&; ... PN > pipe&; tail -f pipe | tee >(S1) >(S2) ... >(SN) > /dev/null` |
44fc2f3d SK |
58 | |
59 | The cool thing is that, because the pipe is always read (`tail -f ... > /dev/null`), | |
09caa63e | 60 | the publishers are never blocked, so we get a live stream of events to which we |
44fc2f3d SK |
61 | can attach any number of interested subscribers (` ... tee ... `) and, because |
62 | the pipe is named, if a subscriber needs to - it too can publish something to | |
63 | the pipe without being blocked. | |
64 | ||
65 | ``` | |
66 | parallel +----------+ +----------+ +----------+ | |
67 | stateless | sensor_1 | | sensor_2 | ... | sensor_n | | |
68 | collectors +----------+ +----------+ +----------+ | |
69 | | | | | | |
70 | data data data data | |
71 | | | | | | |
72 | V V V V | |
73 | multiplexing +-------------+-----------+---------+ | |
74 | to a pipe | | |
75 | | | |
76 | V | |
77 | copying to +-------------+-+---------+---------+ | |
78 | subscribers | | | | | |
79 | V V V V | |
80 | +------------+ ... +----------------+ | |
81 | any number of | status bar | | energy monitor | | |
82 | parallel +------------+ +----------------+ | |
83 | subscribers | | | |
84 | V V | |
85 | +----------------+ +-------------+ | |
86 | | xsetroot -name | | notify-send | | |
87 | +----------------+ +-------------+ | |
88 | ``` | |
89 | ||
90 | ### 1.0 | |
91 | ||
92 | This was an improvement of having everything in one script, but the controller | |
93 | was still way too complicated for no good reason. | |
94 | ||
55407653 | 95 | ``` |
43e49903 SK |
96 | parallel +----------+ +----------+ +----------+ |
97 | stateless | sensor_1 | | sensor_2 | ... | sensor_n | | |
98 | collectors +----------+ +----------+ +----------+ | |
99 | | | | | | |
100 | data data data data | |
101 | | | | | | |
102 | V V V V | |
103 | serial +----------------------------------------------+ | |
104 | stateful | controller | | |
105 | observer +----------------------------------------------+ | |
106 | | | |
107 | decision messages | |
108 | decision | | |
109 | messages | | |
110 | copied to | | |
111 | any number | | |
112 | of interested | | |
113 | filter/actuator | | |
114 | combinations | | |
115 | | | |
116 | V | |
117 | +-------------+-+---------+---------+ | |
118 | | | | | | |
119 | V V V V | |
120 | parallel +------------+ +------------+ +------------+ | |
121 | stateless | filter_1 | | filter_2 | ... | filter_n | | |
122 | filters +------------+ +------------+ +------------+ | |
123 | | | | | | |
124 | V V V V | |
125 | parallel +------------+ +------------+ +------------+ | |
126 | stateless | actuator_1 | | actuator_2 | ... | actuator_n | | |
127 | executors +------------+ +------------+ +------------+ | |
128 | | | | | | |
129 | commands commands commands commands | |
130 | | | | | | |
131 | V V V V | |
132 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
133 | ~~~~~~~~~~~~~ operating system ~~~~~~~~~~~~~~~~~ | |
134 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
55407653 | 135 | ``` |
7daecd24 | 136 | |
44fc2f3d SK |
137 | ### 0.x |
138 | ||
139 | A single script, re-executed in a loop at some intervals, serially grabbing all | |
140 | the needed data and outputting a status bar string, then passed to `xsetroot -name`, | |
141 | while saving state in files (e.g. previous totals, to be converted to deltas). | |
142 | ||
143 | This actually worked surprisingly-OK, but had limitations: | |
144 | ||
145 | - I use an SSD and want to minimize disk writes | |
146 | - not flexible-enough to support my main goal - easy experimentation with | |
147 | various ad-hoc monitors: | |
148 | - I want to set different update intervals for different data sources | |
149 | - I don't want long-running data collectors to block the main loop | |
150 | ||
ec80b440 | 151 | ### Actuator |
43e49903 SK |
152 | Actuator is anything that takes action upon controller messages. A few generic |
153 | ones are included: | |
154 | ||
155 | - `khatus_actuate_alert_to_notify_send` | |
156 | - `khatus_actuate_status_bar_to_xsetroot_name` | |
157 | ||
44fc2f3d SK |
158 | and, by default, are left disconnected from the data feed, so if desired - need |
159 | to be manually attached when starting `khatus`. See usage section. | |
ec80b440 SK |
160 | |
161 | ### Errors | |
7daecd24 SK |
162 | Any errors encountered by any sensor are propagated as alerts by the |
163 | controller, which are in turn actualized as desktop notifications by the | |
43e49903 | 164 | `khatus_actuate_alert_to_notify_send` actuator: |
ec80b440 | 165 | |
7daecd24 | 166 | ![screenshot-self-error-propagation](screenshot-self-error-propagation.jpg) |
1341dc96 SK |
167 | |
168 | TODO | |
169 | ---- | |
170 | ||
44fc2f3d | 171 | - status bar templating language |
1341dc96 SK |
172 | - retry/cache for sensors fetching flaky remote resources (such as weather) |
173 | - throttling of broken sensors (constantly returns errors) | |
174 | - alert specification language | |
175 | - trigger threshold | |
176 | - above/bellow/equal to threshold value | |
177 | - priority | |
178 | - snooze time (if already alerted, when to re-alert?) | |
179 | - text: subject/body | |
7917538c SK |
180 | |
181 | Redesign notes | |
182 | -------------- | |
183 | ||
184 | - controller should not do formatting | |
185 | - need in-memory db for diskless feedback/throttling and cache |