автоматизации как-то конечно помогут

угу, а где интерфейс поиска лучше?

ну точнее как помогут

оно везде транслироваться будет в Lucene query

тебе все равно ставить ES

а морды можешь крутить какие нравятся

У них вроде есть какие-то инструменты даже по алертингу и прочему, но все будет зависить от того что в ES

Тебе нужно чем-то (rsyslog/logstash/fluentd) парсить эти логи и делать из них структурированные логи )

тогда это имеет какой-то смысл

а парсеры надо настраивать под каждый формат логов

плюс ты получишь operational overhead на работу с ES

он не беспроблемный, его надо будет поддерживать, чинить, обновлять, тюнить

Да, я знаю, уже сталкивалась, но не как с хранилкой логов

короче идеальный случай когда тебе логи уже будут идти структурированные

но тогда тебе даже руками из консоли станет проще делать выборки

Мне скорее нужно написать утилиты, которые будут делать эти выборки сами, и повесить логику на результаты этих выборок

Ага. Я программеров заставил в джсоне логи писать. Но ес с кабаной нужен саппорту

Ес просто удобно централизирует хранение

а морды можешь крутить какие нравятся

спасибо в общем :)

@polnoch я 5-ую кибану еще не видел, но 4-ая очень инопланетная, грейлог был понятнее

Но у чата нет какого-то общего мнения, что лучше, greylog, или ELK, или что ещё?

но если с нуля ставить то это уже ес5, и либо кибана5, либо грейлог

вот что лучше - смотри ты, потому что тебе этим пользоваться

у них разные подходы к организации интерфейса

грейлог создает впечатление более админско-ориентированного, а кибана как некий интерфейс где ты хочешь найти не знаешь что и узнаешь в процессе поиска

у нас грейлог используют для хранения логов самописных приложений, а ЕЛК для хранения логов сервисов

ну пользоваться - на самом деле этому некому. Т.е. сейчас рабочий процесс построен так, что в красивый интерфейс zabbix никто не смотрит, разве что раз в месяц, а используются в основном его фишки по автодискавери и автоподключению темплейтов

@polnoch выбирай что ТЕБЕ понравится

поэтому красота интерфейса опять же не важна, зато важно, что бы было красивое API

если что переиграешь потом

у нас грейлог используют для хранения логов самописных приложений, а ЕЛК для хранения логов сервисов

а почему не что-то одно?

а почему не что-то одно?

Исторически так сложилось :)

А что больше нравится?

у меня саппорт не смог в грейлог

хз почему

но если с нуля ставить то это уже ес5, и либо кибана5, либо грейлог

я пытаюсь съехать с 1го эластика на 5й, у меня деградация с 300к инсертов в минуту до 10к, при тюнинге до 50к

я не понимаю как им пользуются для логов люди )

У меня логи в очереди в реббите лежат

Иначе не успеваю закидывать данные

я пытаюсь съехать с 1го эластика на 5й, у меня деградация с 300к инсертов в минуту до 10к, при тюнинге до 50к

Может, да. Я эластиком не занимаюсь

в минуту?

это даже не смешно:)

Я вот все читаю все эти "достижения" людей, как они логи собирают, ставят ELK, собирают террабайты логов в день. А потом задаюсь вопросом — зачем?

Ну серьезно, зачем вам куча бесхозной информации, которую надо обрабатывать, хранить, обслуживать и не терять.

Это примерно как с мониторингом. "У нас 100500 метрик отслеживается, смотрите какой я молодец!". Собсна, вопрос, зачем? Нахуя столько метрик, когда можно подумать головой один раз, и собирать 10 метрик, по которым можно сделать вывод о выходе из строя какой-то из подсистем.

Может мне кто-нибудь объяснить? Может я отсталый просто?)

Зачем 10 метрик, если достаточно одной - "все работает / ничего работает".

Может мне кто-нибудь объяснить? Может я отсталый просто?)

чтобы расследовать когда сломаеться что-то новое

Отсталый :)

Шутко

чтобы расследовать когда сломаеться что-то новое

Вот сломается — сделаешь метрику на это.

Не успеет, его уже уволят

Делать тысячи метрик и обтекать потом разворачивая кластера ELK ИМХО бредово

Это часть философии разработки

http://highscalability.com/log-everything-all-time

У нас в клаудвотче порядка 50 метрик заведено

Я не могу представить ситуации когда они бы не покрыли какой-то кейс

смишно

У нас в клаудвотче порядка 50 метрик заведено

это хорошо значит кто-то сел подумал и покрыл этими метриками возможные кейсы

или вот https://www.datadoghq.com/blog/monitoring-101-collecting-data/

Вот пример, на базе в AWS у нас метрика на CPU: 1) Ниже 5% 2) Выше 45%

"Instrument everything and collect as many work metrics, resource metrics, and events as you reasonably can. Observability of complex systems demands comprehensive measurements."

ну и да кластер мониторинга стоит гораздо меньше чем то время которое придеться потратить когда придеться разбираться с проблемами

Первая покрывает кейс когда бекенд отвалился, вторая когда хуйню задеплоили

ERROR: S client not available

Вот пример, на базе в AWS у нас метрика на CPU: 1) Ниже 5% 2) Выше 45%

железные метрики фигня, бизнес метрики вот тут соль и баги

Или, наоборот, кто-то думает, что сел и хорошо подумал покрыв все кейсы. А потом словит где-то проблему и будет оправдываться "а я не знаю, откуда это, у меня нет логов на это... но я напишу, обязательно напишу" ;)

Я именно щас про железячные метрики

В большой организации твой тщательно подобранный набор метрик протухнет дня через 3 максимум

Я именно щас про железячные метрики

так их и реально 50 штук и больше ненадо

Тупо из за количества изменений в системе

остальное то как раз бизнес генерирует, там всяки латенси ответа от базы бекэндов и прочие счетчики запросов

Ну можно подумать и с другой стороны - если не самые дурные инженеры не в самых дурных конторах так делают - значит есть какой то в этом смысл?

У каждого бизнеса свои критерии. Если манифест написал задрот из финансовой сферы, это не значит что проекты средней руки должны бежать и делать так же

Видел я такой цирк

Я вот все читаю все эти "достижения" людей, как они логи собирают, ставят ELK, собирают террабайты логов в день. А потом задаюсь вопросом — зачем?

Бигдата, возможно для аналитики когда-нибудь понадобится, но когда ,никто​ не знает

Каждые 10 минут тебя трясёт мониторинг, в т. Ч. Ночью

Потому что бизнес сказал не отключать уведомления ночью

Впизду

ну значит неправильно настроен мониторинг

если сервис в мониторинге - у сервиса проблема

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

я капитан очевидность, да?

Это к вопросу об 100500 метрик на каждый чих

Не все отклонения требуют немедленного реагирования

Даже при правильно настроенном мониторинге

Некоторые алерты могут подождать день а сервис все равно работать

господа, а в порядке пятницы, а вам не кажется что программстов надо всех взять и на галеры отправить ?

отправить с галер на галеры?

отправить с галер на галеры?

да. надо больше галер.

опять ебаное.ит протекает

как же заебало "продуманное программирование". когда при деланье интеграции с ад забывают вытягивать группы. или при выполении джобоа на многих нодах не предусматривают возможность взять переменные с одной ноды и притащить их как входные данные для другой ноды.

квазигалеры

и таких вот примеров очевидных вещей чо то становится просто много

как же заебало "продуманное программирование". когда при деланье интеграции с ад забывают вытягивать группы. или при выполении джобоа на многих нодах не предусматривают возможность взять переменные с одной ноды и притащить их как входные данные для другой ноды.

мне кажется ты про персональную боль

я про персональную да.