Use of username and password instead of API

[MacBoy2828]

Hi

We are facing a situation where we have hundreds of FortiGates, and they are not managed by FortiManager. Each has a different API. Managing these APIs would be a headache, and we have to constantly modify the APIs for the exporter since our environment is very dynamic. Is there another method to get the statistics instead of the API? What would be the best approach in our case? Can we use a username and password?

[thenodon]

@MacBoy2828 I agree that Fortinet change the api's between versions. In an exporter that I built for a customer, before this exporter existed, we manage this by adding the version number as a scraping parameter. One solution would be to add the version to the configuration profile and then chose different API calls against the Fortigate based on the version in the fortigate-exporter.
The alternative is to enable snmp on the fortigate and use the snmp-exporter. But that may end up in the same issue if the MIBs are different for different fortios versions. Looking at https://docs.fortinet.com/document/fortigate/8.0.0/fortigate-mib-information-overview/630205 that seems to be the case, but then you can at least have one scrape jobs for what is common modules and specific scrape jobs for snmp modules where it differ between fortios versions.

[MacBoy2828]

@thenodon We already have an SNMP exporter, but a FortiGate exporter would be more comprehensive than the SNMP exporter.
Having a different API for every version is also another headache.
To make the exporter expandable for monitoring a large number of devices, there should be a better way than regularly tweaking every API. Is there a way that the exporter logs into the devices and stores their API automatically? This reduces the need for manually managing the APIs. A single username and password with read-only access via Radius can be configured for this purpose.

[thenodon]

@MacBoy2828 I do not think that kind of dynamic is possible. You still need code to translate and parse response to metrics. Having a structure in the exporter to switch code path based on a version input, query parameter, is the resonable way. That would mean that the exporter can support multiple versions of fortios in a controlled way.

[thenodon]

And I spoke to early - the fortios version, major and minor, is already collected prior to probing

fortigate_exporter/pkg/probe/probe.go

Line 100 in 2852c73

// Test client connection before we blast all the probes.