Notifications

3268 views

Issue

*****NOTE: 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
Description
What these scripts do
Prerequisites
Procedure
Known Issues
FAQs

 

 

 

Description


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.

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:

  1. Add the appropriate relationships needed for pattern Discovery to continue to identify the current CIs that are being discovered via probes.
  2. Update certain relationships that may have different relationship types or have different parent/child values.
  3. 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 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.

1. Should be on New York release or later and currently using probes for OS Discovery.

2. Should deactivate all Discovery and Service Mapping jobs as well as any Import jobs that may affect CMDB data during migration.

3. Need to have the Horizontal Pattern probe record in the discovery_probes table, similar to the screenshot below.

 

 

4. 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.

5. 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

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.

6. 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 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

 

 

NOTE: If any of these pattern 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


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.

  1. 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.
    1. Navigate to System Definition -> Scheduled Jobs
    2. In the Scheduled Jobs table, click New and select the option Automatically run a script of your choosing.
    3. Put these values below for this script:
      1. Name = Migrate Probe to Pattern Windows
      2. Active = True
      3. Run = Once
      4. Starting = [Choose the date/time you want to run this script]
      5. Conditional = False
      6. Run this script =

        var fix = new FixWindowsModelForPatterns();
        fix.addMissingRelationsForWindows();

    4. Click Submit and then wait for this script to run at the Starting time that was provided.
    5. 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();

  2. To run the conversion process on all the classifiers in one step, follow this process.

    NOTE: This is only recommended for smaller CMDBs

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

        FixMissingRelationsFromProbesToPatterns.moveProbesToPatterns();

    4. 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 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 the 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) 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.

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.

Article Information

Last Updated:2019-08-02 21:08:21
Published:2019-07-02