All my students ask about collectd (even about who was the responsable of
including collectd in the objectives). This is another 'nonsense' like the SQL
objectives in LPIc 1.
I can only answer that probably it was one of collectd authors trying to
promote it, as no one uses it at all.
Better drop away collectd than keepkng it. It might be simple on its guts but
isn't simple to see its graphs running, thus it makes no sense to teach it
because it takes too long before being minimally useful. Has anyone seen a
rrdtool example??? considering rrdtool out of scope and requiring it to
actually see something is a bit confusing.
That's why I suggested munin as a replacement, because it also uses RRD files
but it's able to create its own graphics and has zero config before running.
In any case, keeping a minoritary and ugly to use solution as collectd makes no
sense at all, better dropping it away and not replacing it by any other
software rather than keeping this mess as is.
Regards,
Kenneth
Enviat des del meu dispositiu Samsung
-------- Missatge original --------
De: Fabian Thorns <[email protected]>
Data: 22/02/2016 23:52 (GMT+01:00)
A: "This is the lpi-examdev mailing list." <[email protected]>
Assumpte: Re: [lpi-examdev] LPI 200.2 and collectd
I agree that collectd wouldn't be the first thing that comes my mind either...
I wouldn't dare to suggest Nagios or Icinga being part of an LPIC-2 exam as
both could easily fill an exam on their own. I see that topic more about
getting an idea of which kind of properties exist and how to measure them. Any
simple tool would be sufficient for that task. Just removing collectd would
make 200.2 hard to test...
Do you have any other tool that you see more prominent / useful these days? Or,
given we drop collectd, would you prefer to extend the "Awareness of monitoring
solutions" part to feature knowledge and comparison of Icinga2 and Cacti (or
keep Nagios and MRTG included?) and maybe spice in conceptual knowledge of
SNMP? We should try to avoid "submarines" (to quote Anselm) which consist of a
tiny tiny bullet in the objectives and open enormous discussions in training.
Fabian
On Mon, Feb 22, 2016 at 11:39 PM, Bryan J Smith <[email protected]> wrote:
Bryan J Smith <[email protected]> wrote:
These types of objectives will always be difficult to keep "Scope Creep" from
entering. that said ...
Sorry, "Send" hit. Continuing ...
Ultimately, the context is "Capacity Planning." So we're actual talking about
collecting statistics. So instead of talking about collectd, Nagios/Icinga,
etc..., why aren't we actually talking about what most of these tools use? [1]
I.e., RRDTools and its RRD files
Just saying, I'd focus on RRD and similar solutions, under the objective's
context, "Capacity Planning."
-- bjs
[1]
https://en.wikipedia.org/wiki/RRDtool#Other_tools_that_use_RRDtool_as_a_DBMS_and.2For_graphing_subsystem
On Mon, Feb 22, 2016 at 2:43 PM, Anselm Lingnau
<[email protected]> wrote:
[email protected] wrote:
> My support for munin as easy & nice-looking capacity planning + Icinga
> (as nagios successor) for monitoring.
We can probably bikeshed this until the cows come home.
The advantage of collectd is that it is small, it measures the most important
things, and it is reasonably easy to understand. Apart from that, if you have
seen one monitoring tool you have more or less seen them all, and everybody is
going to be using something different from everybody else anyway.
If we put Nagios or Icinga on the exam, the next question is going to be where
do we stop, since surely we don't want everyone to have to know all the 94
Nagios plugins in Debian Jessie, but the 10 plugins that you use are likely
going to be different from the 10 plugins that I use or that Simone uses,
while each one of us will argue vehemently that *our* plugins are the most
important ones and absolutely must be on the exam while the others can get
lost.
_______________________________________________
lpi-examdev mailing list
[email protected]
http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
_______________________________________________
lpi-examdev mailing list
[email protected]
http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
