When using timeout, the generator generates a file that is incorrectly parsed

[numo68]

Host operating system: output of uname -a

quay.io/prometheus/snmp-exporter:latest Docker image running on
Linux 0e08dc4e182e 5.10.60-qnap #1 SMP Thu Nov 21 15:39:26 CST 2024 x86_64 GNU/Linux

snmp_exporter version: output of snmp_exporter -version

snmp_exporter, version 0.27.0 (branch: HEAD, revision: 4c054bf5b6732883fc40543be9600a96b4263a58)
  build user:       root@4a651fb63b95
  build date:       20250103-18:14:14
  go version:       go1.23.4
  platform:         linux/amd64
  tags:             unknown

What device/snmpwalk OID are you using?

does not matter

If this is a new device, please link to the MIB(s).

What did you do that produced an error?

I tried to use the timeout parameter in the generator.yml according to the README such as

  ...
  qnap:
    timeout: 10s
    walk:
  ...

Subsequently all the scrapes aborted after a few microseconds. I looked at the generated snmp.yml that also contained

    timeout: 10s

I suspected a failed parsing of the duration and manually quoted the value as a string one

    timeout: "10s"

That resolved the error.

I was not able to convince the generator to generate the quotes in any way, they were always either stripped or I got errors when attempting to escape them somehow. I am not 100% sure what parser is "right" here but I think that the duration with a time unit string is clearly a string and it would be better to quote it in both the generator's README example, as well as in the generated snmp.yml.

Thanks

What did you expect to see?

A timeout being respected.

What did you see instead?

An incorrectly parsed timeout causing an immediate scrape error.

[SuperQ]

That sounds more like an snmp.yml config parsing issue. Quotes should not be necessary for this.

[numo68]

True, according to https://yaml.org/spec/1.2.2/#1032-tag-resolution the10s is a string. Quoting it would be a bit defensive, it however makes sure that it is not up to the yaml parser (or very sharp eyes :) ) to distinguish between 1e0 and 1d0 . But yes, the real problem is somewhere else.

I don't know anything about go so I unfortunately cannot run experiments to pinpoint where exactly it gets broken, not even where the duration gets parsed (there seems to be one code path yaml -> time and then there is a self-implemented version in model/time.go of the common repo).