pcp
[Top] [All Lists]

pmlogger: fetch.c: changed & PMCD_ADD_AGENT:

To: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Subject: pmlogger: fetch.c: changed & PMCD_ADD_AGENT:
From: Dave Brolley <brolley@xxxxxxxxxx>
Date: Mon, 30 May 2016 15:47:58 -0400
Cc: PCP Mailing List <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
Hi Ken,

I'm working on http://oss.sgi.com/bugzilla/show_bug.cgi?id=1100 and have a couple of questions for you.
  1. I'm looking at the code in src/pmlogger/src/fetch.c where 'if (changed & PMCD_ADD_AGENT)' is handled. It seems to me that this test which adds a mark record in the case a pmda (re)starts (outside the loop which handles the received pdus) is too late, since pdus representing several potentially changed/reset metrics may have been erroneously logged before then. Should the test not be made, and the mark record not be generated inside the loop at the point at which the change is first noticed?

  2. I'm considering two possibilities for checking the consistency of the PMNS+metadata:
    1. Check the consistency of all metrics in all task list items at this point
      • pro: It gets the check out of the way with no additional infrastructure at the point of the change
      • con: It might be too much work to do in shot at this point in the fetch/log cycle?

    2. Check the consistency of metrics are they are fetched later
      • pro: less work now and allows the current log to continue until an inconsistent metric is actually to be fetched
      • pro: pmlogger may potentially continue indefinitely, since inactive metrics may never be flagged
      • con: error may be harder to relate to the actual event, since it may be detected much later
      • con: some additional infrastructure needed to flag those metrics which still need to be checked
Any thoughts?
Dave
<Prev in Thread] Current Thread [Next in Thread>
  • pmlogger: fetch.c: changed & PMCD_ADD_AGENT:, Dave Brolley <=