Search results

Actually the catch-all is not any kind of sin. The regexp-metric-categorizing is mostly beneficial in repeating parts, such as CPU Cores, where you can then pick "max" or "avg" or something like that over collection of things. Using Max I've actually seen my Ryzen 3950X reach 4.7k at least once...

Yeah to give some explanation for that last line... all the lines above, that you correctly saw, try to categorize/structurize the sensors like for different Cores and such; they take coreNo separate so one can aggregate and treat the values still in same sensor but different cores. That last...

Thank you for simple writeup of "Getting started from scratch"!!! The journey to "get sensors in data" seems to be neverending, I'm lacking bit behind of my ideas how to better handle the sensors. HWiNFO made it quite great initially, so many of the angles were working good (bit too well, so...

Some delay (other projects) to close up the WMI. Meanwhile I got the Corsair HX1000i PSU; here's the regexp and example images for PSU graphs (last 7 days in the example, except Efficiency is realtime one): PSU data is from my main system only though as I don't have HXi series but only in that...

Lucky for us, the old post was found in Internet WebArchive - and it includes the answer (its a whole page of posts so you need to find the GB and MB issue): http://web.archive.org/web/20150402102620/https://www.hwinfo.com/forum/Thread-HWiNFOMonitor?pid=2651 Clip from the page: "Yeah, this is...

Just for heads up, I'm closing in to adding configurable support for WMI providers; that is tons of metrics available for Windows. Below some examples in Prometheus and JSON formats: WMI gets access to all kinds of system stuff... also adding it in eases the path for adding more other...

Right now it isn't possible, but I'll see what I can do. Initially I didn't consider the metric names being good to just "pass through as-is", but of course when renamed, that's a common case. I think PromDapter should support renaming as well, and that would further justify the source-based...

Yes that would be nice! I can merge all the customizations in so that they are included in future releases. Here or GitHub is OK, whichever you prefer.

The example graph picture is showing my 3 PCs actually :). Prometheus includes by default (or at least my installation does) "instance" information that includes host:port, so you get to aggregate them by default. Just add all the PCs IPs to scrapers and you're good to go. I've planned to add...

Nice! The CPU + GPU Power is just combining the metrics from previous two graphs into the same graph, odd that it doesn't work. I checked my own currently used graph metrics and its just combination. CPU graph alone: hwi_cpu_package_power_w GPU graph alone: hwi_gpu_power_w Combined graph...

The setup goes like this: 1. The systems to be monitored need to run HWiNFO (with sensor window opened at least once) and PromDapter - that is your 10445 port So this is one or more systems that all provide the Prometheus-compatible data 2. Prometheus is installed on some server, and its...

Oh you need Prometheus Database installed, that is "scraping" (= reading in Prometheus terms) from that metrics - data... and then Grafana is the visualization system that provides the graphs. So to answer "what is exacty required?" is following: 1. Prometheus Database 2. Grafana They likely...

I'm happy to hear that. The refactoring took most of the time, so now adjusting the output is easier; but the flat structure seems to serve best, as the grouping up can be done on caller's side with more flexible manner. Please let me know, if you find any issues or prefer some adjustment on...

Ok, finally managed to release the new version. https://github.com/kallex/PromDapter/releases v0.9.16 No other additions, but JSON output support, with some initial grouping support too (this is not so trivial, had to alter it a bit from initial suggestion). The JSON can be tested with few...

Closing in, had to refactor some of the Prometheus specific data structures to more common (I was naive initially to focus on Prometheus alone). Current version (not yet released) is outputting something like this; I'll now revisit your suggestions and see if I can match them properly. {...

I will check them still though; if they're available, I'll pass them through - but if they are calculated on the fly (and that would be needed to be replicated), then its better to do it in the data handling end of the pipe. I've been busy elsewhere for few days now, will try to get the JSON...

These are quite generic structures; array and grouped up by sensor. Should be pretty easy to implement - I check how the different value types best play along. About min/max/average, I can check them out, but I personally don't think they belong at this layer with context of Prometheus; of...

You can try temporarily adding "catch-all" line to your .yaml file; as last (before the aggregation part) or first in case last doesn't still catch it: - '(?<MetricName>.*)' NOTE! It will screw all the sensor names / categorization and other parts (being as last line might limit the effect)...

I'm senior enough to have my "own school of thought". I don't believe in delaying development for trying to find "unified smart data structure". I believe in extensibility/flexibility to have multiple EXACT required structures. So we'll proceed ASAP with the exact structure you need :-).

Yes, please share your needs and current/preferred structure. I speak fluent C#, its trivial for me to add...