[Xymon] Xymon version 5

[Ralph Mitchell]

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+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
>
>
> _______________________________________________
> Xymon mailing list
> Xymon at xymon.com
> http://lists.xymon.com/mailman/listinfo/xymon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20151101/6426a4d3/attachment.html>