Log Pattern Alerting

Hands-off alerting when Log Pattern volume changes.

Overview

Detecting rapid changes in Log Pattern volume yields actionable information to spot unusual pattern trends or anomalies.

2-click monitoring of log patterns provides an easy and hands-off alerting setup mode. Users can choose to be alerted if a given pattern appears (presence detector) or if a given pattern volume suddenly changes (drift detector).

Alert notifications are delivered in the notification area which is located on the top right corner of the UI. Triggered alerts are visible in the Pattern Alert tab and are easily enabled or disabled.

Monitoring a Log Pattern

From there, users need to select either detect drift and/or detect presence.

Viewing Log Pattern alerts

One a Log Pattern was monitored, a new graph appears in the Pattern Alert tab. This graph shows the temporal evolution of the corresponding pattern volume and displays detected alerts as vertical upward red arrows.

Log Pattern notifications

Each triggered alert appears with the type of alerting (presence or drift), the timestamp at which it was triggered, the pattern description and a link to the corresponding Pattern Alert tab.

Drift or presence? Which algorithm to choose ?

First, let us describe how each of those detectors operate:

  • Drift: the median of pattern log counts over fixed-size, consecutive windows is observed. If this KPI value differs strongly from neighboring ones, the detector triggers a drift alert.

  • Presence: the occurrence of a given log pattern is observed. If this event occurs, the detector triggers a presence alert.

As a rule of thumb, users should select:

  • Drift: when log volumes peaks or troughs point to an issue. Typical scenarios include detecting brute-force, dictionary attacks on web servers, detecting that a data pipeline's expected throughput is changing unexpectedly, detecting that a constant volume of logs (for some component) is subject to variations, etc.

  • Presence: when the presence of a given log pattern points to an issue. Typical scenarios include detecting unwanted error or warning patterns that require immediate escalation (for instance because they correspond to system unavailability or client impact), detecting that after remediation by engineering team a given pattern has disappeared for good and never re-appears, etc.

Last updated