I am proposing changing pmlogconf in the following ways:
- The pmlogconf version will go from 1.0 to 2.0
- Replace in-line groups (currently defined in the pmlogconf script) by external files, one group of metrics per file. The files will live in an arbitrary tree structure below the (new) config directory $PCP_VAR_DIR/config/pmlogconf. With the exception of the v1.0 directory (see below), when pmlogconf is run to create a new configuration file, all the group files below $PCP_VAR_DIR/config/pmlogconf will be processed. So add-ons, private PMDAs, local admins etc can add new group files as desired either in an existing subirectory (not recommended) or by adding their own subdirectory.
- Group files will have the following format:
- one or more lines starting with the keyword "ident"
- either a "probe" or a "force" control line (see below)
- lines beginning with white space are metrics to be logged, one per line
- lines beginning with # are comments
- blank lines are ignored
- "probe" control lines begin with the keyword probe, followed by a metric name, optionally followed by a <condition>, optionally followed by a <state rule>. Metric names do NOT include any instance specifier.
- The following <condition> forms are supported:
- The keyword exists - true if the corresponding metric exists in the PMNS
- The keyword values - true if the corresponding metric has 1 or more values
- The operator ~ followed by an <op> - true if any of the instances for the corresponding metric contain (in the awk regular _expression_ pattern matching sense) <op> ... <op> is an arbitrary sequence of non-blank characters (no quotes and no escapes, could be numeric or a non-numeric sequence)
- One of the operators ~!, ==, !=, >, >=, <=, < and <op> (like ~) with the obvious (for C/awk/perl programmers) semantics
- If <condition> is missing, the default is exists
- The <state rule> determines what happens if the <condition> is true or false and has the form: ? <true-state> : <false-state>. <true-state> and <false-state> must be one of the keywords include (include and enable the group in the output file), exclude (omit the group from the output file) or available (include and disable the group in the output file). If <state rule> is missing, the default is "? include : exclude".
- "force" control lines begin with the keyword force followed by one of the states defined above ... the state action is applied unconditionally to the group in the output file.
- The evaluation of <condition>s is only done when a new pmlogconf file is being created, and assumes pmlogconf accepts a (new) -h hostname command line argument ... <conditions> are evaluated by contacting the pmcd on hostname (defaults to localhost).
- Old (1.0) groups will be migrated to the v1.0 subdirectory of the pmlogconf configuration tree, and any old pmlogconf configuration file will be quietly transformed to version 2.0 the first time it is processed with pmlogconf.
- Otherwise the use of pmlogconf with an existing configuration file is unchanged.
- Migration and initial setup will be split off into separate pmlogconf-migrate and pmlogconf-setup scripts and hidden in $PCP_BINADM_DIR
Here are some sample control lines that could be used in a group file
probe mypmda.foo
if mypmda.foo exists, the group will be included in the control file and enabled, otherwise exclude it
probe otherpmda.bar values ? enable : available
if otherpmda.bar has at least one value then the group will be included in the control file and enabled, otherwise include and disable the group
probe hinv.ncpu > 1000
if lots of CPUs, include and enable the group, otherwise exclude it
probe kernel.uname.version ~ Ubuntu ? available : exclude
if this looks like a Ubuntu platform include the group, but disable it, otherwise exclude it
force avaliable
unconditionallly include and disable the group
Comments? Suggestions? Feedback?
ps I have a proof of concept implementation for much of the pmlogconf-setup probe/force stuff ... it looks OK.
|