Недавно из комментариев узнал про систему RuSIEM. Она относится к классу продуктов SIEM (Security Information and Event Management). Я в целом далёк от темы безопасности и связанным с этим софтом, так как это отдельное направление в IT. Эта система привлекла меня тем, что у неё есть полностью бесплатная версия RvSIEM, которая занимается только сбором и обработкой логов, анализируя их на наличие содержимого, связанного с защитой и безопасностью.
Решение полностью российское, соответственно документация, весь интерфейс, все встроенные фильтры и отчёты полностью на русском, что упрощает эксплуатацию. Я немного разобрался с RvSIEM: развернул, посмотрел, что умеет и как работает. На первый взгляд неплохая система. Кратко расскажу, что конкретно она делает.
RvSIEM умеет принимать логи из различных систем: веб сервера, операционные системы (в том числе Windows), СУБД, почтовые сервера, шлюзы, сетевые устройства и т.д. Она их автоматически парсит, если используются стандартные шаблоны логов этих приложений и собирает по ним аналитику. Например, вычленяет из них IP адреса источников, информацию об учётных данных, если речь идёт о логине, статусы и критичности событий из логов приложений и т.д.
Всё это стекается в общее хранилище на базе Elasticsearch и ClickHouse, там анализируется и строятся отчёты. Например, можно вывести сквозной список всех IP адресов, с которых были подключения, которые не относятся к IP адресам РФ. Можно сделать отдельный отчёт по логинам RDP или в админку самой RvSIEM. Причём отчёты можно выгружать в различных форматах: PDF, DOCX, XSLX, CSV.
Есть стандартные преднастроенные фильтры и отчёты. Можно писать свои. То же самое и к парсерам относится. Используются grok фильтры для парсинга, как в Logstash. С ними нетрудно разобраться и распарсить свой формат логов. Я в своё время это освоил, когда надо было. Управление всё через веб интерфейс, в консоль ходить не обязательно.
Рассказываю, как я всё это установил. Пошёл на сайт и в разделе скачать оставил заявку. На следующий день мне прислали на почту мою учётную запись в ЛК с документацией всей системы RuSIEM. Там есть все ссылки и инструкции на загрузку. Используется общий установщик, а конкретно установку RvSIEM выбираешь при его запуске.
С установкой проблем не возникло, там всё просто. Инструкция на русском, сделал по ней. Хотя по сути там нужно просто скачать скрипт и запустить его. Дальше установщик всё делает сам. Он работает на базе ролей Ansible. Никаких лицензий потом получать не надо.
Дам одну существенную рекомендацию по настройкам Elasticsearch. Он по умолчанию съедает всю оперативную память и его прибивает OOM Killer. У меня было 4GB памяти, сделал 8GB, не помогло, сделал 12GB - тоже не помогло. Elasticsearch регулярно падал, хотя в тестовой системе нагрузки никакой не было. Мне это надоело и я в файл
Они ограничивают потребление в 4GB, что для небольшой нагрузки достаточно. После этого система стала стабильно работать.
RvSIEM умеет собирать логи разными способами. В основном это syslog, NetFlow и свой агент, в том числе для Windows. То есть настройка простая. Например, в Angie можно напрямую отправить логи в RvSIEM в формате syslog:
Основное ограничение бесплатной версии - 500 EPS (events per second). Не знаю, что тут конкретно имеется ввиду. Наверное, суммарное количество строк логов в секунду.
Для бесплатной системы функциональность более чем. Не знаю, есть ли у кого-то что-то лучше. Да и в целом мне понравилась система. Довольно быстро разобрался, развернул, посмотрел, как работает. Особых проблем не возникло. Попробуйте, если вам нужен такого рода продукт.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#logs #security #отечественное
Решение полностью российское, соответственно документация, весь интерфейс, все встроенные фильтры и отчёты полностью на русском, что упрощает эксплуатацию. Я немного разобрался с RvSIEM: развернул, посмотрел, что умеет и как работает. На первый взгляд неплохая система. Кратко расскажу, что конкретно она делает.
RvSIEM умеет принимать логи из различных систем: веб сервера, операционные системы (в том числе Windows), СУБД, почтовые сервера, шлюзы, сетевые устройства и т.д. Она их автоматически парсит, если используются стандартные шаблоны логов этих приложений и собирает по ним аналитику. Например, вычленяет из них IP адреса источников, информацию об учётных данных, если речь идёт о логине, статусы и критичности событий из логов приложений и т.д.
Всё это стекается в общее хранилище на базе Elasticsearch и ClickHouse, там анализируется и строятся отчёты. Например, можно вывести сквозной список всех IP адресов, с которых были подключения, которые не относятся к IP адресам РФ. Можно сделать отдельный отчёт по логинам RDP или в админку самой RvSIEM. Причём отчёты можно выгружать в различных форматах: PDF, DOCX, XSLX, CSV.
Есть стандартные преднастроенные фильтры и отчёты. Можно писать свои. То же самое и к парсерам относится. Используются grok фильтры для парсинга, как в Logstash. С ними нетрудно разобраться и распарсить свой формат логов. Я в своё время это освоил, когда надо было. Управление всё через веб интерфейс, в консоль ходить не обязательно.
Рассказываю, как я всё это установил. Пошёл на сайт и в разделе скачать оставил заявку. На следующий день мне прислали на почту мою учётную запись в ЛК с документацией всей системы RuSIEM. Там есть все ссылки и инструкции на загрузку. Используется общий установщик, а конкретно установку RvSIEM выбираешь при его запуске.
С установкой проблем не возникло, там всё просто. Инструкция на русском, сделал по ней. Хотя по сути там нужно просто скачать скрипт и запустить его. Дальше установщик всё делает сам. Он работает на базе ролей Ansible. Никаких лицензий потом получать не надо.
Дам одну существенную рекомендацию по настройкам Elasticsearch. Он по умолчанию съедает всю оперативную память и его прибивает OOM Killer. У меня было 4GB памяти, сделал 8GB, не помогло, сделал 12GB - тоже не помогло. Elasticsearch регулярно падал, хотя в тестовой системе нагрузки никакой не было. Мне это надоело и я в файл
/etc/elasticsearch/jvm.options.d/rusiem.jvm.options добавил настройки:-Xms4g-Xmx4gОни ограничивают потребление в 4GB, что для небольшой нагрузки достаточно. После этого система стала стабильно работать.
RvSIEM умеет собирать логи разными способами. В основном это syslog, NetFlow и свой агент, в том числе для Windows. То есть настройка простая. Например, в Angie можно напрямую отправить логи в RvSIEM в формате syslog:
access_log syslog:server=10.20.1.9:5014,facility=local7,tag=angie,severity=infoerror_log syslog:server=10.20.1.9:5014,facility=local7,tag=angie,severity=infoОсновное ограничение бесплатной версии - 500 EPS (events per second). Не знаю, что тут конкретно имеется ввиду. Наверное, суммарное количество строк логов в секунду.
Для бесплатной системы функциональность более чем. Не знаю, есть ли у кого-то что-то лучше. Да и в целом мне понравилась система. Довольно быстро разобрался, развернул, посмотрел, как работает. Особых проблем не возникло. Попробуйте, если вам нужен такого рода продукт.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#logs #security #отечественное
2👍135👎10
Много на канале писал и пишу про сбор и анализ логов. Соберу все известные мне продукты и способы организации централизованного хранения логов, которые пришли в голову. Это будут как специализированное ПО для этого, так и другие продукты с такой функциональностью.
◽️ELK Stack. Известный и функциональный продукт, который подойдёт как для условно небольших одиночных серверов, так и больших кластеров. Из минусов - он довольно прожорлив до ресурсов и сложен в настройке. Надо прям учиться с ним работать, разбираться. С кондачка, потыкав мышкой не настроить. У меня есть подробная статья по настройке всего стека со сбором логов из разных систем. Статья ждёт обновления и адаптации под новую 9-ю версию. Сюда же добавлю похожие продукты - Graylog и OpenSearch.
◽️VictoriaLogs - функциональный и простой в настройке сборщик логов от одноимённой компании и их стека продуктов. Лично мне решение очень понравилось своей простотой, универсальностью и скоростью настройки. Смело рекомендую - пробуйте и используйте.
◽️Loki - известный продукт от стека Grafana. Относительно простой по сравнению с ELK, но с достаточной функциональностью для многих типовых задач. Продукт известный и популярный, есть куча инструкций и способов автоматической установки. Легче освоить и начать пользоваться, чем ELK.
◽️RvSIEM - полностью бесплатный компонент российской коммерческой системы RuSIEM. Он не только про сбор и хранение, но и анализ на предмет безопасности и уязвимостей. Но даже если вам не нужен анализ, сам сбор организован удобно. Мне понравился продукт.
◽️Elasticvue - GUI для Elasticsearch. То есть это максимально простое хранение логов с помощью Elasticsearch, где есть простой интерфейс для просмотра содержимого.
◽️Службы Systemd: journal-remote и journal-upload. Централизованный сбор логов средствами systemd со всех серверов с этой системой логирования. Функциональность очень простая - только сбор бинарных логов. Для просмотра через браузер можно использовать ещё один продукт - journal-gatewayd.
◽️Стандартный rsyslog. С помощью обычного syslog сервера очень просто организовать централизованный сбор текстовых логов. Смотреть в браузере можно с помощью Tailon, Logdy или Webmin. Для тех кто не знает, добавлю, что rsyslog агент есть и под Windows.
◽️Syslog-ng. Более продвинутый syslog сервер, в котором можно удобнее организовать сбор логов, нежели в rsyslog.
◽️Zabbix. В этой системе есть отдельный механизм по сбору и анализу логов, а также уведомления на какие-то события в них. Понятно, что это продукт из другой оперы и много логов туда слать нельзя, так как хранение в SQL базе. Но, к примеру, организовать сбор логов и уведомления на их основе можно. Я много раз настраивал и настраиваю. Тут в заметке несколько примеров.
Отдельно упомяну сервис axiom.co, куда можно сгружать свои логи и анализировать. У сервиса очень комфортный бесплатный тарифный план на хранение 25 GB и трафик 500 GB в месяц.
Из похожей серии сервис мониторинга New Relic, который в том числе позволяет собрать 100 GB логов.
Во все эти системы логи можно отправлять с помощью Vector. На текущий момент это наиболее простой, функциональный и производительный инструмент для этих задач. Вроде выходило что-то новое и перспективное по этой теме, но я не запомнил. Сам использую Vector.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#logs #подборка
◽️ELK Stack. Известный и функциональный продукт, который подойдёт как для условно небольших одиночных серверов, так и больших кластеров. Из минусов - он довольно прожорлив до ресурсов и сложен в настройке. Надо прям учиться с ним работать, разбираться. С кондачка, потыкав мышкой не настроить. У меня есть подробная статья по настройке всего стека со сбором логов из разных систем. Статья ждёт обновления и адаптации под новую 9-ю версию. Сюда же добавлю похожие продукты - Graylog и OpenSearch.
◽️VictoriaLogs - функциональный и простой в настройке сборщик логов от одноимённой компании и их стека продуктов. Лично мне решение очень понравилось своей простотой, универсальностью и скоростью настройки. Смело рекомендую - пробуйте и используйте.
◽️Loki - известный продукт от стека Grafana. Относительно простой по сравнению с ELK, но с достаточной функциональностью для многих типовых задач. Продукт известный и популярный, есть куча инструкций и способов автоматической установки. Легче освоить и начать пользоваться, чем ELK.
◽️RvSIEM - полностью бесплатный компонент российской коммерческой системы RuSIEM. Он не только про сбор и хранение, но и анализ на предмет безопасности и уязвимостей. Но даже если вам не нужен анализ, сам сбор организован удобно. Мне понравился продукт.
◽️Elasticvue - GUI для Elasticsearch. То есть это максимально простое хранение логов с помощью Elasticsearch, где есть простой интерфейс для просмотра содержимого.
◽️Службы Systemd: journal-remote и journal-upload. Централизованный сбор логов средствами systemd со всех серверов с этой системой логирования. Функциональность очень простая - только сбор бинарных логов. Для просмотра через браузер можно использовать ещё один продукт - journal-gatewayd.
◽️Стандартный rsyslog. С помощью обычного syslog сервера очень просто организовать централизованный сбор текстовых логов. Смотреть в браузере можно с помощью Tailon, Logdy или Webmin. Для тех кто не знает, добавлю, что rsyslog агент есть и под Windows.
◽️Syslog-ng. Более продвинутый syslog сервер, в котором можно удобнее организовать сбор логов, нежели в rsyslog.
◽️Zabbix. В этой системе есть отдельный механизм по сбору и анализу логов, а также уведомления на какие-то события в них. Понятно, что это продукт из другой оперы и много логов туда слать нельзя, так как хранение в SQL базе. Но, к примеру, организовать сбор логов и уведомления на их основе можно. Я много раз настраивал и настраиваю. Тут в заметке несколько примеров.
Отдельно упомяну сервис axiom.co, куда можно сгружать свои логи и анализировать. У сервиса очень комфортный бесплатный тарифный план на хранение 25 GB и трафик 500 GB в месяц.
Из похожей серии сервис мониторинга New Relic, который в том числе позволяет собрать 100 GB логов.
Во все эти системы логи можно отправлять с помощью Vector. На текущий момент это наиболее простой, функциональный и производительный инструмент для этих задач. Вроде выходило что-то новое и перспективное по этой теме, но я не запомнил. Сам использую Vector.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#logs #подборка
Please open Telegram to view this post
VIEW IN TELEGRAM
7👍127👎1
Установка и настройка Aspia
Серверные компоненты системы router и relay доступны для установки под Windows и Linux. Под Linux они поставляются в виде собранных deb пакетов, поэтому мне видится самым простым и логичными вариантом установки - из пакетов.
Есть собранные Docker контейнеры от сторонних пользователей, но в данном случае я не вижу в них смысла, потому что по сути это одиночные исполняемые файлы, написанные на C++, конфигурационные файлы к бинарникам и systemd службы. Всё это есть в пакете.
Ставить будем на арендованную VPS с настроенным доменным именем и внешним IP. На сервер будут установлены обе службы: router и releay.
📌 Установка Aspia Router:
Генерируем конфиг:
Правим конфигурацию
Остальное можно не трогать. Запускаем службу:
Логи смотрим тут:
📌 Установка Aspia relay:
Генерируем конфиг:
Смотрим публичный ключ роутера:
Правим конфигурацию
Запускаем службу:
Логи смотрим тут:
Логи служб можно сделать подробнее и перенести в файлы. Описано в документации.
📌 Aspia Console поддерживает установку на Windows, Linux, macOS. Выбирайте, что вам удобнее. Я ставил на Windows и Ubuntu. Загружаете дистрибутив из репозитория и устанавливаете.
После первого запуска вам предложат создать новую адресную книгу. Сразу после создания, переходите в раздел Инструменты ⇨ Управление маршрутизатором и добавляйте подключение к роутеру. Указывайте IP адрес или доменное имя и стандартную учётку admin / admin. После подключения сразу добавьте новую учётную запись администратора, а стандартную отключите.
Адресная книга хранится локально, заполняется вручную. Это существенный минус приложения, так как если компьютеров много, то заполнить книгу первый раз вручную будет хлопотно. Потом её можно будет выгрузить или разместить на сетевом диске с общим доступом. Адресную книгу стоит сразу закрепить, чтобы она открывалась автоматически при запуске. И рекомендую сразу зашифровать её в свойствах.
📌 Aspia Host может быть установлен только на системы под управлением Windows. Это существенное ограничение Aspia, так как, конечно, хотелось бы видеть здесь ещё как минимум Linux, но что есть то есть.
Загружаем установщик в виде msi пакета, запускаем. Заходим в Параметры ⇨ Маршрутизатор, вводим адрес сервера с router и ключ из файла
После настройки хоста можно выгрузить его параметры в файл
На этом базовая настройка окончена, можно пользоваться сервисом. Всё довольно просто и понятно. Я без проблем и каких-то трудностей всё настроил сходу. Для переноса сервера или релея достаточно перенести файл с конфигурацией router.json, router.pub и базу /var/lib/aspia/router.db3.
Программа написана на C++ и потребляет очень мало ресурсов. Можно запустить на минимальной VPS.
Полезные ссылки:
- Сайт программы / Исходники
- Обзор основных возможностей
- Установка и настройка
- Часто задаваемые вопросы (FAQ)
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#aspia #remote
Серверные компоненты системы router и relay доступны для установки под Windows и Linux. Под Linux они поставляются в виде собранных deb пакетов, поэтому мне видится самым простым и логичными вариантом установки - из пакетов.
Есть собранные Docker контейнеры от сторонних пользователей, но в данном случае я не вижу в них смысла, потому что по сути это одиночные исполняемые файлы, написанные на C++, конфигурационные файлы к бинарникам и systemd службы. Всё это есть в пакете.
Ставить будем на арендованную VPS с настроенным доменным именем и внешним IP. На сервер будут установлены обе службы: router и releay.
📌 Установка Aspia Router:
# wget https://github.com/dchapyshev/aspia/releases/download/v2.7.0/aspia-router-2.7.0-x86_64.deb# apt install ./aspia-router-2.7.0-x86_64.debГенерируем конфиг:
# aspia_router --create-configПравим конфигурацию
/etc/aspia/router.json, добавляя туда: "RelayWhiteList": "127.0.0.1",Остальное можно не трогать. Запускаем службу:
# systemctl enable --now aspia-routerЛоги смотрим тут:
# journalctl -u aspia-router📌 Установка Aspia relay:
# wget https://github.com/dchapyshev/aspia/releases/download/v2.7.0/aspia-relay-2.7.0-x86_64.deb# apt install ./aspia-relay-2.7.0-x86_64.debГенерируем конфиг:
# aspia_relay --create-configСмотрим публичный ключ роутера:
# cat /etc/aspia/router.pubПравим конфигурацию
/etc/aspia/relay.json, добавляя туда: "PeerAddress": "341485.simplecloud.ru", "RouterAddress": "127.0.0.1", "RouterPublicKey": "A3F9B2D33F27F6809E0178EFC64786C", "StatisticsEnabled": "false", Запускаем службу:
# systemctl enable --now aspia-relayЛоги смотрим тут:
# journalctl -u aspia-relayЛоги служб можно сделать подробнее и перенести в файлы. Описано в документации.
📌 Aspia Console поддерживает установку на Windows, Linux, macOS. Выбирайте, что вам удобнее. Я ставил на Windows и Ubuntu. Загружаете дистрибутив из репозитория и устанавливаете.
После первого запуска вам предложат создать новую адресную книгу. Сразу после создания, переходите в раздел Инструменты ⇨ Управление маршрутизатором и добавляйте подключение к роутеру. Указывайте IP адрес или доменное имя и стандартную учётку admin / admin. После подключения сразу добавьте новую учётную запись администратора, а стандартную отключите.
Адресная книга хранится локально, заполняется вручную. Это существенный минус приложения, так как если компьютеров много, то заполнить книгу первый раз вручную будет хлопотно. Потом её можно будет выгрузить или разместить на сетевом диске с общим доступом. Адресную книгу стоит сразу закрепить, чтобы она открывалась автоматически при запуске. И рекомендую сразу зашифровать её в свойствах.
📌 Aspia Host может быть установлен только на системы под управлением Windows. Это существенное ограничение Aspia, так как, конечно, хотелось бы видеть здесь ещё как минимум Linux, но что есть то есть.
Загружаем установщик в виде msi пакета, запускаем. Заходим в Параметры ⇨ Маршрутизатор, вводим адрес сервера с router и ключ из файла
/etc/aspia/router.pub. Тут же в разделе Пользователи можно добавить пользователей, которые будут иметь доступ к этому компьютеру, а на вкладке Безопасность некоторые другие параметры, в том числе одноразовые пароли.После настройки хоста можно выгрузить его параметры в файл
aspia-host-config.json. Если положить этот файл вместе с .msi установщиком, он автоматом подхватит настройки при установке.На этом базовая настройка окончена, можно пользоваться сервисом. Всё довольно просто и понятно. Я без проблем и каких-то трудностей всё настроил сходу. Для переноса сервера или релея достаточно перенести файл с конфигурацией router.json, router.pub и базу /var/lib/aspia/router.db3.
Программа написана на C++ и потребляет очень мало ресурсов. Можно запустить на минимальной VPS.
Полезные ссылки:
- Сайт программы / Исходники
- Обзор основных возможностей
- Установка и настройка
- Часто задаваемые вопросы (FAQ)
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#aspia #remote
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍103👎2
Я часто упоминал в различных заметках систему по сбору логов Loki. Например, вот в этой подборке подобных систем (там сразу можете посмотреть аналоги). При этом у меня нет ни одной заметки на тему того, как её быстро развернуть. Решил написать краткое руководство по этой теме.
Проект относительно новый, стартовал в 2018 году в противовес стеку ELK. Grafana решила сделать более простой и легковесный вариант хранения логов немного с другой моделью анализа, без полной индексации текстов логов, используя вместо этого метки для потоков. На деле получился хороший продукт, интегрированный в стек Grafana + Prometheus с похожей идеологией хранения и поиска (язык запросов LogQL по аналогии с PromQL).
Для начала выполню базовые действия для запуска Loki и Grafana и настрою отправку логов в Loki от различных Docker контейнеров. Большее в одну заметку не уместить. Думаю, что далее я эту тему разовью.
Я не буду запускать Loki и Grafana в одном Docker Compose файле, так как им не обязательно быть установленными вместе. Grafana поддерживает весь стек своих продуктов, так что нет особого смысла поднимать её рядом со сборщиком логов.
Сначала запустим Loki. Готовим для него
В файле
Проверим, что сервис стартовал:
Это нормальный ответ. 404 нам ответил Loki. Запустим теперь Grafana:
Указываем нужную версию в compose.yaml и запускаем:
Идём браузером по IP сервера, где запущена Grafana на порт 3000. Учётка по умолчанию - admin / admin. Заходим в Grafana, идём в раздел Connections ⇨ Data sources ⇨ Add data source. Выбираем Loki. В качестве настроек достаточно указать только url. В моём случае это http://192.168.137.30:3100/. Мотаем страничку в самый низ и нажимаем Save & Test. Ошибок быть не должно.
Стек поднят и готов к приёму логов. Отправим туда логи контейнеров Docker. Для этого у Docker существует драйвер. Его необходимо установить на хосте:
Проверяем, что он установился:
Всё в порядке. Теперь мы можем в самом демоне Docker настроить отправку всех логов в Loki через правку его конфигурации в
Это не очень удобно, если у нас нет желания собирать логи абсолютно всех контейнеров. Удобнее управлять этим для каждого контейнера отдельно. Для этого в compose файл достаточно добавить ещё одну секцию logging. Покажу сразу итоговый пример для запуска Grafana из этой публикации:
Перезапускаем проект:
Идём в Grafana, раздел Drilldown ⇨ Logs. Выбираем в выпадающем списке service имя контейнера и смотрим его логи.
Настройка простая и быстрая, легко автоматизируется. Далее я разовью эту тему и добавлю логи из других систем.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#loki #logs #devops
Проект относительно новый, стартовал в 2018 году в противовес стеку ELK. Grafana решила сделать более простой и легковесный вариант хранения логов немного с другой моделью анализа, без полной индексации текстов логов, используя вместо этого метки для потоков. На деле получился хороший продукт, интегрированный в стек Grafana + Prometheus с похожей идеологией хранения и поиска (язык запросов LogQL по аналогии с PromQL).
Для начала выполню базовые действия для запуска Loki и Grafana и настрою отправку логов в Loki от различных Docker контейнеров. Большее в одну заметку не уместить. Думаю, что далее я эту тему разовью.
Я не буду запускать Loki и Grafana в одном Docker Compose файле, так как им не обязательно быть установленными вместе. Grafana поддерживает весь стек своих продуктов, так что нет особого смысла поднимать её рядом со сборщиком логов.
Сначала запустим Loki. Готовим для него
compose.yaml и конфигурацию в config.yaml. Не буду приводить здесь содержимое. Оно будет отправлено следующим сообщением в архиве со всеми остальными конфигурациями. Для удобства скопировал её же в gitflic.# curl https://get.docker.com | bash -# git clone https://gitflic.ru/project/serveradmin/grafana-loki.git# cd grafana-loki/loki/В файле
compose.yaml укажите актуальную версию image на момент установки. Запускаем проект:# docker compose up -dПроверим, что сервис стартовал:
# curl http://192.168.137.29:3100404 page not foundЭто нормальный ответ. 404 нам ответил Loki. Запустим теперь Grafana:
# cd ../grafanaУказываем нужную версию в compose.yaml и запускаем:
# docker compose up -dИдём браузером по IP сервера, где запущена Grafana на порт 3000. Учётка по умолчанию - admin / admin. Заходим в Grafana, идём в раздел Connections ⇨ Data sources ⇨ Add data source. Выбираем Loki. В качестве настроек достаточно указать только url. В моём случае это http://192.168.137.30:3100/. Мотаем страничку в самый низ и нажимаем Save & Test. Ошибок быть не должно.
Стек поднят и готов к приёму логов. Отправим туда логи контейнеров Docker. Для этого у Docker существует драйвер. Его необходимо установить на хосте:
# docker plugin install grafana/loki-docker-driver:3.6.0-amd64 --alias loki --grant-all-permissionsПроверяем, что он установился:
# docker plugin ls018395707e37 loki:latest Loki Logging Driver trueВсё в порядке. Теперь мы можем в самом демоне Docker настроить отправку всех логов в Loki через правку его конфигурации в
/etc/docker/daemon.json. Для этого туда надо добавить:{
"debug": true,
"log-driver": "loki",
"log-opts": {
"loki-url": "http://192.168.137.30:3100//loki/api/v1/push",
"loki-batch-size": "400"
}
}Это не очень удобно, если у нас нет желания собирать логи абсолютно всех контейнеров. Удобнее управлять этим для каждого контейнера отдельно. Для этого в compose файл достаточно добавить ещё одну секцию logging. Покажу сразу итоговый пример для запуска Grafana из этой публикации:
services:
grafana:
image: docker.io/grafana/grafana-oss:12.3.1
container_name: grafana
logging:
driver: loki
options:
loki-url: "http://192.168.137.30:3100/loki/api/v1/push"
loki-retries: 2
loki-max-backoff: 800ms
loki-timeout: 1s
keep-file: "true"
mode: "non-blocking"
ports:
- "3000:3000"
volumes:
- grafana-data:/var/lib/grafana
restart: unless-stopped
volumes:
grafana-data:
driver: local
Перезапускаем проект:
# docker compose stop# docker compose up -dИдём в Grafana, раздел Drilldown ⇨ Logs. Выбираем в выпадающем списке service имя контейнера и смотрим его логи.
Настройка простая и быстрая, легко автоматизируется. Далее я разовью эту тему и добавлю логи из других систем.
———
ServerAdmin:
#loki #logs #devops
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍105👎5
Продолжу тему со сбором логов в Loki. Хочу написать законченный цикл заметок, в которых будет показан сбор логов популярных сервисов. В прошлой заметке я установил Loki + Grafana и отправил в Loki логи контейнеров Docker. Сегодня передам туда системные логи формата journald или текстовых файлов от syslog. Я покажу пример с обоими типами логов, а вы уже по месту сможете выбрать, какие использовать.
Изначально у Grafana для сбора логов с хостов была небольшая программа Promtail. Её и сейчас можно использовать, но больше её не развивают и не обновляют. На замену предложен Alloy - огромный комбайн, который включает в себя и сбор логов, их обработку и насыщение дополнительными данными, и преобразование, сбор трейсов, а также отправку системных метрик в Prometheus вместо Node Exporter. То есть Alloy объединяет логи и метрики.
В итоге вместо легковесного и простого в настройке продукта мы получаем комбайн всё в одном. Если используется полный стек Grafana в виде мониторинга, логов и трассировки, то наверное это удобно. Если собираются только логи, то не очень. Вместо Alloy можно взять Fluent Bit, Fluentd или Vector. Последние два легковесны, популярны, с простой настройкой. Можно взять и их. Но я в своём примере ограничусь стеком Grafana и буду использовать Alloy.
Репозиторий Grafana для IP адресов из России заблокирован. В общем случае он добавляется вот так:
Мы же подключим копию репозитория из зеркала Яндекса. Для краткости я подключу его без ключа. Если вам это не подходит, то скачайте ключ и как-то передайте его на целевые машины:
Как я уже упомянул, конфигурация Alloy немного замороченная. Не сказать, что прям сильно сложная, но лично мной воспринимается тяжело. Нужно вникать, когда читаешь и постоянно мотать туда-сюда конфиг, чтобы удостовериться в том, что не запутался в сущностях и названиях.
Я уже подготовил простой конфиг для логов, так что достаточно будет просто скачать и применить у себя. В базовом сценарии каких-то особых сложностей нет. Они начнутся, когда будете разбираться с различными метками, автоназначением и т.д.
Забирайте config.alloy из моего репозитория, копируйте в
Больше ничего делать не надо. На все хосты Alloy устанавливается и настраивается аналогично. В Loki логи будут прилетать с метками в виде %hostname%-logs и %hostname%-journal. Соответственно, по именам серверов вы и сможете их там выбирать. Метки, если что, можно изменить. Они настраиваются в параметрах labels и job соответственно. В конфигурации это всё наглядно видно.
По аналогии можно добавить любые текстовые логи. Тут никакой привязки к syslog нет. Просто забираем текстовые логи, определённые параметром:
Теперь можно идти в Grafana, раздел Drilldown ⇨ Logs. Выбираем в выпадающем списке service с нужным именем и типом логов и смотрим.
Единственное, что мне не нравится тут, так это то, что в тексте лога есть метки времени, и в самом хранилище есть метки времени, когда запись была добавлена. Иногда они не совпадают и это неудобно. В Logstash есть модуль date для того, чтобы выделять дату из текста поступающих логов и использовать ее в качестве даты документа в Elasticsearch.
❓Кто-нибудь настраивал подобное в Loki, чтобы время документа совпадало со временем в логе?
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#loki #logs #devops
Изначально у Grafana для сбора логов с хостов была небольшая программа Promtail. Её и сейчас можно использовать, но больше её не развивают и не обновляют. На замену предложен Alloy - огромный комбайн, который включает в себя и сбор логов, их обработку и насыщение дополнительными данными, и преобразование, сбор трейсов, а также отправку системных метрик в Prometheus вместо Node Exporter. То есть Alloy объединяет логи и метрики.
В итоге вместо легковесного и простого в настройке продукта мы получаем комбайн всё в одном. Если используется полный стек Grafana в виде мониторинга, логов и трассировки, то наверное это удобно. Если собираются только логи, то не очень. Вместо Alloy можно взять Fluent Bit, Fluentd или Vector. Последние два легковесны, популярны, с простой настройкой. Можно взять и их. Но я в своём примере ограничусь стеком Grafana и буду использовать Alloy.
Репозиторий Grafana для IP адресов из России заблокирован. В общем случае он добавляется вот так:
# mkdir -p /etc/apt/keyrings# wget -O /etc/apt/keyrings/grafana.asc https://apt.grafana.com/gpg-full.key# chmod 644 /etc/apt/keyrings/grafana.asc# echo "deb [signed-by=/etc/apt/keyrings/grafana.asc] https://apt.grafana.com stable main" > /etc/apt/sources.list.d/grafana.listМы же подключим копию репозитория из зеркала Яндекса. Для краткости я подключу его без ключа. Если вам это не подходит, то скачайте ключ и как-то передайте его на целевые машины:
# echo "deb [trusted=yes] https://mirror.yandex.ru/mirrors/packages.grafana.com/oss/deb/ stable main" > /etc/apt/sources.list.d/grafana.list# apt update# apt install alloyКак я уже упомянул, конфигурация Alloy немного замороченная. Не сказать, что прям сильно сложная, но лично мной воспринимается тяжело. Нужно вникать, когда читаешь и постоянно мотать туда-сюда конфиг, чтобы удостовериться в том, что не запутался в сущностях и названиях.
Я уже подготовил простой конфиг для логов, так что достаточно будет просто скачать и применить у себя. В базовом сценарии каких-то особых сложностей нет. Они начнутся, когда будете разбираться с различными метками, автоназначением и т.д.
Забирайте config.alloy из моего репозитория, копируйте в
/etc/alloy и перезапускайте службу. Заодно добавьте в автозагрузку. По умолчанию она вроде не делает этого:# systemctl restart alloy# systemctl enable alloyБольше ничего делать не надо. На все хосты Alloy устанавливается и настраивается аналогично. В Loki логи будут прилетать с метками в виде %hostname%-logs и %hostname%-journal. Соответственно, по именам серверов вы и сможете их там выбирать. Метки, если что, можно изменить. Они настраиваются в параметрах labels и job соответственно. В конфигурации это всё наглядно видно.
По аналогии можно добавить любые текстовые логи. Тут никакой привязки к syslog нет. Просто забираем текстовые логи, определённые параметром:
__path__ = "/var/log/{syslog,messages,*.log}",Теперь можно идти в Grafana, раздел Drilldown ⇨ Logs. Выбираем в выпадающем списке service с нужным именем и типом логов и смотрим.
Единственное, что мне не нравится тут, так это то, что в тексте лога есть метки времени, и в самом хранилище есть метки времени, когда запись была добавлена. Иногда они не совпадают и это неудобно. В Logstash есть модуль date для того, чтобы выделять дату из текста поступающих логов и использовать ее в качестве даты документа в Elasticsearch.
❓Кто-нибудь настраивал подобное в Loki, чтобы время документа совпадало со временем в логе?
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#loki #logs #devops
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍79👎2
Продолжу одновременно две темы, которые развиваю последнее время - почтовый сервер на базе Postfix и сбор логов в Loki. Покажу, как очень просто и быстро собирать логи Postfix в Loki с базовым анализом содержимого и простенькой визуализацией в дашборде.
Напомню, что у меня есть подробная статья про мониторинг Postfix с помощью Zabbix. Там в том числе выполняется и анализ логов, но локально, а в систему мониторинга уходит результат локальной обработки. Сами логи Postfix не хранятся.
Сегодня я рассмотрю другой вариант - непосредственно хранение логов на внешнем сервере Loki, который сам будет парсить данные и выполнять некоторую аналитику. Я выведу на дашборд метрики:
◽️Количество доставленных и отклонённых писем в виде соотношения и временной шкалы
◽️Статистика по доменам внешних получателей писем от нас
◽️Статистика по полученным письмам локальных доменов нашего сервера
◽️Статистика по отклонённым письмам в разрезе ошибок и доменов
Помимо этого Loki автоматически будет парсить поступающие логи, что позволит выполнять группировки по 24 распознанным полям: имя получателя, имя отправителя, домен отправителя, IP адрес, ID сообщения, статусы и т.д.
Данную заметку я пишу на примере реального почтового сервера, который я настроил по этой своей статье. Это важно, так как в разных версиях Postfix немного отличается формат логов. Я за основу взял готовый Dashboard из базы Grafana и подправил его под свою версию сервера и настроек Alloy, которые я возьму из этой заметки. А сам Loki установлен и настроен так же, как тут.
Первым делом устанавливаем Alloy на почтовый сервер с Postfix. Посмотреть установку можно в предыдущей заметке. Для сбора только почтовых логов достаточно такой конфигурации:
После этого логи сразу потекут в Loki. Их можно смотреть в разделе Drilldown ⇨ Logs. В качестве service_name в соответствии с настройками Ally будет указано имя сервера и приписка
Далее нам нужно импортировать дашборд. Я положил его в свой репозиторий grafana-loki, в раздел
Если у вас Loki и Postfix настроены по моим статьям и заметкам, на которые я дал ссылки, то всё должно получиться, потому что все настройки я взял с работающего сервера. Проверил в момент написания заметки. Как это всё выглядит, видно ниже на скриншотах.
Если что-то не работает на дашборде, значит либо лог немного отличается, там локальный парсер прямо в настройках виджетов, либо выборка по меткам не совпадает, если свои метки ставили. Всё это проверяется тут же, в дашборде, в настройках виджетов. Я так всё и правил в изначальном дашборде. У меня после импорта ничего не работало. Поправил и шаблоны парсинга, и метки под свои настройки, добавил ещё один виджет, разделив внешних и внутренних получателей. В итоге всё получилось.
Ниже публикую файлы, которые используются в заметке. Они же продублированы в репозитории.
Подобная настройка максимально простая и быстрая, настраивается буквально за 5 минут по готовым конфигам и шаблонам. Плюс, это всё в формате IaC.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#loki #logs #mailserver #postfix
Напомню, что у меня есть подробная статья про мониторинг Postfix с помощью Zabbix. Там в том числе выполняется и анализ логов, но локально, а в систему мониторинга уходит результат локальной обработки. Сами логи Postfix не хранятся.
Сегодня я рассмотрю другой вариант - непосредственно хранение логов на внешнем сервере Loki, который сам будет парсить данные и выполнять некоторую аналитику. Я выведу на дашборд метрики:
◽️Количество доставленных и отклонённых писем в виде соотношения и временной шкалы
◽️Статистика по доменам внешних получателей писем от нас
◽️Статистика по полученным письмам локальных доменов нашего сервера
◽️Статистика по отклонённым письмам в разрезе ошибок и доменов
Помимо этого Loki автоматически будет парсить поступающие логи, что позволит выполнять группировки по 24 распознанным полям: имя получателя, имя отправителя, домен отправителя, IP адрес, ID сообщения, статусы и т.д.
Данную заметку я пишу на примере реального почтового сервера, который я настроил по этой своей статье. Это важно, так как в разных версиях Postfix немного отличается формат логов. Я за основу взял готовый Dashboard из базы Grafana и подправил его под свою версию сервера и настроек Alloy, которые я возьму из этой заметки. А сам Loki установлен и настроен так же, как тут.
Первым делом устанавливаем Alloy на почтовый сервер с Postfix. Посмотреть установку можно в предыдущей заметке. Для сбора только почтовых логов достаточно такой конфигурации:
loki.write "default" {
endpoint {
url = "http://195.20.47.169:3100/loki/api/v1/push"
}
external_labels = {}
}
local.file_match "postfix" {
path_targets = [{
__address__ = "localhost",
__path__ = "/var/log/mail.log",
instance = constants.hostname,
job = string.format("%s-maillog", constants.hostname),
}]
}
loki.source.file "postfix" {
targets = local.file_match.postfix.targets
forward_to = [loki.write.default.receiver]
}После этого логи сразу потекут в Loki. Их можно смотреть в разделе Drilldown ⇨ Logs. В качестве service_name в соответствии с настройками Ally будет указано имя сервера и приписка
-maillog. В моём случай это будет mail.zeroxzed.ru-maillog. На картинках другое название, но это мне показалось более удачное.Далее нам нужно импортировать дашборд. Я положил его в свой репозиторий grafana-loki, в раздел
grafana/dashboards/, файл Postfix Delivery Status.json. Его нужно скачать и импортировать в Grafana. Во время импорта в качестве источника данных укажите свой Datasource с Loki. Если он не подцепится автоматически, то после импорта зайдите в настройки дашборда, раздел Variables, укажите его явно в переменной DS_LOKI.Если у вас Loki и Postfix настроены по моим статьям и заметкам, на которые я дал ссылки, то всё должно получиться, потому что все настройки я взял с работающего сервера. Проверил в момент написания заметки. Как это всё выглядит, видно ниже на скриншотах.
Если что-то не работает на дашборде, значит либо лог немного отличается, там локальный парсер прямо в настройках виджетов, либо выборка по меткам не совпадает, если свои метки ставили. Всё это проверяется тут же, в дашборде, в настройках виджетов. Я так всё и правил в изначальном дашборде. У меня после импорта ничего не работало. Поправил и шаблоны парсинга, и метки под свои настройки, добавил ещё один виджет, разделив внешних и внутренних получателей. В итоге всё получилось.
Ниже публикую файлы, которые используются в заметке. Они же продублированы в репозитории.
Подобная настройка максимально простая и быстрая, настраивается буквально за 5 минут по готовым конфигам и шаблонам. Плюс, это всё в формате IaC.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#loki #logs #mailserver #postfix
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍66👎1
Прорабатываю тему централизованного хранения логов в Loki. Потом для удобства объединю её в большую статью. Уже наметил план. Решил, чтобы вечно не откладывать, резать слона по частям, а не пытаться сразу всё сделать.
На текущий момент я разобрал следующие темы:
1️⃣ Установка, настройка Loki, сбор логов Docker контейнеров
2️⃣ Сбор системных логов Linux (syslog и journald) с помощью Alloy
3️⃣ Сбор логов Postfix и пример создания дашборда для них
Сегодня разберу вопрос отправки журналов с логами Windows. Как бы не пытались аврально импортозаместиться, всё равно инфраструктура на Windows - значительная часть. А может и бóльшая, смотря как считать.
На удивление, настройка Alloy оказалась довольно замороченной, несмотря на то, что есть документация. ИИ по какой-то причине предлагает постоянно неработающие конфигурации. Я что с Linux, что с Windows в итоге разбирался сам.
Основная проблем с метками, привязанными к имени сервера и с их синтаксисом в конфигурации в целом. С непривычки приходится много времени тратить, чтобы разобраться. Вообще, это самая важная часть настройки сбора логов в Loki, так как тут выборка в основном по ним идёт. Надо сразу аккуратно продумать всю схему, чтобы потом не путаться.
Установка Alloy в Windows максимально простая - скачиваем установщик из репозитория и запускаем. Нужен будет файл alloy-installer-windows-amd64.exe.
Alloy устанавливается как служба с автозапуском. После установки нужно отредактировать конфигурацию. К сожалению, если я правильно понял, для логов Windows не работает автообнаружение всех системных журналов, в том числе служб и сервисов с автоматическим назначением меток к ним. Их нужно явно указывать в конфигурации.
Покажу пример с тремя стандартными журналами: System, Application и Security. Положил работающий и отлаженный файл конфигурации в репозиторий. На винде отлаживать неудобно, так как если в конфигурации была ошибка, служба тупо не запускалась с неинформативной ошибкой. Приходилось вручную всё проверять и пробовать разные варианты.
В итоге получил то, что хотел. Для логов назначил две метки:
◽️
◽️
С этими метками можно просто открыть все логи сервера по имени и в нём по меткам открыть нужные потоки. Но если будет необходимость сразу из общего списка взять отдельный job конкретного сервера, это тоже можно сделать, так как в названии job будет имя сервера.
Редактируем конфигурацию, перезапускаем службу Alloy и идём в Grafana смотреть логи. Никаких дополнительных настроек делать не надо. Loki сам парсит виндовые логи и выделяет в них стандартные поля: event_id, channel, level, security_userId, timeCreated и т.д. По ним сразу можно делать выборку.
Несмотря на некоторые трудности и неудобства стека на базе Loki и Alloy, пользоваться им приятно в том плане, что базовые настройки относительно просты и функциональны. Можно особо не заморачиваясь просто отправлять логи в Loki и с ними тут будет удобно работать. Он сам распарсит стандартные типы, что позволит сразу выборки делать и рисовать дашборды. Когда изучал ELK с парсингом больше ковырялся. Тут он как-то проще работает.
Далее планирую разобрать сбор логов веб сервера и создание дашбордов для них с важными метриками. Плюс, отдельно хранение и очистку старых журналов. А потом всё это можно будет собрать в единую законченную статью.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#loki #logs #devops
На текущий момент я разобрал следующие темы:
Сегодня разберу вопрос отправки журналов с логами Windows. Как бы не пытались аврально импортозаместиться, всё равно инфраструктура на Windows - значительная часть. А может и бóльшая, смотря как считать.
На удивление, настройка Alloy оказалась довольно замороченной, несмотря на то, что есть документация. ИИ по какой-то причине предлагает постоянно неработающие конфигурации. Я что с Linux, что с Windows в итоге разбирался сам.
Основная проблем с метками, привязанными к имени сервера и с их синтаксисом в конфигурации в целом. С непривычки приходится много времени тратить, чтобы разобраться. Вообще, это самая важная часть настройки сбора логов в Loki, так как тут выборка в основном по ним идёт. Надо сразу аккуратно продумать всю схему, чтобы потом не путаться.
Установка Alloy в Windows максимально простая - скачиваем установщик из репозитория и запускаем. Нужен будет файл alloy-installer-windows-amd64.exe.
Alloy устанавливается как служба с автозапуском. После установки нужно отредактировать конфигурацию. К сожалению, если я правильно понял, для логов Windows не работает автообнаружение всех системных журналов, в том числе служб и сервисов с автоматическим назначением меток к ним. Их нужно явно указывать в конфигурации.
Покажу пример с тремя стандартными журналами: System, Application и Security. Положил работающий и отлаженный файл конфигурации в репозиторий. На винде отлаживать неудобно, так как если в конфигурации была ошибка, служба тупо не запускалась с неинформативной ошибкой. Приходилось вручную всё проверять и пробовать разные варианты.
В итоге получил то, что хотел. Для логов назначил две метки:
◽️
instance = "имя сервера", например WINSRV01.◽️
job = "имя сервера"-"имя журнала", то есть WINSRV01-application. С этими метками можно просто открыть все логи сервера по имени и в нём по меткам открыть нужные потоки. Но если будет необходимость сразу из общего списка взять отдельный job конкретного сервера, это тоже можно сделать, так как в названии job будет имя сервера.
Редактируем конфигурацию, перезапускаем службу Alloy и идём в Grafana смотреть логи. Никаких дополнительных настроек делать не надо. Loki сам парсит виндовые логи и выделяет в них стандартные поля: event_id, channel, level, security_userId, timeCreated и т.д. По ним сразу можно делать выборку.
Несмотря на некоторые трудности и неудобства стека на базе Loki и Alloy, пользоваться им приятно в том плане, что базовые настройки относительно просты и функциональны. Можно особо не заморачиваясь просто отправлять логи в Loki и с ними тут будет удобно работать. Он сам распарсит стандартные типы, что позволит сразу выборки делать и рисовать дашборды. Когда изучал ELK с парсингом больше ковырялся. Тут он как-то проще работает.
Далее планирую разобрать сбор логов веб сервера и создание дашбордов для них с важными метриками. Плюс, отдельно хранение и очистку старых журналов. А потом всё это можно будет собрать в единую законченную статью.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#loki #logs #devops
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
2👍98👎1
Домучиваю статью про Loki. Никак не соберусь и не доделаю её полностью. В процессе настройки хочется наполнить систему реальными логами в нормальном объёме, чтобы всё проверить. Я использовал для этого простую утилиту с гитхаба для генерации логов типовых форматов - flog.
Это одиночный бинарник на Go, с которым очень просто работать. Он поддерживает несколько форматов:
- Apache common
- Apache combined
- Apache error
- RFC3164
- RFC5424
- Common log fomat
- JSON
По сути тут 2 типовых формата - разные виды логов веб сервера и syslog, плюс json, где тоже генерируются логи веб сервера.
Для использования можно скачать бинарник в репозиотрии, либо запустить через docker:
Вывели в консоль 10 строк стандартного лога apache, nginx и т.д. Все веб сервера чаще всего используют по умолчанию этот формат логов. Если добавить ключ
Если тестируете логи докера, то удобно запустить генерацию через докер и собирать вывод stdout. В случае какого-то отдельного веб сервера, удобнее писать логи в файл, как это обычно делает веб сервер и потом их забирать. Делается это примерно так:
Сгенерировали лог
Такая вот простая утилитка, которая нужна исключительно для настройки и отладки систем сбора логов. Из-за максимальной простоты её удобно использовать для этой задачи. Не придумаю, где она ещё может быть полезна.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX 😩
#logs
Это одиночный бинарник на Go, с которым очень просто работать. Он поддерживает несколько форматов:
- Apache common
- Apache combined
- Apache error
- RFC3164
- RFC5424
- Common log fomat
- JSON
По сути тут 2 типовых формата - разные виды логов веб сервера и syslog, плюс json, где тоже генерируются логи веб сервера.
Для использования можно скачать бинарник в репозиотрии, либо запустить через docker:
# docker run -it --rm mingrammer/flog flog -f apache_common -n 10Вывели в консоль 10 строк стандартного лога apache, nginx и т.д. Все веб сервера чаще всего используют по умолчанию этот формат логов. Если добавить ключ
-l, то генерация логов будет идти непрерывно, пока её не остановишь.Если тестируете логи докера, то удобно запустить генерацию через докер и собирать вывод stdout. В случае какого-то отдельного веб сервера, удобнее писать логи в файл, как это обычно делает веб сервер и потом их забирать. Делается это примерно так:
# wget https://github.com/mingrammer/flog/releases/download/v0.4.4/flog_0.4.4_linux_amd64.tar.gz# tar -xzf flog_0.4.4_linux_amd64.tar.gz flog# mv flog /usr/local/bin/# flog -t log -f apache_combined -o /var/log/nginx/access.log -b 10485760/var/log/nginx/access.log is created.Сгенерировали лог
/var/log/nginx/access.log размером в 10 МБ. Теперь этот файл можно отправить в Loki. Конкретно по веб серверу хочу сделать отдельную заметку с примером дашборда.Такая вот простая утилитка, которая нужна исключительно для настройки и отладки систем сбора логов. Из-за максимальной простоты её удобно использовать для этой задачи. Не придумаю, где она ещё может быть полезна.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#logs
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍54👎2
Я наконец-то дописал статью про сбор и хранение логов в Loki:
⇨ Настройка Grafana Loki для сбора логов
Написал в формате, как делал раньше - достаточно бездумного копипаста, чтобы всё получилось. То есть если вам не хочется вникать, то можно этого не делать. Просто копируете то, что я предлагаю, и всё получится. Я постарался зафиксировать все нюансы, ничего не пропуская.
В статье рассказано, как развернуть Loki и отправить туда:
◽️Системные логи Linux и Windows
◽️Логи Docker контейнеров
◽️Логи веб сервера Nginx или Angie
◽️Логи сетевых устройств
То есть дана база для внедрения системы в разнородной инфраструктуре, чтобы собрать вообще все логи в одном месте. База не в плане внедрения, а в плане обзора возможностей и технических нюансов работы непосредственно с Loki. Автоматизацию этого процесса нужно будет делать самостоятельно по месту.
Помимо сбора логов я показал на примере веб сервера, как делать свои дашборды, и как выборочно удалять данные из хранилища.
Весь текст написан и проверен полностью мной. ИИ привлекал только для изучения и подготовки своих конфигураций. Я сам изучал продукт с нуля, поэтому старался разобраться с основными моментами. Вообще все материалы, которые я пишу, я делаю сам от и до. После ИИ всё перепроверяю и дополняю.
В целом, система мне понравилась. Много лет я собираю логи в ELK Stack. Он более функциональный, порог входа у него выше, и потребление ресурсов тоже заметно выше, чем у Loki. У них разный формат хранения и обработки данных, из-за этого сильно отличаются возможности по визуализации. Некоторые вещи по выборке и подготовке данных, которые сразу работают в ELK, в Loki в лоб не работают.
Например, нельзя просто взять и сформировать топ 10 IP адресов клиентов сайта, которые сделали больше всего запросов за сутки или неделю. Если в ELK я просто брал и делал это на дашборде, то Loki выдаёт ошибки на слишком большой объём данных, который нужно обработать для выполнения запросов. Там нужно это реализовывать по другому. Ну и других различий много: аутентификация, очистка данных, отказоустойчивость и многое другое в ELK более развито.
Если нужно что-то проще и легковеснее, чем Loki, то можно взять VictoriaLogs. Там всё проще и быстрее, чем в Loki. По крайней мере год назад так было, когда я тестировал этот продукт. Он активно развивается, так что в планах ещё раз его попробовать в таком же формате, как Loki, собрав туда разнородные логи со всех систем. Это если время найду на это. Особой нужды лично у меня в этом нет.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX 😩
#loki #logs #статья
⇨ Настройка Grafana Loki для сбора логов
Написал в формате, как делал раньше - достаточно бездумного копипаста, чтобы всё получилось. То есть если вам не хочется вникать, то можно этого не делать. Просто копируете то, что я предлагаю, и всё получится. Я постарался зафиксировать все нюансы, ничего не пропуская.
В статье рассказано, как развернуть Loki и отправить туда:
◽️Системные логи Linux и Windows
◽️Логи Docker контейнеров
◽️Логи веб сервера Nginx или Angie
◽️Логи сетевых устройств
То есть дана база для внедрения системы в разнородной инфраструктуре, чтобы собрать вообще все логи в одном месте. База не в плане внедрения, а в плане обзора возможностей и технических нюансов работы непосредственно с Loki. Автоматизацию этого процесса нужно будет делать самостоятельно по месту.
Помимо сбора логов я показал на примере веб сервера, как делать свои дашборды, и как выборочно удалять данные из хранилища.
Весь текст написан и проверен полностью мной. ИИ привлекал только для изучения и подготовки своих конфигураций. Я сам изучал продукт с нуля, поэтому старался разобраться с основными моментами. Вообще все материалы, которые я пишу, я делаю сам от и до. После ИИ всё перепроверяю и дополняю.
В целом, система мне понравилась. Много лет я собираю логи в ELK Stack. Он более функциональный, порог входа у него выше, и потребление ресурсов тоже заметно выше, чем у Loki. У них разный формат хранения и обработки данных, из-за этого сильно отличаются возможности по визуализации. Некоторые вещи по выборке и подготовке данных, которые сразу работают в ELK, в Loki в лоб не работают.
Например, нельзя просто взять и сформировать топ 10 IP адресов клиентов сайта, которые сделали больше всего запросов за сутки или неделю. Если в ELK я просто брал и делал это на дашборде, то Loki выдаёт ошибки на слишком большой объём данных, который нужно обработать для выполнения запросов. Там нужно это реализовывать по другому. Ну и других различий много: аутентификация, очистка данных, отказоустойчивость и многое другое в ELK более развито.
Если нужно что-то проще и легковеснее, чем Loki, то можно взять VictoriaLogs. Там всё проще и быстрее, чем в Loki. По крайней мере год назад так было, когда я тестировал этот продукт. Он активно развивается, так что в планах ещё раз его попробовать в таком же формате, как Loki, собрав туда разнородные логи со всех систем. Это если время найду на это. Особой нужды лично у меня в этом нет.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#loki #logs #статья
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍156👎1
Сколько лет настраиваю веб сервера Nginx и только недавно случайно узнал, когда настраивал отправку логов в Loki, что веб сервер может одновременно писать логи в разных форматах. Просто в голову не приходило попробовать, что так можно.
Речь вот про что. Допустим, вы отправляете логи в какое-то хранилище. Туда удобнее отправлять формат json. Он удобен для машины, но не для восприятия человеком. Да, можно взять jq или что-то подобное для удобства, но это всё равно не то. Глазами удобнее всего смотреть на обычные текстовые логи.
Если хотите оставить себе возможность смотреть на логи глазами и грепать их, то можно сделать вот так. Показываю сразу пример конфигурации Angie/Nginx.
Разумеется, без особого основания так делать не надо, потому что нагрузка на запись от логирования возрастёт в 2 раза. Но если очень хочется, то можно. Будут писаться одновременно оба лога в разных форматах.
У меня, к примеру, куча башевских костылей написана под обычный формат логов. Иногда бывает нужно прямо на хосте что-то быстро сделать. Если нет обычных логов, мне неудобно. Конечно, тут можно возразить, что от этого надо избавляться и использовать другие подходы. Ну уж какие есть. Я не работаю с большими нагрузками. Для меня всё это некритично. Можно ручками сходить на сервер и что-то там проверить, сделать.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX 😩
#logs #angie #nginx
Речь вот про что. Допустим, вы отправляете логи в какое-то хранилище. Туда удобнее отправлять формат json. Он удобен для машины, но не для восприятия человеком. Да, можно взять jq или что-то подобное для удобства, но это всё равно не то. Глазами удобнее всего смотреть на обычные текстовые логи.
Если хотите оставить себе возможность смотреть на логи глазами и грепать их, то можно сделать вот так. Показываю сразу пример конфигурации Angie/Nginx.
http {
...................
log_format main
'$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
log_format json escape=json
'{'
'"time_local":"$time_local",'
'"remote_addr":"$remote_addr",'
'"remote_user":"$remote_user",'
'"request":"$request",'
'"status": "$status",'
'"body_bytes_sent":"$body_bytes_sent",'
'"request_time":"$request_time",'
'"http_referrer":"$http_referer",'
'"http_user_agent":"$http_user_agent"'
'}';
...................
access_log /var/log/angie/access.log main;
access_log /var/log/angie/access.json.log json;
...................
}Разумеется, без особого основания так делать не надо, потому что нагрузка на запись от логирования возрастёт в 2 раза. Но если очень хочется, то можно. Будут писаться одновременно оба лога в разных форматах.
У меня, к примеру, куча башевских костылей написана под обычный формат логов. Иногда бывает нужно прямо на хосте что-то быстро сделать. Если нет обычных логов, мне неудобно. Конечно, тут можно возразить, что от этого надо избавляться и использовать другие подходы. Ну уж какие есть. Я не работаю с большими нагрузками. Для меня всё это некритично. Можно ручками сходить на сервер и что-то там проверить, сделать.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#logs #angie #nginx
Please open Telegram to view this post
VIEW IN TELEGRAM
👍117👎4
Небольшой практический совет для тех, кто собирает или планирует собирать логи Docker контейнеров в Loki. У меня был подробный цикл заметок по этой теме:
1️⃣ Установка, настройка Loki, сбор логов Docker контейнеров
2️⃣ Сбор системных логов Linux (syslog и journald) с помощью Alloy
3️⃣ Сбор логов Postfix и пример создания дашборда для них
4️⃣ Сбор журналов Windows.
5️⃣ Приём логов Syslog с помощью Vector
6️⃣ Отключение сбора статистки в Alloy
Также есть общая статья со всеми этими темами. Мне нравится эта система. Я её сейчас постоянно использую. Скорее всего больше не буду настраивать ELK, так как для моих задач мне Loki хватает, хотя она и менее функциональная, но проще в настройке и меньше требует ресурсов.
Во время изучения Loki собирал логи с помощью встроенного плагина докер - grafana/loki-docker-driver. Он удобен в первую очередь тем, что можно в каждом конкретном контейнере указать, что логи отправляются в Loki. Примерно так:
Благодаря этому можно выбирать, какой контейнер и куда отправляет логи. Если вам нужны логи только от одного контейнера, а у вас их крутится 10, то этот драйвер будет в самый раз.
Но у такого подхода есть существенные минусы, с которыми я столкнулся:
1️⃣ Сам по себе драйвер - отдельная сущность. И если в нём будут ошибки, то у вас не запустятся контейнеры, которые от него зависят. И я эти ошибки ловил. Не всегда и не везде, но иногда было так, что этот драйвер по какой-то причине не запускался. Причём быстро выяснить причину не удавалось. Просто не запускался автоматически loki.sock после перезагрузки хоста. Лечилось ручным запуском. Причина была не в том, что Loki недоступен.
2️⃣ За плагином надо отдельно следить и обновлять. Причём обновление требует перезапуска самой службы Docker со всеми вытекающими последствиями в виде остановки или перезапуска контейнеров в зависимости от их настроек. Это если у вас не включен параметр live-restore. С ним контейнеры не будут перезапускаться вместе со службой. По умолчанию этот параметр не активен. С ним есть свои нюансы.
Для более надёжной и стабильной работы логи докера лучше вынести в текстовый файл и забирать сборщиком логов, который вы обычно используете. Он и так скорее всего будет установлен для сбора системных логов, так что добавить в него сбор ещё одного текстового лога будет не очень накладно. А если нужно фильтровать контейнеры, для которых нужен сбор логов, можно в них добавлять отдельную метку для этого. Тот же Alloy без проблем отфильтрует контейнеры по этой метке.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX 😩
#docker #logs #loki #совет
Также есть общая статья со всеми этими темами. Мне нравится эта система. Я её сейчас постоянно использую. Скорее всего больше не буду настраивать ELK, так как для моих задач мне Loki хватает, хотя она и менее функциональная, но проще в настройке и меньше требует ресурсов.
Во время изучения Loki собирал логи с помощью встроенного плагина докер - grafana/loki-docker-driver. Он удобен в первую очередь тем, что можно в каждом конкретном контейнере указать, что логи отправляются в Loki. Примерно так:
logging: driver: loki options: loki-url: "http://192.168.137.30:3100/loki/api/v1/push" loki-retries: 2 loki-max-backoff: 800ms loki-timeout: 1s keep-file: "true" mode: "non-blocking"Благодаря этому можно выбирать, какой контейнер и куда отправляет логи. Если вам нужны логи только от одного контейнера, а у вас их крутится 10, то этот драйвер будет в самый раз.
Но у такого подхода есть существенные минусы, с которыми я столкнулся:
Для более надёжной и стабильной работы логи докера лучше вынести в текстовый файл и забирать сборщиком логов, который вы обычно используете. Он и так скорее всего будет установлен для сбора системных логов, так что добавить в него сбор ещё одного текстового лога будет не очень накладно. А если нужно фильтровать контейнеры, для которых нужен сбор логов, можно в них добавлять отдельную метку для этого. Тот же Alloy без проблем отфильтрует контейнеры по этой метке.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#docker #logs #loki #совет
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
ServerAdmin.ru
Я часто упоминал в различных заметках систему по сбору логов Loki. Например, вот в этой подборке подобных систем (там сразу можете посмотреть аналоги). При этом у меня нет ни одной заметки на тему того, как её быстро развернуть. Решил написать краткое руководство…
1👍53👎1