On Fri, 13 Sep 2013, Michael Friedrich wrote:
> On 13.09.2013 14:18, Christophe HAEN wrote:
>> To comment on what Michael F. said, the problems indeed showed up when
>> several users were keeping the classic cgi page opened.
>> Actually, it even sometimes impacted the performance of the icinga
>> core itself and the latency was going high.
>
> that's generally something one does underestimate in setups. monitor the
> apache access.log with e.g. check_logfiles and count the requests - and
> then look at the size of status.dat/objects.cache and calculate the
> magic number of cpu cycles ;-)
>
> i had that problem in my previous workplace, and ramdisks did not help
> much (physical hardware, proliant g7 with fast raid1 controller below).
Now I'm sorry that I hit "cancel" on a capacity-planning post
I was writing in response to the original poster...
Michael makes some good points on how things can go awry as the
number of clients increases on "Classic" web, and those can be
addressed in a couple of ways, all of which increase the overall
complexity of the moniotring environment -- but which bring benefits
as the number of consumers of the data increases.
> obviously one might not like icinga web in the first place. but for
> removing the load of querying for data from your actual monitoring core,
> it's a great deal.
My experience with Icinga Web (the new one) indicates that the new
tool offers much value, both in presentation and the offload of work
from the machine on which core runs. In an "ultimate" setup where a
very large number of individuals need to be watching the monitoring
data "new web" will scale better -- at the expense of complexity.
Such an "ultimate" setup might well have several database-servers all
of which are read-only replicas of the master and which get accessed
via load-balanced web-servers with plenty of mainstore which to deal
with the demands of PHP.
> regarding the sparc 440mhz - well that's low end, just as embedded
> hardware. noone expects a mysql cluster running on pi's (or do they?).
> having an rdbms as backend for icinga web and reporting, you'll get more
> complex data aggregation capabilities left to the rdbms itsself fetching
> the output afterwards. example - sorting in memory on browser call is
> evil. classic ui / cgis do that - they parse the files into memory and
> operate on that. that's quite the same you need to do with livestatus
> json in your php application, sort it like beckham on-call.
I candidly admit that my 440 MHz SPARC is a corner-case, but such
a setup is remarkably useful for detecting things like memory-leaks
that might take weeks to become noticable on a modern multi-gigabyte,
multi-gigaHertz system. On Pi-based systems, there seems to be at
least one guy who was trying it, and if there's one there are more.
There's no way in creation that I'd recommend such a system (his
or mine) for anything like a production environment, but for
development and R&D they're quite useful indeed. (It turns out that
it was the Apache web-servers that crushed my little machine -- not
the database (which runs on a separate machine.)
Cheers!
+------------------------------------------------+---------------------+
| Carl Richard Friend (UNIX Sysadmin) | West Boylston |
| Minicomputer Collector / Enthusiast | Massachusetts, USA |
| mailto:crfri...@rcn.com +---------------------+
| http://users.rcn.com/crfriend/museum | ICBM: 42:22N 71:47W |
+------------------------------------------------+---------------------+
------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
_______________________________________________
icinga-users mailing list
icinga-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/icinga-users
