Bug 2027428

Big fan of option a/ here - this path gives us alot of options, whereas option b/ gives us alot of development work to roughly achieve what we can already do now (from the end users perspective).

There's also been discussion in the past about us providing a (cloud based and/or internal) service where Red Hat customer support folk could be sent PCP archives (or send 'em themselves) for processing - and the output would be a running container with PCP, Redis and Grafana with all PCP metrics pre-loaded.

I like this option for several reasons:
- it removes manual effort from our support folk to get up and running with PCP, Redis and Grafana
- we can potentially deliver improvements to the analysis experience outside of the RHEL cycle (i.e. fast access to fixes for our support folk)
- in the future (with our proposed work to extend sysstat to generate PCP archives), customers running sysstat would also benefit from this service
- in the further future, we could deliver pmdiff, pcp2pdf, even AI/ML-based analysis of the uploaded archive(s) during the upload/pre-processing stage, that would further automate assisting our support folks with performance analysis of customer data

(In reply to Nathan Scott from comment #2)
> Big fan of option a/ here - this path gives us alot of options, whereas
> option b/ gives us alot of development work to roughly achieve what we can
> already do now (from the end users perspective).

+1, let's go with option a)

> There's also been discussion in the past about us providing a (cloud based
> and/or internal) service where Red Hat customer support folk could be sent
> PCP archives (or send 'em themselves) for processing - and the output would
> be a running container with PCP, Redis and Grafana with all PCP metrics
> pre-loaded.

So the PCP metrics would be embedded / part of the container image?
I was thinking of a general container image which is loading the PCP archives at container startup from the host via a container bind mount.

> 
> I like this option for several reasons:
> - it removes manual effort from our support folk to get up and running with
> PCP, Redis and Grafana

+1

> - we can potentially deliver improvements to the analysis experience outside
> of the RHEL cycle (i.e. fast access to fixes for our support folk)

Yep, we could publish the container on Docker Hub or Quay.io

> - in the future (with our proposed work to extend sysstat to generate PCP
> archives), customers running sysstat would also benefit from this service

+1

> - in the further future, we could deliver pmdiff, pcp2pdf, even AI/ML-based
> analysis of the uploaded archive(s) during the upload/pre-processing stage,
> that would further automate assisting our support folks with performance
> analysis of customer data

Sounds good, that would be a custom web-based platform running in the container, with buttons to export PDFs, show diffs visually, another button to open Grafana etc.?
(fwiw, let's focus on the container with PCP+Redis+Grafana for this BZ, and add the future features (the last point above) in the upstream roadmap on GitHub?)


Afaics Mustafa from Peter's Team already worked on a container [1], we can build upon that.

[1] https://github.com/distributed-system-analysis/pbench/tree/main/agent/containers/images/visualizers (PCPGrafVisualizer)

Completed in upstream:

https://quay.io/repository/performancecopilot/archive-analysis
https://github.com/performancecopilot/pcp/tree/main/build/containers/archive-analysis

The container is now available upstream at https://quay.io/repository/performancecopilot/archive-analysis and will track the latest versions of PCP and Grafana.

Importing PCP archives created with older versions of RHEL/PCP is supported, there is no requirement of a matching version of the PCP archive and this container.
In case you encounter an error importing an archive, please open a bug report.

https://access.redhat.com/solutions/6974688