xymonfetch doesn't reload log files on -HUP # journalctl integration (as conditional) to replace logfetch on systems w/o syslog # max message size - C_LAST or INBUF? # Send back response for client before handle_client? # Print out max cchannel sizes on setup ### rrdcachectl should a) use RUNDIR (or search multiple dirs) and/or b) accept a full path ## make nl-encoded modifier text searchable, as well as line1 ## The full TODO list here has been removed. Future blue-sky discussion will be ## occuring on the xymon users or development lists. You should subscribe to both! # xymongen should cache std pages and bulletin # xymond: attempting to send reponse when conn closed should be safer # xymond: compress in xymond does NOT mandate noresponse # xymonproxy: add --noresponse-compressed to restore current behavior (otherwise assume that any compressed msg could be two-way # and don't throw it onto BFQ) # add --decompress-transit option to xymonproxy # norawdata flag for xmh_items to inhibit display of non-threshold data in status messages # only works for hosts in hosts.cfg! - xymoncommerrno holds last sendmessage errno result or load_hostinfo result - Find all environment (setenv/putenv) updators and factor out. - prereq for turning lookups into char ** array (xmh_find_item) instead of linear search On each status message coming in, if matches a set of "network tests", and conn is red, and noclear is not set, set status to clear even if red (Solves network tests from other scripts not using same xymonnet logic) ## Document: line1 of a status message should not contain any of the following characters: | \n \r \t \\ # Make line1 a first-class citizen in logrec, pre filtered through msg_data # add GRAPH_cpu (etc) examples in xymonserver.cfg # debug vprintf weirdness -- why so much in xymond? # volatile debug flag? # The rest here is just a mental note for things that have only been half-implemented # and need to be completed. * client/history logs: check if file is gzipped and decompress (or send as gzipped) on the fly * Fix checkpoint default patch * xymonproxy select not decrementing investigation * find more places to remove mallocs * xymonnet -- parallel DNS (TEST) lookup * For items without dependency checking, start batch chunks once some are completed = httpstatus can be set to go red instead of clear # - add "dircount: line to client-local documentation", and processing in xymond_client # Add xxHash digest routines # Finish iostat parser work (for Linux/BSD at least) # libwrap support? 'xymond' vs 'xymonproxy' (etc...) # see: http://marc.info/?l=amd-dev&m=105849759412346&w=2 for example -- pretty simple # # TODO: add'l info in 'ping' ("xymond 4.3.17 $HOSTNAME $XYMONSERVERIP") # 'xymondstats' = output (more or less) of xymond test # "proxystats" = output (more or less) of xymonproxy test from (first) proxy # json export format: "xymondjboard" # add cookie= filter # add lastcookie= record # add each of the XMH_RAW/xmh-filters as environment variables for xymond_alert scripts # (needed for "last client message" linking) ## --reportaddr= for interval based binaries (xymonnet/xymongen) as override for XYMONSERVER ## --reportaddr= options for all daemons xymond, xymonproxy, xymonlaunch ## SUBJECT="" in alerts.cfg instead of host:svc # # add fake httpstatus codes for non-HTTP responses (eg, DNS failure, connection timeout) # add la15 la5 la1 metrics gathering # xymond_client unix_cpu: if nproc data available available, add pre-computed RRD metric of la/nproc # # TODO: 'hostsnap' command # TODO: log timing on xymond(x)board queries # --send-stachg-on-modify # send a copy of onto the stachg channel when we add a new (based on identifier) modify to # an existing status, regardless of whether the color has changed Conceptually, the "GROUP" concept in status messages, "modify" message sources, and "&color" lines in status messages are all doing basically the same thing. Overriding and/or deciding an overall color based on (at least partially) some tagged list of discrete sub-test qualifiers. This should be made a first-class concept with support in xymond core. Color and options should be queryable, a new channel for tagchg would receive all status changes *and* all tag changes (adds/removals) - while stachg only gets status *color changes*. "xymondboard status=disk tag=/root color=red" This provides simple, O(N) dependency between items, allows statuses to have a richer metadata store, is backwards compatible, lets alerts be configured on new "problems" within an already-bad test, and gives a solution for posting transient problems without polluting the status space.