Counting active FTD site VPNs: which number do you mean?

Before writing the Ansible task, answer a smaller question: what is being counted? A configured peer, an IKE session, an IPsec security association and a monitored tunnel-status record are four different units, and rekeying or multiple protected networks makes their totals diverge. If the dashboard and the playbook disagree, they are usually counting different things rather than one of them being wrong.

Four things people call active

A configured peer is a topology object: it exists because someone defined it. An IKE session is a control-plane relationship that can be up while no traffic flows. An IPsec SA is the data-plane association for a particular selector pair, and one tunnel can carry several. A monitored tunnel status is the platform's own operational verdict, which is usually the closest thing to what an operator means by the tunnel is up.

Only the last one is a reasonable basis for an operational count. The first one is a configuration inventory, and reporting it as active is how a dashboard shows green for a peer that has been down since Tuesday. Decide which unit the consumer of the number needs, then label the metric with that unit in its own name.

Decision one: which management plane?

If the device is managed by FDM, the FTD REST API is the relevant surface. If it is managed by FMC, that API is not an interchangeable substitute, and the objects live behind FMC's own API. Confirm this before you write a single request, because the wrong plane returns a plausible error that reads like a permission problem.

For a fleet, the answer also decides where the count belongs: per device through FDM, or per domain through FMC. Those are different scopes and they produce different numbers for the same fleet.

Decision two: which resource answers it?

For a version-bounded example, the FMC 7.3 API object reference documents GET resources under the health path:

/api/fmc_config/v1/domain/{domainUUID}/health/tunnelstatuses
/api/fmc_config/v1/domain/{domainUUID}/health/tunnelsummaries

The tunnel-status resource supports device and status filters, including TUNNEL_UP. That gives you a real operational resource to inspect for that release rather than a guess about a field name.

Confirm availability, permissions, request parameters and the response schema on the deployed FMC's API Explorer before implementing a parser. Documentation for one release is a starting point, not a contract for the one you are running.

Write the count contract

State the metric in one sentence: unique operational tunnel records for one intended device and domain whose reported state is TUNNEL_UP. Then document how redundant devices and multiple records for one logical site are represented, because those two cases decide whether your number matches the one in the meeting.

Do not silently change the unit from tunnel record to remote site. If the business wants sites, map records to sites explicitly and publish the mapping. A count that quietly redefines itself is worse than no count, because nobody can tell when it changed.

Treat the summary resource as a convenience only after confirming what it summarizes. It may aggregate exactly what you need, or it may answer a subtly different question. Read its schema once, write down the difference, and use the status resource if the summary cannot be explained. A summary you do not understand is a number you cannot defend in a review.

Make the workflow preserve uncertainty

Use the approved HTTPS API, validate the certificate, keep tokens out of task output, and fetch the scope with the release's supported filter and pagination. Then validate the schema before calculating anything.

fetch intended domain/device runtime records
validate response, completeness and freshness
deduplicate by the documented tunnel identity
count records matching the approved up-state definition
report count with scope, timestamp and metric unit

That is workflow pseudocode, not a tested playbook. Take the actual field names from the installed API instead of inventing a JSON key called active.

The important rule is failure behaviour: an authorization error, an unsupported resource, a stale sample or an incomplete page set must produce unknown or error, never a successful zero. A zero that means I could not ask is the most expensive kind of wrong.

Validate against the platform's own view

Compare the first result with the release's VPN monitoring view for the same device and moment. When they differ, find out which unit each one uses before changing the playbook.

Retain non-secret context for each run: scope, timestamp, metric unit and record count. The FMC 7.3 API object reference is the source for the resource paths above, and the API Explorer on your own deployment is the source for everything else.