With PromQL, the state label with a boolean value tends to be more
user-friendly.
For example, you can do things like `avg_over_time(foo{state="some
state"}[10m])` to detect problems, but maybe ignore one or two state
changes.
Similarly, you can be more specific about states with `changes_over_time()`.
On Tue, Jul 19, 2022 at 12:21 AM Roman Baeriswyl <[email protected]>
wrote:
> 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/CABbyFmqyz54x2h%3Dtq5D77-DZV75BBiSnKqY-xztCGx_47um8_g%40mail.gmail.com.
