Probe to Pattern Migration: Procedure for switching from probe-based Discovery to pattern-based Discovery - Support and Troubleshooting

Probe to Pattern Migration: Procedure for switching from probe-based Discovery to pattern-based Discovery Issue  This probe to pattern migration process is supported only for customers running on New York release or later and currently using probes for Discovery.

Table of Contents Overview What these scripts do Prerequisites Procedure Known Issues FAQs

Overview Horizontal Discovery patterns have become the standard for discovering Configuration Items (CIs). Patterns provide a simpler and more intuitive way to debug and troubleshoot discovery compared with legacy probes and sensors.

Probe-based discovery and pattern-based discovery use different mechanisms of saving data in the CMDB. Using both discovery methods together may result in duplicate data in the CMDB. In addition, pattern-based discovery relies on relationships, while the legacy probe-based discovery uses references.

For detailed information about the difference between probe-based and pattern-based horizontal discovery, refer to the product documentation Using Patterns For Horizontal Discovery .

This process is only intended for instances running on New York release or later. There is a high risk of invalid and/or duplicate data if trying to run this migration on releases prior to New York.

What these scripts do These migration scripts will do the following:

Add the appropriate relationships needed for pattern Discovery to continue to identify the current CIs that are being discovered via probes. Update certain relationships that may have different relationship types or have different parent/child values. Update the appropriate Discovery Classification records ( discovery_classy ) to convert the Triggers probes records ( discovery_classifier_probe ) to use pattern-related probes. Prerequisites Starting in the Orlando release, there is a Script Include called ProbeToPatternPrerequisiteScript that can be used to run most of these checks prior to starting the migration. For more information on this script, and for those on New York who wish to import this Script Include to use on their instances, please refer to KB0750351 .

Should be on New York release or later and currently using probes for OS Discovery. Should deactivate all Discovery and Service Mapping jobs as well as any Import jobs that may affect CMDB data during migration. Needs to have the Horizontal Pattern probe record in the discovery_probes table, similar to the following screenshot.

Should have the following out-of-box relationship type records ( cmdb_rel_type ) existing on their instance. Runs on::Runs ( sys_id: 60bc4e22c0a8010e01f074cbe6bd73c3 ) Owns::Owned by ( sys_id: 25242fb2377a9200738d021a54990e88 ) Contains::Contained by ( sys_id: 55c95bf6c0a8010e0118ec7056ebc54d ) Uses::Used by ( sys_id: cb5592603751200032ff8c00dfbe5d17 ) Defines resources for::Gets resources from ( sys_id: de5aeb6a0ab3015854626f204fb7b1c0 ) Virtualized by::Virtualizes ( sys_id: d93304fb0a0a0b78006081a72ef08444 ) Provides::Provided by ( sys_id: f67e9ecdff602000dada361332f49d35 ) Provided By::Provides ( sys_id: 4afd799338a02000c18673032c71b817 ) Members::Member of ( sys_id: 55c913d3c0a8010e012d1563182d6050 ) Registered on::Has registered ( sys_id: aa9434870ab301544ce2943bf03fd7a8 ) NOTE: If any of these records no longer exist or if they exist but with a different sys_id value (i.e. if the record is custom created), see the FAQ section below for how this can be addressed. Should have the following classifier records with these exact names. Windows Windows 2000 Server Windows 2003 Server Windows 2008 Server Windows 2012 Server Windows 2016 Server Windows NT Server Windows Hyper-V Server Unix Linux Solaris HP-UX AIX SNMP Standard Network Router Standard Network Switch F5 BIG-IP Load Balancer A10 Load Balancer Alteon Load Balancer ACE Load Balancer Netscaler Load Balancer Radware - AppDirector - Load Balancer Processes (Starting in Orlando) Apache Server JBoss Server Weblogic Server MySQL Server Microsoft SQL Server Tomcat Microsoft IIS Server PostgreSQL Instance Oracle Instance NOTE: If any of these records no longer exist or if the name has been changed on these records, see the FAQ section below for how this can be addressed. For any of the classifiers mentioned in step 4, check the Triggers probes list. There should be an existing record to run the Horizontal Pattern that should be set as active = false , similar to the screenshot below.

If any or all of the classifiers do not have records like the above in the Triggers probes list, the fix scripts can create those as necessary. However, we will need to verify that the instance has the following pattern records ( sa_pattern ) to be able to link to based on the name.

Windows Windows OS - Servers Windows OS - Desktops Hyper-V Server Unix Linux Server (see example below) Solaris Server HP-UX Server AIX Server SNMP Network Router Network Switch F5 Load Balancer A10 Load Balancer Alteon Load Balancer ACE Load Balancer by SSH Netscaler Load Balancer AppDirector Load Balancer Processes (Starting in Orlando) Apache On Windows Apache on UNIX based OS Jboss WebLogic My SQL server On Windows and Linux MSSql DB On Windows Tomcat IIS PostgreSQL DB Oracle DB On Windows Oracle DB On Unix

NOTE: If any of these patterns records no longer exist or if the name has been changed on these records, see the FAQ section below for how this can be addressed.

Procedure NOTE: Starting in Orlando, there is now a UI Page to be able to execute this migration process. Please refer to KB0781470 for more details. Below procedure is only applicable for customers on New York release.

There are two possible ways to use these conversion scripts. Please choose the option that is most appropriate based on the size of your CMDB.

NOTE: This probe to pattern migration process is only meant to run one time and only in one direction. We do not support reverting back to using probes, as this will likely cause data issues in the CMDB if this is done.

The preferred approach is to run the individual conversion scripts below one at a time. For example, if starting with the Windows script, follow the process below. Navigate to System Definition -> Scheduled Jobs In the Scheduled Jobs table, click New and select the option Automatically run a script of your choosing. Put these values below for this script: Name = Migrate Probe to Pattern Windows Active = True Run = Once Starting = [Choose the date/time you want to run this script] Conditional = False Run this script = var fix = new FixWindowsModelForPatterns(); fix.addMissingRelationsForWindows();

Click Submit and then wait for this script to run at the Starting time that was provided. Once this is completed, repeat this process for the other CI types below. Unix: Name = Migrate Probe to Pattern Unix Run this script =

var fix = new FixUnixFamilyModelForPatterns(); fix.addMissingRelationsForUnix();

Routers & Switches: Name = Migrate Probe to Pattern Network Run this script =

var fix = new FixSwitchAndRouterModelForPatterns(); fix.addMissingRelationsForSwitchesAndRouters();

Load Balancers: Name = Migrate Probe to Pattern Load Balancers Run this script =

var fix = new FixPatternLoadBalancersModel(); fix.addMissingRelationsForLoadBalancers();

To run the conversion process on all the classifiers in one step, follow this process. NOTE: This is only recommended for smaller CMDBs

Navigate to System Definition -> Scheduled Jobs . In the Scheduled Jobs table, click New and select the option Automatically run a script of your choosing. Put these values below for this script: Name = Migrate Probe to Pattern Full Active = True Run = Once Starting = [Choose the date/time you want to run this script] Conditional = False Run this script = FixMissingRelationsFromProbesToPatterns.moveProbesToPatterns();

Click Submit and then wait for this script to run at the Starting time that was provided. NOTE: These scripts could also be run in Scripts-Background, although this is only recommended for smaller CMDBs.

Known Issues *** There is a known issue with Duplicate Storage Devices that can occur during Windows migration. Please refer to KB0748332 (login needed) for more details. ***

*** "glide.discovery.ip_based.active" not updated during migration as expected, PRB1368993. If so, manually update the property value to false.

*** OS Packages migration is supported in Orlando Patch 7 and Paris Patch 1 onwards. Please refer to KB0827777 (login needed) for more details. ***

*** There are also some additional known differences between probes and patterns not handled by the migration. See KB0827212 for more details. ***

FAQs 1) What if we are using custom probes in the classifiers? How should these be handled? The migration process is intended to set up the instance to use patterns as if we are enabling Discovery for the first time.

By default, any custom probes that may have been added to a classifier that we are migrating will be made active = false . This is to help prevent any potential issues that may arise with data being discovered by these custom probes interfering with new data being discovered by patterns.

These custom probes can always be re-activated by navigating to the respective classifier and set the Triggers probe record back to active = true .

2) What if we do not have some of the default relationship type records as mentioned from the Prerequisites list? In the Script Include FixPatternsModelBasic , this is where these relationships are defined as such.

If any of these relationships are missing, we need to reinsert the default versions of these records. This can be done by seeing if the missing records are existing in the deleted records table ( sys_audit_delete ) and then restore the deleted records or if possible you may need to request from Technical Support to import the missing records from an out-of-box instance.

If any of these relationships are existing, but instead have a different sys_id value, the recommendation is to restore the default version of the relationship if possible and remove the custom version. This may also include having to update any existing relationship records ( cmdb_rel_ci ) that may be using this custom relationship type to instead use the default value.

However, if this is not possible, then this FixPatternsModelBasic script will need to be manually updated to replace the default value with the custom value that is being used. For example, if you have a record for the relationship Runs on::Runs , but with a different sys_id ( ex. 517ab95338a02000c18673032c71b904 ), then you will need to replace the appropriate variable value to reference this new sys_id value like below.

this.RUNS_ON = "517ab95338a02000c18673032c71b904";

3) What if we do not have specific classifier records or pattern records with the names as mentioned from the Prerequisites list (ex. Instead of Windows 2008 Server , we are using a custom classifier called Windows 2008 Custom )? In the individual "Fix" Script Includes (ex. FixWindowsModelForPatterns , FixUnixFamilyModelForPatterns , etc.), the migration process converts the classifiers from probes to patterns using function calls like this below.

migrate.enablePattern('windows', 'Windows 2008 Server', 'Windows OS - Servers');

This function call passes three parameters:

The first parameter helps to identify which discovery_classy table we are targeting against (ex. discovery_classy_windows ). The second parameter tells us which classifier record we are targeting against (ex. Windows 2008 Server ). The third parameter tells us which pattern we should use if we need to crate a new discovery_classifier_probe record to trigger the pattern (ex. Windows OS - Servers ). If there is a different classifier record that needs to be updated or if the pattern has a different name, then this function call can be modified to pass in the appropriate values. For instance, if in this example mentioned above we need to use Windows 2008 Custom instead of Windows 2008 Server , you can make the following change:

migrate.enablePattern('windows', 'Windows 2008 Custom', 'Windows OS - Servers');

Or, if the pattern that is being used is also different then you can change to something like this:

migrate.enablePattern('windows', 'Windows 2008 Custom', 'Windows OS - Custom');

This should only be done if you are using customized classifiers or patterns and are not using, or no longer have the out-of-the-box classifiers or patterns.

4) Are there any System Properties affected by this change? There is a System property named glide.discovery.ip_based.active that will get set to a value of false when these migration scripts are run. This property is mainly a reference that Discovery is now using patterns instead of probes.

5) What should be done if there is an error that occurs during the migration process? What logs should be collected? When running the migration scripts, most of the details about what is happening during this process will get logged in the syslog table and will have a Source value of DiscoveryMigrateToPatterns . See example screenshot below.

Starting in Orlando, there is also a new log table ( probe_to_pattern_log ) where this log information will be stored as well. Please refer to KB0781470 for more details.

Investigating these log details, along with looking into other typical node logs, can be helpful to see when and where any issues may occur.

If further assistance is needed, you can open a case with Technical Support to investigate accordingly.