{"revision":"c10276e953456835cdbb1f3a60d58ae1980be353","document":{"id":29626,"path":"it-operations-management/discovery/discovery-performance-framework.md","title":null,"bundle":null,"doc_type":null,"release":null,"body":"---\ntitle: Discovery performance metrics\ndescription: This Discovery enhancement collects performance metrics on probe/pattern and sensor processing times and then aggregates that data over time. You can use the roll-up data to monitor the performance of specific discoveries or to compare performance between versions after an upgrade. By default, Discovery tracks the performance of individual probes, sensors, and patterns by measuring the processing time. When patterns are used, Discovery measures the Identification and Reconciliation Engine \\(IRE\\) processing time. Use the roll-up by build data to ensure that the processing times for Discovery components remain consistent for discoveries in a 24 hour period. View aggregate build data before and after an upgrade to compare the performance of the old and new versions. All aggregated performance data is read-only.Use the roll-up by status data to ensure that the processing times for probes/patterns and sensors remain consistent for a specific Discovery. All aggregated performance data is read-only.Use the roll-up by target data to ensure that the processing times for probes/patterns and sensors remain consistent for each Discovery of a specific IP address. All aggregated performance data is read-only.Discovery performance metrics can accumulate data for probes, patterns, and sensors each time Discovery runs. Discovery calculates processing times and increments the number of times a component runs for each roll-up profile: status, target, or build. All aggregated performance data is read-only.\nlocale: en-US\ncanonical_url: https://www.servicenow.com/docs/r/australia/it-operations-management/discovery/discovery-performance-framework.html\nrelease: australia\nproduct: Discovery\nclassification: discovery\ntopic_type: concept\nlast_updated: \"2026-03-12\"\nreading_time_minutes: 10\nbreadcrumb: [Discovery monitoring and issue resolution, Using Discovery, Discovery, ITOM Visibility, IT Operations Management]\n---\n\n# Discovery performance metrics\n\nThis Discovery enhancement collects performance metrics on probe/pattern and sensor processing times and then aggregates that data over time. You can use the roll-up data to monitor the performance of specific discoveries or to compare performance between versions after an upgrade.\n\n## Metrics\n\nDiscovery provides these individual performance metrics:\n\n-   Probe and pattern processing time.\n-   Sensor processing time.\n-   Identification and Reconciliation Engine \\(IRE\\) processing time for Discovery patterns. This processing time is already included in the sensor processing time, but is isolated here to provided more insight into the identification and reconciliation of pattern payloads.\n\nDiscovery can aggregate individual metrics for these attributes:\n\n-   Builds/versions\n-   Discovery status\n-   Target IP address\n\n## How metric aggregations are triggered\n\nMetric roll-ups are initiated as follows:\n\n-   **Aggregated by build**: Implemented by the **Aggregate Discovery Probe And Sensor Metrics By Build** scheduled job. This job runs at 0200, local time.\n-   **Aggregated by status**: Implemented by the **Rollup Probe/Sensor Metrics by Status** Script Action, which is triggered by the **discovery.complete** or **discovery.cancelled** registered events.\n-   **Aggregated by target**: Implemented by the **Rollup Probe/Sensor Metrics by Target** Script Action that is triggered by the **discovery.device.complete** registered event.\n\n**Note:** If Discovery execution is cancelled before it completes, Discovery cannot update the IP target metric aggregation table. This is because the **discovery.device.complete** event that triggers aggregation does not run. IP target data for an interrupted Discovery is collected when subsequent discoveries run successfully on the target. Cancelling Discovery execution does not affect the aggregation of other metrics, which are triggered differently.\n\n## Tables\n\nDiscovery performance metrics data is stored in these tables:\n\n|Table|Description|\n|-----|-----------|\n|Probe and Sensor Metrics \\(Individual\\) \\[discovery\\_perf\\_metric\\_probe\\_sensor\\]|Stores the individual performance metrics for probes/patterns, sensors, and IRE processing times.|\n|Probe and Sensor Metrics \\(Aggregate\\) \\[discovery\\_perf\\_metric\\_probe\\_sensor\\_rollup\\]|This is the base table for the metric aggregations and does not store data itself. The three roll-up tables, by-build, by-status, and by-target all extend this table.|\n|Probe and Sensor Metrics \\(Aggregated by Build\\) \\[discovery\\_perf\\_metric\\_probe\\_sensor\\_rollup\\_by\\_build\\]|Stores the aggregated performance metrics for probes/patterns, sensors, and IRE by build and version.|\n|Probe and Sensor Metrics \\(Aggregated by Status\\) \\[discovery\\_perf\\_metric\\_probe\\_sensor\\_rollup\\_by\\_status\\]|Stores the aggregated performance metrics for probes/patterns, sensors, and IRE by Discovery status.|\n|Probe and Sensor Metrics \\(Aggregated by Target\\) \\[discovery\\_perf\\_metric\\_probe\\_sensor\\_rollup\\_by\\_target\\]|Stores the aggregated performance metrics for probes/patterns, sensors, and IRE by IP address.|\n\n## Discovery properties\n\nPerformance metrics properties control whether or not aggregation occurs, but not what data is included in the aggregation. Status and IP target data is collected as follows:\n\n-   Rollups for status always contain new data. Discovery continuously collects data on all probes and sensors during the discovery execution for that discovery status and stores it in the Probe and Sensor Metrics \\(Individual\\) \\[discovery\\_perf\\_metric\\_probe\\_sensor\\] table. Aggregation rolls up all probe and sensor data for that particular status after **discovery.cancel** and **discovery.complete** events are fired for that status, but only if the aggregation property for status roll-ups is enabled.\n-   Discovery continuously collects data on IP targets and stores it in the Probe and Sensor Metrics \\(Individual\\) \\[discovery\\_perf\\_metric\\_probe\\_sensor\\] table. Aggregation rolls up all existing IP target data after the **glide.discovery.perf.metrics.rollup\\_by\\_target** property is enabled and creates records in the Probe and Sensor Metrics \\(Aggregated by Target\\) \\[discovery\\_perf\\_metric\\_probe\\_sensor\\_rollup\\_by\\_target\\] table.\n\nThese properties control the gathering of probe and sensor metrics:\n\n<table id=\"table_hq4_lwt_kfb\"><thead><tr><th>\n\nProperty\n\n</th><th>\n\nDescription\n\n</th></tr></thead><tbody><tr><td>\n\nglide.discovery.perf.metrics.enable\\_collection\n\n</td><td>\n\nEnables collection of performance metrics.-   **Type**: true \\| false\n-   **Default**: true\n\n</td></tr><tr><td>\n\nglide.discovery.perf.metrics.rollup\\_by\\_build\n\n</td><td>\n\nEnables aggregation of individual discovery performance metrics into a roll-up table that groups by build.-   **Type**: true \\| false\n-   **Default**: true\n\n</td></tr><tr><td>\n\nglide.discovery.perf.metrics.rollup\\_by\\_status\n\n</td><td>\n\nEnables aggregation of individual discovery performance metrics into a roll-up table that groups by discovery status.-   **Type**: true \\| false\n-   **Default**: false\n\n</td></tr><tr><td>\n\nglide.discovery.perf.metrics.rollup\\_by\\_target\n\n</td><td>\n\nEnables aggregation of individual discovery performance metrics into a roll-up table that groups by target IP address. By default, Discovery continuously collects individual IP address metrics, even when aggregation by target IP is disabled. When you enable IP target aggregation, Discovery includes all target metrics in the roll-up table.-   **Type**: true \\| false\n-   **Default**: false\n\n</td></tr></tbody>\n</table>## View Discovery performance metrics for probes, sensors, and patterns\n\nBy default, Discovery tracks the performance of individual probes, sensors, and patterns by measuring the processing time. When patterns are used, Discovery measures the Identification and Reconciliation Engine \\(IRE\\) processing time.\n\n### Before you begin\n\nRole required: discovery\\_admin or admin\n\n### Procedure\n\n1.  Navigate to **All** &gt; **Discovery** &gt; **Discovery Performance Metrics** &gt; **Probe/Sensor \\(Individual\\)**.\n\n2.  Sort the list by Discovery status to see the list of probes and patterns that ran in a specific Discovery.\n\n3.  You can view the metrics for each probe, sensor, or pattern in the list or open the record.\n\n    All probe and sensor metrics data are read-only.\n\n    \\[Omitted image \"DiscoPerformanceMetricProbe.png\"\\] Alt text: Individual probe and sensor metrics\n\n    The Probe and Sensor Metrics \\(Individual\\) form provides these fields:\n\n    |Field label|Field name|Description|\n    |-----------|----------|-----------|\n    |Build/version|build\\_version|Build on which the Discovery was run.|\n    |Discovery status|discovery\\_status|ID number of the Discovery status from which the metrics were collected.|\n    |Target IP address|target\\_ip|IP address of the target for this Discovery.|\n    |ECC queue input|ecc\\_queue\\_input|Identifies a particular ECC input record in the ECC queue table.|\n    |ECC queue topic \\*|ecc\\_queue\\_topic|Identifies the Java class in the MID Server that executes the probe.|\n    |ECC queue name \\*|ecc\\_queue\\_name|Identifies the probe/pattern evaluated for performance in this aggregation.|\n    |Probe \\*|probe|Name of the probe used for this Discovery.|\n    |Probe processing time|probe\\_time|Interaction time of the MID Server with the target, including construction of the payload that is sent back to the instance. The time is in milliseconds.|\n    |IRE processing time|ire\\_time|Time required to process the pattern payload on the instance by the Identification and Reconciliation Engine \\(IRE\\). IRE time is useful because it shows the part of the sensor time used by the pattern. The time is in milliseconds.|\n    |Sensor processing time|sensor\\_time|Time it took the sensor to process the payload on the instance for a Discovery. The time is in milliseconds.|\n\n    \\* Used to uniquely identify a probe/pattern and accompanying sensor when gathering metrics for a Discovery.\n\n\n## View Discovery performance metrics aggregated by build\n\nUse the roll-up by build data to ensure that the processing times for Discovery components remain consistent for discoveries in a 24 hour period. View aggregate build data before and after an upgrade to compare the performance of the old and new versions. All aggregated performance data is read-only.\n\n### Before you begin\n\nRole required: discovery\\_admin or admin\n\n### Procedure\n\n1.  Navigate to **All** &gt; **Discovery** &gt; **Discovery Performance Metrics** &gt; **Probe/Sensor \\(Rollup-By-Build\\)**.\n\n2.  Sort the list by **Build/version**.\n\n    \\[Omitted image \"DiscoPerformanceBuildFilter.png\"\\] Alt text: Filtering the list of performance data aggregated by build\n\n3.  Filter by a specific build to see the aggregated processing times for the probes and patterns that performed a Discovery on that build.\n\n4.  Open a record to see the probe/pattern statistics for the selected build.\n\n    The form displays additional fields not visible on the list. Roll-up calculations are over a 24 hour period, beginning every night at 0200.\n\n5.  See the table of performance aggregation data for descriptions of additional metrics displayed on the form for roll-ups by build.\n\n\n## View Discovery performance metrics aggregated by status\n\nUse the roll-up by status data to ensure that the processing times for probes/patterns and sensors remain consistent for a specific Discovery. All aggregated performance data is read-only.\n\n### Before you begin\n\nRole required: discovery\\_admin or admin\n\n### About this task\n\n### Procedure\n\n1.  Navigate to **All** &gt; **Discovery** &gt; **Discovery Performance Metrics** &gt; **Probe/Sensor \\(Rollup-By-Status\\)**.\n\n2.  Sort the list by **Discovery status** to see the aggregated processing times for the probes and patterns that ran during a specific Discovery.\n\n    \\[Omitted image \"DiscoPerformanceStatusFilter.png\"\\] Alt text: Filtering the list of performance data aggregated by status\n\n3.  Filter by a specific status to display metrics available for probes and patterns that ran in that status.\n\n4.  Open a record to see the probe/pattern statistics for the selected status.\n\n    The form displays additional fields not visible on the list. Roll-ups are only created for a completed or cancelled status.\n\n5.  See the table of performance aggregation data for descriptions of additional metrics displayed on the form for roll-ups by status.\n\n\n## View Discovery performance metrics aggregated by IP address\n\nUse the roll-up by target data to ensure that the processing times for probes/patterns and sensors remain consistent for each Discovery of a specific IP address. All aggregated performance data is read-only.\n\n### Before you begin\n\nRole required: discovery\\_admin or admin\n\n### Procedure\n\n1.  Navigate to **All** &gt; **Discovery** &gt; **Discovery Performance Metrics** &gt; **Probe/Sensor \\(Rollup-By-Target\\)**.\n\n2.  Sort the list by **Target IP address**.\n\n    \\[Omitted image \"DiscoPerformanceTargetFilter.png\"\\] Alt text: Filtering the list of performance data aggregated by target IP address\n\n3.  Filter by a specific IP address to see the aggregated processing times for the probes and patterns that performed the Discovery of that IP address.\n\n4.  Open a record to see the statistics about the selected probe/pattern for the specific IP address.\n\n    The form displays additional fields not visible on the list. Roll-ups are performed after IP Discovery has completed successfully.\n\n5.  See the table of performance aggregation data for descriptions of additional metrics displayed on the form for roll-ups by target.\n\n\n## Aggregated data for Discovery performance metrics\n\nDiscovery performance metrics can accumulate data for probes, patterns, and sensors each time Discovery runs. Discovery calculates processing times and increments the number of times a component runs for each roll-up profile: status, target, or build. All aggregated performance data is read-only.\n\n### Sample roll-up form\n\nThis is an example of an aggregation record for probe and sensor metrics. The metrics fields shown here are used for each aggregation.\n\n\\[Omitted image \"PerfFrameworkStatusRollup.png\"\\] Alt text: Sample roll-up by Status form\n\n### Performance Framework aggregated data\n\nExcept where noted, these fields are common to all aggregation records.\n\n<table id=\"table_kxl_yd2_mfb\"><thead><tr><th>\n\nField label\n\n</th><th>\n\nField name\n\n</th><th>\n\nDescription\n\n</th></tr></thead><tbody><tr><td>\n\nBuild/version\n\n</td><td>\n\nbuild\\_version\n\n</td><td>\n\nName of the build running on the instance. This name identifies the version, patch level, and release date of the ServiceNow platform.\n\n</td></tr><tr><td>\n\nDiscovery status\n\n</td><td>\n\ndiscovery\\_status\n\n</td><td>\n\nID number of the Discovery status record for this aggregation. **Note:** This field only appears on the form for roll-ups by status.\n\n</td></tr><tr><td>\n\nTarget IP address\n\n</td><td>\n\ntarget\\_ip\\_address\n\n</td><td>\n\nIP address of the target for this Discovery.**Note:** This field only appears on the form for roll-ups by target.\n\n</td></tr><tr><td>\n\nAggregation cutoff\n\n</td><td>\n\naggregation\\_cutoff\n\n</td><td>\n\nThe cutoff time varies, depending on the roll-up profile. -   **By-build**: Occurs daily at 02:00, by default.\n-   **By-status**: Closing time of the last aggregation for that Discovery status, which might have run the last time **discovery.complete** or **discovery.cancelled** ran for that status.\n-   **By-target**: Closing time of the last aggregation for that target IP address, which might have run the last time **discovery.device.complete** ran for that IP address.\n\n</td></tr><tr><td>\n\nECC queue topic \\*\n\n</td><td>\n\necc\\_queue\\_topic\n\n</td><td>\n\nIdentifies the Java class in the MID Server that executes the probe.\n\n</td></tr><tr><td>\n\nECC queue name \\*\n\n</td><td>\n\necc\\_queue\\_name\n\n</td><td>\n\nIdentifies the probe/pattern evaluated for performance in this aggregation.\n\n</td></tr><tr><td>\n\nProbe \\*\n\n</td><td>\n\nprobe\n\n</td><td>\n\nName of the probe used for this Discovery.\n\n</td></tr><tr><td>\n\nProbe time \\(count\\)\n\n</td><td>\n\nprobe\\_time\\_count\n\n</td><td>\n\nNumber of times a probe ran for a given roll-up profile.\n\n</td></tr><tr><td>\n\nProbe time \\(average\\)\n\n</td><td>\n\nprobe\\_time\\_average\n\n</td><td>\n\nAverage time a probe took to gather data on the target and format the payload for a given roll-up profile.\n\n</td></tr><tr><td>\n\nProbe time \\(minimum\\)\n\n</td><td>\n\nprobe\\_time\\_min\n\n</td><td>\n\nMinimum time a probe took to gather data on the target and format the payload for a given roll-up profile.\n\n</td></tr><tr><td>\n\nProbe time \\(maximum\\)\n\n</td><td>\n\nprobe\\_time\\_max\n\n</td><td>\n\nMaximum time a probe took to gather data on the target and format the payload for a given roll-up profile.\n\n</td></tr><tr><td>\n\nProbe time \\(total\\)\n\n</td><td>\n\nprobe\\_time\\_total\n\n</td><td>\n\nTotal time used by a probe to gather data on the target and format the payload for a given roll-up profile.\n\n</td></tr><tr><td>\n\nSensor time \\(count\\)\n\n</td><td>\n\nsensor\\_time\\_count\n\n</td><td>\n\nNumber of times a sensor processed payloads for a given roll-up profile.\n\n</td></tr><tr><td>\n\nSensor time \\(average\\)\n\n</td><td>\n\nsensor\\_time\\_average\n\n</td><td>\n\nAverage time a sensor took to process payloads on the instance for a given roll-up profile.\n\n</td></tr><tr><td>\n\nSensor time \\(minimum\\)\n\n</td><td>\n\nsensor\\_time\\_min\n\n</td><td>\n\nMinimum time a sensor took to process a payload on the instance for a given roll-up profile.\n\n</td></tr><tr><td>\n\nSensor time \\(maximum\\)\n\n</td><td>\n\nsensor\\_time\\_max\n\n</td><td>\n\nMaximum time a sensor took to process a payload on the instance for a given roll-up profile.\n\n</td></tr><tr><td>\n\nSensor time \\(total\\)\n\n</td><td>\n\nsensor\\_time\\_total\n\n</td><td>\n\nTotal time used by a sensor to process payloads on the instance for a given roll-up profile.\n\n</td></tr><tr><td>\n\nIRE time \\(count\\)\n\n</td><td>\n\nire\\_time\\_count\n\n</td><td>\n\nNumber of times a pattern's payload was processed by the Identification and Reconciliation Engine \\(IRE\\) for a given roll-up profile.\n\n</td></tr><tr><td>\n\nIRE time \\(average\\)\n\n</td><td>\n\nire\\_time\\_average\n\n</td><td>\n\nAverage time used for IRE processing of a pattern's payload for a given roll-up profile.\n\n</td></tr><tr><td>\n\nIRE time \\(minimum\\)\n\n</td><td>\n\nire\\_time\\_min\n\n</td><td>\n\nMinimum time used for IRE processing of a pattern's payload for a given roll-up profile.\n\n</td></tr><tr><td>\n\nIRE time \\(maximum\\)\n\n</td><td>\n\nire\\_time\\_max\n\n</td><td>\n\nMaximum time used for IRE processing of a pattern's payload for a given roll-up profile.\n\n</td></tr><tr><td>\n\nIRE time \\(total\\)\n\n</td><td>\n\nire\\_time\\_total\n\n</td><td>\n\nTotal time used for IRE processing of a pattern's payload for a given roll-up profile.\n\n</td></tr></tbody>\n</table>\\* Together, these values uniquely identify a probe/sensor pair \\(a \"probe execution\"\\) that is used for a Discovery.\n\n"}}