Overwriting the Diagnostics Configuration
Article ID: 369791
Updated On:
Products
Issue/Introduction
By using a JSON solution config file, you can manage some parameters of VCF Diagnostics, such as deactivating rules or setting defaults for some tasks, depending on your environment. You can create such a file by navigating to Operations > Configurations > Management Packs Configuration > Add:
File Name: diagnostics_mp_config_overwrites.json
Free format: yes
Content example:
{
"disabledRuleIds": ["RULE_ID"]
}
You take the RULE_ID parameter from the list of Diagnostics rules in the Findings Catalog on the Diagnostic Findings tab on VCF Operations. You can add multiple parameters, separated by a comma.
Environment
VCF Operations
Resolution
The two most common cases when you would need a JSON solution config file to overwrite the Diagnostics configuration are the following:
- Consider sizing limits for your environment:
Best practice is to segregate workloads to optimize performance and computation time of VCF Diagnostics. This means dividing an environment by some logical grouping, such as by geography or business function for example, to avoid excessive use of resources for the Diagnostics collector if you use the whole stack. Part of this strategy is the ability to manage the limit of the number of objects that are part of such workloads and setting up a cloud proxy for each workload. You see an alert for the threshold of the max object count that you must consider when segregating workloads, which gives you a decision point whether to segregate workloads or increase the limit if this makes sense for your setup.
Example:
{
"disabledRuleIds":
[
["RULE_ID"]
],
"maxObjectsCount": 1000000
}
- Deactivate a Diagnostics finding from being calculated:
In the rare case that a Diagnostic finding doesn’t produce adequate or wrong output, you can deactivate the Diagnostic rule.
Example:
Contents example:
{
"disabledRuleIds": ["NSXT_TrimmedException_KB_92309", “AUTOMATION_datarecordsleak_KB_93133”]
}
See the full list of possible parameters fields with example values:
{
"disabledRuleIds": ["AUTOMATION_datarecordsleak_KB_93133"],
"maxObjectsCount": 1000000,
"parallelRuleExecutionCount": 10,
"findingsLimitForRule": 500,
"queryTimeoutInMins": 3,
"activeScanDurationInHrs": 24,
"historicalScanMaxDurationInDays": 7,
"activeScanRetentionInHrs": 36,
"historicalScanRetentionInHrs": 96,
"workloadProvisioningRetentionInHrs": 168,
"snapshotProvisioningRetentionInHrs": 168
}
The set parameters take effect in Diagnostics findings calculations in up to 4 hours. DisabledRuleIds and maxObjectsCount are the only setting we recommend making without involving Broadcom Support. The other settings we've introduced them to ease configuration in certain situations with no code change.
disabledRuleIds - Ids of disabled rules.
All other settings are related to manual (on demand) scans and do not apply to normal rule evaluation. These scans are triggered by the user and result in asynchronous tasks being executed on every Diagnostics adapter in the environment.
parallelRuleExecutionCount - Applies to manual log scans. In cases where there are multiple cloud proxies, the scan task is executed in parallel on all of them. This setting limits the number of parallel log scans.
logScanTimeoutMinutes - Applies to manual log scans. Defines a timeout for log scan tasks in minutes.
findingsLimitForRule - Applies to manual logs scans. For every log rule we execute an LogInsights log query. This setting will limit the number of results LI can return, which directly limits the total number of findings that can be produced.
queryTimeoutInMins - Applies to manual logs scans. Limit for the time a single LI query can run in minutes.
activeScanDurationInHrs - The period for active findings scan. How far back to look for log messages.
historicalScanMaxDurationInDays - A limit for the period for historical findings scan. How far back to look for log messages.
activeScanRetentionInHrs - Defines the period for which active findings are retained.
historicalScanRetentionInHrs - Defines the period for which historical findings are retained.
workloadProvisioningRetentionInHrs - Defines the period for which workload provisioning findings are retained.
snapshotProvisioningRetentionInHrs - Defines the period for which snapshot provisioning findings are retained.
troubleshootResultRetentionInHrs = Defines the period for which troubleshooting results are retained.
sleepTimePostScanInMillis - Defines a period between producing the findings and reporting a scan as complete. Effectively we're giving some time for all the internal cashes to get updated with the new information, before we tell the user a scan is ready.
Additional Information
Feedback
