Re: Разбор ошибок в логах.
On 2017-06-22, Tim Sattarov wrote: > транспортный протокол (порт 9300) удобнее в каких то случаях, но я > пользовался только REST (9200) > клиенты расписаны здесь > https://www.elastic.co/blog/found-java-clients-for-elasticsearch > https://www.elastic.co/guide/en/elasticsearch/client/index.html Есть проблема с их Java API. Мне интересно только Bulk API, по зависимостям они танут весь Netty + Lucene: https://www.elastic.co/guide/en/elasticsearch/client/java-api/current/java-docs-bulk.html Итого 26 MiB. Хоть и будут толкать вроде по 9300 порту, не думаю что как либо умнее чем это сделает curl / HttpURLConnection... -- http://defun.work/
Re: Разбор ошибок в логах.
Tim Sattarov -> debian-russian@lists.debian.org @ Thu, 22 Jun 2017 23:22:29 -0400: > небольшой оффтопик: > Кстати, мне интересно, что все катят бочку на systemd, и никто не > жалуется на rsyslog. > Если посмотреть, как они меняют формат конфига, шифруются с > документацией и предлагают свои платные сервисы по настройке всего, тут > явный шкурный интерес. и это один из основных сервисов в системе, > ставится тоже по умолчанию и имеет кучу обратных зависимостей. Чо, у нас реально есть пакеты, которые зависят не от любого демона, обрабатывающего логи, а именно от rsyslog? Я, кстати, лениво подумываю заменить его на что-нибудь более толковое. А то у меня он что-то конфиги читает только при перезапуске, а при старте системы - нет...
Re: Разбор ошибок в логах.
On 22/06/17 06:42 PM, Oleksandr Gavenko wrote: > Есть подозрение что конечным пунктом у Вас Elasticsearch. Да, он самый ( и да, можно просто на "ты" ) > В общем я не в восторге от Logstash - требования по памяти нереальные и > реализован на JRuby. Для "низкоуровневых" сервисов типа > сбора/роутинга/доставки > событий крайне печально выглядит. > > В основном то пользуються что бы обогатить события геотегом и определить > тип девайсика на кофейной гуще. Если я ошибаюсь - поправьте! Это то чем я в основном пользуюсь, про кофейную гущу, это конечно сильно, вполне себе база расшифровки user-agent, по конкретным полям Но может он больше, просто на моих объёмах я не хочу перегружать его лишней логикой. https://www.elastic.co/guide/en/logstash/current/filter-plugins.html > Даже сама компания-производитель для обогащения данных в Elasticsearch в > момент инсерта придумала Ingest Nodes, почитайте: > > https://www.elastic.co/blog/new-way-to-ingest-part-1 > > What are Ingest Nodes? > > Ingest Nodes are a new type of Elasticsearch node you can use to perform > common data transformation and enrichments. Ingest node нужна для прямолинейного ввода данных, примерно так же как в моём сценарии, когда данные идут уже в готовом виде и никакой обработки в процессе не нужно. Если нужны нестандартные пути ввода, вывода и фильтрация - без logstash в этом решении не обойтись. Я как раз был на ElasticON, когда они объявили версию 5 и все эти новые типы нод. Кстати, тогда же они объявили, что переписали часть logstash на чистой Java. и продолжают переписывать и отказываться от JRuby > > Я API не раскопал для доступа к этой ноде. Пока эксперементировал с REST/Json > PUSH запросом на порт 9200. По 9300 можно типа как то эфективней вбрасывать, > это порт общения между нодами в кластере, но протокол тоже не особо > документирован. весь ingest node API это pipelines и HTTP PUT в эти пайпы. https://www.elastic.co/guide/en/elasticsearch/reference/5.4/ingest.html я сам не пользуюсь пока новыми нодами, потому что пока остался на версии 2.x транспортный протокол (порт 9300) удобнее в каких то случаях, но я пользовался только REST (9200) клиенты расписаны здесь https://www.elastic.co/blog/found-java-clients-for-elasticsearch https://www.elastic.co/guide/en/elasticsearch/client/index.html я думаю, при желании можно разобраться в протоколе или просто использовать библиотеки доступа. > Я смотрю на https://redis.io/topics/introduction и не понимаю как применить на > практике... Пример расписан здесь: http://www.rsyslog.com/coupling-with-logstash-via-redis/ Другой вариант, о котором все говорят для буферизации это Apache Kafka (тоже Java) небольшой оффтопик: Кстати, мне интересно, что все катят бочку на systemd, и никто не жалуется на rsyslog. Если посмотреть, как они меняют формат конфига, шифруются с документацией и предлагают свои платные сервисы по настройке всего, тут явный шкурный интерес. и это один из основных сервисов в системе, ставится тоже по умолчанию и имеет кучу обратных зависимостей. > Пока не ясно как эфективно сериализовать в файл и как помечать записаное / > прочитаное, что бы файлы были в консистентном состонии, если само приложение > упадет. Можно писать в файл и скормить этот файл rsyslog, он будет отслеживать последнюю позицию, до которой все события отправлены. он же может отсылать данные, пока не получит подтверждения о приёме. примеры на том же rsyslog.com. > Потому доставкой события разумно повесить на само приложение, исключая > пропажу сообщений, если колектор логов слишком долго в даунтайме. я у себя отдаю всё действия связанные с логами специализированной программе - (r)syslog. Тот самый доморощенный Unix-way, о котором все говорят: программа делает одно и делает это хорошо. rsyslog может собирать события с клиентов, протокол общения выверен годами, специализированных клиентов обычно не нужно. Формат выдачи можно настроить по желанию (я перевожу в JSON, то, что ещё не переведено клиентом, на стороне rsyslog) rsyslog стоит везде, ставить отдельный сборщик типа filebeats я не хотел, лишнее звено. а потом уже rsyslog может переслать всё по сети в центральное хранилище, можно по JSON поверх TCP, можно по протоколу syslog, как будет удобнее. Если сервера долго живущие, и на них можно заходить и смотреть локальные логи - то, конечно, лучше держать копию локально. В динамической среде приходится надеяться на центральное хранилище: сервер может быть в любой момент остановлен и удалён. небольшое отступление про ELK (основная тройка продуктов от elastic.co): мне совершенно не нравится как и на чем они написаны, всей душой не люблю ни Java, ни Ruby ни Nodejs с его npm. Но, к сожалению, ничего лучше на рынке пока нет. Идея хорошая и та часть, с которой общаются пользователи, тоже неплоха. Радостно видеть, что они наконец начинают переходить на Golang (все *Beats). полностью с Java они не уйдут, так как используют Apache Lucene.
Re: Разбор ошибок в логах.
On 2017-06-22, Eugene Berdnikov wrote: > Оракл, к примеру, именно так и делает. В лог он пишет: ошибка такая-то, > сгенерён трейс-файл, лежит там-то. Если нужно, идёшь и смотришь трейс. Сколько инстансов Оракла в организации? В модном облаке может быть сотни сервисов и по ssh никто не лазит. Я не работал в такой организации, не представляю как они собирают логи, скорее всего покупают некое решение. Суть в том что "плохую ноду" просто убивают и в течении минуты развертываеться новая. А данные для разбора инцидента сохранены отдельно. Идея отдельного файла для трейса небось связана с поддержкой продукта. Отправить в супорт выделенный файлик проще чем рассказывать как вычленить из иных мест... Кстати в традициях Java компонентов плевать много стек-трейсов. inode'ы закончаться очень быстро. Я столкнулся раз с таким в IDE NetBeans, они на каждый ивент пользовательского ввода писали файл. Я их час удалял с загрузочной флешки )) -- http://defun.work/
Re: Разбор ошибок в логах.
On 2017-06-22, Tim Sattarov wrote: > я, чтобы избежать тормозов logstash, на всех источниках логов, где мог, > включил/настоял на JSON вывод. > теперь он только занимается складированием логов плюс небольшая логика > по развёртыванию geoip и user-agent информации. Есть подозрение что конечным пунктом у Вас Elasticsearch. В общем я не в восторге от Logstash - требования по памяти нереальные и реализован на JRuby. Для "низкоуровневых" сервисов типа сбора/роутинга/доставки событий крайне печально выглядит. В основном то пользуються что бы обогатить события геотегом и определить тип девайсика на кофейной гуще. Если я ошибаюсь - поправьте! Даже сама компания-производитель для обогащения данных в Elasticsearch в момент инсерта придумала Ingest Nodes, почитайте: https://www.elastic.co/blog/new-way-to-ingest-part-1 What are Ingest Nodes? Ingest Nodes are a new type of Elasticsearch node you can use to perform common data transformation and enrichments. Легковесными сборшиками / мониторилками событий (серия *Beat от elastic.co) они впихивают данные уже напрямую в Ingest Nodes, минуя logstash. Ведь сама Elasticsearch - маштабируемая, работает в кластере с протоколами резервированния / балансировки данных. Я API не раскопал для доступа к этой ноде. Пока эксперементировал с REST/Json PUSH запросом на порт 9200. По 9300 можно типа как то эфективней вбрасывать, это порт общения между нодами в кластере, но протокол тоже не особо документирован. > По поводу потерь логов и буферизации - рекоммендуют использовать redis > или что то подобное. Я пока не заморачивался, но придётся. > Поток и размер логов стремительно растёт. > Я смотрю на https://redis.io/topics/introduction и не понимаю как применить на практике... Пока рассматривал такую идею логгера. Собирать события в очереди и по обьему / времени отправлять пачки по сети в рамках самого процеса. Если сервис не доступен или очередь переполнилась - писать на диск. Затем записанное отправить в более удачное время. Ключевым вижу (а Java позволяет) запустить отдельный поток отправляющий данные, выбрать неблокирующую очередь для сбора событий и сериализовать избыточные события в файлы. И все в рамках одного PID. Пока не ясно как эфективно сериализовать в файл и как помечать записаное / прочитаное, что бы файлы были в консистентном состонии, если само приложение упадет. Самым надежным местом записи есть файл. Всевозможные колекторы событий, слушащие порт рано или позно перегружаються и не будут недоступны. Потому доставкой события разумно повесить на само приложение, исключая пропажу сообщений, если колектор логов слишком долго в даунтайме. -- http://defun.work/
Re: free software-friendly hardware
> Andrey Jr Melnikov writes: > Ivan Shmakov wrote: > Andrey Jr Melnikov writes: > Ivan Shmakov wrote: Ну разве что в РФ их [Purism], я так понимаю, массово не возят. По причине широкого выбора моделей, дружественных к иного рода ПО. >>> Дорого и неэффективно. Проще купить Xiaomi Air 13.3 на Core >>> i7-7500U/8GB/256GB-SSD - >>> https://xiaomi-mi.com/notebooks/xiaomi-mi-notebook-air-133-fingerprint-ed-i7-8gb256gb-silver/ >>> он хоть стоит меньше и вайфай 2х диапазанный и не atheros. >> И как у него с поддержкой Debian? На всякий случай напомню: >> «non-free» — это не Debian. > С такими запросами - к Столману. Это с каких это пор он занимается производством/поставкой оборудования? Напротив, Purism — занимается; и «ЦА» у них именно пользователи свободного ПО. В отличие от. > А то ща будет открытием, что intel microcode загружаемый в процессор > тоже non-free, но вет без него он может глючить в специфических > случаях, а free - нет и не предвидится. Без микрокода процессор не работает вовсе. Другое дело, что есть выбор между уже загруженным «заводским», и загружаемыми обновлениями. Свободным ПО, строго говоря, не является ни то, ни другое. Только проблема наличия на кристалле вспомогательного процессора (AKA Intel ME), неподконтрольного пользователю вовсе, — несколько актуальнее будет, IMO. > С поддержкой у ядра всё нормально, с "поддержкой" Debian - нет, > ожидайте, пока 4.11.x ядро достаточно протухнет, чтоб попало в > stable. Или хотя-бы в backports. Пересобрать ядро, при необходимости, мне проблемы не составит. Но если поставщик опять заладит про «тот получит две шкатулки если установит blob-ы» — мне его и даром не надо. Пусть сия машина найдет себе более другого покупателя. В виде пользователя Steam, или еще чего. -- FSF associate member #7257 np. Parallax — Johan Andersson 3013 B6A0 230E 334A
Re: free software-friendly hardware
22.06.2017 22:22, Andrey Jr. Melnikov пишет: > Ivan Shmakov wrote: >>> Andrey Jr Melnikov writes: >>> Ivan Shmakov wrote: > >> [???] > >> >> Ну разве что в РФ их [Purism], я так понимаю, массово не возят. >> >> По причине широкого выбора моделей, дружественных к иного рода ПО. > >> > Дорого и неэффективно. Проще купить Xiaomi Air 13.3 на Core >> > i7-7500U/8GB/256GB-SSD - >> > >> https://xiaomi-mi.com/notebooks/xiaomi-mi-notebook-air-133-fingerprint-ed-i7-8gb256gb-silver/ >> > он хоть стоит меньше и вайфай 2х диапазанный и не atheros. >> И как у него с поддержкой Debian? На всякий случай напомню: >> ??non-free?? ??? это не Debian. > С такими запросами - к Столману. Столлман двигает эту политику, это хорошо, но не каждый, кто пользуется Debian - Столлман. > А то ща будет открытием, что intel microcode > загружаемый в процессор тоже non-free, но вет без него он может глючить в > специфических случаях, а free - нет и не предвидиться. > Да никакое не открытие: бинарный блоб, да и торчит он в разделе non-free. > С поддержкой у ядра всё нормально, с "поддержкой" Debian - нет, ожидайте, > пока 4.11.x ядро достаточно протухнет, чтоб попало в stable. Или хотя-бы в > backports. > Дык зачем использовать stable, когда testing уже вполне стабилен?
Re: free software-friendly hardware
Ivan Shmakov wrote: > > Andrey Jr Melnikov writes: > > Ivan Shmakov wrote: > [???] > >> Ну разве что в РФ их [Purism], я так понимаю, массово не возят. > >> По причине широкого выбора моделей, дружественных к иного рода ПО. > > Дорого и неэффективно. Проще купить Xiaomi Air 13.3 на Core > > i7-7500U/8GB/256GB-SSD - > > > https://xiaomi-mi.com/notebooks/xiaomi-mi-notebook-air-133-fingerprint-ed-i7-8gb256gb-silver/ > > он хоть стоит меньше и вайфай 2х диапазанный и не atheros. > И как у него с поддержкой Debian? На всякий случай напомню: > ??non-free?? ??? это не Debian. С такими запросами - к Столману. А то ща будет открытием, что intel microcode загружаемый в процессор тоже non-free, но вет без него он может глючить в специфических случаях, а free - нет и не предвидиться. С поддержкой у ядра всё нормально, с "поддержкой" Debian - нет, ожидайте, пока 4.11.x ядро достаточно протухнет, чтоб попало в stable. Или хотя-бы в backports.
Re: optical media
300? На прежней моей работе было более 3000 дисков архива. Собственно, и сейчас есть, хотя новые данные идут на НЖМД. […] Суровые вы ребята. Эксперты рекомендуют: https://cld.bz/users/user-WmA6B3j/Arctic-World-Archive/1 Плёнка - лучший вариант. :-) http://www.piql.com/
Re: Установить debian без systemd
22.06.2017 17:42, Sohin Vyacheslav пишет: 22.06.2017 17:39, Konstantin Matyukhin пишет: Бэкапить флэшки значительно удобнее и быстрее. согласен, но сколько нужно флешек, чтобы забэкапить правильного размера музколлекцию, скажем лет за 20-30? Если коллекция на СД - несколько дисков, скорее всего, уже не читаются, и бекапить уже поздно.
Re: Установить debian без systemd
> > > 22.06.2017 17:39, Konstantin Matyukhin пишет: > >> Бэкапить флэшки значительно удобнее и быстрее. > > согласен, но сколько нужно флешек, чтобы забэкапить правильного размера > > музколлекцию, скажем лет за 20-30? > > > А сколько это в граммах^W гигабайтах ? > В этом случае больше подойдет NAS c рейдом, конечно. Флешка оно больше для взять в поездку, послушать в машине и пр. -- С уважением, Константин Матюхин
Re: Разбор ошибок в логах.
On Thu, Jun 22, 2017 at 10:58:08AM -0400, Tim Sattarov wrote: > On 22/06/17 10:51 AM, Eugene Berdnikov wrote: > > Лог пишется для человека, для его чтения глазками. Поэтому записи в логе > > следует делать краткими и информативными. > Вот не соглашусь, я в своей компании с этим борюсь. Логи, особенно в > больших количествах (у нас сейчас десятки миллионов событий в день) > должны быть машиночитаемы. Чтобы можно было делать правильный анализ. Maшиночитаемость (структурированость) не противоречит информативности. > > Логи и трейсы можно смешивать, но это приводит к головной боли, которая > > Вам не даёт покоя. :) > Лучше не смешивать, а складывать трейсы в отдельное хранилище. Если > можно, конечно :) Оракл, к примеру, именно так и делает. В лог он пишет: ошибка такая-то, сгенерён трейс-файл, лежит там-то. Если нужно, идёшь и смотришь трейс. -- Eugene Berdnikov
Re: Разбор ошибок в логах.
On 22/06/17 10:51 AM, Eugene Berdnikov wrote: > On Thu, Jun 22, 2017 at 04:15:54PM +0300, Oleksandr Gavenko wrote: >>> Сделайте отладочную выдачу короткой и осмысленной, и наступит облегчение. >>> А для трейсов напишите свой фильтр, выделяющий нужные фрагменты. >> Запись в текстовый файл в одну строку - решение для 80-ых. Структурированые >> данные легче фильтровать, чем выкручиваться regex'ами. > Вы, похоже, опять путаете отладочную выдачу (лог) и трейсы с дампами. > > Лог пишется для человека, для его чтения глазками. Поэтому записи в логе > следует делать краткими и информативными. Вот не соглашусь, я в своей компании с этим борюсь. Логи, особенно в больших количествах (у нас сейчас десятки миллионов событий в день) должны быть машиночитаемы. Чтобы можно было делать правильный анализ. > Логи и трейсы можно смешивать, но это приводит к головной боли, которая > Вам не даёт покоя. :) Лучше не смешивать, а складывать трейсы в отдельное хранилище. Если можно, конечно :)
Re: Разбор ошибок в логах.
On Thu, Jun 22, 2017 at 04:15:54PM +0300, Oleksandr Gavenko wrote: > > Сделайте отладочную выдачу короткой и осмысленной, и наступит облегчение. > > А для трейсов напишите свой фильтр, выделяющий нужные фрагменты. > > Запись в текстовый файл в одну строку - решение для 80-ых. Структурированые > данные легче фильтровать, чем выкручиваться regex'ами. Вы, похоже, опять путаете отладочную выдачу (лог) и трейсы с дампами. Лог пишется для человека, для его чтения глазками. Поэтому записи в логе следует делать краткими и информативными. Трейсы же, даже если они текстовые, содержат детальную информацию о поведении программы и значениях переменных. Они могут быть обработаны различными инструментами, если грамотно структурированы. Логи и трейсы можно смешивать, но это приводит к головной боли, которая Вам не даёт покоя. :) -- Eugene Berdnikov
Re: Установить debian без systemd
On 22/06/17 10:42 AM, Sohin Vyacheslav wrote: > > 22.06.2017 17:39, Konstantin Matyukhin пишет: >> Бэкапить флэшки значительно удобнее и быстрее. > согласен, но сколько нужно флешек, чтобы забэкапить правильного размера > музколлекцию, скажем лет за 20-30? > А сколько это в граммах^W гигабайтах ?
optical media
> Andrey Jr Melnikov writes: > artiom wrote: > 21.06.2017 14:03, Victor Wagner пишет: > On Wed, 21 Jun 2017 12:55:23 +0200 Konstantin Matyukhin wrote: [Рассылка, похоже, взялась и за мои сообщения.] В чем преимущество CD/DVD-ROM перед USB-флешками? Рискну предположить: в цене за GiB? >>> В том, что DVD в коробочке с красивой оберткой замечательно >>> смотрится на полке. >> Пока их мало. Затем, уже не до обёрточек. И вырастают бобины с >> болванками. Пластиковые конверты в коробке соответствующих габаритов (вариант: папке A5) — удобнее. > Ага. А лет через нцать выяснится, что «убер дорогой DVD арыгыналь, > да?» был произведен дядюшкой Ляо в подвале из некачественного > пластика и помутнел. Как впрочем и линза у привода. На всякий случай проверил; DVD+R, записан 2006-11-15, — как будто бы читается. Полезной привычки сохранять на диске контрольные SHA-1/2 я тогда еще не приобрел, но $ bzip2 -t дает «ok». Хотя да — привод, который его писал, давно «сдан в архив.» По причине перехода на SATA. С другой стороны, приводы жестких дисков тоже не застрахованы ни от прихода в негодность, ни от появления новых интерфейсов. >>> А держать архивы фильмов на USB-флешках по фильму на флешку >>> довольно неудобно. >> Держите на СХД или USB HDD. > Нее, на болванках лучше. У меня один из друзей разбирая антресоль > вынул оттудова штук 300 болванок с фильмами, посмотрел на них и снес > на помойку. 300? На прежней моей работе было более 3000 дисков архива. Собственно, и сейчас есть, хотя новые данные идут на НЖМД. […] -- FSF associate member #7257 58F8 0F47 53F5 2EB2 F6A5 8916 3013 B6A0 230E 334A
Re: Установить debian без systemd
22.06.2017 17:39, Konstantin Matyukhin пишет: > > Бэкапить флэшки значительно удобнее и быстрее. согласен, но сколько нужно флешек, чтобы забэкапить правильного размера музколлекцию, скажем лет за 20-30? -- BW, Сохин Вячеслав
Re: Установить debian без systemd
> > все, что на флешках и винтах до долгосрочной перспективы и не дотянет > наверное - или перезапишется в виду пояления "более свежего" контента > или флешка/винт умрет, а CD возможно будет читаться)) Бэкапить флэшки значительно удобнее и быстрее. -- С уважением, Константин Матюхин
Re: Установить debian без systemd
22.06.2017 16:31, Oleksandr Gavenko пишет: > Есть разные технологии нарезки CD/DVD. "Домашние" перестают читаться за 5 лет > лежания в конверте. ну наверное 5 лет плюс/минус... вообще держать на дисках долгосрочные коллекции музыки/фильмов, а на флешках софт - это логичная практика IMHO, не весь же контент держать только на флешках и винтах? все, что на флешках и винтах до долгосрочной перспективы и не дотянет наверное - или перезапишется в виду пояления "более свежего" контента или флешка/винт умрет, а CD возможно будет читаться)) -- BW, Сохин Вячеслав
Re: Разбор ошибок в логах.
On 22/06/17 09:15 AM, Oleksandr Gavenko wrote: > > Запись в текстовый файл в одну строку - решение для 80-ых. Структурированые > данные легче фильтровать, чем выкручиваться regex'ами. > Поддерживаю я, чтобы избежать тормозов logstash, на всех источниках логов, где мог, включил/настоял на JSON вывод. теперь он только занимается складированием логов плюс небольшая логика по развёртыванию geoip и user-agent информации. Единственная проблема с длинными строками, пока не смог побороть rsyslog, чтобы не резал По поводу потерь логов и буферизации - рекоммендуют использовать redis или что то подобное. Я пока не заморачивался, но придётся. Поток и размер логов стремительно растёт.
Re: Установить debian без systemd
On 2017-06-21, Andrey Jr. Melnikov wrote: > Надо будет при случае найти CD 2002 года с музыкой и проверить - читается > или нет. Есть разные технологии нарезки CD/DVD. "Домашние" перестают читаться за 5 лет лежания в конверте. Маркетинговые заявления про 120 лет (выведенные старением через повышеную температуру) - чушь. Тут есть толковый материал по деградации лазерных дисков (на научных публикациях) http://www.cd-info.com/archiving/ -- http://defun.work/
Re: Разбор ошибок в логах.
On 2017-06-22, Eugene Berdnikov wrote: > Здесь мы уходим от исходного утверждения "grep в терминале бессмысленен". > В less тоже есть подсветка, кстати. > >> grep -B120 ?? В отличии от Python причина ошибки в Java трейсе в конце... > > Здесь мы уходим от исходного утверждения "grep не работает". Работает. > Только задаче он не сильно адекватен, но это уже другой вопрос. > Игра словами. Я не разбирался есть ли в less закладки. Но это потому что пока я умею наиболее эфективно в Emacs копаться по логам. Кстати Emacs на длинных строках (в десятки переводов строк) - тормозной. Кроме трейсов есть еще длиннющие SQL запросы от ORM. Интерес зачастую представляет "from", что можно поиском найти. Или попросить ORM отформатировать однострочник в многострочник - становящийся читаемым. > Тогда ещё одно событие, и мозг будет вынесен. :) Зато будет повод > отвлечься и подумать о том, как структурировать отладочный вывод. > Возможно, также упорядочить код и переделать структуры данных. > Вот я и задумался )) В век, когда серверов много и приложения строятся на готовых компонентах (черных ящиков) централизированая, унифицированая система разбора логов - это уже не модно, а рабочий инструмент. Цены от провайдеров комплексных решений в килобаксах в год. Не разумно за сотню мегабайт логов в неделю отдавать такие деньги. > У разработчика всегда есть выбор средств отладки. Он может пользоваться > printf() и его аналогами, а может копаться в дампах, трейсах, ковыряться > в программе дебаггером и т.д. При выборе неадекватного средства появляются > шансы захлебнуться в потоках дерьма, особенно при близости к Java. > Не, у разработчика есть что другие сделали. Если ничего не сделали, то ничего и нету. printf() мой любимейший способ. Но он работает только: * по знакомой кодобазе или имплементации знакомого протокола * открытых исходниках В чужих незнакомых компонентах printf() не работает. Т.е. суть метода - подтвердить или опровергнуть гипотезу, вставив printf() в *правильное* место. Логирование - аналог отладочного printf(), только систематично/структурировано. > Сделайте отладочную выдачу короткой и осмысленной, и наступит облегчение. > А для трейсов напишите свой фильтр, выделяющий нужные фрагменты. Запись в текстовый файл в одну строку - решение для 80-ых. Структурированые данные легче фильтровать, чем выкручиваться regex'ами. -- http://defun.work/
Re: Разбор ошибок в логах.
On Thu, Jun 22, 2017 at 12:12:55PM +0300, Oleksandr Gavenko wrote: > 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 в терминале бессмысленен". В less тоже есть подсветка, кстати. > >> * в случае трейсов они многострочные - grep не работает > > > > У грепа есть ключики -A и -B, рекомендую. > > > grep -B120 ?? В отличии от Python причина ошибки в Java трейсе в конце... Здесь мы уходим от исходного утверждения "grep не работает". Работает. Только задаче он не сильно адекватен, но это уже другой вопрос. > >> * события раскиданы по группе файлов, пока копаешься в одном, фокус на > >> тройку > >> других теряеться (может многотабовый редактор тут поможет, я не уверен) > > > > Создатель поставил человеку мозг, который способен держать в фокусе > > внимания от 3 до 7 объёктов одновременно. А уж как эти объекты перед своим > > носом повесить -- дело вкуса: некоторые подключают к компу три монитора. > > > Если в конкретном логе сосредоточился на группе 7 событий? Тогда ещё одно событие, и мозг будет вынесен. :) Зато будет повод отвлечься и подумать о том, как структурировать отладочный вывод. Возможно, также упорядочить код и переделать структуры данных. > > Вы о логах или трейсах? Трейсы в Java это отдельный мотив для суицида... :) > > > Трейс всегда идет как дополнение к комплекту. Что можно достать из события: > > https://logback.qos.ch/apidocs/ch/qos/logback/classic/spi/ILoggingEvent.html > > Трейсы всегда полезны и позволяют зачастую воссоздать довольно реалистично > состояние приложения. У разработчика всегда есть выбор средств отладки. Он может пользоваться printf() и его аналогами, а может копаться в дампах, трейсах, ковыряться в программе дебаггером и т.д. При выборе неадекватного средства появляются шансы захлебнуться в потоках дерьма, особенно при близости к Java. Сделайте отладочную выдачу короткой и осмысленной, и наступит облегчение. А для трейсов напишите свой фильтр, выделяющий нужные фрагменты. -- Eugene Berdnikov
Re: Ищу голосовую общалк у.
On 22.06.2017 10:42, sergio wrote: Я нашёл --- это Riot! https://riot.im А в чём плюсы, почему она?
Re: Ищу голосовую общалк у.
On 22.06.2017 12:16, Oleksandr Gavenko wrote: On 2017-06-22, Sohin Vyacheslav wrote: 22.06.2017 10:42, sergio пишет: Я нашёл --- это Riot! https://riot.im Current release: v0.11.3 не сыровато ли? Смотрю что Message-Id ведет к моему давнему вопросу. Из децентрализованых я пробовал Tox и Ring. Оба были год назад сырыми и неудачными решениями. Я также смотрел на наличие Android клиентов. Весь спектр "общалок" доступен для выбора на сайтах типа: http://alternativeto.net/software/tox/ Tox пока сыроват (реализация сырая).
Re: free software-friendly hardware
artiom писал(а) в своём письме Thu, 22 Jun 2017 13:00:52 +0300: NVIDIA-то чем опять не угодил? Натанцевался много лет назад и больше не хочу такой радости. И давеча принесли мне на «поиграться» Compaq TC1100, а у него, как на беду, nvidia. И дров к ней уже нет вообще. Legacy тоже нет уже, а совсем старые дрова знают только древние иксы. 12-я бубунта завелась, но с бубном, а всё свежее — только VESA, или nouveau, но глючно. С ATI такой проблемы нет вообще. Старьё нормально работает с открытыми дровами и не жужжит (есть бук 2006-го года). Свежие нормально работают с любыми дровами. У ати своих проблем хватает. Compaq TC1100, я посмотрел, вообще раритет, там не то, что 2006-й, в 2005-м поддержку его закончили. Не знаю, для чего на старьё ставить проприетарные дрова от нвидии (хотя легаси должен поддерживать). Вот как раз legacy и не поддерживает уже, им не древнее 2009-го железку подавай. Не, я понимаю что железка — окаменелость, но для ATI есть открытые дрова, которые работает даже с окаменелостями, а вот с nvidia — фигвам. Ну ATI тоже не сказка. Адепты ATI колются, но продолжают жрать свой кактус: нестабильное железо и периодически не собирающиеся драйвера. Не спорю. Что ATI, что intel, что nvidia — у всех есть неудачные железки и дрова. И все они кактусы, каждый по своему. Но лично мне с nvidia не очень везло. А новая система на окаменелостях - это очень редкий кейс. Ну, если железка работает и вполне справляется с задачами — отчего же не использовать её? Но конкретно этот компак мне дали на «поиграться», не более. Поигрался и отдал. С весой работает, и ладно. Не игры же вы на нём собрались гонять? Да даже просто окошки тормозят, какие уж там игры. Так проблема не в весе, наверное, вы не KDE туда навернули? :-) KDE 4 (debian jessie) прекрасно работает на MSI S271 10-и летней давности. А на компаке ubuntu 12. Там то ли unity, то ли что-то похожее. Но я подозреваю что там всё таки сама видюха сильно слабая — родная XP тоже не блещет скоростью оконного интерфейса. -- Написано с помощью почтового клиента Opera: http://www.opera.com/mail/
Re: free software-friendly hardware
22.06.2017 05:12, Ivan Shmakov пишет: >> Andrey Jr Melnikov writes: >> Ivan Shmakov wrote: > > […] > > >> Ну разве что в РФ их [Purism], я так понимаю, массово не возят. > >> По причине широкого выбора моделей, дружественных к иного рода ПО. > > > Дорого и неэффективно. Проще купить Xiaomi Air 13.3 на Core > > i7-7500U/8GB/256GB-SSD - > > > https://xiaomi-mi.com/notebooks/xiaomi-mi-notebook-air-133-fingerprint-ed-i7-8gb256gb-silver/ > > он хоть стоит меньше и вайфай 2х диапазанный и не atheros. > > И как у него с поддержкой Debian? На всякий случай напомню: > «non-free» — это не Debian. > Судя по железу, я могу сказать, что неплохо, хотя и есть маленькие проблемы. Non-free имеет минус разве что с точки зрения безопасности (драйвер следит за тобой o.O ) и с точки зрения политики. А Debian на нём вполне себе комфортно будет работать.
Re: free software-friendly hardware
NVIDIA-то чем опять не угодил? >>> Натанцевался много лет назад и больше не хочу такой радости. И давеча >>> принесли мне на «поиграться» Compaq TC1100, а у него, как на беду, >>> nvidia. И дров к ней уже нет вообще. Legacy тоже нет уже, а совсем >>> старые дрова знают только древние иксы. 12-я бубунта завелась, но с >>> бубном, а всё свежее — только VESA, или nouveau, но глючно. С ATI такой >>> проблемы нет вообще. Старьё нормально работает с открытыми дровами и не >>> жужжит (есть бук 2006-го года). Свежие нормально работают с любыми >>> дровами. >>> >> У ати своих проблем хватает. >> Compaq TC1100, я посмотрел, вообще раритет, там не то, что 2006-й, в >> 2005-м поддержку его закончили. >> Не знаю, для чего на старьё ставить проприетарные дрова от нвидии (хотя >> легаси должен поддерживать). > Вот как раз legacy и не поддерживает уже, им не древнее 2009-го железку > подавай. > Не, я понимаю что железка — окаменелость, но для ATI есть открытые > дрова, которые работает даже с окаменелостями, а вот с nvidia — фигвам. > Ну ATI тоже не сказка. Адепты ATI колются, но продолжают жрать свой кактус: нестабильное железо и периодически не собирающиеся драйвера. А новая система на окаменелостях - это очень редкий кейс. >> С весой работает, и ладно. Не игры же вы на нём собрались гонять? > Да даже просто окошки тормозят, какие уж там игры. > Так проблема не в весе, наверное, вы не KDE туда навернули? :-)
Re: Ищу голосовую общалк у.
On 2017-06-22, Sohin Vyacheslav wrote: > 22.06.2017 10:42, sergio пишет: >> >> Я нашёл --- это Riot! >> >> https://riot.im >> > Current release: v0.11.3 > > не сыровато ли? > Смотрю что Message-Id ведет к моему давнему вопросу. Из децентрализованых я пробовал Tox и Ring. Оба были год назад сырыми и неудачными решениями. Я также смотрел на наличие Android клиентов. Весь спектр "общалок" доступен для выбора на сайтах типа: http://alternativeto.net/software/tox/ -- http://defun.work/
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/
Re: Ищу голосовую общалк у.
22.06.2017 10:42, sergio пишет: > > Я нашёл --- это Riot! > > https://riot.im > > Current release: v0.11.3 не сыровато ли? -- BW, Сохин Вячеслав
Re: Разбор ошибок в логах.
On Thu, Jun 22, 2017 at 10:31:05AM +0300, Oleksandr Gavenko wrote: > Я использую Java и логи ограничатся Java. > > Постоянно приходиться выяснять причину проблем через содержимое логов. > > Я встречаю сложности типа: > > * длиннючие строки, grep в терминале бессмысленен, через ag в Emacs исследую У меня xterm длинные строки не обрубает, а показывает в несколько строк, и боюсь, у него это по дефолту. :) Вообще, есть less, он умеет и обрубать, и переносить, и менять режим на ходу (-S). Чтобы легче было что-то найти в длинной выдаче грепа, рекомендуется ставить ключик --color=auto. > * в случае трейсов они многострочные - grep не работает У грепа есть ключики -A и -B, рекомендую. > * события раскиданы по группе файлов, пока копаешься в одном, фокус на тройку > других теряеться (может многотабовый редактор тут поможет, я не уверен) Создатель поставил человеку мозг, который способен держать в фокусе внимания от 3 до 7 объёктов одновременно. А уж как эти объекты перед своим носом повесить -- дело вкуса: некоторые подключают к компу три монитора. > * бессмысленная сложность из-за ротации файла > * из-за ротации файлов теряеться история, лазить в архивах очень больно > * события из разных потоков перемешаны между собою, фильтрация из-за > многострочных трейсов by grep невозможна Вы о логах или трейсах? Трейсы в Java это отдельный мотив для суицида... :) > > > Согласны ли Вы терять события в случае недоступности колектора логов или > гранилища логов? Терять? Я согласен. У меня есть, например, распределённая (по паре городов) почтовая система, и сетевой коллектор логов. При проблемах с сетью, понятно, часть записей может быть потеряна при передаче, даже при высоком уровне резервирования межофисных каналов. Но меня это не волнует. Во-первых, есть ещё локальные хранилища логов на узлах, если что -- можно свериться с ними. Во-вторых, я уверен, что при недостатке каких-то фрагментов я это замечу. Ну и в третьих, необязательно заливать всё в хранилище на лету, если нужна полнота -- есть масса способов надёжно реплицировать данные по сети, пожертвовав риалтаймом. Но эти способы дороже простого риалтайма, и мне с ними заморачиваться не хочется. > Я удивлен что "писатели" в Java мире такого не делают. В мире Java вообще сложилась такая культура программирования, что от этого мира я лично предпочитаю держаться подальше. Хотя никакой связи с тем, что пишется из программы в логи, здесь нет (если речь о логах, а не трейсах). -- Eugene Berdnikov
Re: Ищу голосовую общалк у.
Я нашёл --- это Riot! https://riot.im -- sergio
Re: Разбор ошибок в логах.
On Thu, 2017-06-22 at 10:31 +0300, Oleksandr Gavenko wrote: > Я использую Java и логи ограничатся Java. > > Постоянно приходиться выяснять причину проблем через содержимое > логов. > > Я встречаю сложности типа: > > * длиннючие строки, grep в терминале бессмысленен, через ag в Emacs > исследую > * в случае трейсов они многострочные - grep не работает > * события раскиданы по группе файлов, пока копаешься в одном, фокус > на тройку > других теряеться (может многотабовый редактор тут поможет, я не > уверен) > * бессмысленная сложность из-за ротации файла > * из-за ротации файлов теряеться история, лазить в архивах очень > больно > * события из разных потоков перемешаны между собою, фильтрация из-за > многострочных трейсов by grep невозможна > * для анализа я запаковую файлы и качаю с удаленного хостя > * время разработчика (меня) теряеться, если будет интуитивно понятный > Web > доступ с кнопочками часть инцидентов решит выделенный человек, > отвечающий за > поддержку пользователей > > В целом иметь базу с возможностью автоматических запросов - > правильно: > > * история становиться линейной - нет ротационных проблем, нет нужды > стыковать > время при рассмотрении логов из разных типов логов > * фильтрация станет милисекундным делом, а не shell-fu подвигом на 10 > мин > * логи под рукой, забываю про архивирование/копирование > > Не хватает только "смотрелки" для базы. > > Популярным бесплатным решением есть ELK. Пробовал. > > Скажу сразу что не понравилось разношерстность: > > * elasticsearch - Java - OK, умею тюнить > * filebeat - Go - WTF? 50 МБ рантайма для парсера/отправителя логов? > * Logstash - JRuby - WTF? 1 GiB хипа и хипстерский тормознутый > рантайм? > * Kibana - nodejs, бог с ним, это на выделенном сервере и есть > недокументированый ключик --max-old-space-size= > > Парсить логи filebeat неприятно. Особенно если формат расширяем через > MDC (см > ниже). > > Logstash - дерьмо. Хипстеры, лентяи и тупые ставят. Конкурирующие > решения не > без проблем (Apache Flume доку не доделали, читай сорцы называется). > > Для добавления полезной информации (типа имени клиента, номера > телефона, > номера обрабатываемого документа) есть Mapped Diagnostic Context: > > https://logback.qos.ch/manual/mdc.html > > Для алертов есть еще маркеры https://www.slf4j.org/api/org/slf4j/Mark > er.html > > Вот это дело хотелось бы куда-то засунуть и как-то визуально > фильтровать. > > Elasticsearch+Kibana решают задачу, но есть проблемы с доставкой > данных в > Elasticsearch. > > Я хотел бы что бы база стала местом, которому я доверяю. > > Самым надежным местом записи есть файл. > > Потом парсить файлы опасно внешним процесом. filebeat имеет баг > репорты когда > данные пропукались из-за ротации и недоступности Elasticsearch. > > Да и парсить изначально структурированные данные, записаные в > неструктурируемой форме (многострочные трейсы или расширяемые > парамерты MDC) > неадекватно. > > Есть писатели в рамках Java процеса в Elasticsearch. В случае > даунтайма > Elasticsearch они могут копить в буфер в памяти. Если остановить > сервис - > данные пропадут. > > В рассылке Logback мне сказали что луди только на коленках писали > решения, > буферизирующие на диск, пока Elasticsearch. Т.е. готового нету. > > Я начал "писать надежную доставлялку" в Elasticsearch стуктурированых > данных > логирования в Java и появились вопросы по целесообразности. > > > > Интересно стороннее мнение по написаному выше. > > Как обычно решаються перечисленные сложности при анализе > ошибок/инцидентов по > логам? > > > > Есть ли Web-морды для фильтрации и просмотра отлогированых событий > (по типу > Kibana) но для реляционных хранилищь (MariaDB/PostgreSQL/etc)? > > Или может есть "нетраниционные" хралища и морды к ним? > > X-Pack для ELK стоит в районе 10к/год, остальные "Ынтырпрайз" больше- > меньше, не > рациональная трата для маленькой компании. > > > > Конечно же хочеться интеграции системы алертов с мордой, что бы по > клику сразу > попадал в контекст и разбирался. > > > > Согласны ли Вы терять события в случае недоступности колектора логов > или > гранилища логов? > > Я удивлен что "писатели" в Java мире такого не делают. > Ну тут конечно не срача ради но, ява уг это и так понятно. Ява девелоперам походу большую часть денег за это платят чтобы они в таких логах рылись. Тут или смирится или перейти на что другое.
Re: мониторинг присутствия хостов
22.06.2017 08:36, Jurgen V. Uzbekoff пишет: > Nagios или Icinga? наверное monit попроще будет... -- BW, Сохин Вячеслав
Разбор ошибок в логах.
Я использую Java и логи ограничатся Java. Постоянно приходиться выяснять причину проблем через содержимое логов. Я встречаю сложности типа: * длиннючие строки, grep в терминале бессмысленен, через ag в Emacs исследую * в случае трейсов они многострочные - grep не работает * события раскиданы по группе файлов, пока копаешься в одном, фокус на тройку других теряеться (может многотабовый редактор тут поможет, я не уверен) * бессмысленная сложность из-за ротации файла * из-за ротации файлов теряеться история, лазить в архивах очень больно * события из разных потоков перемешаны между собою, фильтрация из-за многострочных трейсов by grep невозможна * для анализа я запаковую файлы и качаю с удаленного хостя * время разработчика (меня) теряеться, если будет интуитивно понятный Web доступ с кнопочками часть инцидентов решит выделенный человек, отвечающий за поддержку пользователей В целом иметь базу с возможностью автоматических запросов - правильно: * история становиться линейной - нет ротационных проблем, нет нужды стыковать время при рассмотрении логов из разных типов логов * фильтрация станет милисекундным делом, а не shell-fu подвигом на 10 мин * логи под рукой, забываю про архивирование/копирование Не хватает только "смотрелки" для базы. Популярным бесплатным решением есть ELK. Пробовал. Скажу сразу что не понравилось разношерстность: * elasticsearch - Java - OK, умею тюнить * filebeat - Go - WTF? 50 МБ рантайма для парсера/отправителя логов? * Logstash - JRuby - WTF? 1 GiB хипа и хипстерский тормознутый рантайм? * Kibana - nodejs, бог с ним, это на выделенном сервере и есть недокументированый ключик --max-old-space-size= Парсить логи filebeat неприятно. Особенно если формат расширяем через MDC (см ниже). Logstash - дерьмо. Хипстеры, лентяи и тупые ставят. Конкурирующие решения не без проблем (Apache Flume доку не доделали, читай сорцы называется). Для добавления полезной информации (типа имени клиента, номера телефона, номера обрабатываемого документа) есть Mapped Diagnostic Context: https://logback.qos.ch/manual/mdc.html Для алертов есть еще маркеры https://www.slf4j.org/api/org/slf4j/Marker.html Вот это дело хотелось бы куда-то засунуть и как-то визуально фильтровать. Elasticsearch+Kibana решают задачу, но есть проблемы с доставкой данных в Elasticsearch. Я хотел бы что бы база стала местом, которому я доверяю. Самым надежным местом записи есть файл. Потом парсить файлы опасно внешним процесом. filebeat имеет баг репорты когда данные пропукались из-за ротации и недоступности Elasticsearch. Да и парсить изначально структурированные данные, записаные в неструктурируемой форме (многострочные трейсы или расширяемые парамерты MDC) неадекватно. Есть писатели в рамках Java процеса в Elasticsearch. В случае даунтайма Elasticsearch они могут копить в буфер в памяти. Если остановить сервис - данные пропадут. В рассылке Logback мне сказали что луди только на коленках писали решения, буферизирующие на диск, пока Elasticsearch. Т.е. готового нету. Я начал "писать надежную доставлялку" в Elasticsearch стуктурированых данных логирования в Java и появились вопросы по целесообразности. Интересно стороннее мнение по написаному выше. Как обычно решаються перечисленные сложности при анализе ошибок/инцидентов по логам? Есть ли Web-морды для фильтрации и просмотра отлогированых событий (по типу Kibana) но для реляционных хранилищь (MariaDB/PostgreSQL/etc)? Или может есть "нетраниционные" хралища и морды к ним? X-Pack для ELK стоит в районе 10к/год, остальные "Ынтырпрайз" больше-меньше, не рациональная трата для маленькой компании. Конечно же хочеться интеграции системы алертов с мордой, что бы по клику сразу попадал в контекст и разбирался. Согласны ли Вы терять события в случае недоступности колектора логов или гранилища логов? Я удивлен что "писатели" в Java мире такого не делают. -- http://defun.work/
