Comments 26
Люди уже сделали хорошие средства для хранения логов и работы с ними. А вы все еще сидите на текстовых файликах.
Плюс Sentry еще как облачная альтернатива для логирования на клиенте и сервере
Люди уже сделали хорошие средства для хранения логов и работы с ними. А вы все еще сидите на текстовых файликах.
ни то, ни то не является "хорошим" средством для хранения логов и работы с ними. Скорее являются "стандартными" и наиболее известными средствами. Причем эластик в лидерах. Кстати, про graylog забыли. Ну, и я ставлю, что почти наверняка эффективность хранения в КХ будет выше, чем в эластике. Просто потому что как правило полнотекстовый поиск как в эластике нафиг не нужен… В этом отношении очень интересен подход Loki (Grafana), когда они выделяют самые существенные метки в лог-сообщениях.
Еще добавлю, что логи — это просто жесть как дорого с точки зрения хранения и обработки. И поэтому нужно взвешивать все плюсы и минусы и нужно ли действительно хранить логи на каком-то уровне логирования. Потому что это все равно упадет костами на продукт. Тот же Яндекс недавно озвучивал мнение, что вместо того, чтобы писать логи — лучше сразу стараться писать нормальный код… А логи не нужны ))))
/это не относится к ситуации необходимости отправки СОБЫТИЙ из приложения — например, событий аудита, но неправда ли — это совершенно другой юзкейс, чем просто поток логов для отладки/разработки?/
p.s. ну, и добавлю, что есть вообще-то принципиальная разница между "логами" и "трейсами" (тем более между различными приложениями — реверанс в сторону jaeger/dynatrace и прочих apm)...
Графана — это отличная морда для графиков, мониторингов и подобного. Использовать ее для тестовых логов как-то странно. Не пробовал.
Не писать логи это смело. Не писать каждый чих наверно стоит, но с возможностью бстро включить если что не так. Деньги экнономить стоит.
А вот вообще не писать страшно. Потом же концов не найдешь.
Баланс нужен.
Логи это логи. Приложение пишет текстом что-то важное для нее. Я только об этом.
Графана — это отличная морда для графиков, мониторингов и подобного. Использовать ее для тестовых логов как-то странно. Не пробовал.
Не страннее, чем использовать графану вместо кибаны для вывода информации из ES.
Логи это логи. Приложение пишет текстом что-то важное для нее. Я только об этом.
Опыт показывает, что правы те люди, которые говорят, что логи не нужны. Может вы вместо ES хотите Jaeger/dynatrace? Или Sentry? Или что-то ещё? Потому что из логов очень быстро мы доходим до антипаттернов вроде «метрики из логов» (wat?) или «алертинг по логам». Вместо того, чтобы использовать более подходящие решения.
Дополнительно — «плоский» текстовый формат логов тоже вынуждает бороться с ним. Потому что логи — это структурированная информация (когда вылетает из приложения), потом текст как универсальный способ передачи, потом нам приходится парсить текст logstash и прочим, чтобы восстановить исходную структуру. Представляете себе сколько тактов процессора на это жжется в никуда? И мы получаем все «прелести» обработки логов вроде truncated сообщения или необходимость клеить multiline.
Насчёт быстрого переключения лог-левела на ходу — полностью согласен с Вами.
Логи что бы было что почитать когда прод начал себя вести как-то странно. Или еще хуже перестал работать. Когда прод взрывается и даже некуда посмотреть что вообще проиходит это печально.
Сам момент странного поведения или прекращения работы по логам отслеживать естесвенно нельзя.
Формат это старое легаси. С ним все научились жить. Что поделать. Может и доживем до какой революции в этом месте.
Опыт показывает, что правы те люди, которые говорят, что логи не нужны.
Либо вы должны сейчас привести пример как находится и решается проблема которая возникла на проде но нигде в логах не зафиксирована. Либо это все же не опыт а его отсутствие вместе с фантазиями на тему идеального ПО.)
Метрики и алертинг по логам это просто и удобно — очень junion подход все пытаться оптимизировать по потребляемым ресурсам RAM, CPU и т.д., когда в подавляющем большенстве случаев нужно оптимизировать трудозатраты.
лучше сразу стараться писать нормальный код
И обязательно без багов!
Но иногда, установка агрегатора логов — это оверкил, бывает много ситуаций когда надо посмотреть лог не попадающий в агрегатор. Это не конкурент ELK или Graylog, это конкурент Notepad и «tail -F foo.log»
Если у вас любое другое постоянное окружение не в общей системе это серьезная бага. Надо починить при первой возможности.
И остаются только временные CI стенды. А на них ничего и не будет. По понятным причинам. Хотя и не очень надо, grep и less с головой хватает. Там логов немного.
Если у вас прод не в общей системе это факап.
Разверните мысль, пожалуйста? Почему это прод (в общем) должен быть в общей системе? Легко может оказаться, что каждая команда (мы про agile) может иметь своё хранилище… и это будет лучше — ну, например, потому что у каждой команды свой набор чувствительных данных в логах
Общее место для команды, отдела, подразделения, да любой организационной
единицы как вы там работаете.
Хотя когда команд 10+ стоит подумать и сделать всем одинаково. Чуствительную информацию ловить общими средствами и заставлять удалять, настраивать один раз, админить один раз, просто клевые идеи друг у друга таскать легко. Времени можно вагон наэкономить.
Чуствительных данных в логах не должно быть. Одно из первых мест для утечки же.
Спорный вопрос. В явном виде — наверное, да, но если мы говорим про observability все равно должен быть способ понять — что это запросы от клиента А, а это от клиента Б… Пускай будет маскирование и обфускация — я не против. Но это ещё сильнее повышает общую стоимость солюшена. Ну, и плюс я гарантирую, чтобы всегда что-то «чувствителньое» возьмёт и просочится в логи…
Хотя когда команд 10+ стоит подумать и сделать всем одинаково.
Есть разница между «общее хранилище как единый инстанс эластика» и «managed elastic, который может себе поднять сам по общим шаблонам». В первом случае там ещё 100500 вопросов возникает вроде мультитенантности, разделения костов по потребителям и пр. Т.е. необходимо централизованное, но «не совсем» решение
В явном виде — наверное, да, но если мы говорим про observability все равно должен быть способ понять — что это запросы от клиента А, а это от клиента Б… Пускай будет маскирование и обфускация — я не против.
Я именно про явный вид.
Совсем чуствительная вроде паролей вообще ни каком виде не должна быть.
А id юзера тот же хешированный почему бы и нет. Соседний отдел пусть видит так и общей защиты от утечек хватит. Да и утечет не очень страшно.
Но это ещё сильнее повышает общую стоимость солюшена.
Да не особо он ее повышает. Хеш посчитать несложно, заменить все чуствительное на какой-нибдуь ray-id тоже несложно.
Если у вас логи забиты ФИО юзеров, то у вас проблема и исправлять ее дорого. Но надо и срочно, утечка это только вопрос времени. А если уже все хорошо, то поддерживать недорого.
Ну, и плюс я гарантирую, чтобы всегда что-то «чувствителньое» возьмёт и просочится в логи…
Сканирующая в фоне и ставящая блокеры на команды разработки (тут уже можно под контролем человека) автоматика рулит. От простейшей по ключевым словам, до сколь угодно сложной. Посоветовать не могу, таких публичных решений не знаю.
Есть разница между «общее хранилище как единый инстанс эластика» и «managed elastic, который может себе поднять сам по общим шаблонам». В первом случае там ещё 100500 вопросов возникает вроде мультитенантности, разделения костов по потребителям и пр. Т.е. необходимо централизованное, но «не совсем» решение
Это уже совсем дело вкуса и маштабов. И то и то типовое и подходит под условие у всех все одинаково.
Главное что бы не было у одних эластик, у вторых кликхаус, у третих текстовые логи и обертка самописная над ними. В этот момент стоит задуматься и обобщить лучшие практики. И заставить всех на них перейти. Хотя бы за год.
штука действительно интересная, если нет желания городить страшилу из графаны и эластиков, а нужно быстро сориентироваться по событиям из разных мест.
Спасибо.
это я недосмотрел, или нет ссылки на гит?
Недосмотрели, да.
Больше похоже на самобытный такой хоум-проект, который можно заодно толкнуть в универе как курсач.
А если по теме, то всё давно изобретено — clickhouse, ELK
clickhouse, ELK — это другое, они — агрегаторы логов, они индексируют содержимое в отдельной базе, иногда это оверкил. Моя штука нужна когда просто хочешь посмотреть содержимое лог-файла.
Пока заметил, что даже небольшое несовпадение паттерна в конфиге с паттерном в логе ломает весь парсинг.
Будем посмотреть. Спасибо!
Круто! То что нужно! Собирался в свободное время написать что-то похожее, но вы меня сильно опередили. На проде есть кластер из 3 нодов, пока проходит сертификация и rollout приложения нужно часто копаться в логах. А использовать SSH+консоль контрпродуктивно. А ELK и прочаие сторонние тулзы не предусмотрены контрактом.
Есть пожелание по поводу настройки работы с rolled-файлами. Допустим роллинг файлов сконфигурирован по паттерну: service.${hostname}_%d{yyyy-MM-dd}.%i.log, то есть текущий лог записывается на каждой ноде в файл service.nodeX.log, который потом заворачивается в напр. service-nodeX_2021-01-20.0.log по дате и лимиту в МБ. Насколько я понял, для того, чтобы сработал мёрж нужно указать все файлы на всех нодах вручную, а мы точно не знаем сколько их. Поэтому в шорткатах будет очень удобно иметь возможность использовать URL-параметры и wildcards|regexp для задания фильтра на файлы, а также указывать имя хоста:
log-paths = {
daily = {
file = [
${HOME}"/my-app/logs/service.node-cn-01_${date}.*.log@node-cn-01",
${HOME}"/my-app/logs/service.node-cn-02_${date}.*.log@node-cn-02",
${HOME}"/my-app/logs/service.node-cn-03_${date}.*.log@node-cn-03"
]
}
}И использовать в URL типа http://localhost:8111/log?log=daily&date=2020-01-20.
Новый подход к просмотру логов