P0.NoECC.00

Introduction

The P0.NoECC.00 code is associated with a ServiceNow Discovery Log if the corresponding records in the ECC Queue (generated by ServiceNow Discovery) get purged before Discovery Admin can get to them.

The ECC Queue is one of the several out-of-the-box Tables in ServiceNow that gets populated by ServiceNow Discovery as a part of its standard logging.

This is seen in scenarios where the number of ServiceNow Discovery Logs generated every time ServiceNow Discovery is run, is in the multi-millions and it takes several days for Discovery Admin to scan these logs.

Follow the steps below to mitigate the number of errors identified as P0.NoECC.00 thereby ensuring that a higher percentage of ServiceNow Discovery Logs get analyzed by Discovery Admin, before getting auto-purged by ServiceNow.

Step 1: Get the Total Duration

Identify the time it takes to run an exhaustive Troubleshooting of your ServiceNow Discovery Logs with Discovery Admin, aligned with the Discovery Schedules in scope.

To get this number, start by running Ad-hoc Troubleshooting or Scheduled Troubleshooting for the Discovery Status Records generated by the scoped Discovery Schedules.

This will give you a predictable number of days for which we must ensure that the Logs generated by ServiceNow Discovery (in the ECC Queue) need to be retained.

Proceed to Step 2.

Step 2: Retain ECC Queue for Longer

Based on the duration identified in Step 1, update the retention policies for the ECC Queue to retain ServiceNow Discovery Logs for a couple of days, beyond the amount of time it takes Discovery Admin to complete the Troubleshooting.

This ensures Discovery Admin has the time needed to analyze the relevant Logs generated by ServiceNow Discovery before they get auto-purged.

To update the retention policies:

Navigate to: System Definition > Table Rotations
Search : Name = ecc_queue
- Open the Record
- Update: Duration = 2
Search : Name = sa_discovery_log_history
- Open the Record
- Update: Duration = 2

This extends the data retention for the tables above to 12 days, providing the buffer we need to successfully analyze the ServiceNow Discovery Logs.

Click here to reference the related ServiceNow Documentation.

This will significantly reduce the number of rows corresponding to P0.NoECC.00

If ECC Queue retention isn't an option (due to Platform restrictions), explore Step 3.

Step 3: Reduce the Scope

Evaluate the possibility of reducing the number of Discovery Schedules scoped for recurring analysis.

Examples of scope reduction could include Discovery Schedules corresponding to IP Ranges with less critical infrastructure, end-user devices, etc.

This will reduce the number of ServiceNow Discovery Logs analyzed by Discovery Admin, resulting in faster completion times, which can be set as the new baseline.

Repeat Step 1 and Step 2 with the reduced scope to make sure the ECC Queue records (generated by ServiceNow Discovery) are retained for an appropriate amount of time.

If Scope Reduction isn't an option (due to Business Impact), explore Step 4.

Step 4: Segregate the Scope

Evaluate the possibility of scanning a subset of the Discovery Schedules with a higher frequency.

So, instead of having one Scheduled Troubleshooting analyzing everything every week, we can break it down to analyze a subset of the Discovery Schedules, daily.

For example, if the Scheduled Troubleshooting takes 5 days to analyze 100 Schedules, we can analyze ~20 Schedules every day, allowing us to complete the analysis before the ECC Queue records (generated by ServiceNow Discovery) are purged.

This will require multiple Scheduled Troubleshooting records to ensure we get complete coverage for the scoped Discovery Schedules.

Our goal is to ensure the current Scheduled Troubleshooting completes before the next one is scheduled to start.

This may require several iterations to make sure we have the correct granularity for the segregation of Discovery Schedules.

TIP:

Make sure all the Scheduled Troubleshooting records are named so that they start with the same Text.

Example: Datacenter-Daily-1, Datacenter-Daily-2

This way, Dashboards can still report on the consolidated results by filtering on Name STARTS WITH.

Example: Name STARTS WITH Datacenter-Daily-

NOTE:

For existing Dashboards, remember to update the filters to include Name STARTS WITH

If Scope Segregation isn't an option (due to Resource Availability), proceed to Step 5.

Step 5: Do Nothing

If neither of the options detailed above is viable for immediate implementation, Doing Nothing is our default choice.

If we are in this scenario, the following approach will help temporarily mitigate the gap.

Track the P0.NoECC.00 for variance.

This way you know what percentage of the Logs generated by ServiceNow Discovery is being auto-purged before Discovery Admin can Troubleshoot them.

While changes in the number of records corresponding to P0.NoECC.00 will directly affect the counts for your Incident Error Codes, if the total counts are trending down, it will still show progress.

This will also help reconcile data in Dashboards for alignment of the total errors, before and after the P0.NoECC.00 mitigation is implemented.

Additionally, since identifying and fixing a subset of errors can indirectly fix other related errors, having limited analysis (till you effectively mitigate P0.NoECC.00) will still provide value, from a remediation standpoint.

If you have any questions or clarifications on the steps above, including if you see anything unique in your environment that is not addressed in this Article, please reach out to your Discovery Admin point-of-contact.