Comments 11
Трудно не отметить длину титула должности. Внушает!
А что собственно с просмотром логов? Ничего лучше Kibana (которая, к сожалению, только с еластиком работает) не нашел.
Мы используем Grafana. Для мониторинга вполне хватает. Поскольку Clickhouse — sql-like база данных, есть odbc-драйвер. Это позволяет использовать множество готовых UI-инструментов: от Tableau и Power BI до SuperSet и Redash. Впрочем, мы их пока не использовали для таких целей.
Не поделитесь скриншотами с текстами логов?
Полностью разделяю ваш восторг от ClickHouse. У нас он заменил связку ElasticSearch+Spark. Я был в шоке, когда увидел, что ClickHouse с легкостью делает в реальном времени то, для чего требовались кластеры ES и DataBricks и много минут на перегонку данных.
Хочу поделиться одним из кейсов. Из API стороннего сервиса грузим отчёт в десятки тысяч строк. Потом этот отчёт мапится в миллионы строк. Памяти категорически не хватает, а нужно сделать агрегацию, прежде чем сложить всё в базу. Думал, что придётся писать модуль на Сях. Но ClickHouse оказался просто магией: загрузил во временную таблицу промежуточные данные и сагрегировал за секунды. Сами данные съедали в разы меньше, чем удалось выжать из Питона с NumPy, но во время агрегации памяти уже не хватало. Достаточно поменять настройку КликХауса, и он волшебным образом как-то всё проделывает с использованием диска, по-прежнему за считанные секунды.
Так что рекомендую попробовать не только как хранилище, но и как число-дробилку.
Полностью разделяю ваш восторг от ClickHouse. У нас он заменил связку ElasticSearch+Spark. Я был в шоке, когда увидел, что ClickHouse с легкостью делает в реальном времени то, для чего требовались кластеры ES и DataBricks и много минут на перегонку данных.
Хочу поделиться одним из кейсов. Из API стороннего сервиса грузим отчёт в десятки тысяч строк. Потом этот отчёт мапится в миллионы строк. Памяти категорически не хватает, а нужно сделать агрегацию, прежде чем сложить всё в базу. Думал, что придётся писать модуль на Сях. Но ClickHouse оказался просто магией: загрузил во временную таблицу промежуточные данные и сагрегировал за секунды. Сами данные съедали в разы меньше, чем удалось выжать из Питона с NumPy, но во время агрегации памяти уже не хватало. Достаточно поменять настройку КликХауса, и он волшебным образом как-то всё проделывает с использованием диска, по-прежнему за считанные секунды.
Так что рекомендую попробовать не только как хранилище, но и как число-дробилку.
У кликхауса есть утилита clickhouse-local, кстати. Которая позволяет использовать движок в командой строке (нет необходимости использовать сам сервер). На вход файл для обработки, на выход файл с результатом.
К сожалению, нет возможности — это конфиденциальная информация. Но надо сказать, что это обычный лог, генерируемый Microsoft IIS в формате w3c. Основной нюанс здесь — это составить grok-шаблон для логстеша, чтобы он расщеплялся на поля. Чтобы можно было их в фильтре дообработать. Так можно и логи апач распарсить или nginx.
Не поделитесь скриншотами с текстами логов?
К сожалению, нет возможности — это конфиденциальная информация. Но надо сказать, что это обычный лог, генерируемый Microsoft IIS в формате w3c. Основной нюанс здесь — это составить grok-шаблон для логстеша, чтобы он расщеплялся на поля. Чтобы можно было их в фильтре дообработать. Так можно и логи апач распарсить или nginx.
Ого, про clickhouse-local не знал, спасибо.
Хотелось на конечный интерфейс к логам посмотреть. Не получилось быстро нагуглить. Как выше уже написали, Kibana для чтения логов прекрасна. По некоторым причинам использую вместо неё Graylog и не перестаю плеваться. Интересно, может ли Grafana составить конкуренцию.
Хотелось на конечный интерфейс к логам посмотреть. Не получилось быстро нагуглить. Как выше уже написали, Kibana для чтения логов прекрасна. По некоторым причинам использую вместо неё Graylog и не перестаю плеваться. Интересно, может ли Grafana составить конкуренцию.
А в начале статьи есть картинка из графаны. Это реальные графики на основе логов.
У графаны есть ещё виджет Таблица. Мы его тоже используем. Например, топ url запросов или топ ошибочных урл. Все понятно и удобно.
В целом, для дашборда можно задавать фильтры. Например, можно задать часть url.
У графаны есть ещё виджет Таблица. Мы его тоже используем. Например, топ url запросов или топ ошибочных урл. Все понятно и удобно.
В целом, для дашборда можно задавать фильтры. Например, можно задать часть url.
Попробую расшифровать вопрос Balek, т.к. мне он тоже интересен.
Вы показываете скриншоты с графиками и цифрами и называете примеры «топ урлов».
Мне же (и Balek) хочется увидеть как выглядит просмотр логов.
Представьте себе сервис, который пишет построчно:
Вот как такие вещи смотреть и искать в графане?
Вы показываете скриншоты с графиками и цифрами и называете примеры «топ урлов».
Мне же (и Balek) хочется увидеть как выглядит просмотр логов.
Представьте себе сервис, который пишет построчно:
- Начал работу над ABC...
- Подзадача А успешно (заняло 1 сек).
- Подзадача B успешно (заняло 5 сек).
- Подзадача C сфейлилась с ошибкой 123 (текстовое описание ошибки)
- Backtrace:
- — main.c:123
- — main.c:10
Вот как такие вещи смотреть и искать в графане?
Понял. Вы имеете ввиду логи приложения.
Обычно в таких логах есть время записи, уровень (error, warn, info и проч.), номер потока и сообщение. Их нужно сначала в логстеше, например, расщепить на столбцы и записать в ClickHouse.
Текст сообщения прям в отдельный столбец целиком.
А когда записи лога уже в таблице, то в графане просто настраивается виджет Таблица и к нему привязывается select с группировкой и фильтром в where через like. Примерно так:
В клике, конечно, нет полнотекстового индексирования как в эластике, и есть нюансы при хранении больших строк. Но сообщения из лога (без стек-трейса) вполне нормально могут работать (В последних версиях появилась крутая фича Adaptive granularity).
Мы у себя сейчас, как раз, в процессе настройки парсинга логов приложений. На дашборде видим таблицу с сообщениями варнингов и ошибок, например, за последние 12 часов.
Нам надо, наверное, отдельную статью написать про такой сценарий. Там есть нюансы. Но текущие результаты вполне устраивают. В файлы с логами смотреть не приходится.
Обычно в таких логах есть время записи, уровень (error, warn, info и проч.), номер потока и сообщение. Их нужно сначала в логстеше, например, расщепить на столбцы и записать в ClickHouse.
Текст сообщения прям в отдельный столбец целиком.
А когда записи лога уже в таблице, то в графане просто настраивается виджет Таблица и к нему привязывается select с группировкой и фильтром в where через like. Примерно так:
select logdatetime
, message
, count() as c
from default.log_app
where message like '%сфейлилась с ошибкой%'
and logdatetime > $from -- это фильтр времени в графане
group by logdatetime
, message
order by logdatetime
limit by 100
В клике, конечно, нет полнотекстового индексирования как в эластике, и есть нюансы при хранении больших строк. Но сообщения из лога (без стек-трейса) вполне нормально могут работать (В последних версиях появилась крутая фича Adaptive granularity).
Мы у себя сейчас, как раз, в процессе настройки парсинга логов приложений. На дашборде видим таблицу с сообщениями варнингов и ошибок, например, за последние 12 часов.
Нам надо, наверное, отдельную статью написать про такой сценарий. Там есть нюансы. Но текущие результаты вполне устраивают. В файлы с логами смотреть не приходится.
Такой же опыт с ClickHouse, запросы, которые раньше занимали несколько минут на разных решениях, на ClickHouse начали выполняться за секунды. Ребята из Яндекс Метрики действительно провели очень большую работу по оптимизации. Жаль нельзя использовать ClickHouse как основную базу, так как записи неизменяемые (видимо, чтобы не перестраивать индексы), но для логов подходит идеально.
Не почему же нельзя как основную. Вполне можно. Мы для одного проекта делали с обновлениями: https://youtu.be/Ptyknfy5DWM
написав sql- подобный язык для бизнеса.
Sign up to leave a comment.
БД ClickHouse для людей, или Технологии инопланетян