Richard Hartmann comments

Results 325 comments of


                                            Richard Hartmann

Implement out-of-bounds verification & error handling when accessing OIDs not retrieved before

Reality is that configs are still baked by hand, both by old and new users. Basic error checking is not an anti-pattern, so re-opening.

Implement out-of-bounds verification & error handling when accessing OIDs not retrieved before

This is not about selecting anything outside of what's in the (currently named) `walk:` section, it's merely about not silently coming up empty when a data structure does not hold...

Implement out-of-bounds verification & error handling when accessing OIDs not retrieved before

https://docs.google.com/document/d/1McJJIiJfHgoecVrVNXx4ABJmI5M21e-6O9IgMNbVnvw

Implement out-of-bounds verification & error handling when accessing OIDs not retrieved before

On top of logging, we should also expose this as a counter.

invalid character on device description passes from snmp_exporter to prometheus - invalid utf-8 label

@SuperQ I agree with your sentiment, but I do wonder what it should be changed to. Drop the label silently? Strip down é to e? If yes, what about ☺?

invalid character on device description passes from snmp_exporter to prometheus - invalid utf-8 label

@SuperQ just to deliberately think about it once.

generator new file management

I think all of the above could be achieved with support for a `snmp.d` or `snmp.yml.d`, no?

generator new file management

https://github.com/prometheus/snmp_exporter/issues/628 should cover the essence of your intention, correct?

generator new file management

Now that I think about it again, that makes sense. I will need to think about it some more. A mapping from `generator_fool.yml` -> `snmp_exporter_foo.yml` could make sense.

@xkilian We're discussing details on and off; the overview: generator should follow how snmp_exporter does it. snmp_exporter will follow how Prometheus does it. Prometheus will most likely use standard Go...