We're reclaiming inactive PDIs to keep them available for active builders. Learn what's changing, who's affected, and how to protect your work. Read More

Performance Analytics vs Custom Table for CMDB Data Quality Reporting (400k+ CIs)

HARIKRISHNAR648
Tera Contributor

Monday

Hi  @everyone,

We have a CMDB with approximately 400k+ CIs and need to build data quality reports (missing attributes, completeness, etc.).

For an environment of this size, what is the recommended approach?

  • Use Performance Analytics (automated indicators/KPIs), or
  • Calculate the metrics and store the results in a custom table for reporting

What are the restrictions in ootb performance analytics?

Labels:
0 Helpfuls
  • 152 Views
1 REPLY 1

vaishali231
Kilo Sage

Wednesday

Hey @HARIKRISHNAR648 

Based on experience with large CMDB implementations (300k–1M+ CIs), I would recommend using a hybrid approach rather than relying solely on either Performance Analytics or a custom reporting table.

1. Start with OOTB CMDB Health

If your goal is to measure data quality (Completeness, Correctness, and Compliance), the first choice should be the OOTB CMDB Health framework. It is specifically designed for CMDB data quality and includes scheduled jobs, health dashboards, health result tables, and score calculations that are optimized for large CMDBs.

This avoids reinventing functionality that already exists in the platform.

2. Use Performance Analytics for Trending

Performance Analytics works well for executive dashboards and historical trends.

Typical KPIs include:

  1. % of CIs missing Owner
  2. % of CIs missing Support Group
  3. Completeness score by CI Class
  4. Compliance score over time
  5. Correctness trend by Business Service

PA stores snapshots during collection rather than recalculating every dashboard load, making it suitable for trend analysis.

However, I would recommend collecting aggregated indicators (counts, percentages, scores) rather than indicators that iterate through every CI with complex scripted logic.

3. When a Custom Table Makes Sense

A custom table becomes useful when requirements go beyond what CMDB Health or PA provide, for example:

  1. Custom scoring algorithms
  2. Multiple business-specific quality rules
  3. Detailed per-CI quality history
  4. Integration with external BI tools
  5. Complex reports requiring pre-calculated results

In that case, calculate the metrics with a scheduled job during off-peak hours and store only the summarized results. Avoid calculating against all 400k records every time a report is opened.

 

Performance Analytics Considerations / Limitations

Some points to keep in mind:

  1. Historical data is not retroactive
    PA only starts collecting data after indicators are configured. It cannot generate historical trends for periods before collection started.
  2. Collection performance
    For a CMDB with 400k+ records, poorly written scripted indicators can significantly increase collection time. Keep indicator source queries simple and leverage indexed fields wherever possible.
  3. High-cardinality breakdowns
    Avoid creating breakdowns on fields such as CI Name, Serial Number, or Sys ID, as they create a very large number of breakdown elements.

Recommended breakdowns include:

  1. CI Class
  2. Company
  3. Environment
  4. Business Service
  5. Support Group
  6. Location
  1. KPI vs Record Detail
    Performance Analytics is intended for KPI and trend reporting, not detailed record listings.

For example:

  1.  "12% of Windows Servers are missing an Owner."
  2.  "Show me the 4,826 Windows Servers missing an Owner."

For record-level reporting, use standard list reports, database views, or CMDB Health result tables.

  1. Storage Growth
    Every indicator collection stores historical scores. If you have many indicators with multiple breakdowns collected frequently, storage usage will grow over time, so retention policies should be considered.
  2. Near Real-Time Data
    PA reflects the last successful collection. If indicators are collected nightly, dashboards will not show changes made after the latest collection until the next scheduled run.

 

Recommendation for a 400k+ CI Environment

For an environment of this size, I would recommend the following architecture:

  1. Use CMDB Health as the primary engine for data quality evaluation.
  2. Use Performance Analytics to trend the health scores and KPIs over time.
  3. Use standard reports or CMDB Health results to identify the individual CIs contributing to poor scores.
  4. Introduce a custom summary table only if business requirements require calculations or reporting that cannot be achieved through OOTB CMDB Health and PA.

This approach scales well, minimizes the impact on the CMDB, leverages OOTB capabilities, and avoids maintaining custom logic unless there is a genuine business need.

 

*********************************************************************************************************

If this response helps, please mark it as Accept as Solution and Helpful.

Doing so helps others in the community and encourages me to keep contributing.

Regards

Vaishali Singh

Servicenow Developer
Linkedin - https://www.linkedin.com/in/vaishali-singh-2273361bb