Hi -
nathans wrote:
> The usual model would be local pmie daemon (no temporary connection).
Sorry, I was extrapolating from observations of a particular local
pmie process here, which maintained no permanent tcp connection to the
-h HOSTNAME, but rather closed / reopened it every pmie polling cycle.
But looking at it now more closely, the affected pmie is one that is
using an ssh tunnel (-h localhost:XYZ), where the remote pmcd.hostname
is of course different from localhost etc. I see pmie trying to
connect to the pmcd.hostname, failing (since it's firewalled that
route), then falling back to the initially supplied -h HOSTSTRING.
There's a real bug in there.
> I'm not following how its a complication to have a second connection
> to pmcd...? (relative to the level of complication of pmlogger code
> that we'd have to consider, which would appear to require a decision
> making engine like pmie to be built into pmlogger...?).
Sure, from the PoV that the pmie codebase was not written to be
encapsulated as a library. From the PoV of the target pmcd though,
there would be less run-time complexity, in the form of one fewer
client.
> > it cannot piggy-back on an archive being written-to by pmlogger.
>
> Can you explain that some more? ("piggy-back" in what way?) The pmlc
> model is that pmie tells pmlogger what (extra) to log dynamically, via
> pmlc, so in that sense it is piggy-backing on the existing archive...?
Right, I was referring to a hypothetical scenario where pmie's inputs
could be taken from the pmlogger-archive being written, rather than
via a secondary connection to pmcd. That would reduce the load on
pmcd, if the predicate inputs happened to be subsets of the pmlogger
outputs.
- FChE
|