On 06/23/2018 11:59 AM, Chris Lambertus wrote:
This is a good summary. As we move forward with the design specs, I’d also like
to see some comparisons with existing off-the-shelf monitoring systems (zabbix,
nagios, etc.,) to show that Warble is first and foremost easy to set up. This
is typically the biggest barrier to entry for folks trying to set up a
monitoring solution. Zabbix and Nagios specifically require a fairly steep
learning curve to get any useful data.
the potential turnkey aspect of Warble is very much on my mind. I want
it to be as easy as downloading, running a setup script, and things
should be operational. While we can't "compete" against other software
products (this is very anathema to ASF projects), we can highlight what
we think are Warble's strengths and mebbe do a matrix comparison of
features, pros and cons etc.
As for the database, I'm leaning towards using ElasticSearch for the
permanent storage, and possibly Redis for the ephemeral lookup cache for
the alerter.
If it can be made turn-key, I’m OK with ES, but it’s a heavy solution for small
scale monitoring. It may be worth considering a tiered approach with something
as simple as sqllite as the “default” backend with ES for a more
enterprise-sized deployment.
I think this is a reasonable approach. For the initial development, we
can definitely start with something simple like sqlite, and as
development continues, we can add in the more advanced stuff that would
require a proper timeseries/aggregated database system once we get
closer to scoping out the visualization aspects of gathered data (that
is, beyond the basic alerting and up/down stats).
Any thoughts on being backwards-compatible with existing nagios check scripts?
There’s a fairly broad ecosystem there that might be leveraged.
This is a tricky question, and my immediate reaction is that this is not
something _I_ would focus on, as building an additional API endpoint for
Nagios could take quite a while. Instead, I'll be working on building a
simple and 'modular' base class for tests as possible, so anyone can
quickly build a test for whatever they want to test for, or quickly port
from other systems to Warble. This is not to say that the Nagios idea is
bad, but rather that I would prefer starting out with what I know.
To give an idea of what a test class currently looks like, I have an
example class at https://paste.apache.org/Ji05 - all tests are shaped
the same way, and have an init and a run function, which relies on a
bunch of common libraries to quickly do stuff. You pass test parameters
to the test class, and it spits out a generic report object. We
prooobably can make wrappers for nagios and other systems in the future.
-Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@warble.apache.org
For additional commands, e-mail: dev-h...@warble.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@warble.apache.org
For additional commands, e-mail: dev-h...@warble.apache.org
