Best practices and do's and don't regarding TSCO Gateway Manager AutoETL runs

Version 1
    Share This:

    This document contains official content from the BMC Software Knowledge Base. It is automatically updated when the knowledge article is modified.


    PRODUCT:

    TrueSight Capacity Optimization


    APPLIES TO:

    TrueSight Capacity Optimization 11.0, 10.7, 10.5



    QUESTION:

    What are some best practices and do's and don't regarding the TSCO Gateway Manager AutoETL Manager runs?


    ANSWER:

     

    Gateway Manager

    (1) When you create a TSCO Gateway Manager run it will not ask you for any parameters related to that Manager run (it will only ask for information regarding the AutoNodeDiscovery feature of the run).  All of the configuration parameters for the run will come from the 'Default' Manager run configuration. 

    So, it is critical that before a TSCO Gateway Manager run is submitted (via Gateway Manager -> Gateway Server -> Open the Gateway Server where the run will be scheduled -> Add button) that the default Manager run properties (Gateway Manager -> Gateway Operations -> Create New Run) be set to the values appropriate for the run being scheduled. 

    Note that most parameters associated with the Manager run can be changed via Gateway Manager -> View Scheduled Runs -> Click on the master run name, but the parameter changes will take one day to be picked up by the Manager run.  Also, some changes (such as the Collect -> Summarize Data option) will take even longer to take effect since the pre-registered 'Days in Advance' collection requests will have been registered with the old parameter (and those requests won't be updated after the change).  So data collection side parameter changes can take up to 4 days to take effect. 

    (2) Manager runs should not be scheduled directly under Gateway Manager -> Gateway Operations -> Create New Run.  That is the only way to schedule Manager runs and does not create an AutoNodeDiscovery or Multiple-Manager-Run AutoNodeDiscovery run. 

    (3) When possible, it is best to schedule one large Multiple-Manager-Run AutoNodeDiscovery run (one large computer list) and then let it split that list into multiple Manager runs and multiple domain files associated with the Manager runs.  

    AutoETL

    (1) NEVER manually modify the ETL Run Configuration -> Vis file parser configuration -> Manager run list for an AutoETL managed Gateway Server VIS parser ETL.  The 'Manager run list' specified there must be perfectly in-sync with the BCOEE_AUTOETL_RUNS table and manual modifications will ruin this synchronization (and make the AutoETL runs behave unexpectedly). 

    (2) Engage Technical Support if you need to change the list of ETL Engine Servers that should be used for AutoETL runs.  The existing chains generally shouldn't just be moved from the existing ETL Engine Server to a different one (since the Scheduler ID is part of the chain name). 

    (3) Note that, by default, TSCO Gateway Server AutoETL chains are created with the option to run 2 ETLs "per available core" concurrently.  That can be too aggressive when multiple Gateway Servers are configured to load balance across the same sets of ETL Engines (for example, 4 Gateway Servers balanced across 4 ETL Engines each with 2 cores will result in 8 ETLs running concurrently on each ETL Engine Server.  The ETL Chain Parallelism can be manually changed for TSCO Gateway Server AutoETL chains as necessary. 

    (4) NEVER manually delete AutoETL created Gateway Server ETLs even if the 'Manager run list' is specified as '##EMPTY##' and the runs are ending in yellow warning state each night.  When deleting excess ETLs the BCOEE_AUTOETL_RUNS table must also be updated to know that the ETLs have been removed (or it may attempt to associate future Manager runs with an ETL that no longer exists). 

      

     


    Article Number:

    000150451


    Article Type:

    FAQ/Procedural



      Looking for additional information?    Search BMC Support  or  Browse Knowledge Articles