Есть несколько серверов под виндой. На каждом из них через NLog постоянно пишутся логи в текстовые файлы.
Хочется иметь возможность просматривать логи централизованно и отсылать алерты админам на почту.
Один из основных алертов — отпадение бд от серверов приложений.
Здравствуйте, BlackEric, Вы писали:
BE>Есть несколько серверов под виндой. На каждом из них через NLog постоянно пишутся логи в текстовые файлы.
Самодельная, что ли, система?
Насколько я понимаю, если пользоваться штатными средствами и писать логи в системный журнал событий, там есть всякая полезная инфраструктура для централизованного сбора логов. Насколько просто ее настроить, не поручусь. Но в венде ничего просто не бывает (хотя научившиеся этому искусству приобретают Стокгольмский синдром и умение всем рассказывать, как это круто и удобно).
Но если система самодельная, то и сбор логов придется делать самодельным. Если бы у меня до этого дошло, я бы, наверное, не стал изобретать для этой цели сетевой протокол, а использовал бы стандартный syslog protocol (RFC-5424). Он несложный, и для приема, сбора и раскладывания таких сообщений в UNIX есть соответствующая инфраструктура.
Здравствуйте, BlackEric, Вы писали:
BE>Есть несколько серверов под виндой. На каждом из них через NLog постоянно пишутся логи в текстовые файлы.
BE>Хочется иметь возможность просматривать логи централизованно и отсылать алерты админам на почту. BE>Один из основных алертов — отпадение бд от серверов приложений.
BE>Как бы это организовать?
Работает ли это всё под виндой, я не знаю, хотя там go, скорей всего работает.
Для хранения логов — loki. К нему есть утилита logcli, с помощью которой можно запросы в эти логи делать. Хорошего веб дашбоарда я не знаю, это единственный минус этой системы. Есть интеграция с grafana, но там тоже фигня.
Для сбора, парсинга и загрузки логов — promtail.
Для алертов — alertmanager. Настраиваешь регэкспы и тд, на которые будет срабатывать алерт.
В целом всё это в первый раз настраивать довольно сложно и муторно, ну мне по крайней мере было. Но когда настроено — работает как часы.
Ещё сюда можно метрики добавить, обычно всем они нужны. Это prometheus и разнообразные экспортеры. Ну и графану для веб-интерфейса для визуализации метрик.
Альтернативное и самое популярное решение это elk (elastic + logstash + kibana). Но я так понял, это прям супер монстр.
Здравствуйте, BlackEric, Вы писали:
BE>Есть несколько серверов под виндой. На каждом из них через NLog постоянно пишутся логи в текстовые файлы.
Ну завести что-то более разумное для логов и алертов.
Например AppInsights практически бесплатный, NLog перенаправить туда вместо текстовых файлов (есть адаптер из коробки, там пару строк конфига NLog подправить)
В AppInsights можно все централизованно просматривать ну и алерты какие угодно настроить
Здравствуйте, Pzz, Вы писали:
Pzz>Насколько я понимаю, если пользоваться штатными средствами и писать логи в системный журнал событий, там есть всякая полезная инфраструктура для централизованного сбора логов.
Насчет выделенного не уверен, скорее всего докупать / доставлять надо что-то для централизованного сбора и управления логами.
Есть возможность настроить алерты (отправку емайлов, например) на определенные типы евентов записываемых в системные логи.
BE>Как бы это организовать?
Адаптером загоняются логи в отдельный сервис, который с GUI, алертами и (веб-)просмотрщиком.
А уже сервис надо выбирать под задачу. Из self-hosted: Seq, Loki. Сразу и метрики и логи, и трейсы — uptrace. Новейшая версия Seq вроде тоже кроме логов, уже и с метриками работает.
Из облачных: application insights, aws cloudwatch, dynatrace, и ещё много-много. Я когда выбирал, перебрал наверное десяток.
Здравствуйте, BlackEric, Вы писали:
BE>Как бы это организовать?
Буду банален, но чем ELK-стек не угодил? Обычно он покрывает 99⅔% таких задач. Для случаев «дорого/багато» добавить можно еще Grafana. Все ж стандартное…
А нотифицировать уже — это выбор за вами, хоть push- хоть pull- стратегии.
Здравствуйте, r0nd, Вы писали:
R>Буду банален, но чем ELK-стек не угодил? Обычно он покрывает 99⅔% таких задач. Для случаев «дорого/багато» добавить можно еще Grafana. Все ж стандартное…
Ровно наоборот — дорого-богато это elk, ему надо много памяти что бы внятно раздуплиться. Grafana+promtail работают забесплатно в на инстанцах с минимальной конфигурацией, чтото навроде t3.small.
On Mar 23, 2024, 7:44 PM, Pauel <3693@users.rsdn.org> wrote:
P>Ровно наоборот — дорого-богато это elk, ему надо много памяти что бы внятно раздуплиться. Grafana+promtail работают забесплатно в на инстанцах с минимальной конфигурацией, чтото навроде t3.small.
Конечно нет. ELK — это всего лишь базис, grafana — надстройка, одна из надстроек. Память стоит копейки по сравнению с зарплатой DevOps-ов и затрат на разворачивание инфраструктуры всех надстроек над ELK. Просто чистая grafana никому не нужна (разве что студентам на посмотреть и поиграться) — а стоимость заточки ее под крупный бизнес, как 1,000 стоимостей t3.small в месяц.
⸻ ❧ “Set your goals high, and don’t stop till you get there.” — Bo Jackson
