Re: [pcp] suitability of PCP for event tracing

[Ken McDonell <kenj at internode dot on dot net>]

On 2/09/2010 1:05 AM, David Smith wrote:
> On 08/29/2010 10:54 AM, Ken McDonell wrote:
>
> ... stuff deleted ...
>
> > As Nathan has suggested, if event traces are intended for retrospective
> > analysis (as opposed to event counters being suited for either real time
> > or retrospective analysis), then there is an alternative approach,
> > namely to create a PCP archive directly from a source of data without
> > involving pmcd or a pmda or pmlogger.  We've recently reworked the
> > "pmimport" services to expose better APIs to support just this style of
> > use ... see LOGIMPORT(3) and sar2pcp(1) for an example.  I think this
> > approach is possibly a better semantic match between PCP and a stream of
> > event records.
>
> Hmm.  If I'm understanding all the acronyms correctly, I'm not seeing
> the benefit of using LOGIMPORT to create a PCP archive vs. involving
> pcmd/pmda/pmlogger.  Could you expand here?

David,

The "benefit" is that importing data to create a PCP archive is a data 
translation process that is not dependent on polled sampling of data ... 
you can consume a stream of timestamped data and create a corresponding 
PCP archive as an off-line or batch process.  Import tools are also 
comparatively simple to write.

The "disadvantage" is that you're no closer to real-time monitoring with 
this approach, so it is usually used in cases where there is an existing 
body of historical data and one is interested in using pmie or pmchart 
or pmlogsummary for some retrospective analysis ... non-PCP tools like 
sar and monitoring subsystems that support "Export to Excel" are the 
most common examples.