How big of a thing is "direct SSL communication support throughout" going to be? I mean, what will that cover? I'd really like to see encrypted client-to-server connections, because I'm required to encrypt all network traffic. At present I'm handlng it by using curl to send to xymoncgimsg.cgi. It works well enough for a small number of clients, but is becoming unreliable as more are added.
Ralph Mitchell
On Sun, Nov 1, 2015 at 10:09 AM, J.C. Cleaver <cleaver at terabithia.org> wrote:
On Sun, November 1, 2015 2:18 am, Adam Goryachev wrote:
On 01/11/15 21:08, J.C. Cleaver wrote:
I was actually planning on a roadmap update during the 4.3.22 announcement this week, but might as well post now. :)
After 4.3.22 is released, I'll be opening up the 4.4 release. This is primarily focused on high performance and core features, including a back-port of the compression support from Xymon 5 (a/k/a "trunk"). It's a fairly large patch set that incorporates a lot of the work that had been done in the Terabithia RPMs. The potential for migration gotchas combined with the sheer size of the delta warrants a minor version bump, but it's still identifiably "Xymon 4".
Xymon 5 is the trunk update Henrik has been working on for a while now. The biggest core features are
Would it perhaps be useful to break down the above enhancements, and release them incrementally? compression - version 4.4 sqlite as a data store - version 4.5 IPv6 - version 4.6 direct SSL communication support throughout - version 4.7 a new poller (xymonnet2) - version 4.8 and page generator - version 4.9 more streamlined client->RRD processing - version 5.0 (because now we have done everything that was needed for 5.0 :)
That type of thing might work, though that does mean committing to the order somewhat ;)
sqlite in xymond in particular (rather than the channel workers) is a pretty large change that could have some performance impact over the tree structure in use now.
I'm also looking to complete full removal of display HTML and an easier way to deploy "themes" at the front end (which can, of course, link in to whatever custom display solutions are desired). Some of that might be 4.4, some might be 4.5, but IMO it's additional ways of visualizing / browsing data at the web layer that would most help the project's reach.
This could be good. One thing that might help improve performance of the pages is to use some sort of persistent connection between javascript on the client (browser) and the server. Then any status change can be communicated in real time to the browser which can simply update the icon and background colour as needed. This could also be used to read real time status updates to pass to other systems/services.
Possibly. The problem there is that keeping an active channel open directly into xymond (for what are essentially push notifications) has the potential for impact to the core, which we generally want to avoid. It'd be safer to isolate that by having a --channel=stachg worker writing to a location that can be queried by other processes, optionally notifying, so that message processing isn't affected.*
Generally speaking, though, yes. An AJAX-y dashboard can dynamically update the page without reloading the view, and that's exactly the type of thing that can be provided.
(Intermittently querying for changes can actually be done now with an appropriate "appfeed" filter command, like
http://www.example.com/xymon-cgi/appfeed.sh?filter=color=red,yellow,green+la...
1445783474 , which will give you XML for anything that's changed in the last week or so.
*This does also raise the possibility of providing HA/mirroring directly within xymond. A read-only xymond replicated mirror can be used for report generation and whatnot.)
Finally, separating the "theme" from the code will allow much greater innovation with how the data is presented.
This is definitely the goal. The display we have now has certainly stood the test of time, but can be off-putting to those expecting e.g., a Nagios-type experience.
The existing CGIs now can be replaced with whatever one likes, header customization can be used to wrap xymongen-generated page to match, and channel workers can be written to process data into any sort of message bus or DB (all RRD data at SNC gets written to a rotating tmpfs log, which is ingested by a Big Data system for further analysis and a distinct dashboard)... The problem is that doing all that requires a fair amount of xymon experience to architect something customized to what your site requires; lowering the barrier to entry for that will help.
So, overall, I'm just wondering if we should create smaller targets such that it is possible to add one feature at a time without as long a delay between new feature release?
It's definitely something I'll keep in mind.
Part of the problem this year was that I really only intended to pause development for about a month after 4.3.21 was released -- there'd been a lot of updates leading up to that and I wanted a chance to let it settle a bit. Unfortunately, one month became one full quarter :/ The pace between new feature releases is definitely going to pick back up going forward, one way or the other.
Regards, -jc
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon