Configuration aware reporting Troubleshooting

The objective of page is to provide an overview of troubleshooting techniques for configuration-aware reporting.

Architecture

Troubleshooting

How can I make sure the set of data from a data provider is complete in LQE/LDX
Validation!!!!
The TRS feed is essentially the contract between the data provider and the data consumer.
A data provider’s TRS defines the set of data that should be indexed by a consumer (LQE/LDX).

• Data provider validation operation checks the TRS is accurate to the Data provider's representation.
• Data consumer validation checks that the consumer (LQE/LDX) index (datasources) has the same set of Data.

• Does not check the content of resources <elaborate?>
  • Global configurations can contain other global or local configurations
  • Local configurations have selection resources that define the set of versioned artifacts that are a part of the baseline or stream

What can happen from the Data Provider (TRS)?

• Data Provider server or Network path temporarily down
  • LQE/LDX app logs issue fetching TRS and will retry at next interval

• TRS change log truncation - last read change log event not present in TRS
  • LQE/LDX cannot proceed safely with indexing as there could be missing events – must reindex

• a defect during change log maintenance
• a data provider or LQE outage longer than 7 days
  • why do I need to mention the 606 IFix003 improvement? 6.0.6 ifix003 – Increase resiliency of overall system by increasing change log event retention period to 14 days for the n-1 version of the TRS base document or 28 days from the current version
• TRS content prior to LQE/LDX's last known event is modified
  • LQE (7.0) will review one interval prior’s set of change events to see if there are any discrepancies. If there are, it will log the discrepancies and attempt to process the events.
• TRS provides patches that are invalid
  • Before state (eTag) does not match what is in LQE/LDX
  • LQE (7.0) will refetch the resource at a later interval to recover * TRS content is not accurate compared to the data provider’s repository * Action required is a data provider TRS validation. for example, RM TRS validation.

• LQE/LDX server or Network path temporarily down
  • LQE/LDX resumes indexing from last known event per data provider at the next interval

• Content of the LQE/LDX does not match what is supplied in TRS

• Compares the set of resources in the index with the TRS
• Utilized eTags for comparisons
  • EWM TaP TRS contains eTags for all artifacts
  • Configurations modified with patch events in the changelog contain eTags (Global Config Management, RM, ETM) (RMM, SCM Future)

• Server or network temporarily down (transient)
  • LQE/LDX captures resources it is unable to fetch during the interval into the Skipped Resources list
  • Administrators can manually retry the entire skip list for recovery
  • LQE/LDX auto retries for skipped resources (*needs to be enabled by LQE or LDX Admin)
• Application fails to return the artifact
  • Check Skipped Resource Diagnostic page from Data Provider
  • data provider complimentary diagnostics coordinated with skipped resource list what does this mean
  • Manage skipped resources
    • Ignore skipped resources
    • remove from TRS feed
    • provide comments for ignoring skipped resources did we implement this?

• Identify the data provider (ELM application) that owns the missing data
• Ensure validation has been run at the data provider level - this operation compares the data provider TRS to the actual data in the repository
• Validation results that show repairs can provide data provider developers an idea of where to look for issues.
• Repairs done by the validation operation may fix the issue but best practice is to run a corresponding LQE/LDX validation for that data provider.
  

Report Builder - Data Completeness Checker

• Focus on a single global or local configuration to determine if everything that is referenced by the configuration is available to be considered by the report
  • Unable to determine if the query itself would have included it or filtered it out (if a requirement is skipped, or missing it can’t know what are the properties/relationships of that requirement)
  • Reduces the scope of what it reports to only those referenced by the configuration selected. Does not focus on all skipped resources.
  • looks for resources that the configuration is looking for but aren’t included in the TRS itself
• Running it once for that configuration is enough to know the status of what may be missing which could affect any reports run against that same configuration
• Do nott need to run it for every report
• Slows down reports by up to 20%, which is why it should be only run on demand, not enabled across the entire system.

• Inspect the URL. Based on the URL, are these artifacts involved in the report at all? If not, you can ignore them
• If the artifacts are involved in the report, retry the skipped resource from LQE and observe if it can now be retrieved.
• If not, report the issue against the ELM application providing the data

• This represents artifacts that were never found in the TRS from the data provider.
• If a data provider validation does not properly fix the TRS to include this artifact, report the issue against the data provider
• If it is in the TRS from the data provider, then run LQE/LDX validation against the datasource from the data provider

• Go to the LQE admin view for the datasource
• Go to the Invalid update/patch tab and attempt to repair it there
• Work with the data provider to see if there is a way to repair the selection resource for that configuration (L3 TRS Selections Validation/Repair Tool tool for RM)

• RM L3 TRS Selections Validation/Repair Tool (trsSelections.jar)
• ETM - force refetch of selections via ETM TRS console

LQE Query Execution details

Heading 1

Related topics: Deployment web home, Deployment web home

External links:

• IBM