PMISTART(3)

πŸ‘‘ NAME πŸ‘‘

okay bestie, gather round πŸ’– pmiStart β€” she's the function that establishes a new LOGIMPORT context. That's it. That's the whole job. Slay.


✨ C SYNOPSIS ✨

#include <pcp/pmapi.h>
#include <pcp/import.h>

int pmiStart(const char *archive, int flags);

cc ... -lpcp_import -lpcp

like, include both headers, call her with an archive and some flags, and link against -lpcp_import and -lpcp. periodt.


🐚 Perl SYNOPSIS 🐚

use PCP::LogImport;

pmiStart($archive, $flags);

same energy, Perl edition 🫢


🐍 Python SYNOPSIS 🐍

from pcp import pmi

log = pmi.pmiLogImport(archive, flags)

and in Python land you grab it as a pmiLogImport object, no cap πŸ¦‹


🌈 DESCRIPTION 🌈

So basically, pmiStart is part of the Performance Co-Pilot Log Import API (peep LOGIMPORT(3) for the whole lore), and what she does is create a brand new context. Every single context keeps track of all of this state and metadata, and honestly? It's giving very organised queen:

  • The base name β€” that's archive β€” for the physical files that make up the output PCP archive.
  • The source hostname for the data that's gonna get written into the PCP archive. She defaults to the hostname of the localhost, but you can set it with pmiSetHostname(3).
  • The source timezone for the PCP archive. Defaults to the timezone of the localhost, but you can set it with pmiSetTimezone(3).
  • The output archive version number for the PCP archive. Defaults to the traditional version 2 format, but you can set it with pmiSetVersion(3).
  • Metrics and instance domains, as defined by pmiAddMetric(3).
  • Instances for each instance domain, as defined by pmiAddInstance(3).
  • Handles, as defined by pmiGetHandle(3). Each handle is a metric-instance pair, and each metric-instance pair may have an associated value in each record written to the output PCP archive.
  • An optional set of data values for one or more metric-instance pairs β€” ready for the next record to be written to the output PCP archive β€” as defined by calls to pmiPutValue(3) or pmiPutValueHandle(3).

Now, the flags argument is a bitwise-OR of zero or more of these constants, and yes you're gonna want to know all of them πŸ’…

  • PMI_INHERIT β€” the new context inherits any and all metadata (metrics, instance domains, instances and handles) from the current context. BUT β€” the basename for the output PCP archive, the source hostname, the source timezone and any data values from the current context are not inherited. And lowkey important: if this is the first call to pmiStart, the metadata will be empty, independent of whether PMI_INHERIT is set. πŸ™ˆ
  • PMI_APPEND β€” opens an existing PCP archive for appending instead of creating a new one. The archive label (hostname, timezone, version, start timestamp) is read from the existing archive.meta file and used to initialise the new context. The temporal index is read to seed the last-written timestamp; all subsequent pmiWrite(3) calls must use timestamps strictly later than this value. The archive.meta and archive.index files are opened in read/write mode and positioned at end-of-file; the highest-numbered data volume is opened in append mode. Metrics and instance domains must still be registered via pmiAddMetric(3) and pmiAddInstance(3) before calling pmiPutValue(3) β€” and if the metric descriptor is already present in the archive, the duplicate entry in archive .meta is harmless and will be ignored by readers. And if the archive files don't exist yet? PMI_APPEND behaves identically to creating a new archive (no flags). iconic behaviour honestly πŸŽ€

PMI_APPEND and PMI_INHERIT may be used together πŸ’ž The inherited metric and instance-domain definitions get carried into the new context, and when the archive is opened on the first pmiWrite(3) call, each inherited descriptor is checked against what's already on disk: compatible descriptors are silently skipped (no duplicate written), and incompatible ones are rejected with an appropriate error (e.g. PM_ERR_LOGCHANGETYPE). When the previous context was writing to the same archive, every inherited descriptor already exists on disk, so the combination is effectively a no-op beyond convenience. like, cute but also doing nothing 🧚

If flags is zero, or neither PMI_INHERIT nor PMI_APPEND is set, the new context is created with no metadata and a new archive will be created from scratch. fresh start energy ✨

Also bestie, heads up: since no physical files for the output PCP archive get created until the first call to pmiWrite(3) or pmiPutResult(3), archive could be NULL β€” which creates a convenience context that's populated with metadata to be inherited by subsequent contexts. very main character of her.

The return value is a context identifier that could be used in a subsequent call to pmUseContext(3), and the new context becomes the current context, which persists for all subsequent calls up to either another pmiStart call or a call to pmiUseContext(3) or a call to pmiEnd(3).


πŸ’€ DIAGNOSTICS πŸ’€

When creating a new archive (neither PMI_APPEND nor any other flag that implies file creation), it is an error if the physical files archive.0 and/or archive.index and/or archive.meta already exist β€” but plot twist, this is not discovered until the first attempt is made to output some data by calling pmiWrite(3) or pmiPutResult(3). So pmiStart always returns a positive context identifier. no early warning, she's just built like that 😭

When PMI_APPEND is set and the archive files do not exist, pmiStart silently falls back to creating a new archive, which makes it safe to use PMI_APPEND unconditionally on the first invocation of a data collector. so forgiving, we love a flexible queen 🌸


πŸ”₯ SEE ALSO πŸ”₯


and that's the whole page, bestie 🫢 this one ships under Performance Co-Pilot, filed as PMISTART(3) in the Library Functions Manual. go forth and start some contexts πŸ’–βœ¨πŸŽ€

πŸ“¦ where this page comes from