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/
