True, the amount should not be an issue at all. I wonder what is more convenient for the end user: having 10 states per sensor but with their state name as label, or just having one with the numerical value (which would allow > and < operations for alerts). I cannot decide between those two.
Regarding the other projects: I've looked thru many projects. The first one you mention need to actually run on the dell server itself, which I do not want. The second contains only a few metrics and uses the Redfish api (basically JSON, but I think a bit limited, especially for older systems). There are also a lot of others, mostly based on prometheus/snmp_exporter but they also lack a lot of metrics. In my first try, I created my own snmp_exporter generator (https://github.com/Roemer/idrac-snmp-exporter) even with a fully working automatic pipeline. But I find the generator way too restrictive. I am now working on a node based exporter with express, prom-client and net-snmp and it seems to work fairly well. I can export what I want, exactly how I want. This is the v2 branch which only exposes one set of metrics. Am Mo., 18. Juli 2022 um 23:14 Uhr schrieb Ben Kochie <[email protected]>: > Let's do the math: > > 100 servers * 10 states * 20 sensors = 20,000 metrics > > Worst case, say you have 5000 metrics each for 100 servers, that's still > only 500,000 series. This will probably take about 4GiB of memory. It > should still fit easily in an 8GiB memory instance. > > A single Prometheus can handle millions of metrics if you capacity plan > accordingly. > > Rather than SNMP, have you looked at > https://github.com/galexrt/dellhw_exporter? Or maybe > https://github.com/mrlhansen/idrac_exporter? > > On Mon, Jul 18, 2022 at 10:50 PM Roman Baeriswyl <[email protected]> > wrote: > >> Thanks for the answer. Well, it is not only fans, there are dozens of >> other status fields as well (i'm doing an idrac snmp exporter). And that >> for technically dozens of servers. Should I try to stick with the StateSet >> or should I switch to just expose the numerical represenation? >> >> [email protected] schrieb am Sonntag, 17. Juli 2022 um 10:50:43 UTC+2: >> >>> For things that have state changes you care about, I usually recommend >>> EnumAsStateSet. >>> >>> The good news is that Prometheus deals with compressing the boolean >>> values very well. And since all fans have the same set of states, those >>> values are deduplicated in the index. >>> >>> So while it looks like a lot in the metric output, it stores well in the >>> TSDB. >>> >>> The question is, how many fans on how many servers are we talking about? >>> >>> On Sun, Jul 17, 2022 at 6:26 AM Roman Baeriswyl <[email protected]> >>> wrote: >>> >>>> Hey all >>>> I am working on a Dell iDRAC SNMP Exporter and I struggle with "Status" >>>> fields. >>>> I think there are three main possibilities: >>>> >>>> 1. EnumAsStateSet >>>> The downside here is that it can really clutter the output. For example >>>> the Dell Fans have 10 possible status, so each fan has 10 fields where only >>>> one is set to "1". >>>> >>>> 2. EnumAsInfo >>>> The downside here is that have not so nice time history and it is >>>> probably harder to create alerts. >>>> >>>> 3. Use the numeric value >>>> The downside here is that you need to do the enum lookup in the alert / >>>> dashboard. >>>> >>>> What do you think is in general the best way for such status? >>>> >>>> Thanks for your input. >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Prometheus Users" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/prometheus-users/2b0defe0-0a8e-4ae5-be10-bc0efcadcd73n%40googlegroups.com >>>> <https://groups.google.com/d/msgid/prometheus-users/2b0defe0-0a8e-4ae5-be10-bc0efcadcd73n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "Prometheus Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/prometheus-users/6e4f9bd9-239a-4f24-9735-c5540e9b1411n%40googlegroups.com >> <https://groups.google.com/d/msgid/prometheus-users/6e4f9bd9-239a-4f24-9735-c5540e9b1411n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "Prometheus Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-users/CA%2BKmifFt-azV1gesiK_qPxmtfa5toLG%3DC5y-TiQTSAND5rVt2g%40mail.gmail.com.
