Re: Разбор ошибок в логах.
On 2017-06-22, Eugene Berdnikov wrote:
> On Thu, Jun 22, 2017 at 10:31:05AM +0300, Oleksandr Gavenko wrote:
>> * длиннючие строки, grep в терминале бессмысленен, через ag в Emacs исследую
>
> У меня xterm длинные строки не обрубает, а показывает в несколько строк,
> и боюсь, у него это по дефолту. :) Вообще, есть less, он умеет и обрубать,
> и переносить, и менять режим на ходу (-S). Чтобы легче было что-то найти
> в длинной выдаче грепа, рекомендуется ставить ключик --color=auto.
>
10 переводов строк и уже нечитабельно. В Emacs по С-s можно двигаться к
нужному месту, есть история поиска и подсветка кусочков по регулярке в разные
цвета...
>> * в случае трейсов они многострочные - grep не работает
>
> У грепа есть ключики -A и -B, рекомендую.
>
grep -B120 ?? В отличии от Python причина ошибки в Java трейсе в конце...
>> * события раскиданы по группе файлов, пока копаешься в одном, фокус на тройку
>> других теряеться (может многотабовый редактор тут поможет, я не уверен)
>
> Создатель поставил человеку мозг, который способен держать в фокусе
> внимания от 3 до 7 объёктов одновременно. А уж как эти объекты перед своим
> носом повесить -- дело вкуса: некоторые подключают к компу три монитора.
>
Если в конкретном логе сосредоточился на группе 7 событий?
Если разбор конкретного лога длиться 30 сек? Кратковременная память
человека в среднем 20 сек и в пиках до 40 сек?
>> * события из разных потоков перемешаны между собою, фильтрация из-за
>> многострочных трейсов by grep невозможна
>
> Вы о логах или трейсах? Трейсы в Java это отдельный мотив для суицида... :)
>
Трейс всегда идет как дополнение к комплекту. Что можно достать из события:
https://logback.qos.ch/apidocs/ch/qos/logback/classic/spi/ILoggingEvent.html
Трейсы всегда полезны и позволяют зачастую воссоздать довольно реалистично
состояние приложения.
На них смотрят если они важны. Вопрос в фильтрации, что бы не смотреть на
ненужные и grep не поможет фильтровать текстовую сериализацию ILoggingEvent.
>> Согласны ли Вы терять события в случае недоступности колектора логов или
>> гранилища логов?
>
> Терять? Я согласен. У меня есть, например, распределённая (по паре городов)
> почтовая система, и сетевой коллектор логов. При проблемах с сетью, понятно,
> часть записей может быть потеряна при передаче, даже при высоком уровне
> резервирования межофисных каналов. Но меня это не волнует. Во-первых,
> есть ещё локальные хранилища логов на узлах, если что -- можно свериться
> с ними. Во-вторых, я уверен, что при недостатке каких-то фрагментов я это
> замечу. Ну и в третьих, необязательно заливать всё в хранилище на лету,
> если нужна полнота -- есть масса способов надёжно реплицировать данные
> по сети, пожертвовав риалтаймом. Но эти способы дороже простого риалтайма,
> и мне с ними заморачиваться не хочется.
>
Под репликацией Вы подразумеваете передачу файлов без понимания внутренней
структуры? Тут тоже есть засада с ротацией файлов (придеться именовать файлы
по датам, а не .1, .2, ...) и особо себя вести с обновляемым логом (в который
щас пишут).
Filebeat по назначению такое умеет, понимая ротацию и детектируя запись и
"восстанавливаясь" после своего падения или падения колектора логов (есть
баги, не всегда это делает успешно) и еще бесплатный и "практически
реалтаймовый".
--
http://defun.work/
Reply to: