As a PRTG User, I want be able to add PIE CHART element to map to visualize ANY (!) sensor that has at least 2 dimensions (X - channel(s), Y - numeric value(s) of the same type).
Details of User Story
Ideally, ANY(!) sensor that has at least 2 dimensions (X - channel name(s), Y - numeric value(s) of the same type) should be treated as valid data provider for pie chart diagram. At the same time, default channels (downtime, execution time, etc.) can/should/may be excluded from the pie chart, since their metrics might be different (%, ms, etc.) from the raw collected set of data (memory, billing, time, IOPS, etc.).
In our particular case, we are looking for any options to use PIE chart diagram to visualize following scenarios: - % CPU usage by processes - Memory usage by processes - AWS billing by services - % of error/debug/warn/info/performance/trace messages from an event log
Here are criterion proposals:
By excluding default channels (downtime, execution time, etc), a sensor should have channel(s) with values of the same type.
For example, let's assume, a sensor has channels to measure a) % processor time and b) memory consumed by some processes. The total number of channels (as per PRTG best practice) should be less than 50, i.e. up to 25 processes can be traced (up to 25 processes - for % CPU time, up to 25 processes - memory consumption).
If there are multiple channel values of the same type, ideally we should be able to select what metric (in other words, what channels that do share the same value type) should be used in the pie chart.
For example, there are a) up to 25 channels with % as metric (for CPU time), b) up to 25 channels with Gb as metric (for memory consumption). So, it is end user to the select which group should be displayed in the pie chart - the CPU time or the memory.
The total/sum of all those values (within one selected metric) can be treated as 100%, if no other options are specified.
a) CPU time -> if % of idle is not specified, then the existing information helps us to visualize the most CPU-intensive application.
b) Memory -> if the maximum available memory is not specified, then the existing information helps us to visualize the most memory-consuming application
c) Billing -> if the maximum budget limit is not specified, then the existing information helps us to visualize the most expensive part/cost