Use > JMX Reference > Administration Methods > How to Access Support Using the JMX Console

How to Access Support Using the JMX Console

Universal CMDB provides Supportability JMX methods to help Micro Focus Support diagnose problems in your system. The methods use handlers for each category, which gather information relevant to that category from your system. When you run a handler for a category, it downloads a zip file of the information gathered for that category. Generally, Micro Focus Software Support runs the Supportability methods to help provide a solution for the issue raised.

How to access the Supportability methods

  1. On the UCMDB server, launch the Web browser and enter the following address: https://localhost:8443/jmx-console

    You may have to log in with a user name and password.

  2. Click UCMDB:service=Supportability Services to open the JMX MBEAN View page.

  3. The listSupportCategories method displays all the support categories:

    • To run all the handlers, invoke the runSupportHandlersForAllCategories method.

    • To run specific handlers, invoke the selectAndRunSupportHandlers method and select the handlers you want to run.

    • Alternatively, you can run specific handlers using the runSupportHandlersForSpecificCategories method. In the categories field, enter all the required handlers separated by commas, and click Invoke.

Supportability Handlers

The following handlers are available:

  • Basic.

    • Hardware. Records all the hardware information about the target physical or virtual machine in the Environment.properties file.
    • Basic Database. Records basic properties of the UCMDB connection with the database in the Basic Database.properties file.

    • Basic History. Records the last date that the baseline process ran for each CI type in the Basic History.properties file.

    • Model Update. Records the following data in the Basic Model Update.properties file:

      • Number of CIs per CI type (only for CIs with instances)

      • Number of CIs connected to a Node CI type or one of its descendants

    • URM Counters. Records each of the registered URM types and the number of instances of each one in the Basic URM Counters.properties file.

    • Changed Settings. Records the changed infrastructure settings and their values for this customer in the Changed_Settings_Customer <customerID>.properties file.

    • Integrations Audit. Shows a summary of all the existing integration points in the Integrations Audit.txt file.

    • Integrations Configuration. Shows detailed information of all the existing integration points in the Integrations Configuration.txt file.

    • LWSSO Settings. Stores the output of JMX methods retrieveConfiguration and retrieveConfigurationFromSettings to the LWSSO_Settings.properties file.

    • Memory and Thread Count Info. Records the UCMDB memory usage and thread count in the MemoryAndThreadInfo.html file. The information is displayed in color: green, orange, and red. If the color is not green, it requires attention.

      Note LDAP authentication can generate many idle threads. Until these threads are closed, it can temporarily lead to a high thread number which may cause performance issues.

    • Settings. Records the infrastructure settings and their values for this customer in the Settings Customer <customerID>.properties file.

    • Support Handlers. Shows the supportability handlers invoked and contained in the zip package generated by running the Basic handler in the Support Handlers.txt file. All the supportability handlers can be viewed by using the JMX method listSupportCategories.

    • SystemInfo. Stores the output of the JMX method viewSystemInformation in the SystemInfo .properties file, and shows basic information of UCMDB deployment, including version, probes, and database type.

  • TQL. Records the following data in the TQL.properties file:

    • Number of TQL queries

    • Number of active TQL queries

    • Number of active persistent TQL queries

    • Number of non-active TQL queries

    • It also creates the Failed TQLs.txt file, containing the list of failed active TQL queries

  • View. Records the following data in the VIEW.properties file:

    • Number of views

    • Number of views with a hierarchy definition

    • Number of views with a rule based hierarchy definition

    • Number of template based views

    • Number of perspective based views

    • Number of templates

    • Number of perspectives

    • Number of views of unknown type (this value should always be 0)

  • ViewArchive. Records the following data in the ViewArchive.properties file:

    • Total number of archives

    • Total number of views with archives

  • Snapshots. Records the following data in the Snapshots.properties file:

    • Total number of snapshots

  • Modeling. Records the following data in the Modeling.properties file:

    • Number of business CIs

    • Number of models with content (models containing CIs)

    • Number of pattern based models

    • Number of instance based models

  • Enrichment. Records the following data in the Enrichment.properties file:

    • Number of Enrichment rules

    • Number of all active Enrichment rules

    • Number of non-active Enrichment rules

    • Number of Enrichment business views

    • Number of all active Enrichment business views

    • Number of non-active Enrichment business views

  • High Availability. Gathers the High Availability information from all of the servers in the cluster:

    • The High Availability cluster information is recorded in HA.properties:

      • Is_ha_enabled
      • Cluster name (if high availability is enabled)

      • Cluster nodes number (if high availability is enabled)

      • Cluster nodes names (if high availability is enabled)

    • The values for the High Availability settings (starting with ha.) are recorded in HA settings.properties

  • Domains. Gathers IP range information and records in the DomainsConfiguration Customer <CustomerID>.xml file.
  • Integrations. Gathers integrations related information.

    • ApiAdapter.zip. Exports the UCMDB API adapter which allows defining Reconciliation Priority for API Data In flows.

    • CmdbHistoryAdapter.zip. Exports the UCMDB history adapter which is used to federate data from UCMDB's History.

  • Management Zones. Gathers rank, name, range definition, discovery activities, activity jobs, and scheduling information for management zones. Records this information in the MngZonesConfiguration Customer <CustomerID>.xml file.

  • Authorization. Records all the roles, users, user groups and role assignments in the Authorization.properties file. In a multi-tenancy environment, it records the tenant association of each role assignment.

  • History. Records the number of history events in the current history table for each CI type in the History.properties file (only for CI types with history events)

  • Class Model. Records the class model as an XML file, Class Model.xml. In a multi-customer environment, it records the number of different class models and their differences at the SDK level in the Class Model.properties file. (In a single-customer environment, this file contains only the information for the single customer.)

  • Reconciliation. Records data processing statistics read from the cmdb.reconciliation.log file. It records the data in Excel format, in the DiscoveryProcessingStatistics.xls file. Data that might require attention is highlighted in yellow and red. These thresholds are selected based on data collected for UCMDB version 10.xx medium and large deployments.

    The following Excel sheets are created:

    • dailyRates. Records daily statistics. The following items are explained:

      • Total Model time. Time needed to insert, update, or delete CIs to DB. A higher value might show a DB slowness and require DBA involvement.

      • Total Identify time. Time required in building TQL queries, calculating TQL queries, matching between bulk and what was brought with TQL queries from the UCMDB server.

      • Total DataIN time. Time required for merge operations and recursive merge operations.

      • Daily Usage(% from 24h). Amount of time in a day the server is busy with data in processing. If this field is highlighted in yellow or red, the server might be overloaded or there is a performance slowness.

    • Jobs Throughput Rates Detailed. Data recorded per discovery/integration job from the time the data is analysed. (First timestamp recorded in the logs.)

    • dailyRatesPerJob. Data recorded per discovery/integration job from the time the data is analyzed but breakdown per day.

    • dailyRatesPerDataSource. Data recorded per source type and display by day.

    • FailedBulksInfo. Number of bulks that failed to be recorded by the discovery job. It shows the number of bulks that failed and the time spent. At the end a summary is made for all failed bulks.

    • RemoveByIDStats. Records data for the CIs that are marked by the probe as candidates for deletion or CIs to be deleted.

    • dailyRatesPerProbe. Records data per day for each probe that reports data. Also it fetches all data that are not created through probe as 'Not through Probe'.

    • Jobs Throughput Rates Per Probe. Records data reported by every probe from the time the data is analyzed. (First timestamp recorded in the logs.)

    • General Info. Shows the timeframe analyzed and recorded in the Excel file. Also records time spent for successful and failed processed bulks . Number of data in bulks ignored from log file shows the number of bulks that were ignored. Possible reasons are that data was not properly read or that the reconciliation bulk was not logged properly in the log (every bulk must have two lines: entry line and summary line logged in consecutive rows in the log file).

    Note  

    • The data is read from the cmdb.reconciliation.log file based on regex. If the log4j layout is changed for the cmdb.reconciliation.log file, the data cannot be parsed.
    • A job might show a performance degradation if the total time is higher than 600 seconds.

  • Data In. Records actual deletion period and deletion candidate period information of the root CI type that was overwritten by the settings for child CI types in the Data In.properties file. It also checks for inconsistency in the database (objects or links that exist in the root CIT's table but not in the subtype’s table or the other way around). The inconsistent objects are recorded in the inconsistencyInModel.txt file and the inconsistent links are recorded in the inconsistencyLinks.txt file.