[Xymon] Xymon version 5

[J.C. Cleaver]

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+lastchange>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