Implement out-of-bounds verification & error handling when accessing OIDs not retrieved before about snmp_exporter HOT 15 OPEN

Data point: just got bitten by that again.

from snmp_exporter.

And again!

from snmp_exporter.

The generator handles this automatically.

from snmp_exporter.

from snmp_exporter.

It ensures all required OIDs are walked.

from snmp_exporter.

The generator doesn't prevent users from making their own invalid configs. I think we should fix this eventually, I just don't think it's a big priority.

from snmp_exporter.

I think if a user is hand generating a config they're on their own. There's many things we can't check for them, such as index types and data types.

from snmp_exporter.

Totally, that's why I marked this as enhancement, not bug. Config validation would be a nice to have. We can improve on it incrementally.

from snmp_exporter.

There's no need for config validation. Only the generator should be producing configs, and any issues handled as bugs there. For this particular issue this is already handled and unittested.

The exporter is a dumb tools that'll do exactly what you tell it to, even if that doesn't make sense. Manual generation of configs was only a temporary thing until we had the generator.

from snmp_exporter.

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.

from snmp_exporter.

I'm not willing to add complexity to support users using this tool in a non-recommended fashion. All MIB-related logic including this is designed to belong in the generator, and only the generator. Adding something like this would make potential features like #131 more difficult than they already are to implement, as that requires sophisticated selection of what to walk.

If users insist on hand creating configs, they are free to write their own validation tools.

from snmp_exporter.

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 the expected information.

I would like to avoid open/close ping-pong, but either I am misunderstanding your concern about complexity or you are somewhat driven by "well, don't do that, then".

from snmp_exporter.

It's a mix. This doesn't fit architecturally and it'd get in the way of future features/optimisations. That the use case for this comes from something users aren't meant to be doing doesn't provide a strong case to override those concerns.

from snmp_exporter.

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

from snmp_exporter.

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

from snmp_exporter.