Can multiple modules be supported？

[linqianye]

hello,
Can SNMP exporter support multiple modules to adapt to private MIBs of different vendors?
Now it's like this in prometheus.yml,

  - job_name: 'test-switch'
    scrape_interval: 60s
    static_configs:
     - targets:
       - 172.22.1.57
       - 172.22.1.58
    metrics_path: /snmp
    params:
      module: [if_mib]
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: 127.0.0.1:9116

In the code above, can you realize the following functions?

  - job_name: 'test-switch'
    scrape_interval: 60s
    static_configs:
     - targets:
       - 172.22.1.57
       - 172.22.1.58
    metrics_path: /snmp
    params:
      modules:
      - if_mib
      - cisco_bgp
      - juniper_ospf

[SuperQ]

It's something I would be interested in exploring. We would need to think about if we would execute in parallel or serial. Also how to handle duplicate walks.

[ghost]

Hi, although it's not exactly the case, the way I do it is using relabeling on prometheus.yml:

- job_name: snmp
  honor_labels: true
  metrics_path: /snmp
  params:
    module: [generic]
  file_sd_configs:
  - files:
    - 'snmp/snmp_targets.json'
  relabel_configs:
    - source_labels: [__module]
      target_label: __param_module
    - source_labels: [__address__]
      target_label: __param_target
    - source_labels: [__param_target]
      target_label: instance
    - target_label: __address__
      replacement: snmp_exporter:9116

In the snmp_targets.json there is a disposable label "__module" that defines the specific snmp module the target should use. I'm not sure if the "honor_labels" option is required though, but as the saying says "if it is working..."

[aaronnad]

+1 for this, would make it much easier for being able to use a single job.
I personally would prefer the job to run in parallel, that way the interval is known for a user where they may have some modules that take longer than others to run, meaning the scrape_timeout would not need to be extended per job.

[amuntean-godaddy]

+1

[TwistWR]

+1

[candlerb]

    params:
      modules:
      - if_mib
      - cisco_bgp
      - juniper_ospf

I would very much like this too. However, I want to be able to specify it per-target using rewriting rules, and currently a __param_XXX module cannot generate a list, i.e. repeated instances of the same query parameter.

Hence I would rather it were a comma-separated list:

    params:
      modules:
      - "if_mib,cisco_bgp,juniper_ospf"

I suggest that these requests are done serially, and in the order specified. Note that it's possible for a subsequent module to generate the same timeseries as an earlier one (i.e. same metric with same labels); if so, either the earlier or the later should take precedence. (It doesn't really matter which; you can reverse the order of the list of modules in the query if necessary). Doing this serially helps make this deterministic, and also avoids loading the target device with additional concurrent SNMP queries.

I am happy to set the timeout to be the largest expected combination of modules on the slowest device. In any case, it is necessary to set the scrape job interval to be at least this time.

[SuperQ]

Fixed in #731.

[candlerb]

Or fixed in #945

[SuperQ]

Oops, copied the wrong URL.