Config parser loads invalid metric names.

[SuperQ]

The config parser needs to validate metric names against Prometheus valid metric names.

I don't remember if there's a function or not, but we could implement this with a basic regexp: [a-zA-Z_]([a-zA-Z0-9_])*

For example, this should fail:

if_mib:
  walk:
  - 1.3.6.1.2.1.2
  get:
  - 1.3.6.1.2.1.1.3.0
  metrics:
  - name: sys.UpTime
    oid: 1.3.6.1.2.1.1.3
    type: gauge

[brian-brazil]

All the intelligence is in the generator, which already has appropriate munging to ensure that only valid metric names are produced.

The exporter is only intended to be used with the generator, and I'm against adding code just to deal with users who decide to hand-craft their config as there's many many ways such a config could be broken. If you hand-craft a config, it's your responsibility to ensure it's sane.

[SuperQ]

That attitude does not solve corruptions, is unfriendly to users, and does not help with defense in depth.

[brian-brazil]

Any corruption of the metric names will be caught by existing code, there are already three layers of checks for invalid metric names. This also seems like a rather niche form of corruption to worry about specifically.

I do not want to spend time supporting the use case of hand generating snmp.yml. Rather than spending lots of time to try and support such users and teach them the internals of both this exporter and SNMP, we should be pointing them towards the generator which is much easier and friendlier to use.

[jpVm5jYYRE1VIKL]

I also using handcrafted config. And as i understand it is quite wide used practice. Because to use generator need to fulfill too much conditions.

[RichiH]

The generator has come a long way, but e.g. #180 is still blocking a lot of people from using it. I know of several reimplementations of snmp_exporter due to this and other factors.

Users crafting configs by hand will not stop just because the handcrafted part is kept brittle.

@SuperQ and me are willing & able to support people who handcraft configs so you would not need to care about that.

[brian-brazil]

It is an explicit architecture decision that there is no sanity checking of the config in the exporter, and I do not intend to change that as that's a rabbit hole in terms of code complexity.

[brian-brazil]

My stance has not changed, and given generator changes since the number of users hand generating configs should have gone down quite a bit too.