Workarounds needed for Palo Alto

[gsperry2011]

This is not intended to be a bug report where I expect things to be fixed but I do think it is a place other folks might come looking (like I did) to fix the numerous issues with using this snmp_exporter and generator to collect metrics from Palo Alto firewalls. None of the issues described here are problems with this exporter or generator (I think). What I believe is that the MIBs from Palo aren't exactly standard which causes issues with the snmp_exporter as it relies on the manufacturers MIBs.

First issue:

This is a relatively common one I found quickly online. The work around involves editing the MIBs downloaded from Palo to prevent conflicts with ifIndex and ifDesc and then re-generating snmp.yml. The generator.yml already has some logic in place to work around Palo's conflicting OIDs but doesn't account for this issue yet (and I don't expect it to). I found the issue described in detail and workaround here: #623

Second issue:

This one I couldn't find documented anywhere and took some digging. I grabbed a dashboard for Palo from Grafana's website: https://grafana.com/grafana/dashboards/13907 - This has a widgit which queries for panChassisType which was blank for me and not a metric Prometheus was collecting. After some digging I discovered that for some reason unknown to me at the moment, while panChassisType is found in the Palo MIBs, the generator doesn't create this as an OID to collect. This is the value required to read the "model" of the Palo e.g. PA-3060. If I manually edit a generated snmp.yml to add the the following lines, the exporter does successfully collect it.

paloalto_fw:
  walk:
  - 1.3.6.1.2.1.2
  - 1.3.6.1.2.1.25.1
  - 1.3.6.1.2.1.25.2
  - 1.3.6.1.2.1.25.3
  - 1.3.6.1.4.1.25461.2.1.2.1
  - 1.3.6.1.4.1.25461.2.1.2.3
  - 1.3.6.1.4.1.25461.2.1.2.5
  - 1.3.6.1.4.1.25461.2.1.2.2.1.0                        # <--- Added line
  get:
  - 1.3.6.1.2.1.1.3.0
  metrics:
  - name: panChassisType                                # <--- Added line
    oid: 1.3.6.1.4.1.25461.2.1.2.2.1.0                 # <--- Added line
    type: DisplayString                                        # <--- Added line
    help: String of the model of palo firewall model. e.g. PA-3060 - 1.3.6.1.4.1.25461.2.1.2.2.1.0       # <--- Added line

Third issue:

Metrics fresh out of the generator around interfaces only contain the interface index # which is not particularly useful because once you get into Grafana or alerting you will likely find that you want the interface name so you can provide a useful name onto a Grafana graph or alert message rather than providing some ifIndex = Interface name matrix and letting them sort it out. I was able to add an additional lookup onto specific metrics to add the interface name in the labels to be consumed. Note that you will have to add this lookup to every metric you wish to have the "useful" interface name on, which IMO is basically all of the metrics you would use in Grafana or alerts specific to an interface.

Example of metric from generator:

ifSpeed{ifIndex="1"} 1e+09
ifSpeed{ifIndex="10"} 1e+09
ifSpeed{ifIndex="101020036"} 1e+09
ifSpeed{ifIndex="101070213"} 1e+09
ifSpeed{ifIndex="101070214"} 1e+09

Example with the added lookup:

ifSpeed{ifIndex="10",ifName="ethernet1/5"} 1e+09
ifSpeed{ifIndex="101020036",ifName="ethernet1/2.36"} 1e+09
ifSpeed{ifIndex="101070213",ifName="ethernet1/7.213"} 1e+09
ifSpeed{ifIndex="101070214",ifName="ethernet1/7.214"} 1e+09

The lookup code looks like this:

    lookups:
    - labels:
      - ifIndex
      labelname: ifName
      oid: 1.3.6.1.2.1.2.2.1.2
      type: DisplayString

And here is a full example using the ifSpeed metric above:

 - name: ifSpeed
    oid: 1.3.6.1.2.1.2.2.1.5
    type: gauge
    help: An estimate of the interface's current bandwidth in bits per second - 1.3.6.1.2.1.2.2.1.5
    indexes:
    - labelname: ifIndex
      type: gauge
    lookups:
    - labels:
      - ifIndex
      labelname: ifName
      oid: 1.3.6.1.2.1.2.2.1.2
      type: DisplayString