Monitor Fortinet FortiManager managed devices, configuration sync, policy packages, change tasks, and appliance health with Smartscape topology.
The Fortinet FortiManager extension ingests the management-plane state from a Fortinet FortiManager. The extension runs as a Python extension on an ActiveGate and polls the FortiManager JSON-RPC API (POST /jsonrpc), authenticating with an API token, a username and password session, or, for FortiManager Cloud, the FortiCloud SSO exchange.
The extension bundles its own data source: the Python collector runs on the ActiveGate and retrieves the data from FortiManager. On the FortiManager side, you only need to create a read-only API administrator (or, for FortiManager Cloud, a FortiCloud IAM API user) and enter its credentials in the monitoring configuration.
FortiManager manages the firewalls from the management plane, so it stores state that no individual device can report about itself. On each collection cycle, the extension authenticates and issues the JSON-RPC get requests for every enabled feature set. It then:
self_monitoring feature set reports API call outcomes, response time, session re-authentications, and collection duration as sfm.fortimanager.* metrics.The extension reads the following JSON-RPC resources:
| Data group | JSON-RPC resource | Collection tier | Feature set or toggle |
|---|---|---|---|
System status, HA, appliance interfaces, and resources |
| Standard |
|
ADOMs and managed devices |
| Real time |
|
ADOM workspace locks |
| Real time |
|
Policy packages and install status |
| Standard |
|
Tasks |
| Standard |
|
Configuration revisions |
| Standard | System configuration events toggle (on by default) |
FortiAnalyzer alerts |
| Standard | Alert events toggle (off by default) |
By default, the real-time tier runs every 60 seconds and the standard tier every 300 seconds. You can change both intervals; see Create the monitoring configuration.
443 unless changed), which your network must allow. For FortiManager Cloud, the ActiveGate instead needs outbound HTTPS (TCP 443) to the instance URL and to customerapiauth.fortinet.com, Fortinet's shared SSO host. If direct access isn't available, you can configure a proxy. FortiManager must also accept requests from the source address of the extension's requests: the ActiveGate's address, or the proxy or NAT address in between. For details, see the Trusted Hosts setting in Create the FortiManager API account.| Permission | CLI attribute | Needed for |
|---|---|---|
System Settings |
| System status, HA, the appliance's interfaces and resources, and tasks ( |
Administrative Domain |
| Listing the ADOMs the administrator can see ( |
Device Manager |
| ADOMs, managed device inventory and state, workspace locks, and configuration revisions ( |
Policy & Objects > Policy Packages & Objects |
| Policy package inventory and install status ( |
Incidents & Events |
| FortiAnalyzer alerts. Only when the Alert events toggle is on. |
Don't grant Read-Write; the extension doesn't need it.
When you save the monitoring configuration, the extension validates only connectivity, authentication, the permissions behind the system status and ADOM list reads, and the ADOM scope. If another permission is missing, FortiManager returns a permission error (HTTP 403 or JSON-RPC code -11). The extension logs which admin profile section to grant and reports a non-OK endpoint status for that feature set. It continues collecting all other data.
The extension works with the FortiManager JSON-RPC API and provides ready-made metrics, topology, logs, dashboards, and alert templates for the following data groups:
For these data groups, everything is ready to use from the moment you save a monitoring configuration. The feature sets and log toggles you enable, the admin profile you grant, and the ADOM scope you set determine which data groups reach Dynatrace and how much the collection costs.
Note the following constraints:
Activation has four parts: activate the extension from Dynatrace Hub, create the FortiManager API account, create the monitoring configuration, and verify that data arrives. The prerequisites are listed under Requirements.
Activate the Fortinet FortiManager extension in
Hub (see Deploy an extension from Dynatrace Hub). Upon activation, the extension deploys the Python collector, the metric definitions, the OpenPipeline metrics source and Smartscape pipeline, the unified analysis screens, the dashboards, and the alert templates.
The OpenPipeline metrics source is bound to this extension (sourceType: extension, source: com.dynatrace.extension.fortinet-fortimanager) and statically routed to the Fortinet FortiManager Smartscape Metrics Pipeline. You don't need to add a dynamic route: the fortimanager.* metrics reach the Smartscape pipeline automatically as soon as the extension starts reporting.
After activation, everything that ships with the extension is listed on the extension's Content page.
Self-managed FortiManager
dynatrace_ro) and an optional Description.0.0.0.0/0.0.0.0 in Trusted Hosts > Trusted IPv4 Host 1, which accepts every address. If you use IPv6, adjust the IPv6 entries the same way.You can also create the same profile in the FortiManager CLI:
config system admin profileedit "dynatrace_ro"set system-setting readset adom-switch readset device-manager readset adom-policy-packages readset event-management read # only when the Alert events toggle is onnextend
FortiManager Cloud
<id>.<region>.fortimanager.forticloud.com.Add a monitoring configuration, select the ActiveGate group that runs it, and fill in the fields below.
The configuration's description becomes the configuration_label dimension on every metric and log record. The dashboards' FortiManager filter lists this value, so give each configuration a recognizable name.
To store credentials securely, you can reference entries from the credential vault instead of entering them directly.
Authentication
| Field | Applies to | Description |
|---|---|---|
Deployment Type ( | All |
|
FortiManager host ( | Self-managed | Hostname or IP address of the FortiManager, without scheme and port. |
FortiManager port ( | Self-managed | HTTPS port for the API. Default: |
Authentication mode ( | Self-managed |
|
Use credential vault ( | All | When turned on, the credentials are read from credential vault entries instead of being entered directly. Default: off. |
Vault credential (API token) ( | Self-managed, token, vault | A token credential holding the API key. |
Vault credential (username / password) ( | Self-managed, session, vault | A username and password credential holding the administrator's username and password. |
API key ( | Self-managed, token, without vault | The REST API Admin's API key. Stored as a secret and sent only as a bearer token. |
Username ( | Self-managed, session, without vault | The administrator's username and password. |
FortiManager Cloud URL ( | Cloud | The instance URL recorded in Create the FortiManager API account, without |
Vault credential (client ID / API key) ( | Cloud, vault | A username and password credential whose username is the client ID and whose password is the API key. |
Vault credential (IAM password) ( | Cloud, vault | A token credential holding the IAM API user's password. A separate entry is needed because one vault entry carries only two values. |
Client ID ( | Cloud, without vault | The FortiCloud IAM API user's three credentials. |
Collection intervals
| Field | Default | Range | Applies to |
|---|---|---|---|
Real time interval ( |
| 60–300 | ADOMs, managed device state and HA members, ADOM device counts, and workspace locks |
Standard interval ( |
| 60–3600 | System status and appliance resources, policy packages, tasks, configuration revisions, FortiAnalyzer alerts, and the |
A value outside its range, or one that isn't a number, is logged and replaced with the default instead of failing the configuration.
Scope and options
| Field | Default | Description |
|---|---|---|
ADOM scope ( | Empty | Comma-separated ADOM names to monitor, matched exactly and case-sensitively. If empty, every ADOM visible to the administrator is monitored. This setting is the main lever on cost; see Licensing and costs. |
Task lookback (minutes) ( |
| How far back to look for tasks. A task still in progress is followed past the lookback until it finishes. |
System configuration events ( | On | ADOM configuration revision history as |
Alert events (requires FortiAnalyzer features) ( | Off | FortiAnalyzer correlated alerts as |
Alert lookback (minutes) ( |
| How far back to look for alert events. Shown only while Alert events is on. |
Range window size ( |
| Records requested per page when listing devices, policy packages, tasks, or alerts. |
Request timeout (seconds) ( |
| Per-request HTTP timeout for every call, including login and logout. |
Verify TLS certificate ( | On | Turn off only for a self-signed certificate that can't be replaced. A TLS validation failure is never silently downgraded to an unverified connection. |
Proxy ( | Not set | Optional Address (must start with |
Primary tags ( | Not set | Up to 20 key-value pairs added to every metric, log record, and Smartscape node this configuration produces. Keys must start with |
Primary fields ( | Not set | Up to 10 cloud and cost attribution pairs (for example, |
Enable debug logging ( | Off | Raises the extension log level to |
Feature sets
Select the feature sets you want on the same configuration screen. default is always active. The rest are opt-in per monitoring configuration, and we recommend all of them. For what each one collects, see Details and Feature sets. Configuration revisions and FortiAnalyzer alerts are controlled by the System configuration events and Alert events toggles instead of by feature sets.
When you save the monitoring configuration, the extension runs a pre-flight check that:
/sys/status and expects status.code 0./dvmdb/adom and confirms that ADOM scope, if set, matches at least one ADOM visible to the account.Each call is a single attempt with a timeout of at most 20 seconds, so the check finishes within the platform's time limit.
An unreachable host, a refused connection, a timeout, or a TLS validation failure is reported as a connection error naming the base URL. An ADOM scope that matches nothing is reported as an invalid configuration. A green status on the monitoring configuration means all checks passed.
Data appears on the dashboards within one or two collection cycles.
The Fortinet FortiManager extension collects metrics, topology, and log data for:
Metrics are reported under the fortimanager.* namespace. The appliance's CPU, memory, and interfaces are also reported under the platform's com.dynatrace.extension.network_device.* namespace, so its built-in network device page is populated.
The default feature set is always on and reports appliance connectivity, system status, interfaces, CPU, memory, and disk, the ADOM count, and managed devices per ADOM and connection state. The other feature sets are opt-in per monitoring configuration:
device_management): Per-device inventory and connection, configuration sync, and pending-change state, plus HA cluster membership.policy_packages): Package inventory and install status per device and VDOM target.tasks): The task state distribution, plus the fortimanager.task_monitor log.adom_inventory): Devices per ADOM by OS version, and workspace lock state.self_monitoring): API call outcomes, response time, session re-authentications, and collection duration, reported as sfm.fortimanager.*, with no extra FortiManager API call.For the metrics in each feature set, see Feature sets.
The Fortinet FortiManager extension is packaged with:
The extension builds its topology on Smartscape on Grail only. Instead of shipping a static topology, the bundled Fortinet FortiManager Smartscape Metrics Pipeline extracts nodes and edges from the fortimanager.* metrics as they arrive, so the topology reflects changes as ADOMs, packages, and cluster members are added or removed.
The extension creates an EXT_NETWORK_DEVICE node for the FortiManager appliance and an EXT_NETWORK_INTERFACE node for each of its own interfaces, plus FORTIMANAGER_ADOM, FORTIMANAGER_POLICY_PACKAGE, and FORTIMANAGER_HA_MEMBER nodes. The extension adds belongs_to static edges from each interface and each ADOM to the appliance, and from each policy package and each HA member to its ADOM.
The metrics source is statically routed to that pipeline, so you don't need to configure anything: the nodes populate automatically once the first collection cycles complete. Allow a few minutes.
To explore the topology, open
Smartscape, or
Infrastructure & Operations > Network devices for the appliance. Filter for the FortiManager node types, and select an entity to explore its connections.
Each FortiManager entity type has an inventory list and an entity details view. You can reach them from
Infrastructure & Operations > Network > Fortinet FortiManager, by selecting the entity in
Smartscape, or through global search.
| Entity | Inventory screen | Entity details tabs |
|---|---|---|
FortiManager ADOM | ADOMs | Overview, Properties, Devices, Policy packages, Change activity, Events |
FortiManager Policy Package | Policy packages | Overview, Properties, Targets, Events |
FortiManager HA Member | HA members | Overview, Properties, Events |
FortiManager appliance (network device) | Network devices (platform list) | Adds a Related entities tab to the platform page |
Each inventory screen lists every entity of that type with its health alerts and current counts. Each entity details screen opens on an Overview tab of current state, backed by a Properties tab of the entity's attributes.
Tabs whose data isn't collected are hidden instead of shown empty. These screens require Smartscape on Grail, so they're subject to the minimum Dynatrace version in Requirements.
Beyond metrics, the extension sends structured log streams to Grail. Logs carry the per-task, per-revision, and per-alert detail that would otherwise inflate metric cardinality, and they stay queryable with DQL.
| Log source | One record per | Emitted by | Controlled by |
|---|---|---|---|
| Task whose state or progress changed, plus every task in progress, per standard cycle |
|
|
| New ADOM configuration revision |
| System configuration events toggle |
| New or changed FortiAnalyzer alert |
| Alert events toggle |
Every record carries timestamp, log.source, severity, content, and configuration_label, plus the primary tags and fields of the monitoring configuration and the fields listed for each stream. The extension keeps change detection state in memory, so the first cycle after an extension restart behaves as described for each stream.
Severity is ERROR when the task ended in error or reports errors, otherwise INFO.
| Field group | Fields |
|---|---|
Identifiers |
|
State and progress |
|
Target counts |
|
Timing |
|
A task is logged when its state or percentage differs from the previous cycle. Tasks still in progress (pending, running, cancelling, aborting, to_continue) are logged every cycle so a stalled task keeps a current record, and they're followed past Task lookback until they finish. On the first cycle, every task in the lookback window is logged.
adom.oid is FortiManager's numeric ADOM reference, not the ADOM name.
Severity is always INFO.
| Field | Description |
|---|---|
| ADOM the revision belongs to |
| Revision number and name |
| The description the administrator entered |
| Administrator who created the revision |
| Creation time (epoch seconds) |
| Whether the revision is locked against deletion |
Only revisions newer than the last one seen per ADOM are logged. The first cycle after a restart, and the first cycle for an ADOM newly in scope, record the current revision as a starting point without replaying past history.
Severity is mapped from the alert: alert, critical, error, and high map to ERROR, warning and medium map to WARN, and everything else maps to INFO.
| Field group | Fields |
|---|---|
Alert |
|
Lifecycle |
|
Times |
|
Source |
|
Detail |
|
An alert is reported again only when its acknowledgement state, read state, correlated log count, severity, or update time changes. On the first cycle, every alert in the Alert lookback window is logged.
The task and revision logs carry FortiManager administrator usernames verbatim (task.user, revision.created_by), because they answer who changed what. The same usernames appear as the task.user and lock.user metric dimensions. The extension never writes credentials, session tokens, or the device credentials FortiManager stores to any log or metric: device reads request an explicit field list that excludes them.
The Task Activity dashboard reads fortimanager.task_monitor, and the Policy & ADOMs dashboard reads fortimanager.system_config. fortimanager.alert_events is available for ad-hoc DQL queries in
Notebooks and
Logs.
Fortinet publishes no rate limit for the FortiManager JSON-RPC API, so the extension limits its request rate: at most four requests in flight and at least 0.1 seconds between requests against one FortiManager, with reads for several ADOMs batched into one request where the API allows it.
| Situation | Handling |
|---|---|
Transport error or HTTP | Retried up to three times with increasing backoff, within half the collection interval. |
TLS certificate validation failure | Reported as a connection error. Never retried and never downgraded. |
| Re-authenticates once. A second |
| Reported as a permission error naming the admin profile section to grant. |
| All calls wait for |
JSON-RPC code | Reported as a session limit error and not retried. See FAQ. |
A failed endpoint skips that cycle for its feature set only: the extension reports a non-OK endpoint status, and the other collectors keep running. Session and FortiManager Cloud modes sign out at the end of every cycle, so the extension never occupies a session slot between cycles. Token mode uses no session slots.
There is no charge to use the extension. You are only charged for the data that the extension ingests.
The extension polls the FortiManager JSON-RPC API and reports custom metrics from the responses. The metrics consume Davis Data Units (DDUs) (Dynatrace classic license) or Metrics powered by Grail (DPS), according to your license model. The log streams are billed separately, as log ingest and retention.
In the Dynatrace Platform Subscription, metric ingestion consumes Metrics powered by Grail according to the number of ingested metric data points.
The following formula provides approximate data points ingested per year, assuming all feature sets are enabled and the default collection intervals are used.
(( 1 unique managed-device rollup metric * dimension combinations ) -- default, real time (every 1 min)+ ( 11 unique appliance metrics * dimension combinations ) / 5 -- default, standard (every 5 min)+ ( 5 unique device metrics * dimension combinations ) -- device_management (every 1 min)+ ( 2 unique policy package metrics * dimension combinations ) / 5 -- policy_packages (every 5 min)+ ( 1 unique task metric * dimension combinations ) / 5 -- tasks (every 5 min)+ ( 2 unique ADOM inventory metrics * dimension combinations ) -- adom_inventory (every 1 min)+ ( 5 unique self-monitoring metrics * dimension combinations ) / 5 -- self_monitoring (every 5 min)) * 60 minutes * 24 hours * 365 days data points per year
A "dimension combination" is a distinct set of values across a metric's dimensions. Omit any line for a feature set you don't enable.
In practice, each combination maps to one real object—the appliance, an appliance interface, an ADOM, a managed device, an HA member, a policy package target, or a task transition—because every metric carries an identity dimension. Cost therefore scales with the size of the managed estate, not with the number of FortiManager appliances:
fortimanager.policy_package.install_status emits one series per package, device, and VDOM target, and is the largest contributor: around 10,000 series on an estate with 10 ADOMs, 1,000 devices, and 200 packages. Narrowing ADOM scope is the only way to control it.fortimanager.devices and the device state metrics each emit one series per managed device.fortimanager.tasks emits only on task state changes, so it follows how much change activity runs, not the estate size.The log streams add one record per changed or in-progress task per standard cycle, one per new configuration revision, and one per new or changed FortiAnalyzer alert.
In the classic licensing model, metric ingestion consumes Davis Data Units (DDUs) at the rate of .001 DDUs per metric data point. Multiply the above formula for annual data points by .001 to estimate annual DDU usage.
The DDU cost above doesn't include the log records ingested by the log streams, or any problems and custom events raised by the alert templates. For more information, see DDUs for custom Davis events.
When activating your extension using a monitoring configuration, you can limit monitoring to one of the feature sets. To work properly, the extension has to collect at least one metric after the activation.
In highly segmented networks, feature sets can reflect the segments of your environment. Then, when you create a monitoring configuration, you can select a feature set and a corresponding ActiveGate group that can connect to this particular segment.
All metrics that aren't categorized into any feature set are considered to be the default and are always reported.
A metric inherits the feature set of a subgroup, which in turn inherits the feature set of a group. Also, the feature set defined on the metric level overrides the feature set defined on the subgroup level, which in turn overrides the feature set defined on the group level.
| Metric name | Metric key | Description |
|---|---|---|
| — | com.dynatrace.extension.network_device.cpu_usage | — |
| — | com.dynatrace.extension.network_device.memory_usage | — |
| — | com.dynatrace.extension.network_device.if.status | — |
| FortiManager connectivity | fortimanager.connectivity | Whether the extension's last poll of this FortiManager succeeded (1) or failed (0) at the authentication and system-status level. The primary availability signal for this monitoring configuration. |
| FortiManager system status | fortimanager.system.status | Presence signal (constant 1) carrying the FortiManager appliance's own identity and platform attributes (hostname, serial, firmware version/build, HA mode, ADOM mode) — use it to look up which appliance a given series belongs to. |
| FortiManager appliance interfaces | fortimanager.system.interfaces | Presence signal (constant 1) per physical interface on the FortiManager appliance itself, carrying interface name, type, administrative status and configured speed/address. Distinct from managed-device interfaces reported by fortimanager.device.interfaces; the FortiManager's own operational link state has no source field on this endpoint and is permanently unset here. Carries fmg.serial — the appliance's own serial number, because no endpoint this extension reads reports a MAC address for the appliance — so this identifies the appliance's interface nodes the same way fortimanager.system.status identifies the appliance. |
| Managed devices by ADOM and connection status | fortimanager.managed_devices | Count of managed devices grouped by ADOM and connection status (up/down/unknown) — answers "how many devices in each ADOM are currently reachable" without needing per-device detail. |
| Administrative domains | fortimanager.adoms | Count of Administrative Domains (ADOMs) configured on this FortiManager, grouped by restricted product set — a low-cardinality inventory signal for sizing ADOM scope. |
| Appliance CPU utilization | fortimanager.appliance.cpu.utilization | CPU utilization of the FortiManager appliance itself. This is the management appliance watching its own health — it is not a managed-device metric, and a busy FortiManager slows installs and API responses for every device it manages. |
| Appliance memory utilization | fortimanager.appliance.memory.utilization | Memory utilization of the FortiManager appliance itself, derived from its reported used and total values rather than from an embedded percentage string, since that string's formatting varies between firmware builds. |
| Appliance hard disk utilization | fortimanager.appliance.hard_disk.utilization | Hard disk utilization of the FortiManager appliance itself. A full disk stops configuration revisions and logging before it stops device management, so it fails quietly rather than obviously. |
| Appliance flash disk utilization | fortimanager.appliance.flash_disk.utilization | Flash disk utilization of the FortiManager appliance itself. Not present on every platform — where the appliance does not report it, the metric is simply not sent for that cycle rather than reported as zero. |
| Metric name | Metric key | Description |
|---|---|---|
| Policy packages | fortimanager.policy_packages | Presence signal (constant 1) per policy package defined in an ADOM, carrying its name, type (package vs. folder) and parent folder. The package inventory that fortimanager.policy_package.install_status cross-references by name. |
| Policy package install status | fortimanager.policy_package.install_status | Whether a specific policy package's installation is in sync (1 = installed) or not (0 = out of sync or any other reported state) on a given device/VDOM target. The largest-cardinality metric in this extension (one series per package x device x VDOM target) — narrow the adom_scope configuration field to control series count. |
| Metric name | Metric key | Description |
|---|---|---|
| Managed device inventory | fortimanager.devices | Presence signal (constant 1) per managed device, carrying its full identity, platform, firmware, connection/config-sync/database-modified/device status codes and HA role. The canonical per-device inventory record the Managed Devices dashboard and the ADOM screen's device list are built on. Managed devices get no Smartscape node of their own, because FortiManager reports no health or performance for them; the device is reported here and on its ADOM rather than as an empty network device page. os.version is composed from the device's os_ver (the major version alone), mr and patch fields, giving the same form the FortiGate GUI shows. |
| Device connection status | fortimanager.device.connection_status | Whether a managed device is currently connected to FortiManager (1) or not (0). The device-level availability signal. is_model marks a device that was added to FortiManager but has never connected — exclude those from device-down alerting so that staged devices do not raise problems before they are deployed. |
| Device configuration sync status | fortimanager.device.config_sync_status | Whether a managed device's configuration is in sync with FortiManager's database (1 = in sync, 0 = out of sync/unknown). Flags configuration drift that has not yet been pushed to or pulled from the device. |
| Device database modified flag | fortimanager.device.db_modified | Whether FortiManager's database record for a device has pending local modifications not yet installed to the device (1 = modified, 0 = not modified). Distinct from config_sync_status, which reflects the device's own reported sync state rather than FortiManager's pending changes. |
| HA cluster members | fortimanager.device.ha_members | Presence signal (constant 1) per HA cluster member nested under its parent device, carrying the member's serial number, role and priority. Only clustered devices emit rows here; standalone devices emit none. Identity keys on member.serial, never member.name (member.name may repeat the parent device's name); the member's node belongs to its ADOM. |
| Metric name | Metric key | Description |
|---|---|---|
| FortiManager API successful calls | sfm.fortimanager.api.successful_calls | Number of FortiManager JSON-RPC calls that returned status.code 0 in the last self-monitoring window, split by endpoint. A health signal for the extension's own connectivity, not for the managed estate. |
| FortiManager API failed calls | sfm.fortimanager.api.failed_calls | Number of FortiManager JSON-RPC calls that failed (non-zero status.code or HTTP error) in the last self-monitoring window, split by endpoint, vendor error code and error class. The first place to look when the extension reports a non-OK status. |
| FortiManager API response time | sfm.fortimanager.api.response_time | Mean elapsed time of FortiManager JSON-RPC calls in the last self-monitoring window, split by endpoint. Flags a slow or overloaded FortiManager before it starts timing out. |
| FortiManager session re-authentications | sfm.fortimanager.session.reauth | Number of forced session re-logins in the last self-monitoring window, split by reason (idle timeout, invalid session, forced). Session auth mode only — token mode never reports this metric. |
| Collection cycle duration | sfm.fortimanager.collection.duration | Wall-clock duration of each feature set's collection callback in the last self-monitoring window. Identifies which feature set is slow before it risks overrunning its interval. |
| Metric name | Metric key | Description |
|---|---|---|
| ADOM device inventory by OS version | fortimanager.adom.devices | Count of devices within an ADOM grouped by restricted product set and OS version. Answers "how many devices in this ADOM are on which firmware" for upgrade-campaign planning. |
| ADOM workspace lock status | fortimanager.adom.workspace_locked | Whether an ADOM's workspace is currently locked for editing, and by whom. A locked workspace blocks other administrators from making changes until it is released. |
| Metric name | Metric key | Description |
|---|---|---|
| FortiManager tasks | fortimanager.tasks | Presence signal (constant 1) per task inside the configured lookback window whose state or percentage changed since the previous cycle, carrying its current state, type and initiating user. A task that has not moved reports nothing that cycle — the same dedup that keeps task IDs out of metric dimensions — so read this as change activity, not as a census of the window. |
The ActiveGate can't complete an HTTPS connection to the FortiManager. Check the host and port, any firewall or proxy between the ActiveGate and FortiManager, and that the TLS certificate is trusted or Verify TLS certificate is turned off. For FortiManager Cloud, check reachability to customerapiauth.fortinet.com as well as to the instance.
Check the following:
The names in ADOM scope must match ADOMs the administrator can access, exactly and case-sensitively. Check the spelling of each name, the administrator's Administrative Domain selection, and that its admin profile grants Administrative Domain at Read-Only.
FortiManager caps concurrent sessions per administrator. Another tool sharing the account, or sessions left behind by an earlier crash, can exhaust the available slots. Clear them under System Settings > Dashboard > Current Administrators, give the extension an administrator of its own, or switch to API token authentication, which uses no session slots.
This is by design. FortiManager reports no health or performance for the firewalls it manages, so the extension creates no network device node for them (see Compatibility information). Managed devices are listed on their ADOM's Devices tab and on the Managed Devices dashboard. To monitor the firewalls themselves, use the Fortinet FortiGate extension.
HA member nodes need the device_management feature set, and policy package nodes need policy_packages. Enable them on the monitoring configuration and allow a few minutes. You don't need to create an OpenPipeline route: the metrics source is statically routed to the Smartscape pipeline as part of activation.
Each dashboard depends on specific feature sets:
device_management.policy_packages, adom_inventory, and the System configuration events toggle.tasks.self_monitoring.Data starts at the next collection cycle after you enable a feature set, with no back-fill.
This is expected. The tab only appears when task data is attributed to the ADOM, and FortiManager's API offers no way to map a task's ADOM reference to an ADOM name, so the tab stays hidden on every ADOM. Use the Task Activity dashboard for change activity across the estate.
The Alert events toggle is off by default. Once it's on, it returns data only when FortiAnalyzer Features is enabled on the FortiManager, the managed devices forward their logs to it, and the admin profile grants Incidents & Events read access. The activation check doesn't probe this endpoint, so the configuration still shows a green status on a FortiManager without FortiAnalyzer Features.
Alert templates ship disabled. Enable those you want on the extension's Content > Alert template page; enabling one adds it to anomaly detection. Then check the following:
device_management for the device alerts, adom_inventory for the workspace lock alert, and tasks for the failed-task alert.In order of impact:
For details, see Licensing and costs.