As a network administrator in an enterprise environment with an extensive Cisco ACI fabric, having a native ACI sensor in PRTG would be a significant advantage. Currently, we have to integrate important monitoring data such as fabric health score, policy compliance, and tenant-specific performance awkwardly through external scripts or third-party tools. This approach is error-prone and maintenance-intensive, especially since many ACI details are not directly accessible via SNMP.
A dedicated sensor could:
Automatically capture key ACI statistics like health score, fabric errors, and policy deviations,
Eliminate the need for complex API integrations or costly external solutions,
Greatly speed up troubleshooting in daily operations,
Enable better visualization and alerting for SDN-related issues,
Provide native integration via the Cisco APIC API for Health Score, Faults, Events, Fabric Status, monitoring Tenants, VRFs, EPGs, Interfaces, and Leaf/Spine status,
Automatically discover and map objects,
Send notifications on critical or abnormal conditions.
Concrete use cases from my work include:
Monitoring the health score with escalation as soon as the score drops,
Compliance checks for policies to quickly identify policy violations,
Tenant monitoring to detect resource-specific problems per tenant.
Many administrators desire a native ACI integration in PRTG because traditional SNMP or custom sensors do not cover the dynamics, complexity, and depth of SDN. A direct sensor would save us considerable effort and significantly improve Cisco ACI monitoring practices.
M.altawil1993 supported this idea ·
As a network administrator in an enterprise environment with an extensive Cisco ACI fabric, having a native ACI sensor in PRTG would be a significant advantage. Currently, we have to integrate important monitoring data such as fabric health score, policy compliance, and tenant-specific performance awkwardly through external scripts or third-party tools. This approach is error-prone and maintenance-intensive, especially since many ACI details are not directly accessible via SNMP.
A dedicated sensor could:
Automatically capture key ACI statistics like health score, fabric errors, and policy deviations,
Eliminate the need for complex API integrations or costly external solutions,
Greatly speed up troubleshooting in daily operations,
Enable better visualization and alerting for SDN-related issues,
Provide native integration via the Cisco APIC API for Health Score, Faults, Events, Fabric Status, monitoring Tenants, VRFs, EPGs, Interfaces, and Leaf/Spine status,
Automatically discover and map objects,
Send notifications on critical or abnormal conditions.
Concrete use cases from my work include:
Monitoring the health score with escalation as soon as the score drops,
Compliance checks for policies to quickly identify policy violations,
Tenant monitoring to detect resource-specific problems per tenant.
Many administrators desire a native ACI integration in PRTG because traditional SNMP or custom sensors do not cover the dynamics, complexity, and depth of SDN. A direct sensor would save us considerable effort and significantly improve Cisco ACI monitoring practices.