|
2.4, XoRe (ok), 15:30, 03/12/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
Смотря какие объемы логов.
На малых объемах логов - грамотно сделанная схема работы с clickhouse работает быстрее, чем дефолтная схема работы с ES. Это шуточка с двойным дном. Тюнить clickhouse приятнее, чем ES. Там вы рано или поздно упретесь в java с его GC. И тюнинг ES превратится в тюнинг java.
На больших объемах логов ES умрет, а clickhouse - нет. Тем clickhouse и лучше.
Еще из объективных плюсов - грамотная схема с clickhouse позволит логам занимать меньше места. Опять же, становится актуально на больших объемах данных.
| |
2.12, Vitto74 (ok), 19:43, 13/12/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
Разработчики сказали, что им так удобнее. Они уже использовали ES, не понравилось. Я никому не навязываю, просто делюсь опытом.
| |
|
1.3, Аноним (2), 09:47, 03/12/2021 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [к модератору]
| +/– |
Очень неоптимальная схема, максимально нагружающая КХ в момент вставки. Вставлять в него данные рекомендуется блоками хотя бы от 100 тыс. записей, чтобы нормально отрабатывали алгоритмы сортировки в MergeTree.
Ну и по мелочи, например, для namespace вместо String можно использовать LowCardinality(String).
| |
|
2.9, Vitto74 (ok), 19:29, 13/12/2021 [^] [^^] [^^^] [ответить] [к модератору]
| +1 +/– |
По умолчанию fluetn-bit отправляет данные раз в 5 секунд. В документации clickhouse рекомендуется писать в базу не чаще раза в секунду. Действующая схема оптимальна для применения в моём случае, но нет универсальной схемы, которая подойдет всем. В статье я хотел поделиться опытом, который поможет адаптировать fluent-bit для других ситуаций, в которых он в принципе может быть полезен.
| |
|
1.5, Аноним (5), 16:48, 03/12/2021 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [к модератору]
| +/– |
Основная проблема Clickhouse это отсутствие хорошей морды для просмотра логов. Во всяком так было на момент когда я пробовал. Разрабам такой вариант не понравился, CH язык запросов мало кто знает, ES был привычнее.
Но пробовали так, делали. Правда, вместо fluent-bit мы написали своего демонюгу на Go чтобы вытаскивать логи из docker и journald. Сделали отправку батчами и оптимизировали парсеры и структуру во все щели: получались какие-то сумасшедшие цифры по производительности в миллионы строк/сек с кластера с минимальной нагрузкой на демон форвардинга. Писали напрямую с коллекторов в CH.
| |
|
2.11, Vitto74 (ok), 19:41, 13/12/2021 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– |
Мы тоже сначала свой костыль написали, но на java это смотрелось не очень - не самый подходящий для этого инструмент. Поэтому поковырявшись, настроили fluent-bit. Один экземпляр занимает 5Mb памяти и около мегабайта диска,а нагрузку на cpu и диск вообще не заметили.
| |
2.15, Аноним (15), 22:15, 15/01/2022 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
> CH язык запросов мало кто знает
SQL-select для одной таблички мало кто знает из разработчиков, которые логи бэка смотрят? Хорошая команда.
| |
|
1.18, Igor (??), 18:32, 03/06/2022 [ответить] [﹢﹢﹢] [ · · · ] [к модератору]
| +/– |
Способ хороший, однако должен заметить, что приведённая конфигурация fluent-bit может терять чанки. Как я понял, пайплайн работает так: из файла читаются чанки и поднимаются в память. После успешного чтения в DB записывается новая позиция. Далее чанк обрабатывается парсерами, фильтрами и направляется в output. Всё это время чанк держится в памяти. Однако если в output отправить не удалось, то информация об этом не будет никуда сохранена. А если процесс перезапустится, так и не успев отправить этот чанк, то чанк будет потерян: перечитываться заново чанк не будет (т.к. в базе уже записана новая позиция), а сам чанк был в памяти, и после рестарта процесса не сохранился.
Чтобы избежать потери логов, нужно настроить filesystem storage и бесконечные ретраи в output. Тогда после чтения чанк сразу будет записываться на диск, и только потом будет производиться его обработка. Если процесс рестартится, то он перечитывает все сохранённые чанки и продолжает попытку их обработки и отправки. А бесконечные ретраи нужны чтобы эти чанки не дропались после N-ого неуспешного ретрая отправки.
| |
|
2.19, Vitto74 (ok), 02:30, 05/07/2022 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
Бесконечные попытки отправки мы делать не стали т.к. потеря логов при недоступности clickhouse - это не очень большая проблема и с таким мы смиримся легко.
С проблемой потери чанков, не отправленных в момент перезапуска или при недоступности clickhouse, мы еще не сталкивались. Можно подробнее об этой проблеме? Или ссылку на статью, где это писано?
| |
|
|