Comments 39
Отличное начало! С почином!
Теперь масса вопросов.
- Почему грейлог? А не, скажем, эластик? Мне первый нравится самому больше, т.к. это более законченное решение. Но elk как платформа становится все более и более распространенной. А с эксплуатационной точки зрения грейлог имеет сложности эксплуатации и монги, и эластика.
- Что будет, если грейлог "ушел"? Мы же не блокируемся на отпралке лога? Значит, мы его теряем.
- Нужно (мое мнение) четко отделять события и логи. Условно — если у нас разработка, то нам вообще в первую очередь нужна инфа о падениях. А лучше всего эту задачу решает такая штука как sentry. Да, он-премис она бесплатна. С другой стороны в предыдущем пункте я затронул гарантии доставки. И понятно, что если логи чувствительные, то таким наколенным решением не обойтись и нужно продумывать всю систему.
Масса ответов.
1. Под капотомм Грейлога как раз живёт эластик и монго. Просто морда понравилась.
Сложности эксплуатации на весьма большую долю решаются тем, что грейлог поддерживает связывание в «кластер». Каждый экземпляр — одна нода. Если с ней проблемы, но слушать может другая.
2. Да. Вероятность такой ситуации возможна. Но ведь есть файлик с логом! :)
И как раз начал работать над логами в режиме NLog->RabbitMQ->Graylog. А это уже гораздо надёжнее. +из пункта выше ноды…
3. Признаюсь, с sentry не знаком. Есть такое упущение. В любом случае я заострил внимание на разумности сбора сообщений. + в некоторых случаях внешний мониторинг с обратной связью не применим (параноидальные настройки сети на предприятиях, например...).
В любом случае решение не самое идеальное и, возможно, не охватывает все варианты использования и ситуации, но… для удовлетворения базовых потребностей в контроле своих продуктов подходит. :)
Спасибо за реакцию. Наводит на размышления.
- я про это и говорю — сложность грейлога = сложность всех компонентов. Потому что если оно сломается, то придется искать что и где развалилось.
- Может все-таки RabbitMQ -> Kafka заменить ?
- sentry — необязательно использовать ВНЕ контура, можно им уведомлялки слать и на корп почту — главная фишка, что он схлопывает все однотипные проблемы, что позволяет понять пофикшена ли какая-то конкретная бага или нет. Грейлог и ЕЛК — это все-таки решения более общие и на них такой функционал напилить можно, но… зачем? Пускай каждую задачу решает то, что лучше всего для этого подходит )
2. Думал об этом. Причин не нашёл. Rabbit'а хватает. Честно.
3. Как раз Грейлог позволяет работать с отчётами, алертами, фильтрами, потоками… :) Этим и привлёк.
Не буду утверждать, что это конечное решение и я на этом остановлюсь.
Но я дал для примера файлик для композера: там volume'ы живут отдельно.
фейспалм — мы тоже долгое время жили на таком же конфиге, но это докер, это компоуз — это не продакшн решение. Скорее на "тесты", "поиграться". На большой нагрузке это все будет проседать. Ну, и менеджить неудобно (потому что те же инпуты добавляются через гуй грейлога, а порты в компоузе надо менять — фу-фу-фу) Поэтому идеально — конечно, когда появятся соответствующие требования — вынести монгу на отдельную виртуалку, эластик — на отдельную. Настраивать это все каким-нибудь ansible playbook'ом
Формально с моей стороны «ракеты ушли». Дальше «будем посмотреть». А надёжностью и мощностью агрегатора логов я, конечно же, займусь. Спасибо. :)
Решение с volum'ами банально не масштабируется. Если эти контейнеры уходят в какой-нибудь кубер, да даже банально просто на другом докер-хосте поднимать — сразу возникает вопрос, чтоб эти файлы и там собирались, права/место…
Вариант с кроликом тоже плох тем, что в случае проблем сети — мы опять теряем логи (т.е. если nlog не смог достучаться до кролика, или тот перегружен и очередь на отправку растёт == жрёт ресурсы хоста).
Т.е. простой вариант — это, например, тот же logstash/filebeats для чтения/отправки логов из файла и на отдельном volume (да, я про его проблемы сказал, но это всё же простой вариант при ограниченом кол-ве хостов). Тот же filebeat будет гарантировать доставку логов после восстановления сети, может отвечать за ротацию итд. С ним тоже проблемы есть, но как вариант на старт — вполне.
Дальше развивать есть куда — лучше писать просто в stdout и собирать уже docker logging driver'ом, им же сразу класть в очередь (кролик/кафка/что у вас там ещё есть), чтоб гарантировать доставку и оттуда перекладывать в graylog. Потому что у грейлога тоже могут быть проблемы с приёмом: забитый cpu, забитый elasticsearch, сам грейлог может падать… Так что лучше иметь буфер перед ним тоже. Но это уже другая история про другие объёмы и требования.
И ещё — для nlog есть AsyncWrapper.
Решение с volum'ами банально не масштабируется. Если эти контейнеры уходят в какой-нибудь кубер, да даже банально просто на другом докер-хосте поднимать — сразу возникает вопрос, чтоб эти файлы и там собирались, права/место…
Сложно с этим спорить. Скорее всего это именно так.
Вариант с кроликом тоже плох тем, что в случае проблем сети — мы опять теряем логи (т.е. если nlog не смог достучаться до кролика, или тот перегружен и очередь на отправку растёт == жрёт ресурсы хоста).
NLog продолжает писать в файлик. Совсем потерять несколько тяжелее. Но да, вероятность пропусков существует.
Т.е. простой вариант — это, например, тот же logstash/filebeats для чтения/отправки логов из файла и на отдельном volume (да, я про его проблемы сказал, но это всё же простой вариант при ограниченом кол-ве хостов). Тот же filebeat будет гарантировать доставку логов после восстановления сети, может отвечать за ротацию итд. С ним тоже проблемы есть, но как вариант на старт — вполне.
Можно и так… Но хотелось чего-то простого на стороне исполняемого приложения.
Дальше развивать есть куда — лучше писать просто в stdout и собирать уже docker logging driver'ом, им же сразу класть в очередь (кролик/кафка/что у вас там ещё есть), чтоб гарантировать доставку и оттуда перекладывать в graylog. Потому что у грейлога тоже могут быть проблемы с приёмом: забитый cpu, забитый elasticsearch, сам грейлог может падать… Так что лучше иметь буфер перед ним тоже. Но это уже другая история про другие объёмы и требования.
Да. Всё так. Но, когда речь о десктоп-приложении docker logging driver'а нет. Вот шлём сразу хоть куда-нибудь. :) Скорее всего позже буду делать это через шину (Rabbit, Kaffka или whatever...)
Про AsyncWrapper почитаю. Спасибо. Как-то упустил…
— это только со своих серверов или с клиентских машин тоже?
— UDP или HTTP?
— и оттуда, и оттуда.
— http. Сделали имя третьего уровня, пробросили на 12201 контейнера Graylog.
Буферизации не делал сначала, но теперь добавил обёртку асинхронную, где «набивается» очередь сначала. Но она для моих задач не так критична. Правда.
Изначально, конечно, хотелось знать, что на «неизвестно-где-стоящем-компе» случился exception. :)
Только UDP, т.к. когда идет большой поток сообщений, то HTTP это слишком долго.
Статик-логгер — это нарушение буковки D в (некночибудетпомянут) solid. Неявная зависимость и всё такое. Давно уже есть microsoft.extensions.logging и даже для такого динозавра как nlog наверняка есть нужные либы.
Но главный бонус этого microsoft.extensions.logging как раз в том, что можно менять логеры просто настройками, не трогая код приложений (хотя, это как раз и есть то, о чём говорит D).
Вот представь себе либу, которая вот так статиками использует nlog, в другой также гвоздями прибит log4net, а основное приложение вообще использует serilog. Вот чтоб избежать такого бардака и придуманы абстракции, DI и всё такое.
И ещё чисто по удобству — почитай про structured logging. Это реально вот прям другой уровень детализации сообщений, передачи контекстов (тот же Scope в microsoft.extensions.logging прям хорошо помогает).
По поводу microsoft.extensions.logging поясню: это наследие от моей «специализации». При написании плагинов к САПР (Revit, Autocad) приходится балансировать на грани записи информации о событиях и сбора данных. Сбором данных увлекаться не стОит…
Либу из своего класса в статье делать никогда и не планировал. Да и контекст hosted assembly он такой себе… Буду считать это для себя следующим шагом. :)
structured logging мне как раз и обеспечивает Graylog.
Сойдёмся на том, что это один их вариантов. ИМХО, он имеет право на жизнь.
structured logging мне как раз и обеспечивает Graylog.
это лишь один конец — отображение. а когда ты пишешь в лог вот таким образом:
using _logger.BeginScope("processing user {UserId}", userId);
_logger.LogDebug("User {UserName} found", user.Name);
а в грейлоге видишь:
message: User 123 found
Scope: processing user 123
UserId: 123
UserName: First User
при этом не занимаясь ручным наполнением вот этих параметров и не ограничиваясь одним лишь message и тем, что гвоздями забито в GelfTarget. И потом в грейлоге же спокойно ищешь и по UserId и по UserName, потому что они отдельные поля..
при этом не занимаясь ручным наполнением вот этих параметров и не ограничиваясь одним лишь message и тем, что гвоздями забито в GelfTarget. И потом в грейлоге же спокойно ищешь и по UserId и по UserName, потому что они отдельные поля..
Не-не-не… Как раз в «бонусном» методе я упрощаю себе жизнь с отправкой чего-то с кучей параметров и свойств. :) И полей в Graylog'е появляется множество, и никакой ручной работы.
То, чем набил в настройках GraylogHttpTarget — это то, что паровозом с каждым сообщением улетает. Т.с. базовая информация.
timestamp 2020-04-25 17:35:48 +03:00 — вот такое представление в Грейлоге. Но само поле передаётся NLog'ом: «timestamp»: 1385053862.3072 — точность выше.
Искренне надеюсь на Хабр. :) В комментариях много головоломок решалось. Сам видел.
Не смог оставить этот вопрос.
На самом деле при передаче сообщения лога в виде gelf тот же NLog снабжает его sequenceId. По нему можно сортировать сообщения в самом Graylog.
Ну и нашёл блог самой Эластики: https://www.elastic.co/blog/journey-support-nanosecond-timestamps-elasticsearch
Говорят, что наносекунды реальны. :)
Надеюсь Вам это поможет.
The ability to store dates in nanosecond resolution required a significant refactoring within the Elasticsearch code base. Read this blog post for the why and how on our journey to be able to store dates in nanosecond resolution from Elasticsearch 7.0 onwards.
Graylog 3.x does not work with Elasticsearch 7.x!
Под капотом Graylog'а и так Elasticsearch. И как раз вчера на 9200 контейнера с Elasticsearch прикрутил Grafan'у. Я, если честно, в неё не особо умею, но попробую… Коллеги её любят, пусть глядят. :)
Graylog не то чтобы выигрывает чем-то, а просто чуть удобнее стартовать. Быстрее как-то. Есть удобная web-морда. Вменяемая настройка фильтров и АЛЕРТОВ. Мне очень уж оповещения хотелось об определённых ошибках. Если честно был бы голый ELK, если бы Graylog не встретил и не почитал вечерок.
Расширения под перечисленные логгеры естественно пишут люди. Как и сами логгер-библиотеки… Не знаю даже, что тут сказать. На самом деле, кроме NLog я в проекте использую стороннюю target для отправки по http. NLog позволяет custom target создавать… Но опять же, выбрал чуть более простой путь. Объект цели создаётся, в конфигурацию добавляется без ошибок, к просадкам по скорости отправки ничего не добавляет. Не появилось причин не доверять…
В комментах уже упоминали гарантированность доставки, но это не сильно к расширениям относится.
Спасибо, будем этот грейлог покрутить и посмотреть.
Последний эдастик что-то там с алертами умеет, но я не вникал. www.elastic.co/what-is/elasticsearch-alerting
Повторюсь: можно и самому написать отправку под NLog. Я описал, как сам поступил. :)
Попробовать Graylog несложно, я и *.yml для быстрого развёртывания подарил.
Про алерты в Эластике руки не дошли почитать, может и это использую. Спасибо.
Алерты из логов — это антипаттерн.
Ну, ок — если очень хочется — для эластика есть модуль elastalert.
Из графаны не рекомендую — она очень приличную нагрузку на БД эластика даёт своими запросами. Такое себе. Либо очень умно планировать нагрузку, либо тюнить запросы.
Касательно грейлога — по сравнению с эластиком — это именно, что готовый продукт. Со своими ограничениями, но и очень классными фичами. Типа алертов, потоков, интеграции с лдап и всем прочим. Эластик тоже можно "сварить" со всем нужным, но необходимо тогда погружаться в его специфику
Ну, и опять же — вы наверняка не грейлог или эластик хотите, а скорее всего sentry. Он-премис — бесплатно. Попробуйте. Очень крутая штука. Именно для разрабов
Эластик, как база-хранилище уже используется, хватит с неё. :)
Графана пока на уровне «как там мой Graylog, покажешь?». От неё тоже бОльшего не нужно.
Тут в комментах про нагрузку многие высказывались, решение всем стОит подбирать по «размеру». :)
Касательно грейлога — по сравнению с эластиком — это именно, что готовый продукт. Со своими ограничениями, но и очень классными фичами. Типа алертов, потоков, интеграции с лдап и всем прочим. Эластик тоже можно «сварить» со всем нужным, но необходимо тогда погружаться в его специфику
Да. Как-то так на Грейлог и вышел. Вроде легко запустился, вроде всё сразу делает…
sentry — мониторинг. Я таки хотел логи.
Использование Graylog и NLog для сбора логов от приложений на C#. Личный опыт