cockpit: Implement PCP metrics channel in the Python bridge

[jelly]

Current ToDo's

• test failure on Arch exception
• TF failures, create a TEST VM without python3-pcp
• Aks PCP if they wanna upload a wheel.
• tox
• investigate coverage once more
• Debian-stable/testing lack python3-pcp when running test/image-prepare -q debian-testing it fails on pytest.

---

Follow ups, I'd suggest tackling:

• Dropping the cockpit-pcp package
• On demand install in metrics page, change it to installing pcp python3-pcp instead of cockpit-pcp
• Dropping the cockpit-pcp C code et all
• Deal with code which checks for the existence of cockpit-pcp (release-blocker)
• Consider fetch group API https://gist.github.com/jelly/6f4d683fcd3f8797945f5f90bf0fe5d6

[jelly]

Tox is meh :( There is no pcp wheel so need to build it and the PyPi version is outdated 5.0 😞

[jelly]

It is green now \o/

[jelly]

Maybe rename the file to pcpmetrics.py?

[martinpitt]

I checked /var/lib/pcp/config/pmlogconf/tools/cockpit - that's the only remaining file in cockpit-pcp; all enabled metrics are already present in a multitude of other configs in /etc/pcp/pmlogconf , so we can just drop this. It's also strange and against our principles to change the system config with installing cockpit packages. So independently of this PR we can already drop that.

Assuming that the cockpit-pcp binary and the manifest go away, we then just need to change our on-demand installation from cockpit-pcp to pcp to cover the remaining purpose of our rpm (pull in the dependency).

[jelly]

I checked /var/lib/pcp/config/pmlogconf/tools/cockpit - that's the only remaining file in cockpit-pcp; all enabled metrics are already present in a multitude of other configs in /etc/pcp/pmlogconf , so we can just drop this. It's also strange and against our principles to change the system config with installing cockpit packages. So independently of this PR we can already drop that.

Assuming that the cockpit-pcp binary and the manifest go away, we then just need to change our on-demand installation from cockpit-pcp to pcp to cover the remaining purpose of our rpm (pull in the dependency).

See => #21020

[jelly]

Looking again at the fetchGroup API, this looks useful but it is so freaking broken, for some reason it returns no instances for the first metric.. (why!)

#!/usr/bin/python

import cpmapi as c_api
from pcp import pmapi

from test.pytest.test_pcp import instances_archive

# archive_path = "/tmp/pytest-of-jelle/pytest-current/disk-archives0"
archive_path = "/var/log/pcp/pmlogger/t14s/20240723.index"
# archive_path = "/home/jelle/projects/cockpit/cockpit-pcp-python/testEnableNoData/archive3/20240719.09.40.index"
pmfg = pmapi.fetchgroup(c_api.PM_CONTEXT_ARCHIVE, archive_path)
context = pmfg.get_context()

# To work out:
# - omit instances
# - scale

kernel_all_load = pmfg.extend_indom("kernel.all.load", c_api.PM_TYPE_FLOAT)
mem_physmem = pmfg.extend_item("mem.physmem")
mem_avail = pmfg.extend_indom("mem.util.available", c_api.PM_TYPE_FLOAT)
swap_pagesout = pmfg.extend_indom("swap.pagesout", c_api.PM_TYPE_FLOAT)
network_interface_total_bytes = pmfg.extend_indom("network.interface.total.bytes")
t = pmfg.extend_timestamp()

for _ in range(5):
    pmfg.fetch()
    print("time: %s" % t())
    for icode, iname, value in kernel_all_load():
        print('kernel.all.load %s %s=%s' % (icode, iname, value()))
    print("mem.physmem: %s" % mem_physmem())
    print(mem_avail())
    for icode, iname, value in mem_avail():
        if iname is not None:
            print('mem.util.available %s %s=%s' % (icode, iname, value()))
    print("total.bytes %s" % network_interface_total_bytes())
    for icode, iname, value in network_interface_total_bytes():
        if iname is not None:
            print('network.interface.total.bytes %s %s=%s' % (icode, iname, value()))

Maybe something for a follow up, it seems nice

[jelle@t14s][~/projects/cockpit/cockpit-pcp-python]%python3 fetchgroup-pcp.py
time: 2024-07-23 16:05:32.873173
mem.physmem: 32620024
[]
total.bytes []
time: 2024-07-23 16:05:32.894293
kernel.all.load 1 1 minute=1.9800000190734863
kernel.all.load 5 5 minute=1.4700000286102295
kernel.all.load 15 15 minute=1.309999942779541
mem.physmem: 32620024
[(4294967295, None, <function fetchgroup.fetchgroup_indom.__call__.<locals>.<lambda>.<locals>.<lambda> at 0x715ea1f02c00>)]
total.bytes [(0, 'lo', <function fetchgroup.fetchgroup_indom.__call__.<locals>.<lambda>.<locals>.<lambda> at 0x715ea1f02ca0>), (1, 'enp0s31f6', <function fetchgroup.fetchgroup_indom.__call__.<locals>.<lambda>.<locals>.<lambda> at 0x715ea1f02e80>), (2, 'wlp0s20f3', <function fetchgroup.fetchgroup_indom.__call__.<locals>.<lambda>.<locals>.<lambda> at 0x715ea1f02f20>), (3, 'enp0s20f0u2u6', <function fetchgroup.fetchgroup_indom.__call__.<locals>.<lambda>.<locals>.<lambda> at 0x715ea1f02fc0>), (14, 'virbr0', <function fetchgroup.fetchgroup_indom.__call__.<locals>.<lambda>.<locals>.<lambda> at 0x715ea1f03060>), (19, 'virbr1', <function fetchgroup.fetchgroup_indom.__call__.<locals>.<lambda>.<locals>.<lambda> at 0x715ea1f03100>)]
Traceback (most recent call last):
  File "/home/jelle/projects/cockpit/cockpit-pcp-python/fetchgroup-pcp.py", line 38, in <module>
    print('network.interface.total.bytes %s %s=%s' % (icode, iname, value()))
                                                                    ^^^^^^^
  File "/usr/lib/python3.12/site-packages/pcp/pmapi.py", line 3102, in <lambda>
    (lambda i: (lambda: decode_one(self, i)))(i)))
                        ^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/site-packages/pcp/pmapi.py", line 3096, in decode_one
    raise pmErr(self.stss[i])
pcp.pmapi.pmErr: PM_ERR_VALUE Missing metric value(s)

[jelly]

@martinpitt @mvollmer an initial review would be appreciated, I am not super fond of the spaghetti soup, combining direct and archived metrics together kinda makes it messy

This is also the reason we can't easily combine the internalmetrics and the PCP metrics, the archive metrics are too different. Plus we have no Sampler() class

[martinpitt]

Thanks @jelly , great work! I have a lot of little things, but honestly I'm not too worried about the code structure -- there is a lot of bit shifting, data type conversion, and plumbing, and I trust that all of this is necessary. But the overall structure is relatively easy to follow.

I'm really looking forward to landing this!

[jelly]

This seems to go green! @martinpitt I re-added the manifest as the JS code uses this to detect if PCP is available and if it's missing all PCP tests simply fail.

A follow up PR will take care of that.