zeldon
/
htop
mirror of https://github.com/xzeldon/htop.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
htop/DynamicMeter.h

29 lines
608 B
C
Raw Permalink Normal View History

Add a new DynamicMeter class for runtime Meter extension 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 ( https://github.com/htop-dev/htop/issues/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.
2021-06-23 07:44:56 +00:00
#ifndef HEADER_DynamicMeter
#define HEADER_DynamicMeter
PCP: support for 'dynamic columns' added at runtime Implements support for arbitrary Performance Co-Pilot metrics with per-process instance domains to form new htop columns. The column-to-metric mappings are setup using configuration files which will be documented via man pages as part of a follow-up commit. We provide an initial set of column configurations so as to provide new capabilities to pcp-htop: including configs for containers, open fd counts, scheduler run queue time, tcp/udp bytes/calls sent/recv, delay acct, virtual machine guests, detailed virtual memory, swap. Note there is a change to the configuration file path resolution algorithm introduced for 'dynamic meters'. First, look in any custom PCP_HTOP_DIR location. Then iterate, in priority order, users home directory, then local sysadmins files in /etc/pcp/htop, then readonly configuration files below /usr/share/pcp/htop. This final location becomes the preferred place for our own shipped meter and column files. The Settings file (htoprc) writing code is updated to not using the numeric identifier for dynamic columns. The same strategy used for dynamic meters is used here where we write Dynamic(name) so the name can be setup once more at start. Regular (static) columns writing to htoprc - i.e. numerically indexed - is unchanged.
2021-07-11 01:11:29 +00:00
#include <stdbool.h>
PCP: fixup: Missing headers for DynamicMeter
2021-07-18 04:25:45 +00:00
#include "Hashtable.h"
Add a new DynamicMeter class for runtime Meter extension 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 ( https://github.com/htop-dev/htop/issues/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.
2021-06-23 07:44:56 +00:00
#include "Meter.h"
typedef struct DynamicMeter_ {
char name[32]; /* unique name, cannot contain spaces */
char* caption;
char* description;
unsigned int type;
double maximum;
} DynamicMeter;
Hashtable* DynamicMeters_new(void);
Add completion handling for dynamic meters and columns Be sure to free dynamic memory allocated for meters and columns strings, no-op on platforms other than pcp. Closes #774
2021-09-03 02:11:31 +00:00
void DynamicMeters_delete(Hashtable* dynamics);
Align parameters names between function declaration and definition Found by clang-tidy.
2021-08-22 15:14:29 +00:00
const char* DynamicMeter_lookup(Hashtable* dynamics, unsigned int key);
Add a new DynamicMeter class for runtime Meter extension 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 ( https://github.com/htop-dev/htop/issues/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.
2021-06-23 07:44:56 +00:00
Ensure PCP dynamic metric configuration definition uniqueness It can happen that pcp-htop is presented multiple definitions of the same dynamic meter, e.g. if /etc/pcp/htop/meters has a definition matching one in ~/.config/htop/meters - instead of exiting with a duplicate metric error provide more meaningful diagnostics (on close) and also just skip over such entries. System files override home directories which overrides those found below the current working directory. Also fix the derived metric error diagnostic; because this is using CRT_fatalError, which is like perror(3), we must give a meaningful prefix (like program name) at the string end.
2021-07-12 06:51:19 +00:00
bool DynamicMeter_search(Hashtable* dynamics, const char* name, unsigned int* key);
Add a new DynamicMeter class for runtime Meter extension 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 ( https://github.com/htop-dev/htop/issues/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.
2021-06-23 07:44:56 +00:00
extern const MeterClass DynamicMeter_class;
#endif