# Observation Period

The observationPeriod setting in yCrash helps prevent false positive incidents caused by brief CPU or memory spikes. When this setting is enabled, yCrash monitors metric breaches over a defined time period. If the spike continues beyond this set time, only then will yCrash capture 360° artifacts and generate an incident in the dashboard. This ensures that short-term fluctuations don’t trigger unnecessary alerts, providing a more accurate picture of ongoing performance issues.

Note:

The observationPeriod setting only affects CPU and Memory thresholds. It does not influence other thresholds, such as garbage collection pause time, disk usage, or thread count. Those metrics will trigger alerts based solely on their configured threshold values, regardless of the observation period setting.

By default, the observation period is 6 minutes. You can modify the value based on your requirements by following the steps below:

# How to set the Observation Period?

  1. Edit <YC_SERVER_FOLDER>/launch-yc-server.sh (in windows use launch-yc-server.bat)

  2. Add the -DobservationPeriod={Time_Period} system property to launch-yc-server.sh. For example, to set an observation period of
    5 minutes, modify the script as follows:

java ... -Dapp=yc -DlogDir=. -DuploadDir=. -DobservationPeriod=5mins …
1

# Supported Time Formats

The observationPeriod property supports several time formats to provide flexibility in specifying the duration for monitoring. The formats are as follows:

Time Unit Description
Seconds Represented by sec. Example: -DobservationPeriod=30sec
Minutes Represented by min (singular) and mins (plural). Examples: -DobservationPeriod=1min (for 1 minute),
-DobservationPeriod=10mins (for 10 minutes)
Hours Represented by hr (singular) and hrs (plural). Examples: -DobservationPeriod=1hr (for 1 hour),
-DobservationPeriod=3hrs (for 3 hours)
Days Represented by day (singular) and days (plural). Examples: -DobservationPeriod=1day (for 1 day),
-DobservationPeriod=2days (for 2 days)

# Best Practices

  • Keep it longer than m3Frequency:

    The m3Frequency defines how often yCrash samples data (e.g., every 1 minute), while the observationPeriod determines how long a metric breach, like a CPU spike, must persist before an incident is captured. If the m3Frequency is set to 1 minute and the observationPeriod is set to 3 minutes, yCrash will collect data three times at 1-minute intervals. Only if the metric breach occurs in all three samples will an incident be captured and reported. This ensures that short-term spikes are ignored, and only sustained breaches trigger incidents, providing more reliable results and reducing the chances of false positives. By setting the observationPeriod longer than the m3Frequency, you allow multiple samples to be analyzed before deciding whether to capture the incident.

  • Monitoring and Adjusting:

    Regularly review your system’s performance and adjust the observationPeriod accordingly. An overly short observation period might trigger unnecessary alerts, while an excessively long one could delay needed actions.

← Custom Cooling Period →