Error: Log management component is experiencing issues and logs are getting dropped - VCF Operations 9.1
search cancel

Error: Log management component is experiencing issues and logs are getting dropped - VCF Operations 9.1

book

Article ID: 451758

calendar_today

Updated On:

Products

VCF Operations

Issue/Introduction

VCF Operations 9.1 displays a critical alert banner regarding log management ingestion issues, even when the Log Management dashboard shows zero dropped log events.

  • A yellow banner in the UI states: Log management component is experiencing issues and logs are getting dropped.
  • Active alert: Log management ingestion issue detected.
  • The Log Management dashboard shows 0 dropped log events, short pipeline times, and zero queue lengths.

Environment

VCF Operations 9.1

VCF Log management 9.1

Cause

The alert is triggered by the metric: Ingestion -> Avg Write Response Time (ms) exceeding its Dynamic Threshold (DT) value. If the calculated DT upper limit is too close to the actual baseline (e.g., DT at 74ms while baseline is 70-80ms), normal ingestion spikes trigger false positive alerts.

Resolution

To resolve this issue, recalculate the Dynamic Thresholds to allow the system to establish a more accurate baseline.

  1. Log in to VCF Operations.
  2. Navigate to Operate > Administration > Control Panel.
  3. Click the Dynamic Thresholds tile to trigger a recalculation.
Note: It may take several hours for the metric to show corrected values and for the alert to clear as the dynamic threshold is calculated outside normal business hours.
If required, In the VCF Operations Operate -> Administration -> Global Settings -> System Settings menu, reset the time that Dynamic Threshold to be calculated to normal business hours.

Temporary workaround:

Disable the noisy symptom via custom Policy

  • Symptom 22120 ("Average Response Time Above Dynamic Threshold") ships disabled by default in the base policy — it must have been explicitly turned on in whatever custom Policy is applied to this environment. If it's producing pure noise with no real ingestion impact, the customer can go back into that PolicyAlert/Symptom Definitions and override it back to disabled. This fully stops the alert at the source without waiting on us.

Override severity in the custom Policy

  • Symptom 22120 is hardcoded severity="critical" in content, and the alert's state is severity="automatic" (inherits from whichever symptom fired). Policies in Ops can override a symptom/alert's severity without touching content — e.g. downgrade this specific symptom from Critical to Info/Warning, doing so stops it from surfacing as a top red banner while still being visible if they want it.

Additional Information