💾 Archived View for nanako.mooo.com › gemlog › 2024-03-15-a.gmi captured on 2024-06-16 at 12:45:30. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-03-21)
-=-=-=-=-=-=-
My usual over-arching workflow is 1) Do a big main project, 2) Release of said project, 3) Take some downtime and work on smaller stuff. Well I'm basically in step 3 now that Benben 0.4.x is out, and if we ignore my Doom/Quake maps for a moment, I basically have two projects on the table for this downtime:
The first isn't too exciting. midi123 is basically feature complete and just gets polish once in a while. Since Benben's overall design is proven, it's really just a matter of fighting procrastination, and porting the architecture over to midi123. So it won't be that big of a project.
The second is more interesting...
I usually use two instances of GKrellM, one to monitor my desktop, and a second that connects to a daemon to monitor my server. I've tried other monitors in the past and I just keep coming back to GKrellM because 1) it shows me what I want, 2) it's easy to configure, 3) IT PURDY (in that older skeuomorph way that I love so dearly). But, I often have more than one server up and running, and having a bunch of GKrellM instances on my desktop is kinda awkward to handle. Also, GKrellM is still using GTK2, and though I have no problems with this (it's still probably my favorite UI toolkit), I'm not blind to the change going on around me. With the future of the Linux desktop looking quite different, I gotta start thinking about how to future proof myself and my setup. GTK2 has, after all, been EOL since December 2020, and X11 is ever so slowly being sent to pasture, regardless of how much I hate to admit it[2]. Plus I just like to do new things to learn and because it's fun ^_^
So, I've been thinking about how I'd go about designing a monitoring package the architecture and I've decided on a solid foundation.
The Update Protocol is pretty simple where you get a short header, then a list of monitors and their data fields. Each monitor has a unique Type ID (e.g. the Network Usage monitor has a Type ID of 3), and then a set of data fields. Each data field has a Data Type ID, followed by its data. To implement this, I've elected to define a single monitor as a class that inherits from MONITOR and uses a special MONITOR-CLASS metaclass to manage a "Type ID". Then I use CL-SDM's "Pseudo Enum" feature to define the data types, and set up some library functions for serializing the fields properly. I figure this way, I can update the protocol separately from the monitor definitions themselves while I work on it (though officially, the fields the monitors include are part of Update Protocol).
Similar to Protocol Buffers, there's no semantic meanings transferred with the data - it's just raw data. The only way to interpret it is to know which version of Update Protocol is being used. For this reason, I plan to have a short preamble sent when a client first connects that lists the protocol version, as well as a few other things that probably won't change while the system is running (like its CPU architecture). This will also allow a newer client to still connect to older servers since newer clients can just fall back to using an older Update Protocol version.
The LZ4 compression I have planned may get thrown out before I'm done. Right now, the total uncompressed size of an Update Protocol Message is 289 bytes, which includes the header, uptime, load averages, active and total processes, and data on three separate network interfaces plus their names. If I save this raw data to a file, then manually compress it with LZ4 at compression level 9, it becomes 143 bytes, 49.48% the original size. The size of each message will of course grow I add more monitoring data, but I'm not sure how _much_ it'll grow and if its growth will be worth the extra few CPU cycles. Though still, LZ4 compression is extremely cheap, so it may be a non issue. I need to do some more testing first.
Anyway, I already have a basic prototype server with three types of monitors (uptime, load averages + procs, and network usage) up and running in Common Lisp and it seems to be working perfectly fine. For now I'm just printing the data out in the SLIME repl in a loop, but as long as this proves to be stable, I'll start working on designing a simple test client. I also need to look into how I'll be encrypting the messages, if encryption will be optional, and how to handle authentication.
--------- Page served by Aya https://nanako.mooo.com/fossil/aya/ Aya is under the GNU Affero GPLv3 license