Давно не было заметок на тему систем мониторинга, потому что всё более-менее известное и удобное я обозревал ранее. В этот раз попался интересный проект, про который я даже не слышал, не то, что не видел. Упоминание было в пятничной подборке видео, где был обзор на Beszel. Это очень простой и легковесный мониторинг для одного или группы хостов. Поддерживает Linux, FreeBSD, MacOS. Он отлично дополнит подборку легковесных мониторингов для одиночного сервера, хотя поддерживает через агенты сбор метрик и с других серверов.

Сразу перечислю основные особенности:

▪️Простой и легковесный мониторинг, написанный на Go.
▪️После установки сразу готов к работе, не требует особой настройки.
▪️Собирает только базовые метрики: доступность хоста, загрузка процессора, памяти, дисков, сетевой трафик, доступные метрики с сенсоров платформы. Плюс всё то же самое, только для Docker контейнеров.
▪️Собирает информацию через агентов на удалённых серверах. Агенты в виде бинарника или Docker контейнера. Подключается к агентам, сам ходит на хосты за информацией.
▪️Поддерживает различные провайдеры для аутентификации.
▪️Умеет сам себя бэкапить локально или на S3.
▪️Имеет REST API.
▪️Приложение построено на базе фреймворка pocketbase.io. Состояние хранится в SQLite.

Как и было сказано, Beszel очень прост в установке. Состоит из одного бинарника. Запустить можно как напрямую, так и через Docker. Если использовать бинарник, надо будет юнит для systemd писать, поэтому проще в Docker запустить:

# mkdir -p ./beszel_data && \
# docker run -d --name beszel --restart=unless-stopped \
 -v ./beszel_data:/beszel_data -p 8090:8090 henrygd/beszel

Можно идти по IP адресу на порт 8090 и создавать учётную запись. Есть русский язык, причём перевод нормальный. У меня он включился по умолчанию, переключить на английский желания не возникло.

На главной странице можно сразу же добавить сервер для мониторинга. Нажимаете соответствующую кнопку, указываете имя и IP адрес сервера и получаете команду для установки либо через бинарник, либо через Docker. После установки агента, сразу начинается сбор метрик.

Для каждого сервера можно включить свои уведомления или использовать глобальные. Настраиваются в пару кликов, очень наглядно. Отправляться могут как по SMTP, так и через популярные мессенджеры. Под капотом там вебхуки через проект Shoutrrr со своим синтаксисом мессенджеров. Например, для Telegram строка с настройкой уведомлений выглядит так:

telegram://token@telegram?chats=@channel-1[,chat-id-1,...]

Пример уведомлений в Telegram есть внизу на картинке.

Мониторинг реально легковесный. Я запустил на чистой системе, добавил 3 хоста. Нагрузка болталась в районе 0-1% CPU и 56372K памяти. Посмотрел так:

# pmap 25017 -d

Настройка очень простая. Вообще никуда не заглядывал. Сходу всё настроил, оповещения работают, протестировал. И на недоступность хоста, и на потребление ресурсов. В целом, всё понравилось. Очень простой и лёгкий в настройке мониторинг. Выглядит симпатично. Можно пользоваться как для одиночного сервера, так и для нескольких.

⇨ 🌐 Сайт / Исходники

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#мониторинг

Протокол НТТРv3, или как ещё называют эту версию QUIC, появился довольно давно. Практические реализации появились ещё в 2020-м году. Я всё как-то мимо него проходил, не погружался и не настраивал. На прошлой неделе вышло видео:

▶️ Ускоряем HTTP/3: DNS-записи HTTPS

В настройке HTTPv3 ничего сложного нет, так что решил разобраться, попробовать и дальше уже включать по умолчанию. Никаких технических преград сейчас к этому нет.

Для работы HTTP версии 3 нужно выполнить несколько шагов.

1️⃣ В настройке веб сервера включить его поддержку. В Nginx/Angie это делается следующим образом. Добавляем уже к существующим параметрам виртуального хоста с HTTPS следующие настройки:

listen 443 quic reuseport;
http3 on;

location / {
add_header Alt-Svc 'h3=":443"; ma=86400';
}

Обращаю внимание на важный момент. В пакетах Angie из репозиториев разработчиков модуль http_v3_module включён по умолчанию. Не проверял его наличие в пакетах с Nginx. DeepSeek посоветовал вручную собрать Nginx с параметром --with-http_v3_module.

И второй момент. Я изначально add_header добавил не в корневой location, а в параметры сервера, где добавляются другие заголовки. HTTPv3 не заработал. Долго выяснял, в чём дело. Думал, это формальность. Я обычно всегда заголовки ко всему серверу применяю, а не location. Но тут, судя по всему, это имеет принципиальное значение.

2️⃣ Открываем на файрволе порт 443 UDP, так как QUIC работает по UDP. Я сначала тоже забыл это сделать. У меня по умолчанию всё, что не надо, закрыто, поэтому ничего не заработало. Быстро сообразил, что надо открыть UDP порт.

Этих настроек уже достаточно, чтобы HTTPv3 заработал, но не с первого запроса. По умолчанию браузер обращается по v2 и только после того, как придёт настроенный заголовок, переходит на v3. А первые несколько запросов улетают по v2.

Чтобы это исправить, придумана новая DNS запись типа HTTPS. Браузер, при обращении к сайту, ищет A запись и параллельно запрашивает HTTPS. Если она есть и там указано, что сайт поддерживает работу HTTPv3, он сразу обращается по v3.

Не все DNS хостинги поддерживают этот тип записи. Например, DNS от Яндекса не позволяет создать эту запись. Я в итоге от него отказался. Бесплатный DNS хостинг есть у Selectel. Причём недавно они выпустили новую версию этого хостинга и всем предлагают туда перейти. Мне как-то лень переносить было, и так всё работает. Но старая версия DNS хостинга не поддерживает эти записи. Пришлось перейти на новую. Там без проблем создал HTTPS запись. Выглядит она примерно так:

# dig serveradmin.ru HTTPS
serveradmin.ru.     3600  IN   HTTPS  1 . alpn="h3,h2"

1 - приоритет
. - основное доменное имя, аналог serveradmin.ru
alpn="h3,h2" - указание на поддержку версии HTTPv3 и HTTPv2

3️⃣ Таким образом, третий пункт – добавление DNS записи типа HTTPS.

После этого сайт с первого запроса стал работать по протоколу третьей версии.

В настройке нет никаких проблем, можно прямо сейчас использовать новую версию протокола. К тому же это максимально безопасно, так как современные браузеры всегда делают попытку открыть сайт и по v2. Если вы где-то ошибётесь в настройке, то v3 просто не заработает. Я в этом убедился на практике. Когда что-то было не так, сайт работал как и прежде. И только после того, как всё сделал правильно, заработал HTTPv3.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#webserver #angie

С момента первого моего упоминания сервиса axiom.co, продолжаю его использовать. Вновь пишу о нём, чтобы рассказать тем, кто не видел эту информацию. Очень простой в настройке и удобный в использовании для хранения и анализа логов веб сервера. Я пользуюсь полностью бесплатным тарифом, который не требует никаких подтверждений и персональных данных. Аутентификация через учётку на github. При этом позволяет хранить 500GB логов в месяц. Мне этого за глаза.

Про настройку и использование я уже писал ранее. По настройке с тех пор ничего не поменялось. Для отправки используется Vector (иногда падает, надо мониторить и переподнимать), у него встроенная интеграция с axiom.

Axiom условно можно назвать аналогом ELK, только сильно урезанным в плане функциональности. Из-за этого его особо не надо изучать. Отправляешь туда логи, заходишь и мышкой создаёшь нужные дашборды, запросы, отчёты. С ELK так не получится. В новых версиях даже заходить не хочется в виджеты и дашборды. Каждый раз, как первый раз, приходится вспоминать, как тут что-то сделать и построить нужную визуализацию.

Например, я позавчера включил на сайте протокол HTTPv3. Решил сходить посмотреть, сколько запросов по этому протоколу выполняется. Сбор логов настроен по указанной выше ссылке. В веб интерфейсе axiom иду в раздел Query и мышкой в конструкторе строю запрос: Dataset = serveradmin.ru, Where != http_version, Summarize count(), group by http_version.

['serveradmin.ru']
| where isnotempty(http_version)
| summarize count() by bin_auto(_time), http_version

И получил график растущего использования HTTPv3. Протокол используется.

Или вот ещё пример. Посмотрим, по каким url на запросы выходят 404 коды ответов. Dataset = serveradmin.ru, Where status =~ "404", Summarize count(), group by url.

['serveradmin.ru']
| where status =~ "404"
| summarize count() by bin_auto(_time), url

Думаю, идея понятна. В сервисе ничего такого особенного нет, чего нельзя было бы сделать где-то в другом месте. То же самое можно сделать в ELK, Graylog, Loki, Goaccess. Но тут всё бесплатно, ничего настраивать не надо. Просто оправляем логи и пользуемся. Разумеется, если у вас там ничего секретного нет. А то уже предвижу комментарии на тему того, что я свои секретные логи веб сервера никому показывать не могу. Если не можете, то не используйте облачные сервисы. Тут всё очевидно. Наверняка они эти данные как-то используют, иначе откуда такая щедрость.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#logs #webserver

Основной вопрос, который возникает при включении прокола HTTPv3 для сайта: "А какая разница с прошлым протоколом? Зачем включать?". Я решил провести некоторые тесты на своём реальном сайте, включая и отключая h3. Для тестов взял хорошо известный мне инструмент WebPageTest и запустил у себя.

Как обычно, он не собрался без ошибок, пришлось поковыряться. Если кому-то интересен этот локальный сервис для теста производительности сайтов, дайте знать. Сделаю по нему свежую заметку, как собрать и запустить самую свежую версию сервера и агента. Его удобно использовать, так как можно запускать локально и исключать влияние сторонних факторов, которые обязательно будут в публичных сервисах.

Запустил я локальную версию WebPageTest на своём сервере и прогнал серию тестов с отключенным h3 и включенным. Для каждого прогона делал по 9 тестов с двумя запусками, когда второй использует кэш после первого запуска. И сравнил результаты, как между одинаковыми тестами в рамках h2 и h3, так и между ними. Различия между однотипными тестами были минимальны. И между h2 и h3 разница была стабильная.

Результаты получились неоднозначными. Поленился поднять локальную копию сайта. Тестировал на рабочем, который опубликован в интернет. Интересно увидеть практические результаты, а не лабораторные. В итоге разница получилась незначительная в пользу h2. Можно сказать в пределах погрешности, кроме одного значения - Time To first Byte и как его следствие - время начала отрисовки Time to Start Render. В режиме h3 она неизменно была выше, чем в h2. То есть дольше приходил ответ на первый запрос, и позже начиналась отрисовка. Параметр TTFB важный с точки зрения СЕО, так что даже не знаю, как реагировать на эти измерения. По идее надо отключать h3.

Внимательно смотрел на результаты и сравнивал. H3 даёт по всем параметрам результаты не хуже h2, а где-то даже лучше. DNS Lookup одинаковый, то есть проседания на DNS запросы нет, Total Connection Time у h3 неизменно ниже, загрузка всех элементов чуть быстрее, но Time to First Byte, за который по идее отвечает непосредственно сервер, всегда у h3 выше и из-за этого едут все остальные метрики, так как и отрисовка, и полная загрузка начинают отставать. Такое ощущение, что причина в реализации h3 в самом веб сервере. Надо тестировать с другими, но это довольно хлопотно, если разворачивать реальный сайт, а не синтетические странички.

Внизу показал результат сравнения, где получилась наиболее усреднённая картинка. Думаю, что разверну сайт отдельно локально и потестирую. Надо понять, в каком режиме всё же лучше оставлять сайты. В целом, с обоими версиями HTTP у меня результат получился хорошим, ниже рекомендованного порога, который считается хорошим результатом. Но всё равно, чем меньше, тем лучше. HTTPv3 пока отключил.

Было бы интересно узнать, если кто-то делал подобные тесты или видел где-то результаты. Нет возможности посвятить много времени этому вопросу, чтобы окончательно разобраться. Один сайт и веб сервер - не показатель. Надо массовые тесты делать.

#webserver #webpagetest