Телеграмм чат группы itarchitect страница 2401

У вас что, одна операция в секунду и то не всегда?

То есть ничего между 100к и 1 не может быть?

dreamore in Архитектура ИТ-решений

13:56пожаловаться #1

d

Интерфейс - не пригоден для вывода больше 30 строк на экран, да и сами строки выводятся не целиком. И не работает с многострочными записями (без костылей).
Медленно - как только хочется писать хотя бы 100K строк в секунду (а это мало, на самом деле). Впрочем, там и так набегает по полному ядру на 5K строк в секунду, что очень медленно.

Видел в контуре такую историю. Elk меняется на efk. Добавлется кафка как sidecar для каждого приложения с маленьким окном сохранения, чтобы не терять логи и втыкается между производителями логов и efk. Индексы отключаются. Только в ручном режиме и строго по регламенту некоторые люди могут строить индексы. Дошли до 300TB логов. +40GB в сутки

13:58пожаловаться #2

AW

Alex Wells

Представьте, если бы для каждого небольшого фрилансового проектов находили девопса, дба, покупали триллион подписок на сервисы и еще несколько десятков синиоров в придачу - ну идиотизм же.

Да, есть инструменты покруче, но их применение должно быть оправдано

А мы - небольшая компания. Над данным конкретным проектом работает +-12 девелоперов, включая мидлов (меня) и фронтов.

dreamore in Архитектура ИТ-решений

13:58пожаловаться #3

d

В общем плохие решения порождают горы костылей к ним

13:58пожаловаться #4

AW

какой смысл думать над проблемами, с которыми мы еще долгое время не столкнемся?

Igor Nikolskiy in Архитектура ИТ-решений

13:59пожаловаться #5

IN

Антипаттерн - так как провоцирует писать не структурированные логи и искать по "подстроке" (при этом еще и поиск по подстроке делается через полноценный полнотекстовый, что тоже замедляет все и дает не всегда хорошие результаты)

Sed ? Awk?

13:59пожаловаться #6

PD

Alex Wells

То есть ничего между 100к и 1 не может быть?

1 операция в секунду - это уже, по хорошему, несколько сотен записей в лог...

13:59пожаловаться #7

AW

есть более насущеные проблемы

13:59пожаловаться #8

PD

dreamore

Видел в контуре такую историю. Elk меняется на efk. Добавлется кафка как sidecar для каждого приложения с маленьким окном сохранения, чтобы не терять логи и втыкается между производителями логов и efk. Индексы отключаются. Только в ручном режиме и строго по регламенту некоторые люди могут строить индексы. Дошли до 300TB логов. +40GB в сутки

Ну, тут оставили и эластик (который не для таких задач) и кибану (которая тоже не совсем про логи) - и понятно, что напоролись.

14:00пожаловаться #9

AW

1 операция в секунду - это уже, по хорошему, несколько сотен записей в лог...

Даже интересно стало. Может знаете, где глянуть?

dreamore in Архитектура ИТ-решений

14:00пожаловаться #10

d

Ну, тут оставили и эластик (который не для таких задач) и кибану (которая тоже не совсем про логи) - и понятно, что напоролись.

Ну хоть логи они стали собирать не в виде строк а в виде json с общим форматом на организацию

14:01пожаловаться #11

PD

Igor Nikolskiy

Sed ? Awk?

Ну, я пока за хранение в CH (или в аналогичной колоночной базе, не важно). Выборки, в зависимости от целей - или через UI с поддержкой максимального числа строк на экране или sql-ем из IDE или из sql в файл и дальше less-ом (это для анализа по реально большим массивам, где хочется глазами видеть все, что творилось на кластере перед проблемой...)

14:02пожаловаться #12

PD

Alex Wells

Даже интересно стало. Может знаете, где глянуть?

Глянуть на что?

14:02пожаловаться #13

PD

dreamore

Ну хоть логи они стали собирать не в виде строк а в виде json с общим форматом на организацию

А, ну это полезно, да...
Я сейчас вообще скорее за то, что бы приложение писало что придется в sysout (можно даже не json), оттуда читал простенький анализатор и фигачил в jsonl, а уже этот jsonl через fluentbit отдавать в CH (или в аггрегатор перед CH, если, например, хочется с этим еще что-то делать). Ну или можно между fluentbit и CH ставить kafka (если есть ресурсы)

Igor Nikolskiy in Архитектура ИТ-решений

14:04пожаловаться #14

IN

Ну, я пока за хранение в CH (или в аналогичной колоночной базе, не важно). Выборки, в зависимости от целей - или через UI с поддержкой максимального числа строк на экране или sql-ем из IDE или из sql в файл и дальше less-ом (это для анализа по реально большим массивам, где хочется глазами видеть все, что творилось на кластере перед проблемой...)

А смысл? Искусственный интеллект напускать в поспроцессинге? Не проще ли препроцессинг и xml? И like по жизни. Нет?

14:04пожаловаться #15

PD

dreamore

Видел в контуре такую историю. Elk меняется на efk. Добавлется кафка как sidecar для каждого приложения с маленьким окном сохранения, чтобы не терять логи и втыкается между производителями логов и efk. Индексы отключаются. Только в ручном режиме и строго по регламенту некоторые люди могут строить индексы. Дошли до 300TB логов. +40GB в сутки

А зачем kafka как sidecar, в нее же нормально писать потоком сотням тысяч строк в секунду на пару брокеров. И забирать с оптимальным окном для хранилища.

Igor Nikolskiy in Архитектура ИТ-решений

14:05пожаловаться #16

IN

Или у тебя 'сторнирование' наше всё?

14:06пожаловаться #17

PD