Couple new updates.
First, I have a desktop client now. Much nicer. Everything should have a desktop client. I’m currently using QTM. It’s a great way to separate out content from the publishing process, which I kind of needed to do — too many bells and whistles in wordpress to play around with and I don’t want to be a wordpress tinkerer.
Second, I’ve decided this will be the last post I make that is more than one topic (unless I feel like it).
Third, after playing around with nagios for the first time since about 2008 and working with splunk off and on throughout the years I’ve decided that all of them suck and that I need to build my own userspace reporting system.
I want my twitters, emails, facebook notifications, texts, missed call notifications, IRC nick highlights, and any other thing I’d ever look at in my relatively busy life to be in one database, with a frontend I’ve written to show me what’s going on in the various places.
So, like any good (bad) architect, I did what good architects do. I started to design a model.
Problem Statement:
What I want is an aggregation of all of my dmesg entries, any custom alerts I want to add from any source I want, just a tiny service that listens on my machines that sends arbitrary log entries, event notifications, etc, to one place for all the machines, and then a way to easily sort through and view that data easily based on category in a reasonably scalable way so I can explore intradomain solutions across networks.
So, one approach is something like this:
(replace this with an actual model diagram later)
1. publisher
(client process on machine I want to contribute to the log stream -> Unix Socket IPC) -> Client/tcp sock client)
connecting to: ->
3. broker
(tcp socket listener -> IPC -> aggregator for all log messages received, some kind of massive queue and temporary storage -> sort into different streams by category -> IPC -> filter based on registered subscriptions -> tcp sock listener for subscriptions || tcp sock listener for registrations)
receiving connections and relaying to this:
3. subscriber
(tcp sock client -> IPC -> storage)
User Layer:
[Php-driven content manage system for displaying the data?]
Obviously very early in the design phase.