Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

libpcp_import: support for an archive-append mode #1610

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

natoscott
Copy link
Member

In order to implement sysstat/sar semantics, where an
archive is appended to by short-lived processes - and
not by a long-running process ala pmlogger - we're in
need of an append-mode from the LOGIMPORT(3) API.

This is a prototype of the sorts of changes I believe
we'll need. I've updated just the one QA test utility
to exercise it at this stage and the rest will follow
once we've settled on appropriate APIs.

In order to implement sysstat/sar semantics, where an
archive is appended to by short-lived processes - and
not by a long-running process ala pmlogger - we're in
need of an append-mode from the LOGIMPORT(3) API.

This is a prototype of the sorts of changes I believe
we'll need.  I've updated just the one QA test utility
to exercise it at this stage and the rest will follow
once we've settled on appropriate APIs.
@natoscott natoscott requested a review from kmcdonell June 15, 2022 05:12
Refactor some new log-append code out of libpcp_import and
into libpcp; also ensure archive files are opened for read
only when we're not appending.
@natoscott natoscott added this to pcp-6.0.0 (31 July 2022) in Roadmap Jun 16, 2022
@kmcdonell
Copy link
Member

kmcdonell commented Jun 21, 2022

@natoscott Basically LGTM.

My only questions (that I can't resolve from the diffs) are:

  1. Is the state of the auxiliary data (and in particular the hashed indom data) is the same in the open for append case as it would be in the "just keep writing" case? At a first stab this probably needs QA coverage, especially with a V3 archive, a dynamic indom and delta-indom records in play).
  2. There may need to be a <mark> record added, but the logic for this is complicated (consider what pmlogger has to do when a pmcd connection is re-established, or the tests pmlogextract does on pmcd.seqnum). It is unclear to me if this should be part of the libpcp functionality or something the caller needs to take care of ... even in the sysstat case one needs to decide how kernel counter resets to zero on reboot will be accommodated.

@kmcdonell
Copy link
Member

I see some of my issues above have been addressed in the first commit (I was only looking at the second commit) ... proper review will be done shortly.


ctx3 = pmiStart("myarchive", PMI_FLAG_APPEND);
check(ctx3, "pmiStart");
sts = pmiAddMetric("my.metric.bar", pmID_build(245, 0, 2), PM_TYPE_U64, pmInDom_build(245,1), PM_SEM_INSTANT, pmiUnits(1,-1,0,PM_SPACE_MBYTE,PM_TIME_SEC,0));
Copy link
Member

@kmcdonell kmcdonell Jun 22, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this pmiAddMetric() needed? my.metric.bar should have been already defined ... there is no change to qa/369 not qa/369.out so I don't know what the expected QA change is here.
Similarly the pmiAddInstance() calls below are suspect ... the first 3 should error because these instances are already defined.
Or am I misunderstanding the semantics ... by "append" are you only dealing with the libpcp part, and libpcp_import is stateless (in the metadata sense) even when "append" is in play? If the latter, then I think there is a real risk of problems because the libpcp_import view of the metadata and the libpcp view of the metadata and the archive's view of the metadata are not aligned.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The model I'm catering a need for is the sysstat/sadc scenario, where we don't (want to) know whether we are appending or creating - whichever case it is, it should Just Work and do the Right Thing, transparently and correctly. IOW, the application using libpcp_import doesn't want to know about this subtelty, and the correct behavior should just magically happen.

If the archive doesn't exist create it and populate all metric metadata. If it does exist, check the metric metadata still matches (in-memory vs on-disk - fail if not) and append to the existing archive.

Copy link
Member

@kmcdonell kmcdonell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.
QA will need some work.
Q on semantics in comments for qa/src/check_import.c
libpcp_import does not (yet) support delta indoms for V3 archives ... this may be now even trickier, or may be we don't do it!

@natoscott
Copy link
Member Author

LGTM. QA will need some work. Q on semantics in comments for qa/src/check_import.c libpcp_import does not (yet) support delta indoms for V3 archives ... this may be now even trickier, or may be we don't do it!

Yep, QA definitely needs to be fleshed out further. Maybe in some cases V3 archives could be easier for deltas - we do now know when appending and needing to add instance metadata. Certainly this could be improved on later anyway, I think in the default case for sysstat we wont be logging fast-changing indoms.

@natoscott natoscott moved this from pcp-6.0.0 (31 July 2022) to pcp-6.0.1 (Oct 2022) in Roadmap Jul 12, 2022
@natoscott natoscott marked this pull request as draft July 26, 2022 04:30
@natoscott natoscott moved this from pcp-6.0.1 (Oct 2022) to pcp-6.0.2 (Dec 2022) in Roadmap Aug 24, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Roadmap
pcp-6.0.2 (Jan 2023)
Development

Successfully merging this pull request may close these issues.

None yet

2 participants