Discovery Help !!

[SandeepKSingh]

I have noticed that Discovery is slow and timing out when parsing process tables with thousands of rows.
How can you optimize your Discovery Pattern?

[Ravi Gaurav · Accepted solution]

Hi @SandeepKSingh 

• Use Parse Table with filters/conditions (e.g., only processes with java as an Example keyword).

• Use Shared Library scripts to parse efficiently.

• Break large patterns into smaller sub-patterns.

[Ravi Gaurav · Accepted solution]

Check this one out here .. this is from one of the community member recently asked a Interview question

Scenario

While running Discovery, you observe that process tables on servers (Linux/Windows) have thousands of rows.

• Pattern takes a long time to parse them.

• Sometimes the step even times out and discovery fails.

 Answer Options (with Detailed Elaboration)

1. Use Parse Table with Filters/Conditions

• Why: By default, a Parse Table tries to parse all rows, which is expensive when there are thousands of processes.

• Fix:

  • Add conditions inside the Parse Table step (e.g., command contains java or process_name = 'oracle').

  • This reduces parsing to only relevant rows → speeds up pattern execution.

• Example:
  Instead of parsing 10,000 processes, filter for only those with "java" keyword to discover JVMs.

 Impact → Lower ECC payload, faster parsing, fewer DB inserts.

 

2. Use Shared Library Scripts to Parse Efficiently

• Why: Sometimes complex regex parsing in a Pattern step slows things down.

• Fix:

  • Move heavy parsing logic into a Shared Library (Script Include).

  • Call it from the Pattern → cleaner code and reusable across multiple patterns.

• Example:
  Write a shared function like parseJavaProcess(output) that extracts only the required columns.

• Benefit: Faster execution, less duplicate parsing logic, easier to maintain.

 Impact → Optimized parsing, reusable code, consistent results.

 

3. Break Large Patterns into Smaller Sub-Patterns

• Why: A single monolithic pattern parsing too much data can timeout.

• Fix:

  • Split the pattern into modular sub-patterns (e.g., one for OS, one for DB, one for middleware).

  • Use relationships to link them in CMDB.

• Example:
  Instead of parsing all processes + services + ports in one shot, split them into:

  • Pattern A → discovers server + OS info.

  • Pattern B → discovers running databases.

  • Pattern C → discovers application processes.

 Impact → Less load per discovery run, better debugging, parallel execution.

[Ravi Gaurav · Accepted solution]

• Limit data collection at probe level → e.g., use tasklist /fi "imagename eq java.exe" instead of fetching all processes.

• Tune Timeouts in MID Server for process-heavy steps.

• Avoid storing unnecessary attributes (don’t map everything from process table).

• Run targeted discovery schedules (don’t run all patterns on all servers).

[Ravi Gaurav · Accepted solution]

Hi @SandeepKSingh 

• Use Parse Table with filters/conditions (e.g., only processes with java as an Example keyword).

• Use Shared Library scripts to parse efficiently.

• Break large patterns into smaller sub-patterns.

[Ravi Gaurav · Accepted solution]

Check this one out here .. this is from one of the community member recently asked a Interview question

Scenario

While running Discovery, you observe that process tables on servers (Linux/Windows) have thousands of rows.

• Pattern takes a long time to parse them.

• Sometimes the step even times out and discovery fails.

 Answer Options (with Detailed Elaboration)

1. Use Parse Table with Filters/Conditions

• Why: By default, a Parse Table tries to parse all rows, which is expensive when there are thousands of processes.

• Fix:

  • Add conditions inside the Parse Table step (e.g., command contains java or process_name = 'oracle').

  • This reduces parsing to only relevant rows → speeds up pattern execution.

• Example:
  Instead of parsing 10,000 processes, filter for only those with "java" keyword to discover JVMs.

 Impact → Lower ECC payload, faster parsing, fewer DB inserts.

 

2. Use Shared Library Scripts to Parse Efficiently

• Why: Sometimes complex regex parsing in a Pattern step slows things down.

• Fix:

  • Move heavy parsing logic into a Shared Library (Script Include).

  • Call it from the Pattern → cleaner code and reusable across multiple patterns.

• Example:
  Write a shared function like parseJavaProcess(output) that extracts only the required columns.

• Benefit: Faster execution, less duplicate parsing logic, easier to maintain.

 Impact → Optimized parsing, reusable code, consistent results.

 

3. Break Large Patterns into Smaller Sub-Patterns

• Why: A single monolithic pattern parsing too much data can timeout.

• Fix:

  • Split the pattern into modular sub-patterns (e.g., one for OS, one for DB, one for middleware).

  • Use relationships to link them in CMDB.

• Example:
  Instead of parsing all processes + services + ports in one shot, split them into:

  • Pattern A → discovers server + OS info.

  • Pattern B → discovers running databases.

  • Pattern C → discovers application processes.

 Impact → Less load per discovery run, better debugging, parallel execution.

[Ravi Gaurav · Accepted solution]

• Limit data collection at probe level → e.g., use tasklist /fi "imagename eq java.exe" instead of fetching all processes.

• Tune Timeouts in MID Server for process-heavy steps.

• Avoid storing unnecessary attributes (don’t map everything from process table).

• Run targeted discovery schedules (don’t run all patterns on all servers).

[Bhuvan · Accepted solution]

@SandeepKSingh 

Refer below links for best practices and optimization

https://www.servicenow.com/docs/bundle/zurich-it-operations-management/page/product/service-mapping/...

https://www.servicenow.com/community/itom-blog/discovery-best-better-practices/ba-p/2272262

If this helped to answer your query, please mark it helpful & accept the solution.

Thanks,

Bhuvan