mirror of
https://github.com/ClickHouse/ClickHouse.git
synced 2026-10-28 16:18:23 +08:00
Shaun StruwigandClaude Opus 4.8
9b6c25fe12
The `docs/images` tree is ~218 MB, dominated by ~2,000 screenshots. The PNGs were already losslessly optimized (oxipng finds no further gains), so the only lossless lever left is a more efficient container. AVIF is unsupported by Mintlify, so convert static PNGs to lossless WebP (pixel-identical, universally supported). Encoded each PNG with `cwebp -lossless -q 100 -m 6`, keeping the WebP only when it is smaller than the source (19 PNGs where WebP was larger are left as-is), and rewrote every reference across English and all locale pages. converted 2042 PNGs: 131.0 MB -> 92.5 MB (-29.4%) images/ tree: 218 MB -> 179 MB 3737 text files updated; internal-link check passes with 0 errors Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
37 lines
2.4 KiB
Plaintext
37 lines
2.4 KiB
Plaintext
---
|
|
slug: /use-cases/observability/clickstack/event_patterns
|
|
title: 'Event patterns with ClickStack'
|
|
sidebarTitle: 'Event patterns'
|
|
description: 'Event patterns with ClickStack'
|
|
doc_type: 'guide'
|
|
keywords: ['clickstack', 'event patterns', 'log analysis', 'pattern matching', 'observability']
|
|
---
|
|
|
|
import { Image } from "/snippets/components/Image.jsx";
|
|
|
|
Event patterns in ClickStack allow you to quickly make sense of large volumes of logs or traces by automatically clustering similar messages together, so instead of digging through millions of individual events, you only need to review a small number of meaningful groups.
|
|
|
|
<Image img="/images/use-cases/observability/event_patterns.webp" alt="Event patterns" size="lg"/>
|
|
|
|
This makes it much easier to spot which errors or warnings are new, which are recurring, and which are driving sudden spikes in log volume. Because the patterns are generated dynamically, you don't need to define regular expressions or maintain parsing rules - ClickStack adapts to your events automatically, regardless of format.
|
|
|
|
Beyond incident response, this high-level view also helps you identify noisy log sources that can be trimmed to reduce cost, discover the different types of logs a service produces, and more quickly answer whether the system is already emitting the signals you care about.
|
|
|
|
## Accessing event patterns {#accessing-event-patterns}
|
|
|
|
Event patterns are available directly through the **Search** panel in ClickStack.
|
|
|
|
From the top-left **Analysis Mode** selector, choose **Event patterns** to switch from the standard results table to a clustered view of similar events.
|
|
|
|
<Image img="/images/use-cases/observability/event_patterns_highlight.webp" alt="Event patterns" size="lg"/>
|
|
|
|
This provides an alternative to the default **Results Table** which allows you to scroll through every individual log or trace.
|
|
|
|
## Recommendations {#recommendations}
|
|
|
|
Event patterns are most effective when applied to **narrowed subsets** of your data. For example, filtering down to a single service before enabling event patterns will usually surface more relevant and interesting messages than applying patterns across thousands of services at once.
|
|
|
|
They're also particularly powerful for summarizing error messages, where repeated errors with varying IDs or payloads are grouped into concise clusters.
|
|
|
|
For a live example, see how event patterns are used in the [Remote Demo Dataset](/clickstack/example-datasets/remote-demo-data#identify-error-patterns).
|