> ## Documentation Index
> Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Использование ClickHouse для обсервабилити
> Использование ClickHouse в качестве решения для обсервабилити
export const Image = ({img, alt, size = "lg"}) => {
const normalizedSize = ["sm", "md", "lg"].includes(size) ? size : "lg";
return ;
};
## Введение
Это руководство предназначено для тех, кто хочет построить собственное решение для обсервабилити на основе SQL с использованием ClickHouse, с упором на журналы и трассировки. В нём рассматриваются все аспекты создания такого решения, включая вопросы ингестии, оптимизацию схем под ваши сценарии доступа и извлечение структуры из неструктурированных журналов.
Сам по себе ClickHouse не является готовым решением для обсервабилити. Однако его можно использовать как высокоэффективный движок хранения данных обсервабилити, обеспечивающий непревзойдённый уровень сжатия и молниеносное время ответа на запросы. Чтобы использовать ClickHouse в составе решения для обсервабилити, необходимы и интерфейс, и система сбора данных. В настоящее время мы рекомендуем использовать **Grafana** для визуализации сигналов обсервабилити и **OpenTelemetry** для сбора данных (оба варианта являются официально поддерживаемыми интеграциями).
**Не только OpenTelemetry**
Хотя мы рекомендуем использовать проект OpenTelemetry (OTel) для сбора данных, аналогичную архитектуру можно построить и с помощью других фреймворков и инструментов, например Vector и Fluentd (см. [пример](https://clickhouse.com/blog/kubernetes-logs-to-clickhouse-fluent-bit) с Fluent Bit). Существуют и альтернативные инструменты визуализации, включая Superset и Metabase.
## Зачем использовать ClickHouse?
Самая важная возможность любого централизованного хранилища обсервабилити — быстро агрегировать, анализировать и искать огромные объемы журнальных данных из разных источников. Такая централизация упрощает устранение неполадок и помогает быстрее выявлять первопричины сбоев сервисов.
Поскольку пользователи становятся все более чувствительными к цене и считают стоимость таких готовых решений высокой и непредсказуемой относительно их ценности, экономичное и предсказуемое хранение журналов с приемлемой производительностью запросов сегодня важно как никогда.
Благодаря высокой производительности и экономической эффективности ClickHouse стал фактическим стандартом среди движков хранения журналов и трассировки в продуктах для обсервабилити.
Если точнее, ClickHouse идеально подходит для хранения данных обсервабилити по следующим причинам:
* **Сжатие** - Данные обсервабилити обычно содержат поля, значения которых берутся из ограниченного набора, например HTTP-коды или имена сервисов. Колоночно-ориентированное хранилище ClickHouse, в котором значения хранятся в отсортированном виде, обеспечивает очень высокую степень сжатия — особенно в сочетании со специализированными кодеками для данных временных рядов. В отличие от других хранилищ данных, которым обычно требуется столько же места, сколько занимает исходный объем данных, как правило в формате JSON, ClickHouse в среднем сжимает журналы и трассировки до 14 раз. Помимо существенной экономии места для крупных инсталляций обсервабилити, такое сжатие также ускоряет запросы, поскольку с диска нужно считывать меньше данных.
* **Быстрые агрегации** - Решения для обсервабилити обычно в значительной степени опираются на визуализацию данных с помощью диаграмм, например линий, показывающих уровень ошибок, или столбчатых диаграмм, показывающих источники трафика. Агрегации, или GROUP BY, лежат в основе таких диаграмм и должны оставаться быстрыми и отзывчивыми при применении фильтров в сценариях диагностики проблем. Колоночно-ориентированный формат ClickHouse в сочетании с векторизованным движком выполнения запросов идеально подходит для быстрых агрегаций, а разреженное индексирование позволяет быстро фильтровать данные в ответ на действия пользователя.
* **Быстрые линейные сканирования** - Хотя альтернативные технологии опираются на инвертированные индексы для быстрого выполнения запросов к журналам, это неизменно приводит к высокому потреблению дисковых и других ресурсов. Хотя ClickHouse поддерживает инвертированные индексы как дополнительный необязательный тип индекса, линейные сканирования в нем хорошо распараллеливаются и используют все доступные ядра машины (если не настроено иначе). Это потенциально позволяет сканировать десятки ГБ/с (в сжатом виде) для поиска совпадений с помощью [высокооптимизированных операторов сопоставления текста](/docs/ru/reference/functions/regular-functions/string-search-functions).
* **Знакомый SQL** - SQL — повсеместно распространенный язык, знакомый всем инженерам. За более чем 50 лет развития он зарекомендовал себя как фактический стандарт для аналитики данных и по-прежнему остается [третьим по популярности языком программирования](https://clickhouse.com/blog/the-state-of-sql-based-observability#lingua-franca). Обсервабилити — это еще одна задача работы с данными, для которой SQL подходит идеально.
* **Аналитические функции** - ClickHouse расширяет ANSI SQL аналитическими функциями, которые делают SQL-запросы проще и удобнее в написании. Они особенно важны при анализе первопричин, когда данные нужно детально разбирать в разных разрезах.
* **Вторичные индексы** - ClickHouse поддерживает вторичные индексы, такие как bloom-фильтры, чтобы ускорять определенные профили запросов. Их можно при необходимости включать на уровне столбца, что дает пользователю детальный контроль и позволяет оценить выигрыш в производительности относительно затрат.
* **Открытый исходный код и открытые стандарты** - Как база данных с открытым исходным кодом, ClickHouse поддерживает открытые стандарты, такие как OpenTelemetry. Возможность вносить вклад и активно участвовать в проектах привлекательна сама по себе и при этом помогает избежать проблем, связанных с привязкой к поставщику.
## Когда стоит использовать ClickHouse для обсервабилити
Использование ClickHouse для данных обсервабилити требует готовности работать с обсервабилити на основе SQL. Об истории обсервабилити на основе SQL мы рекомендуем прочитать [в этой статье блога](https://clickhouse.com/blog/the-state-of-sql-based-observability), но если кратко:
Обсервабилити на основе SQL подходит вам, если:
* Вы или участники вашей команды знакомы с SQL (или хотите его изучить)
* Вы предпочитаете придерживаться открытых стандартов, таких как OpenTelemetry, чтобы избежать привязки к поставщику и обеспечить расширяемость.
* Вы готовы использовать экосистему, основанную на инновациях open-source, от сбора до хранения и визуализации.
* Вы ожидаете роста до средних или больших объёмов данных обсервабилити в управлении (или даже очень больших объёмов)
* Вы хотите контролировать TCO (совокупную стоимость владения) и избежать стремительного роста затрат на обсервабилити.
* Вы не можете или не хотите мириться с короткими сроками хранения данных обсервабилити только ради снижения затрат.
Обсервабилити на основе SQL может вам не подойти, если:
* Изучение SQL (или даже его генерация!) не привлекает вас или участников вашей команды.
* Вам нужно готовое комплексное решение для обсервабилити.
* Объёмы ваших данных обсервабилити слишком малы, чтобы это дало заметный эффект (например, \<150 GiB), и их рост не ожидается.
* В вашем сценарии использования основной акцент сделан на метрики и требуется PromQL. В таком случае вы всё равно можете использовать ClickHouse для журналов и трассировки вместе с Prometheus для метрик, объединив всё это на уровне представления с помощью Grafana.
* Вы предпочитаете подождать, пока экосистема станет более зрелой, а обсервабилити на основе SQL — более готовой к использованию из коробки.
## Журналы и трассировки
В обсервабилити есть три основных компонента: Logging, Tracing и Metrics. Для каждого характерны свои типы данных и способы доступа к ним.
В настоящее время мы рекомендуем ClickHouse для хранения двух типов данных обсервабилити:
* **Журналы** - Журналы — это записи событий, происходящих в системе, с отметками времени, которые содержат подробную информацию о различных аспектах работы программного обеспечения. Данные в журналах обычно бывают неструктурированными или полуструктурированными и могут включать сообщения об ошибках, журналы пользовательской активности, изменения в системе и другие события. Журналы крайне важны для устранения неполадок, выявления аномалий и понимания того, какие именно события привели к проблемам в системе.
```response theme={null}
54.36.149.41 - - [22/Jan/2019:03:56:14 +0330] "GET
/filter/27|13%20%D9%85%DA%AF%D8%A7%D9%BE%DB%8C%DA%A9%D8%B3%D9%84,27|%DA%A9%D9%85%D8%AA%D8%B1%20%D8%A7%D8%B2%205%20%D9%85%DA%AF%D8%A7%D9%BE%DB%8C%DA%A9%D8%B3%D9%84,p53 HTTP/1.1" 200 30577 "-" "Mozilla/5.0 (compatible; AhrefsBot/6.1; +http://ahrefs.com/robot/)" "-"
```
* **Трассировки** — Трассировки фиксируют путь запросов при их прохождении через различные сервисы в распределенной системе, показывая маршрут этих запросов и их производительность. Данные в трассировках имеют четкую структуру и состоят из спанов и трассировок, которые описывают каждый шаг запроса, включая временные характеристики. Трассировки дают ценную информацию о производительности системы, помогая выявлять узкие места, проблемы с задержками и оптимизировать работу микросервисов.
**Метрики**
Хотя ClickHouse можно использовать для хранения данных метрик, в ClickHouse это направление пока развито слабее: например, еще не поддерживаются такие возможности, как формат данных Prometheus и PromQL.
### Распределённая трассировка
Распределённая трассировка — критически важная возможность обсервабилити. Распределённая трассировка, обычно называемая просто трассировкой, показывает путь запроса через систему. Запрос исходит от конечного пользователя или приложения и распространяется по системе, обычно вызывая цепочку действий между микросервисами. Запись этой последовательности и возможность коррелировать последующие события позволяют пользователю средств обсервабилити или SRE диагностировать проблемы в работе приложения независимо от сложности архитектуры и использования бессерверных компонентов.
Каждая трассировка состоит из нескольких спанов, при этом начальный спан, связанный с запросом, называется корневым спаном. Этот корневой спан охватывает весь запрос от начала до конца. Последующие спаны под корневым дают детальное представление о различных шагах или операциях, происходящих во время выполнения запроса. Без трассировки диагностика проблем с производительностью в распределённой системе может быть крайне затруднена. Трассировка упрощает отладку и понимание распределённых систем, подробно показывая последовательность событий внутри запроса по мере его прохождения через систему.
Большинство поставщиков решений для обсервабилити визуализируют эту информацию в виде водопада, где относительное время показано горизонтальными полосами пропорциональной длины. Например, в Grafana:
Пользователям, которым нужно глубже разобраться в концепциях журналов и трассировок, мы настоятельно рекомендуем [документацию OpenTelemetry](https://opentelemetry.io/docs/concepts/).