ACI Exporter: APIC returns no data for interface traffic/drop stats

[alex.dersch]

Hello Cisco DevNet Community,

We are currently deploying the `opsdis/aci-exporter` to collect Cisco ACI metrics through APIC and expose them to Prometheus/Grafana.

The general exporter setup is working. We can successfully collect and visualize several ACI metrics, for example:

- fabric node inventory via `fabricNode`
- node health via `topSystem` with `rsp-subtree-include=health`
- fabric health via `fabricHealthTotal`
- tenant/application/EPG/VRF/BD health
- interface operational state and speed via `ethpmPhysIf`
- BGP peer metrics via `bgpPeer` / `bgpPeerAfEntry`
- OSPF neighbor metrics via `ospfAdjEp`
- node CPU and memory via `procSysCPU5min` and `procSysMem5min`

We are now trying to extend the Grafana node/interface dashboard with interface traffic, packet drop, and error metrics.

The exporter configuration already contains query definitions for the following ACI classes:

```yaml
interface_rx_stats:
class_name: eqptIngrBytes5min

interface_tx_stats:
class_name: eqptEgrBytes5min

interface_rx_err_stats:
class_name: eqptIngrDropPkts5min

interface_tx_err_stats:
class_name: eqptEgrDropPkts5min
```

However, the exporter only emits the following interface metrics:

```text
aci_interface_oper_speed_bps
aci_interface_oper_state
```

It does not emit metrics such as:

```text
aci_interface_rx_unicast_bytes
aci_interface_tx_unicast_bytes
aci_interface_rx_error_dropped_pkts
aci_interface_tx_error_dropped_pkts
aci_interface_rx_buffer_dropped_pkts
aci_interface_tx_queue_dropped_pkts
```

We checked the exporter logs and confirmed that the exporter does call the statistic classes successfully. The APIC API calls return HTTP 200, but the response size is very small:

```text
class="eqptIngrBytes5min" status=200 length=28
class="eqptEgrBytes5min" status=200 length=28
class="eqptIngrDropPkts5min" status=200 length=28
class="eqptEgrDropPkts5min" status=200 length=28
```

So the exporter appears to be working correctly, but APIC does not return any objects for these statistic classes.

Our goal is to understand how interface traffic, packet drops, and interface errors should be collected from APIC for use with `aci-exporter`, Prometheus, and Grafana.

Questions:

1. Are `eqptIngrBytes5min`, `eqptEgrBytes5min`, `eqptIngrDropPkts5min`, and `eqptEgrDropPkts5min` still the correct APIC classes for interface traffic and drop/error statistics?

2. Are these classes dependent on a specific ACI statistics collection setting, retention policy, statistics family, or monitoring policy?

3. Is there a different or newer APIC class that should be used for physical interface traffic counters, packet drops, and interface errors?

4. Could this behavior be caused by permissions of the APIC API user, even though the API calls return HTTP 200 and not a permission error?

5. Has anyone successfully exposed interface traffic/drop/error counters through `opsdis/aci-exporter`, and if yes, which class queries are used?

For context, interface state and speed work correctly through `ethpmPhysIf`, so the exporter, APIC connectivity, authentication, and basic class queries are functional.

Any guidance on the correct APIC classes or required ACI configuration for these interface statistics would be appreciated.

Thank you.

[olasupoo]

Hi Alex,

Length 28 is just an empty imdata, so APIC really has no objects for those classes. The exporter and the class names are both fine. eqptIngrBytes5min/eqptEgrBytes5min for traffic and eqptIngrDropPkts5min/eqptEgrDropPkts5min for drops are still correct, and the error/buffer/queue breakdowns you want are attributes inside the drop classes (forwarding, buffer, error, lb counters), not separate classes, so there's nothing newer to switch to.

Two things give you an empty 200 like this, and there's a clean way to tell which. Run moquery -c eqptIngrBytes5min on the APIC as admin. If admin also gets nothing, it's stats collection. If admin sees data but your exporter user doesn't, it's RBAC on that user.

If it's collection, check your Monitoring Policy under Fabric > Fabric Policies > Monitoring for the Layer1 physical interface stats. The Egress, Ingress and Ingress Error Packets families need admin state enabled and a history retention that isn't none. If they're sitting on a policy with collection off or retention zeroed, those eqpt objects never get created, which is exactly your empty result.

If it's RBAC, a class query returns 200 but quietly drops objects the user's security domain can't see, so you get an empty imdata instead of a 403. ethpmPhysIf working doesn't rule this out, since different classes can be tagged to different domains. Give the exporter user read access to the right security domain (or all) and retest.

I'd lean towards the monitoring policy, since state and speed come from ethpmPhysIf which isn't a stats class, but the moquery-as-admin check settles it in one go.