Carl R. Friend wrote:
>1) Dump performance data to disk and see what the trend for
> latency is following a restart of Icinga.
I installed pnp4nagios, but this seems to be gathering performance data for the
monitoring targets (hosts and services), not for the Icinga server itself. Is
there some other type of performance data that needs to be activated?
>
>2) Watch the performance of the internal "wall-clock" to see
> how well it tracks the physical clock on the wall. (A VM's
> wall-clock, being virtual, may well be very, very, wrong if
> there is serious contention for cores.)
>
I opened a screen on the hypervisor and a screen on the icinga server. In both
screens I ran "watch -n 1 date" and followed it for a couple minutes. Both
system times are tracking eachother reasonably enough. There's not much if any
lag between them.
>3) Ascertain what form of time-remediation is being performed
> by the hypervisor. TANSTAAFL ("There Ain't No Such Thing As
> A Free Lunch") is pertinent here; cycles used by the hypervisor
> to service another VM are not going to be ones available to
> yours -- and the effect is cumulative. Since Icinga uses the
> system's clock, if that clock is losing time, or is inaccurate
> for any other reason, the latency numbers will be inaccurate
> as well.
This seems like the same thing as #2.
>
>4) Look to see if some services are more affected than other
> services. Sometimes this can yield clues.
>
This I need to examine still.
>5) Are you running IDO? If so, how healthy is the database?
> Newer versions of Icinga feed IDO via a FIFO which tends to
> mitigate blockages in the event-broker for IDO-related
> events.
Not running IDO.
_______________________________________________
icinga-users mailing list
[email protected]
https://lists.icinga.org/mailman/listinfo/icinga-users
