Происхождение термина «лог»
Вы наверняка слышали о том, что скорость морской навигации измеряется в узлах. А задумывались ли вы когда-нибудь о том, почему именно в узлах? Откуда произошло это слово, и что оно, в принципе, обозначает?
Несколько веков назад для измерения скорости судна на море использовали довольно простой инструмент – длинную веревку.
Один конец веревки бросали сзади судна, и засекали на песочных часах время, по окончании которого смотрели на какую длину она размоталась. На веревке через равные промежутки были нанесены специальные отметки в виде узелков из тряпочек или этой же самой веревки.
Расстояние между узелками на веревке было подобрано специальным образом и соответствовало одной морской миле. Если веревка размоталась на три с половиной узла, это говорило о том, что корабль идет со скоростью примерно три с половиной морские мили за час. А сами моряки говорили «скорость три с половиной узла».
Эта веревка с узелками была своеобразной морской линейкой и на английском носила название shiplog или просто log, что в буквальном переводе означало «полено».
Веревочный лог был очень простым и доступным инструментом, но, к сожалению, имел большой недостаток – низкую точность. Выполненные с его помощью замеры были крайне приблизительными, а значит точно рассчитывать время путешествия было невозможно.
Позже, в 18 веке изобрели принципиально новый инструмент для измерения скорости – это был металлический цилиндр с лопастями, при движении в воде лопасти заставляли его вращаться, а количество вращений фиксировалось механическими счетчиками. Примерно как в автомобильном одометре.
Этот инструмент также называли «логом». В свое время он стал большим прорывом морской навигации, так как существенно повысил точность измерений скорости, путешествия по воде стали гораздо более точными и предсказуемыми.
Простые инструменты понятны, но более сложный может существенно увеличить скорость и улучшить качество решений ваших задач
На корабле существовал еще один важный для нас предмет. Выполненные с помощью лога замеры обычно записывали в специальный журнал, который на английском носил название «log book» или просто «лог».
Помимо различных замеров в него также записывали и другие события на судне и вокруг него – какие-то неожиданные находки в море, инциденты с экипажем, входы и выходы в порт, происшествия и аварии и пр. По этим записям всегда можно понять что происходило с кораблем в определенный момент времени.
Именно благодаря веревке с узелками и корабельному журналу сам факт регистрации и фиксации записи чего-либо с тех пор обозначают английским словом «log», а место записи – «логом» (logfile, transaction log, event log и пр.)
В современном мире вы точно слышали про “черный ящик” в самолетах. Это тот самый журнал, лог. В него постоянно, автоматически пишется разная информация: текущие показания датчиков, разговоры пилотов и пр. При крушениях по записям черного ящика восстанавливают картину произошедшего: в какое время какая была высота, скорость, обороты двигателя, крен и т.п. Эти записи помогают разобраться что пошло не так.
Мы можем использовать принцип корабельного журнала и в информационных системах – записывать во время исполнения программы какие-то важные данные для того, чтобы иметь возможность проанализировать их в будущем.
Расскажу как мы на практике пришли к необходимости подробного логирования в отдельной системе через реальные истории трех наших команд - поддержки, тестирования и разработки.
Проблемы в команде поддержки
Впервые о необходимости серьезного логирования мы задумались именно в команде поддержки. Эти ребята общались напрямую с пользователями базы 1С, к ним приходили когда что-то переставало работать. Они знали куда зайти, где посмотреть и что нажать чтобы заработало.
Все чаще и чаще в рабочей базе у нас что-то ломалось, а понять почему мы не могли. Для решения нам требовалась информация о том, как отработала (и отработала ли вообще!) та или иная функциональность в системе, а такой информации чаще всего нигде не было.
Вот не приходят, например, заказы от склада. Сразу куча вопросов появляется: веб-сервис вообще вызывали? Если да - с какими параметрами? В какое время был вызов? Сколько было запросов за день и когда был последний успешный? Вот примерно такие вопросы возникали при расследовании проблем в системе, а ответов на них - не было!
Мы не понимали причин происходящего и не знали что с этим сделать. Поэтому ответом на такие инциденты все чаще становился вот этот смайлик.
Естественно, такая ситуация не устраивала ни нас, ни нашего работодателя. Для решения проблемы и расследования нам нужны какие-то подробные данные о работе программы, а у нас их просто не было нигде.
Но дальше все становилось еще хуже – с ростом нашей системы оказалось, что о многих проблемах в системе мы просто не знали. В разных местах системы возникали разнообразные проблемы: обмены иногда падали, при записи справочника не всегда записывались все нужные данные и т.п. Наша система была в огне, многие ее части не работали как предполагалось, но мы об этом просто не знали - проблемные ситуации никак себя не проявляли до тех пор, пока кто-то из пользователей не пожалуется. Иногда мы узнавали о проблемах в системе совершенно случайно!
Некоторые проблемы были обнаружены катастрофически поздно, когда сделать с этим уже ничего было нельзя. Из-за позднего обнаружения проблем компания начала терять существенные деньги.
О возникающих проблемах в программе нужно узнавать как можно быстрее!
Также серьезной проблемой для поддержки стал рост функциональности в нашей системе, рост количества этих систем и их сложности. Мы начинали только с одной 1С, позже у нас появилось несколько десятков веб-сайтов, внутренних микросервисов и других приложений. Каждый из них хранил информацию в своем месте, в своем формате и по-своему предоставлял доступ к ней. Где-то надо было по SSH зайти и “грепнуть” файлик, где-то - по FTP посмотреть, в другом месте - в админке глянуть.
Если говорить конкретно про 1С, то небольшое количество информации об ошибках, которое она предоставляла, хранилось в абсолютно разных местах:
-
в реквизитах объектов;
-
в дополнительных свойствах;
-
в журнале регистрации;
-
в регистре сведений;
-
в файлах на сервере 1С;
-
некоторые ошибки отправлялись по почте определенным людям.
Разработчики придумывали разные места, где можно сохранить какую-то информацию. Для ребят в поддержке держать в голове весь этот зоопарк особенностей и собирать полную картину «из кусочков» было невероятно сложно. У них часто не получалось решить такие инциденты самостоятельно, приходилось звать и отвлекать разработчиков. Это создавало зависимость – разработчики становились «узким местом», потому что решение инцидентов обязательно требовало их присутствия. Когда они уходили в отпуск или были заняты, решение останавливалось. Как итог, решение таких инцидентов на поддержке стало сильно затягиваться по времени.
Было бы гораздо удобнее, если всю информацию по работе разных систем можно было бы посмотреть в одном месте любому желающему!
Проблемы в команде тестирования
Ребята из отдела тестирования тоже столкнулись с недостатком информации о работе программ. Они работали не на боевой базе, а на множестве разных тестовых копий. Им во время тестирования также требовалась информация о том, как отработала та или иная функциональность.
Например, если они тестировали выгрузку заказов на склад, и заказ по какой-то причине не выгружался. Ребята хотели понять, по какой причине это произошло – они неверно подготовили тестовые данные или это из-за ошибки в коде программы? Такой информации у них не было, и они тоже ходили к разработчикам за помощью. Помимо того, что они разработчиков снова отвлекали, существовала еще и другая проблема – разработчик мог повлиять своим мнением на тестировщика и подтолкнуть его к неверным выводам. А это не очень хорошо с точки зрения тестирования.
Было бы здорово, если бы ребята из тестирования самостоятельно могли посмотреть детали выполнения и ошибки программы, возникающие при тестировании.
Проблемы в команде разработки
А разработчики в первую очередь хотели, чтобы их не отвлекали от работы. Чтобы ребята в поддержке и тестировании могли самостоятельно смотреть и разбираться как работают наши программы.
Хотя потом они осознали для себя и другие преимущества логирования. Разработчики ведь привыкли использовать отладку для разбора и воспроизведения проблем. Это работало на базах для разработки и тестирования, но на рабочей было невозможно отладить десятки и сотни одновременно работающих процессов. Как и невозможно отладить, например, отработавшее вчера регламентное задание или веб-сервис - не всегда можно было понять какие именно входные данные привели к проблеме. Без логирования для разработчиков еще невозможно отлаживать многопоточные алгоритмы – по крайней мере, в платформе 1С. Конфигуратор не приспособлен для отладки одновременно нескольких сеансов, отладка здесь не поможет совсем, нужно какое-то другое решение
Вот с такими проблемами мы у себя столкнулись. Задумавшись над причинами этих проблем, мы осознали, что во время разработки мы часто думаем только о том, как сделать заказанную функциональность работающей. И не задумываемся о том, как контролировать и мониторить корректность работы системы после релиза, в процессе эксплуатации, как быстро обнаруживать проблемы, быстро на них реагировать, и получать всю необходимую информацию для решения этих проблем.
Нам подумалось, что одним из решений могло бы стать подробное журналирование или логирование всего что происходит в программе. Чтобы система самостоятельно записывала все что в ней происходит. Вела бы своеобразный дневник, прочитав который, каждый смог бы восстановить картину происходившего, отследить причины и следствия тех или иных событий.
Инструменты логирования, предлагаемые платформой 1С
Решать описанные проблемы мы начали с систем на базе 1С.
Метод «Сообщить()»
Первый механизм, с которым сталкивается любой разработчик – это вывод сообщений на экран с помощью функции «Сообщить» и ее аналогов. Это самый простой механизм логирования, он хорошо подходит для отладки небольших алгоритмов. Но совершенно не подходит для долгосрочной работы – такие сообщения доступны только интерактивно, здесь и сейчас, и не сохраняются для анализа в будущем.
Также этот механизм не рассчитан для вывода большого количества сообщений. Как только вы попробуете вывести сотни и тысячи сообщений на экран, клиент 1С начнет серьезно «зависать».
Журнал регистрации
Следующий шаг к логированию - журнал регистрации. Это стандартный механизм логирования платформы 1С:Предприятие. Сама платформа записывает в него множество своей внутренней информации: вход и выход пользователя, ошибки прав доступа к определенным объектам и другие. В коде на встроенном языке разработчики могут записывать в этот журнал события с помощью функции «ЗаписьЖурналаРегистрации()».
К сожалению, с журналом регистрации тоже есть ряд проблем.
Самая главная проблема была в том, что поиск по журналу регистрации крайне, невероятно, УЖАСНО медленный. Более того, неосторожный поиск по журналу регистрации мог «подвесить» нам сервер 1С, остановив работу всех пользователей. События пишутся, но искать по ним стандартными средствами было слишком долго и опасно.
Физически файл журнала регистрации размещается на сервере 1С. С большим количеством операций логирования этот файл быстро растет, занимает место, а управление этим файлом (такое, как ротация, архивация), не настолько удобное, как нам бы хотелось.
Важная и удобная возможность журнала регистрации в том, что к тексту сообщения можно отдельно указывать какую-то уточняющую информацию о событии. Например, можно указать ссылку на конкретный документ или справочник, к которым относится запись; пользователя, у которого это событие возникло; к каким метаданным конфигурации оно относится и др.
В логировании эта доп информация о событии называется "контекст"
Эта возможность прикреплять к сообщению некоторую доп информацию (контекст) показалась нам очень удобной. По контексту очень удобно искать и фильтровать записи: находить все что относится только к конкретному пользователю, происходило в определенный период времени или с определенным справочником. Но, к сожалению, формат журнала регистрации ограничен, в нем строго фиксированные колонки доп информации о событии и добавить свои произвольные нет никакой возможности. А мы хотели добавлять к записям свои, произвольные контексты, чтобы быстро по ним искать.
Короче, журнал регистрации оказался для нас ужасно медленным на чтение и не давал возможность хранить произвольный контекст события.
Однако у журнала регистрации есть одно преимущество: параметр “РежимТранзакции”. Он оказался очень важным, сейчас поговорим почему.
Свой регистр
Медленный поиск и ограниченность журнала регистрации привели нас к логичной мысли: создать свой собственный регистр для логов.
По своему регистру мы можем сделать очень быстрый поиск! Еще сделаем гибкую архитектуру, которая позволит нам хранить произвольное количество контекста – например, с помощью плана видов характеристик (как дополнительные свойства в типовых конфигурациях).
Однако реальность оказалась немного печальнее – при логировании в собственный регистр, при большом количестве записей эта таблица начинает расти как ненормальная, и занимает очень много места. Это замедляет такие операции, как резервное копирование базы и восстановление ее из резервной копии.
Но самая большая проблема с регистром была в транзакциях.
Как только мы начинали логировать что-то в регистр в транзакции, и по какой-то причине эта транзакция отменялась, все логи тоже пропадали!
В платформе 1С не существует вложенных транзакций. Транзакция всегда одна, поэтому логи в регистре вместе с отменой транзакции тоже пропадут. Мы хотели бы понимать, почему у нас отменилась транзакция, но лога в этом случае у нас не будет.
Помните параметр “РежимТранзакции” у функции записи в журнал регистрации? С его помощью как раз можно в транзакции записывать события в журнал так, что они не пропадут даже если транзакция отменится! Очень полезная возможность журнала регистрации! Но вот с регистром такой возможности нет совсем.
Проблемы с логированием в регистр навели нас на мысль о том, что система логирования должна быть внешней по отношению к платформе 1С.
Требования к системе логирования
Мы сформулировали для себя требования к хорошей системе логирования:
-
внешняя программа
-
единая для всех приложений компании, все должно быть в одном месте - и от 1С, и от сайтов, и от других программ
-
чтобы поиск информации в этой системе был очень быстрый;
-
чтобы работа этой системы не замедляла наши системы
-
возможность добавлять к логам произвольную аналитику (контекст) по аналогии с журналом регистрации;
-
просто записей в лог недостаточно, необходимы инструменты для анализа и управления логами;
-
И мы хотели оперативно узнавать о том, что у нас в логах появилось что-то важное (например, ошибки) – хотели получать от системы логирования какие-то уведомления.
Внешние системы логирования
Стало понятно, что нужна какая-то внешняя система, мы начали ее искать
Первая самая простая мысль – это взять голую чистую базу данных Elastic Search, CouchDB, MySQL, Postgres, MS SQL – не суть важно, и записывать логи напрямую в нее. Это довольно простой подход, о нем сегодня рассказывал Олег Филиппов. Но как только у вас логов станет несколько миллионов, вы быстро поймете, что вам недостаточно просто записывать логи. Когда их такое огромное количество, вам нужны дополнительные инструменты их обработки – перед базой данных должно стоять какое-то приложение, которое сможет с этими логами что-то сделать.
Была мысль создать свое собственное приложение для логирования – это очень заманчиво для разработчика, но не очень эффективно, так как наверняка кто-то уже решал эти проблемы, а тратить время на изобретение очередного колеса нам не хотелось.
Также можно использовать специализированное ПО для логирования. Оно действительно есть, причем, существующие системы логирования можно разделить на две категории – облачные и те, которые вы можете скачать себе самостоятельно и запустить на собственных серверах.
Облачные системы логирования хранят данные на своих серверах, а вы можете туда писать, оттуда читать, получать какие-то отчеты. Чаще всего, за это нужно заплатить немного денег. Я не буду рассказывать о том, какие существуют облачные сервисы – их довольно много, они легко «гуглятся», возможно, вам они подойдут. Их преимуществом является то, что вам не нужно администрировать сервера и следить за их доступностью. Но самым главным недостатком (по крайней мере, для нас) является то, что эти данные мы храним у каких-то непонятных людей – обычно служба безопасности против таких вещей. Наша - была против.
Поэтому мы стали искать для себя специализированное программное обеспечение, которое мы можем поставить на свой собственный сервер.
Рассмотрев несколько разных систем для логирования, мы остановились на двух кандидатах.
ELK
Первое решение – это ELK, довольно старое и очень хорошо известное в сообществе 1С.
Его название происходит от трех компонентов, из которых он состоит:
-
Высокопроизводительной базы данных Elastic Search;
-
Приложения для обработки логов LogStash;
-
И веб-интерфейса для просмотра логов Kibana.
Несмотря на большую распространенность этой программы, она нам не очень понравилась – у нее была не очень понятная документация, и часть важного для нас функционала была платной и дорогой.
Graylog
Мы остановили свой выбор на системе Graylog. Это относительно молодой софт для логирования, чем-то похож на ELK.
-
Самое главное преимущество Graylog для нас заключалось в том, что он легко интегрируется с 1С через веб-сервисы – вы можете очень быстро начать что-то логировать туда с помощью HTTP-запросов;
-
Graylog полностью бесплатен, имеет открытый исходный код и механизм плагинов;
-
Всей функциональностью Graylog можно управлять с помощью REST-интерфейса – это может очень пригодиться при автоматизации работы с ним;
-
Graylog неплохо масштабируется с ростом объема операций в вашей базе;
-
Имеет хорошую документацию и дополнительные инструменты, такие как уведомления и дашборды;
-
Быстрый поиск и произвольный контекст у сообщений
Преимущества от внедрения Graylog
Что же мы получили, поставив Graylog?
-
Все логи стали писаться в одну систему, доступ к которой осуществлялся через браузер, а значит, его можно открыть и на телефоне, и на планшете – везде. Не нужно запоминать, куда зайти и где что посмотреть – все сосредоточено в одном месте.
-
Начав логировать операции в нашей системе, мы стали обнаруживать очень старые проблемы и ошибки. Например, мы обнаружили заказы, которые в течение двух лет каждые пять минут пытались отправиться на несуществующий сайт. Именно логирование позволило нам обнаружить эти проблемы и очень оперативно их устранить.
-
Когда разработчики стали добавлять операции логирования во время разработки и задумываться о том, какие данные им нужно отслеживать – они стали обнаруживать проблемы и недоработки, о которых они не подумали, еще на этапе разработки. А значит, их исправление было очень дешевым для компании.
Graylog содержит удобные инструменты для анализа логов. Как только логов у вас становится миллионы и миллиарды, вам необходимы инструменты для работы с ними.
В первую очередь я хотел бы отметить дашборды. Это своеобразный рабочий стол, который можно настраивать под каждого пользователя, показывать графики и какие-то важные ключевые показатели.
Вы можете настроить отдельные рабочие столы – для отдела тестирования, разработки, поддержки и отдельный рабочий стол для системных администраторов – каждый сможет видеть важную для него лично информацию. Это очень удобно.
Логи – это также данные. Когда у вас логов становится несколько миллионов, вы можете начать строить по ним статистику. Это может вам дать неожиданный результат – по статистике вы можете начать находить что-то, на что раньше никогда не обращали внимания. Например, вы можете обнаружить, что у вас в магазине с 8 до 10 утра ежедневно возникает проблема с сетью, потому что количество ошибок в это время начинает превышать какую-то норму.
Но, пожалуй, самым важным механизмом в централизованном логировании являются уведомления. Если вы хотите быстро реагировать на какие-то проблемы, вы должны оперативно о них узнавать. Graylog содержит очень хороший механизм для настройки уведомлений. Вы можете настроить, о каких ошибках вас нужно уведомлять, и куда эти уведомления нужно отправлять – в Slack, в Telegram, в Skype или в почту.
Также у Graylog довольно удобный механизм управления логами. Удаление логов происходит очень быстро и не влияет на производительность. Вы можете настроить очень гибкое хранение логов – например, логи с Production-серверов хранить месяц, а логи с тестовых серверов – только три дня.
По стоимости – стартовый сервер Graylog нам обошелся примерно в 6000 рублей в месяц, большая часть из которых ушла на место на жестком диске под логи.
Graylog полностью закрыл все наши потребности в логировании.
Недостатки систем логирования
Какой бы полезной и прекрасной ни была идея логирования, у нее есть недостатки, о которых нужно будет знать перед внедрением.
-
Во-первых, логирование, естественно, не бесплатно. Логи нужно где-то хранить, и места под них нужно очень много – это сотни гигабайт и даже терабайт.
-
Во-вторых, передача логов по сети создает нагрузку на эту сеть. Когда у вас будет миллиард логов, вы это почувствуете, и вам нужно это учитывать.
-
В-третьих, логирование оказывает влияние на производительность. На слайде приведен пример кода, где зеленым отмечены операции логирования. Код у нас в 1С выполняется синхронно, то есть, следующая строка будет ждать, пока завершится предыдущая. Таким образом, операции логирования замедляют основные алгоритмы в вашей системе. Даже если операция логирования выполняется 16 миллисекунд, при сотнях и тысячах таких вызовов вы можете заметить существенное замедление работы системы.
-
Также пример на слайде демонстрирует, что логи захламляют ваш код и затрудняют его чтение. Здесь всего лишь три или четыре строчки значимые (основной алгоритм), а остальные 6 строчек – логи. А чем больше логов, тем сложнее их анализировать – вы с этим столкнетесь, когда будете делать рефакторинг. Поэтому подходите к вопросам логирования с умом, старайтесь логировать только то, что вам действительно нужно.
Обратите внимание
На что я бы рекомендовал обратить ваше внимание при использовании централизованных систем логирования.
Во-первых, работу системы логирования тоже нужно мониторить. Выделенная система логирования может стать важным инструментом в вашей работе, и ее неожиданный выход из строя может негативно сказаться на работе ваших систем. Поэтому хорошей идеей будет настроить мониторинг системы логирования (например, с помощью Zabbix). Вы можете проверять, достаточно ли места для логов, насколько нагружены память, сеть, диски и т.п.
Во-вторых, все функции логирования должны быть Exception-safe. Подумайте о том, какие исключения могут возникнуть в этих функциях, и что будет, если они действительно возникнут. Операции логирования раскиданы в сотнях и тысячах мест вашего кода, и, если вдруг по каким-то причинам в них начнут происходить исключения, выполнение основных алгоритмов в вашей системе остановится, работа системы будет парализована – вы не должны этого допустить.
И в третьих, нельзя забывать про сеть. Обычно логирование – это передача каких-то сообщений по сети, а мы имеем довольно плохую привычку при разработке считать, что сеть работает нормально, сервер отвечает быстро, он доступен, в сети нет никаких задержек, никаких потерь. Но представьте, что будет, если сервер логирования вдруг перестанет вам отвечать. Или в сети будет какая-то задержка – вместо 16 миллисекунд логирование начнет выполняться 800 миллисекунд. Основной алгоритм у вас также замедлится в сотни и тысячи раз, и это может парализовать вашу систему. Поэтому при работе с логированием обязательно учитывайте особенности сети. Проблемы в сети не должны деградировать производительность вашей системы.
Чем могут помочь расширения
В платформе 1С существует один классный инструмент – расширения конфигурации. Он может быть очень полезен при организации логирования в коде.
Чтобы начать логировать, вам нужно вставить в код вызов функций логирования. А для этого нужно установить монопольный доступ, выгнать всех пользователей, произвести релиз – для некоторых бизнесов это может быть недопустимо. Расширение помогает вам решить эту проблему и добавить функции логирования в определенные места без остановки работы 1С.
Еще механизм расширений помогает с захламлением кода. Вы можете вынести операции логирования в расширение, чтобы оставить код основных процедур чистым и читаемым.
Это прекрасная возможность платформы, но использовать ее нужно осторожно, потому что сами расширения усложняют понимание и отладку кода. Используйте их вдумчиво.
Что хотелось бы сделать в логировании для 1С?
Что бы мне хотелось бы улучшить в логировании для 1С?
-
Очень важным источником информации при разборе инцидентов становится программное получение стека вызовов, поскольку мы хотим понимать не только ту строчку кода, в которой возникла проблема, но и то, как мы к ней прошли. К сожалению, в платформе нет такой возможности, но для логирования было бы очень полезно, если бы в будущем она появилась.
Начиная с версии платформы 8.3.15 подробное представление ошибки теперь содержит стек вызовов. Ура!
-
Вторая проблема – не все операции в платформе можно логировать. Например, если вы вызываете функции веб-сервисов через объект WSПрокси, вам будет очень сложно понять, куда этот запрос ушел, и какой был его текст.
-
Чтобы увеличить производительность подсистемы логирования, было бы здорово использовать более быстрые протоколы передачи, например, UDP. Сейчас этого в платформе нет.
-
И для большей независимости подсистемы логирования было бы полезно вынести этот процесс в отдельный поток (использовать многопоточное логирование).
Этот слайд демонстрирует проблему:
-
Слева показана процедура синхронного логирования – когда основной код ожидает завершения операции логирования, он выполняется довольно медленно.
-
Хотелось бы вынести операции логирования в отдельный поток и выполнять его там, не мешая выполнению основного кода.
К сожалению, фоновые задания здесь не подходят, так как на одну операцию основного алгоритма могут быть сотни и тысячи операций логирования. При таком количестве фоновых заданий сервер 1С обычно чувствует себя очень плохо.
Заключение
Итак, в следующий раз при разработке новой функциональности задумайтесь заранее о том, как организовать контроль и мониторинг ее работы в процессе эксплуатации (после релиза). Как быстро и оперативно обнаруживать в ней проблемы. Продумайте, как все это будет работать, когда систем у вас станет десятки, может даже сотни.
Продуманная политика логирования и специализированное ПО для логирования могут быть вам полезными в решении таких задач. Попробуйте Graylog, он не так широко известен, но это отличный инструмент, который нам сильно помог!
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT.
