Introduce the DynamicMeter class for runtime extension #669
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
BenBE
requested changes
Jun 23, 2021
natoscott
force-pushed
the
dynamic-meters
branch
from
8ad8899
to
33ad090
Compare
BenBE
reviewed
Jun 24, 2021
natoscott
force-pushed
the
dynamic-meters
branch
2 times, most recently
from
0c8655e
to
452683d
Compare
BenBE
requested changes
Jun 26, 2021
smalinux
reviewed
Jun 27, 2021
When manipulating CPUMeters in the AvailableMeterPanel we use the bottom 16 bits to hold the CPU number. However, the bitmask used to extract the CPU number only masks the lower 8 bits (0xff).
This commit is based on exploratory work by Sohaib Mohamed. The end goal is two-fold - to support addition of Meters we build via configuration files for both the PCP platform and for scripts ( htop-dev#526 ) Here, we focus on generic code and the PCP support. A new class DynamicMeter is introduced - it uses the special case 'param' field handling that previously was used only by the CPUMeter, such that every runtime-configured Meter is given a unique identifier. Unlike with the CPUMeter this is used internally only. When reading/writing to htoprc instead of CPU(N) - where N is an integer param (CPU number) - we use the string name for each meter. For example, if we have a configuration for a DynamicMeter for some Redis metrics, we might read and write "Dynamic(redis)". This identifier is subsequently matched (back) up to the configuration file so we're able to re-create arbitrary user configurations. The PCP platform configuration file format is fairly simple. We expand configs from several directories, including the users homedir alongside htoprc (below htop/meters/) and also /etc/pcp/htop/meters. The format will be described via a new pcp-htop(5) man page, but its basically ini-style and each Meter has one or more metric expressions associated, as well as specifications for labels, color and so on via a dot separated notation for individual metrics within the Meter. A few initial sample configuration files are provided below ./pcp/meters that give the general idea. The PCP "derived" metric specification - see pmRegisterDerived(3) - is used as the syntax for specifying metrics in PCP DynamicMeters.
Instead use the common NAN pattern to use of the swap cached value on platforms that do not support it.
natoscott
force-pushed
the
dynamic-meters
branch
2 times, most recently
from
3ab45aa
to
6625bbc
Compare
BenBE
reviewed
Jul 7, 2021
Several improvements to the way values are displayed in the PCP platform DynamicMeter implementation: - handle the initial 'caption' setting as with regular meters, this required a new meter callback because we no longer have just a single meter caption for the DynamicMeter case - if no label is provided for a metric in a configuration file use the short form metric name as a fallback - honour the suffix setting in the configuration file - convert metric values to the canonical units for htop (kbyte and seconds), and use Meter_humanUnit when it makes sense to do so. Also improves the handling of fatal string error messages in a couple of places, thanks to BenBE for the review feedback.
BenBE
approved these changes
Jul 8, 2021
smalinux
added a commit
to smalinux/htop
that referenced
this pull request
Jul 17, 2021
Merged, see: htop-dev#669 Allowing any metric to be displayed using htop rather than only the hard-coded set. One of the challenges we have with making pcp and htop work well together, is that pcp has thousands of metrics. And we encourage people to add their own metrics, so really its infinite metrics htop on the other hand has knowledge of a fixed set of metrics, and it cannot be extended yet without writing new code. What I did here is a generic Meter for any PCP metric. - i.e. not the way we're doing it currently, where we write new code each time we want to add a new Meter into htop. so, instead of writing code, imagine this... pcp-htop scans a new direcory /etc/pcp/htop/ at startup for configuration files (plain text) These files would specify new Meters - they would contain information like: pcp metric name, meter name, etc and they would be added into the existing set of meters that htop knows about, at startup. So most importantly, users would not have to add code for new Meters anymore. It also means the tool doesn't become larger and larger forever, as more and more people write their own Meters for their own critical metrics. (i.e. less code bloat)
smalinux
added a commit
to smalinux/htop
that referenced
this pull request
Sep 11, 2022
htop-dev#669) Signed-off-by: Sohaib Mohamed <sohaib.amhmd@gmail.com>
smalinux
added a commit
to smalinux/htop
that referenced
this pull request
Sep 11, 2022
…v#669) Signed-off-by: Sohaib Mohamed <sohaib.amhmd@gmail.com>
smalinux
added a commit
to smalinux/htop
that referenced
this pull request
Sep 11, 2022
…v#669) Signed-off-by: Sohaib Mohamed <sohaib.amhmd@gmail.com>
smalinux
added a commit
to smalinux/htop
that referenced
this pull request
Sep 11, 2022
…v#669) Signed-off-by: Sohaib Mohamed <sohaib.amhmd@gmail.com>
smalinux
added a commit
to smalinux/htop
that referenced
this pull request
Sep 11, 2022
…v#669) Signed-off-by: Sohaib Mohamed <sohaib.amhmd@gmail.com>
smalinux
added a commit
to smalinux/htop
that referenced
this pull request
Sep 11, 2022
…v#669) Signed-off-by: Sohaib Mohamed <sohaib.amhmd@gmail.com>
smalinux
added a commit
to smalinux/htop
that referenced
this pull request
Sep 12, 2022
Related: htop-dev#200 && htop-dev#669 Signed-off-by: Sohaib Mohamed <sohaib.amhmd@gmail.com>
smalinux
added a commit
to smalinux/htop
that referenced
this pull request
Sep 12, 2022
Related: htop-dev#200 && htop-dev#669 Signed-off-by: Sohaib Mohamed <sohaib.amhmd@gmail.com>
smalinux
added a commit
to smalinux/htop
that referenced
this pull request
Sep 12, 2022
Related: htop-dev#200 && htop-dev#669 Signed-off-by: Sohaib Mohamed <sohaib.amhmd@gmail.com>
smalinux
added a commit
to smalinux/htop
that referenced
this pull request
Sep 12, 2022
Related: htop-dev#200 && htop-dev#669 Signed-off-by: Sohaib Mohamed <sohaib.amhmd@gmail.com>
smalinux
added a commit
to smalinux/htop
that referenced
this pull request
Sep 13, 2022
Related: htop-dev#200 && htop-dev#669 Signed-off-by: Sohaib Mohamed <sohaib.amhmd@gmail.com>
smalinux
added a commit
to smalinux/htop
that referenced
this pull request
Sep 15, 2022
Related: htop-dev#200 && htop-dev#669 Signed-off-by: Sohaib Mohamed <sohaib.amhmd@gmail.com>
smalinux
added a commit
to smalinux/htop
that referenced
this pull request
Sep 15, 2022
Related: htop-dev#200 && htop-dev#669 Signed-off-by: Sohaib Mohamed <sohaib.amhmd@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit is based on exploratory work by Sohaib Mohamed.
The end goal is two-fold - to support addition of Meters we
build via configuration files for both the PCP platform and
for scripts ( #526 )
Here, we focus on generic code and the PCP support. A new
class DynamicMeter is introduced - its use the special case
'param' field handling that previously was used only by the
CPUMeter, such that every runtime-configured Meter is given
a unique identifier. Unlike with the CPUMeter this is used
internally only. When reading/writing to htoprc instead of
CPU(N) - where N is an integer param (CPU number) - we use
the string name for each meter. For example, if we have a
configuration for a DynamicMeter for some Redis metrics, we
might read and write "Dynamic(redis)". This identifier is
subsequently matched (back) up to the configuration file so
we're able to re-create arbitrary user configurations.
The PCP platform configuration file format is fairly simple.
We expand configs from several directories, including the
users homedir alongside htoprc (below htop/meters/) and also
/etc/pcp/htop/meters. The format will be described via a
new pcp-htop(5) man page, but its basically ini-style and
each Meter has one or more metric expressions associated, as
well as specifications for labels, color and so on via a dot
separated notation for individual metrics within the Meter.
A few initial sample configuration files are provided below
./pcp/meters that give the general idea. The PCP "derived"
metric specification - see pmRegisterDerived(3) - is used
as the syntax for specifying metrics in PCP DynamicMeters.