Welcome to this presentation on the Cisco ACI health score. I am Nevin Kumar from customer success team. Today, we will be exploring the concept of the health score and Cisco ACI and how it impacts the management of network resources. This overview will provide you with.00:05With an understanding of how the health score functions as an essential metric in evaluating system performance and stability.00:20In today's agenda, we will 1st delve into the health score, discussing what it represents and its importance to system monitoring in ACI. Then we will explore fault, event and audit records examining their role in system diagnostics and maintenance. This framework will help us understand how to utilize these records to maintain optimal system health within Cisco ACI.00:28My environments.00:48Let's start with the ACI health score. The health score gives a quick view of the overall state of the fabric and helps you see if the environment is healthy or needs attention. This score is mainly affected by faults. When faults appear, the score can drop, and when those faults are resolved, the score improves. So in most cases, improving the health score starts with addressing active faults. The.00:51Score is also useful for understanding when a problem began. By looking at the health trend over time, you can often connect score drops to events such as changes, maintenance or fabric issues. It's also normal to see some fluctuation after reloads or upgrades. These temporary changes do not always mean there is a lasting problem.01:11But they should still be reviewed in context. Overall, the health score is a simple and effective way to monitor fabric condition and support faster troubleshooting. Now that we understand what the health score represents, let's look at how Cisco ACI actually calculates it. The health score is not just a single standalone number.01:28It is computed at multiple levels across the fabric, including the individual managed object, tenant, pod, and overall fabric level. That means ACI builds health from the bottom up, combining the condition of smaller components into a higher level score. This calculation is mainly influenced by two things. Faults and dependencies. 1st faults reduce the score.01:46Or based on their severity. In this example, warning, major and minor faults each carry different weights in the scoring logic. Second, the score also depends on the health of related or dependent objects, so even if one object looks fine on its own, its health can still be impacted by issues and components it relies on. All of this is processed through health score policy.02:07Sees using a weighted calculation, which produces a final score between zero and 100.02:27So the key takeaway is simple. The ACI health score is a policy driven weighted summary of both faults and object dependencies, giving you a more accurate picture of overall fabric health. Now let's move from the score itself to where you actually investigate the issues affecting it. Within the APIC, the system tab gives you a fabric wide operator.02:32Operational view. This is one of the 1st places administrators go when they need to understand what is happening across the environment at a global level. In this view, three areas are especially important. Faults, events, and the audit log. The fault section helps you identify active problems that maybe directly lowering the health score. These could include configuration issues, operational fail.02:52Failures, interface problems or communication related alerts.03:12Event records provide a detailed history of network activities within the last 24 h. These logs are crucial for understanding what occurred at specific times, aiding and troubleshooting and ensuring smooth network operations. Using these records, we can identify significant changes in actions within the network.03:18Audit logs offer insights into changes and actions taken by users within the network. These logs are crucial for security and compliance, helping track user activities and changes to network configurations. They ensure accountability and transparency in network management. To troubleshoot effectively in Cisco ACI, it's important to understand.03:36The difference between faults, events, and audit records, because each one answers a different operational question. These records are aci's primary method of logging, and they can be accessed through the GUI, CLI or API. They can also be exported remotely using monitoring policies, which makes them useful not only for day to day operations, but also.03:56For centralized monitoring and long term analysis. Now, the easiest way to remember them is by the question each one answers, false answer, what is broken?04:16They highlight active issues that require attention such as configuration errors, operational failures or connectivity problems, events answer, what happened? They capture state changes and important activity across the fabric, even if those changes do not represent an actual fault. Audits answer, who did what? They track administrative actions, helping you understand what changes.04:25Which were made, who made them, and when. So when you were investigating a health score drop, faults show the problem, events show the sequence of activity, and audits show whether a user change may have contributed to it.04:45That distinction is critical for fast and accurate root cause analysis. Now let's take a closer look at faults because they are the primary drivers behind health score changes in Cisco ACI. In ACI, a fault is not just a text entry in a log. It is actually a managed object or mail. That means the fault exists in some.04:56Had the management information tree as a child of the specific object it affects. Because of that, every fault has its own properties, life cycle, and a unique identifier in the F4X format. Faults are also assigned severity levels. These range from critical and major at the high end, down to minor warning, info, and finally cleared once the condition is.05:16On this slide, the example shows a power supply on leaf 1101 going offline. ACI raises fault at 1451 and the interface shows the exact affected object, including its full distinguished name, topology/pod one/node 1101 slash sys/CH/syslot one.05:37Slash sue. This is one of the strengths of aci's object based model. The system does not just say that something failed. It tells you exactly what failed, where it exists in the hierarchy, and gives you a structured way to trace that issue back to its impact on overall health.05:56Now that we understand what a fault is, the next step is knowing how to read it effectively. This slide shows the fault properties view in Cisco ACI, and it highlights a very practical troubleshooting workflow. The 1st step is to identify the fault code. In this example, the code is F0532. That code tells us the specific fault type ACI.06:12Has detected. Next, we look at the affected object and the description. This is where the real context comes from. Here, the affected object points to a port channel interface on leaf 1202, and the description explains that the port is down because there are NO operational members connected.06:32That immediately gives us direction. Instead of troubleshooting the entire fabric, we can narrow the issue to a specific object on a specific switch. In other words, the fault is already guiding us toward the likely problem area, and that leads to the 3rd step. Take the appropriate action. In this case, the logical next move would be to investigate the port or port channel on leaf one.06:48Thousand 202. Verify member links and confirm connectivity or policy consistency, so the workflow is simple and powerful. 1st, identify the fault. Second, understand the affected object and description. 3rd, take targeted action.07:09Once a fault has been identified, Cisco ACI also gives you the option to acknowledge it. Acknowledging a fault does not clear the issue and it does not fix the underlying problem. What it does is provide an operational signal to others that the fault has already been seen and is currently being reviewed or worked on. In the faults view shown here, you can see an act column when a fault is acknowledged.07:25That status becomes visible to the operations team.07:45This is especially useful in shared environments because it helps avoid duplicate effort. Multiple engineers do not need to independently pick up the same issue if it is already known. In other words, acknowledgement improves team coordination. It tells others this fault is already on someone's radar while still keeping the fault active and visible until the root cause is resolved. So this is really.07:48Really an operational best practice, if a fault is known, being investigated and ownership is clear, acknowledging it can make fault management much more efficient.08:08While faults tell us what is broken, events tell us what is happening, as shown on this slide, an event is mainly an informational alert, unlike a fault, an event does not automatically indicate a problem, and in many cases, it does not require any action from the administrator. The best way to think about events is a record of state transitions or activity inside the fabric.08:19In this example, ACI generated an event because an IP address was detached from an endpoint group. That may sound important, but it can actually be part of completely normal network behavior.08:39If we look more closely at the event properties, we can see details such as the event ID, the severity, and the cause, which in this case is listed as transition. We also see the transaction ID and the user responsible for the action. Here, the user is shown as internal, which tells us the change was triggered automatically by the system rather than by a human administrator.08:49This is what makes events so valuable, even when nothing is technically broken, they give you a timeline of what changed, when it changed, and how the system responded. That context becomes extremely useful during troubleshooting, especially when you are trying to understand what happened just before a fault appeared.09:09Now let's move to the 3rd major record type in Cisco ACI, audit records. If faults tell us what is broken, and events tell us what happened, then audit records tell us who changed what. They maintain a history of configuration changes made within the fabric, which makes them extremely valuable for administration, troubleshooting, and accountability, as shown on this slide, the.09:28The audit log captures details such as the time stamp, the user, the action, the affected object, and a brief description of the change. In the example shown here, we can see actions like creation, modification, and deletion along with the exact object and the configuration that was impacted.09:48This is especially useful when you were investigating unexpected behavior after a policy change. Instead of guessing whether something was manually updated, you can go directly to the audit log and verify exactly what change occurred when it happened and which user or process initiated it. The slide also highlights an important operational point.10:04This is a very good reason to have triple AAA configured properly. When authentication, authorization, and accounting are set up correctly, audit records become much more meaningful because they are tied to real user identities and clearly tracked administrative actions. In day to day operations, audit logs help answer questions like, was this object recently modified? Was something deleted?10:22Accidentally, who made this change? That level of visibility is critical in large environments where multiple administrators maybe working at the same time.10:42Now let's take a deeper look at an individual audit record. At this level, the audit log gives us very specific details about a configuration change. We can see exactly which object was modified, who performed the action, what action was taken, and when it happened. In this example, the affected object is a specific VPC domain, and the action performed is deletion.10:52We can also see the user account responsible for the change, which is extremely useful when multiple administrators are working in the same fabric.11:12One of the most important fields here is the trigger. This tells us exactly what attribute was modified as part of the transaction. That level of detail helps move troubleshooting from guesswork to evidence. We also see the transaction ID, which is valuable because several configuration operations maybe tied to the same administrative task.11:19By following that transaction, an engineer can better understand the full scope of a change. This is why audit logs are so important in Cisco ACI. They provide accountability, traceability, and operational clarity whenever changes are made in the fabric. This concludes our presentation. We've explored acknowledgment, events, and audit logs.11:36Records within Cisco ACI, highlighting their importance in maintaining network performance and security. Thank you for your attention, and feel free to reach out with any questions regarding Cisco ACI health score management.11:57
