ServerAdmin.ru

Небольшой совет из практики настройки мониторинга, а конкретно - графиков. Если используете классический график с осями координат, следите за тем, чтобы отсчёт был от нуля. В подавляющем большинстве случаев вам будет полезен именно такой график, начинающийся от нуля. Это актуально как для Grafana, так и Zabbix.

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

Ниже пример, когда слева - настройки осей по умолчанию в Zabbix, автовычисляемые значения, а справа я выставил вручную ограничения от 0 до 100, что соответствует минимальному и максимальному значению. Визуально по правым графикам проще оценить реальную итоговую загрузку CPU и Memory на узле, которая по факту очень ровная, но по графикам слева так сразу не скажешь.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#мониторинг #совет

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

Я в основном сейчас использую 2 нейросети:

▪️Бесплатный Qwen для быстрых вопросов и поиска в интернете.
▪️Платный z.ai в режиме агента в opencode. Мне очень нравится, как он работает. Делал ещё один заход в openclaw, но опять не пошло. Не нравится он мне. На очереди claude agent, но не хватает времени на него, чтобы плотно заняться.

Всё остальное смотрю эпизодически в рамках исследования и изучения. Никак не подберу какую-то десктопную платформу, чтобы ежедневную мелкую рутину за меня делал. Для всех остальных задач мне очень нравится opencode. Он закрыл почти все мои потребности в автоматизации.

Я не так давно пересобрал один старый системник, который работал как обычный рабочий комп под виндой. Воткнул в него все старые диски, что лежали без дела и стал туда свои бэкапы лить. Кстати, посмотрел стоимость дисков сейчас 😱 Они пипец как подорожали. Всё моё б.у.шное барахло, что я туда воткнул, потянуло на 100 т.р.

Системник был на 100% рабочий, проблем с ним не было. Я его продул, обновил термопасту, воткнул диски, накатил PVE. Какое-то время он поработал и начал аварийно перезагружаться без каких-либо видимых причин. Явных ошибок в логах нет, тем более перед ребутами. Ничего подозрительного не видно.

Решил скормить syslog нейронкам, чтобы они там покопались и вынесли свой вердикт. Заморачиваться не стал, отдал в opencode весь лог на 12 МБ и попросил проверить. Он нашёл там некоторые моменты, типа ошибок в SMART одного из дисков и ошибки сетевой карты Realtek. Это известная тема, они глючат в Linux, и в PVE в частности. Я уже писал об этом не раз (1, 2). Сталкивался много раз с этим, но к аварийным перезагрузкам это никогда не приводило. Вряд ли в этом дело.

Это днём было, а вечером я вайбкодил и решал некоторые задачи. Зашёл в статистику по токенам и заметил, что днём куда-то 1,1 млн. токенов улетели. Это не сказать, что много, но лично у меня незаметно столько не улетает. Задачи относительно простые и короткие. Потом уже сообразил, что это анализ лога столько сожрал.

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

В итоге агенты дали два разных решения. Первый сказал, что виноват диск, надо его отключить. Второй предложил установить другой драйвер на сетевуху, обвинив его в ребутах. Ни то, ни другое не помогло. Причина не в этом. Скорее всего просто железо устало. Материнка старая (14 лет), пора в утиль. Хотя под виндой работала стабильно. Может просто совпадение и время пришло именно сейчас, а может реально с современным линуксом у этого железа какой-то конфликт.

К чему я всё это рассказал. Для успешного решения задач к ИИ полагается приложить опытного специалиста, который умеет и понимает, как с нейронкой работать. Без этого либо результат будет неудовлетворительный, либо по ресурсам будет огромный перерасход. Нельзя просто так взять и отдать все логи на анализ. Надо выстроить рабочий процесс, который позволит эффективно анализировать и не тратить слишком много денег на это.

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

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#ai

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

После той публикации мне из компании Флант написали и предложили всяческую помощь, если я захочу попробовать эту платформу. У неё есть функциональная бесплатная версия, так что мне ещё на конференции захотелось её попробовать. Ничьей помощью я в итоге пользоваться не стал и для чистоты эксперимента всё развернул самостоятельно. Не скажу, что это была простая задача и всё прошло гладко, но лично у меня получилось относительно просто. Расскажу обо всё по порядку.

Сравнение редакций Deckhouse по функциональности и по конкретным модулям. Сходу трудно во всём этом разобраться, поэтому привожу сразу ссылки. Система большая и сложная. В формате заметки не знаю, как всё умещу.

Для установки минимальной конфигурации Deckhouse понадобится управляющий компьютер и хотя бы две ноды - master и worker. Я взял 3 виртуальные машины с Debian 13. Управляющая может быть минимальной конфигурации. У меня заработало с 2CPU, 4GB RAM. А вот рабочие ноды - минимум 4CPU и 8GB RAM. На меньшем установка не пойдёт.

На управляющий компьютер установил Docker и открыл руководство установщика. Достаточно просто запустить контейнер и пройти в браузер:

# docker run --rm --pull always -v $HOME/.d8installer:$HOME/.d8installer -v /var/run/docker.sock:/var/run/docker.sock -p 8080:8080 registry.deckhouse.ru/deckhouse/installer:latest -r $HOME/.d8installer

В руководстве контейнер биндится на 127.0.0.1. Я убрал это, чтобы получить к установщику доступ по сети. Дальше всё сделал по инструкции. Там ничего сложного:

- выбрал редакцию community;
- сгенерировал ssh ключи;
- добавил 2 ноды, указал ip адреса;
- настройки сети и доменного имени не менял, использовал по умолчанию.

Запустил установщик и сразу получил неведомую ошибку ssh - execute on remote: exit status 127. По смыслу понял, что по ssh какая-то команда не запускалась. Так как это было самое начало, то сразу сообразил, что на узлах не хватает sudo. Может это и было где-то указано в руководстве, но я пропустил, сразу не установил. После того, как сделал это, установка пошла.

На master ноду всё установилось без проблем. А вот с worker опять затык. Установка стоит на 50%, в логах ошибок нет. Просто ничего не идёт. Пошёл на ноду разбираться. Установка организована в привычном мне стиле - куча костылей на bash скриптах, залиты по ssh с мастера. Их там около сотни 😁.

Заметил, что висит в вечном цикле скрипт /var/lib/bashible/bashible-new.sh. Посмотрел его содержимое, запустил сам вручную. Увидел, что он ругается на скрипт 000_discover_node_ip.sh. Посмотрел, что он делает - определяет ip ноды и записывает в текстовый файл. Сам не отрабатывает, ругается на несуществующие команды. Не стал разбираться с ним, просто вручную записал ip адрес ноды в текстовый файл, куда он должен записываться.

После этого установка пошла и успешно завершилась. Я получил настроенную работающую платформу. Сразу сходил в раздел Модули и запустил модуль virtualization. Он позволяет управлять виртуальными машинами.

Кластер после запуска минут 10-15 подтупливал и сыпал ошибками. Потом вроде прочихался и неспешно заработал. К сожалению, ничего толком на нём проверить я не смог. Во-первых, там надо разбираться и всё настраивать, что требует какое-то время. А во-вторых, кластеру надо гораздо больше ресурсов. Того, что дал ему я, едва хватает, чтобы самому шевелиться. Он запускает очень много своих сервисов - запущено 95 своих подов.

В целом, у меня всё получилось. Поднял кластер без посторонней помощи, но помогла чуйка. Посоздавал там поды, replicasets. Посмотрел, как всё работает, управляется. На первый взгляд удобно. Установка как-то костыльно сделана с плохой обратной связью и без моих пинков не завелась.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#kuber #devops

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

Встал вопрос, как относительно просто и быстро ускорить процесс снятия дампа. Не буду подробно всё описывать, так это любая ИИ может сделать. Скажу только суть, чтобы вы понимали, что так можно.

Утилита pg_dump может делать дампы в трёх форматах - plain, custom, directory. Plain - обычный текст. Самый медленный формат, но самый удобный в плане дальнейшей работы с ним. Из него можно вытащить отдельную таблицу, проверить какое-то содержимое, обрезать и т.д. По умолчанию он вообще не сжимается. Сжатие можно добавить настройкой pg_dump или через пайп пропустить.

Формат custom - это уже бинарный дамп. Он жмётся по умолчанию. При сопоставимых настройках сжатия по скорости он +- такой же, как palin. Это наиболее популярный формат для дампов, так как из него можно восстанавливаться в несколько потоков, что значительно быстрее формата plain. Тот в восстановлении очень медленный.

Формат directory я вообще никогда не использовал. На первый взгляд он выглядит не очень удобным для обработки и длительного хранения. Но у него есть важное отличие - процесс создания дампа может быть многопоточным. И это серьёзно ускоряет его, если у вас все данные не лежат в одной большой таблице, так как создание параллелится на уровне таблиц. Я у себя потестировал на сервере с 16 ядрами дампить в 10 потоков. Прирост скорости примерно в 2 раза при одинаковых настройках сжатия по сравнению с plain и custom. То есть на ровном месте ускорил снятие дампов в 2 раза.

# sudo -u postgres /opt/pgpro/1c-15/bin/pg_dump -U postgres -Fd -Z6 -j10 -f /tmp/zup-baza01 zup-baza01

Почитал документацию и увидел параметр --compress=method[:detail]. По умолчанию используется сжатие gzip с уровнем компрессии 6, этот параметр его может изменить. Мне не особо критично сильно сжимать. Хотел ещё ускорить процесс и заменить медленный gzip на lz4 или zstd. И так, и сяк указывал параметры - ничего не помогает. Пишет, что неверное значение параметра. Сразу у ИИ спрашивать не стал, думал, уж с такой простой задачей справлюсь сам. Но увы, не справился.

Оказалось, что этот параметр не поддерживается в версии 15, которая используется у меня. А по умолчанию на сайте открывается документация для версии current, которая сейчас 18-я. Я не обратил на это внимание. Переключился на 15-ю версию и действительно увидел, что такого параметра там нет. Так что если у вас версия утилиты поддерживает изменение алгоритмов сжатия, то можно попробовать другие. Они должны быть быстрее gzip. Надо будет обновить этот сервер по возможности.

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

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#postgresql #backup

Существует современная и функциональная замена старичка Fail2Ban - CrowdSec. Я её давно знаю, использовал ещё лет 5-6 назад. Писал статью по ней в своё время. С тех пор много воды утекло. Решил посмотреть, что она из себя представляет сейчас. Дабы не обмануться и не перепроверять информацию, ИИ вообще не использовал. Просто открыл документацию и настроил базовые вещи. Сразу скажу, что система в текущем её бесплатном исполнении мне понравилась своими возможностями. Если уж сейчас и настраивать, то именно её, а не Fail2Ban.

Принцип настройки CrowdSec условно можно назвать похожим на Fail2Ban, но архитектурно она отличается. В CrowdSec тоже есть источники логов, правила обработки, настройки действий. Но всё это очень сильно развито по сравнению с единственным скриптом на python в Fail2Ban. CrowdSec состоит из отдельных компонентов, которые взаимодействуют между собой по API.

Я присмотрел для себя следующую схему работы CrowdSec, которая опирается на общее хранилище логов Loki, которое я недавно разбирал:

◽️Основной движок CrowdSec устанавливается в отдельную VM или контейнер. Он ходит в общее хранилище Loki за логами.
◽️На пограничный шлюз, который занимается фильтрацией трафика, ставится crowdsec-firewall-bouncer-iptables, или другой в зависимости от используемого файрвола.
◽️Для реализации функциональности WAF на веб сервер или прокси в зависимости от его типа устанавливается соответствующий bouncer. Например, crowdsec-nginx-bouncer для Nginx.
◽️Все необходимые логи стекаются в Loki.

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

Сразу скажу, что система непростая. Я некоторое время потратил, чтобы разобраться, вникнуть в суть и развернуть на одиночном сервере, проверить работу. То, что я описал, будет работать в бесплатной версии, никаких подписок не надо. Готовые списки адресов брать не будем, свои тоже никуда не отправляем.

У CrowdSec раньше была бесплатная веб панель для управления и мониторинга, но они её убрали. Предлагают бесплатно зарегистрироваться в облачной панели, использовать её, но за это они будут забирать вашу аналитику для насыщения своих списков, которые она продают по подписке за приличные деньги. В целом, всё честно и прозрачно. Я в веб панели не регистрировался, запустил всё локально. Покажу кратко, что сделал.

1️⃣ Установил CrowdSec и firewall-bouncer для iptables:

# curl -s https://install.crowdsec.net | sudo sh
# apt install crowdsec
# sudo apt install crowdsec-firewall-bouncer-iptables

Первая команда-скрипт подключает репозиторий. Это можно сделать вручную. По умолчанию прилетели настройки для анализа системных syslog файлов и journalctl логов от ssh.service, конфигурация firewall-bouncer для блокировки IP, парсеры ssh логов.

Система полностью автоматически настроена для блокировки как минимум нежелательной активности по SSH. Для системных логов надо отдельно правила с уязвимостями загружать.

2️⃣ Сходил на другой сервер и 5 раз ввёл неверный пароль по SSH. Получил бан. Проверил его так:

# iptables -L -v -n | grep crowdsec

Появилось новое правило для crowdsec, где используется список ipset для всех заблокированных адресов. Посмотрел список алертов:

# cscli alerts list

Увидел там своё событие, посмотрел его подробности:

# cscli alerts inspect -d 2

3️⃣ Проверил список установленных наборов с правилами, по которым делаем проверки:

# cscli collections list

Дополнительные ставим так:

# cscli collections install crowdsecurity/nginx

Смотрю все основные метрики службы:

# cscli metrics

В принципе, этой базы достаточно для того, чтобы начать локально пользоваться системой. Мне она понравилась, буду изучать дальше.

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

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#crowdsec #security #waf

Расскажу про один старый неочевидный трюк в терминале. Он не особо часто нужен, но у меня были ситуации, когда прям очень сильно пригодился бы. Бывает запустишь какой-то процесс в терминале (сборку, перенос кучи мелких файлов, проверка размера огромной директории, дамп большой и медленной базы), не подумав о том, что он может затянуться. И начинаешь переживать за сохранность сессии SSH. Если разорвётся, то процесс остановится. Надо было сразу либо в screen, либо в tmux запускать, но уже поздно. Надо либо ждать и надеяться, либо прерывать и перезапускать.

А на самом деле это вопрос решаемый. Есть небольшая утилита reptyr, которая может без остановки перенести процесс в новую сессию. Причём она в этой сессии продолжит свой вывод в терминал. Утилита живёт в стандартных репах, так что не нужно ничего со стороны скачивать:

# apt install reptyr

Нагляднее и проще всего показать работу reptyr на примере top или htop. Запускаем в обычной консоли top.

# top

Отправляем процесс в фон и там запускаем:

Нажимаем CTRL-Z
# bg

Проверяем, как процесс работает в фоне:

# jobs -l
[1]+ 7972 Stopped (signal)    top

Увидели заодно его pid - 7972. Отвязываем процесс от текущей сессии:

# disown top

Теперь запускаем новую сессию сразу же с tmux. Заходим в неё и там запускаем:

# reptyr 7972

Открыли в новой сессии с tmux всё тот же процесс top.

Вспомнил про эту тему, когда начал работать с opencode. По какой-то причине у меня периодически отлетает сессия с запущенным агентом, работающая в VPS в локалке. Со связью проблем нет. Не знаю, в чём причина. Первое время забывал его запускать в tmux и терял в какой-то момент диалог. Сейчас уже приучил себя запускать длинные сессии в tmux.

К сожалению, reptyr по какой-то причине сессию с opencode не может восстановить. Отправляю в background, отцепляю от сессии, запускаю в новой через reptyr, но всё виснет. Интерфейс opencode не появляется. Там навороченная и активная псевдографика. Наверное в этом дело. Хотя тот же mc без проблем из сессии в сессию переходит.

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

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#bash #terminal

Перебирал старые ролики и нашёл древние видео от провайдера Авантел на тему системного администрирования. Зашёл на их канал в поисках чего-то нового, но, к сожалению, канал пустой. Нет ни одного ролика, а старые доступны только по прямым ссылкам. Провайдер как-будто отходит в мир иной.

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

На Youtube ролики в качестве 4К. Я не смог их скачать в таком качестве, не разобрался. Получилось только 720p. Если кто-то умеет скачивать качество выше, скиньте, пожалуйста, в личку ролики, я перезалью.

▶️ https://www.youtube.com/watch?v=rjqe8T5XBmw
▶️ https://www.youtube.com/watch?v=WNnJ0gjPgEs
▶️ https://www.youtube.com/watch?v=ncXTQ83eW7Q

#юмор

Купил не так давно себе домой ИБП Ippon Kirpich 1050. Хороший аппарат, мне понравился - много розеток, ЖК экран. И самое главное - кнопка управления писком. Я полностью отключил его. У меня есть старый Ippon попроще, где этой кнопки нет. И он постоянно пищит, когда электричества нет, невозможно отключить.

Я решил по сигналу с этого Иппона отключать всё, что подключено к нему, и ко второму, который вообще без управления. Теоретически задача выглядела простой, потому что есть ПО от вендора под нужные системы - Windows и Linux. А практически пришлось повозиться, потому что много нюансов.

Пока была актуальна и развивалась программа Apcupsd, я для этих целей использовал её. Она очень удобная и простая в настройке - одинаковые минималистичные файлы конфигураций под все системы, режим работы клиент-сервер. Специально подбирал ИБП, чтобы поддерживала его. Она была совместима не только с аппаратами APC, но и те же Ippon некоторых моделей поддерживала. Сейчас программа заброшена, не обновляется, даже сайта не осталось. Я посмотрел на неё и понял, что всё, каши с ней больше не сварить 😢.

Ippon предлагает использовать программу PowerMaster, написанную на Java. Она поднимает веб сервер, управление через браузер. На первый взгляд не очень удобное решение, но в духе нашего времени. Я поставил её и на винду, и на линукс. В принципе, работает, хоть и жирновата, функциональность отличная, много чего умеет. Работает тоже в режиме клиент-сервер. Серверную часть ставишь на машину, куда подключен ИБП по USB, на остальные - клиентскую часть, которая подключается к серверу и следит за его состоянием, слушает команды.

У меня ИБП подключен к машине с Windows, а выключать надо сервера с PVE и Xpenology. Ставить на гипервизор тяжёлое Java приложение не хочется, а на Xpenology вообще не понятно, встанет ли. Я даже не пробовал. Решил пойти по другому пути. PowerMaster умеет запускать cmd скрипты на события от ИБП. Я решил отправлять на все зависимые машины по SSH команду на выключение после минуты отсутствия электричества.

Настраивается это в разделе Setting ⇨ Advanced. Событие отключения электричества - Utility power failure. Директория, из которой можно выбрать скрипт для этих событий - C:\Program Files (x86)\PowerMaster Plus\extcmd. Там уже есть шаблон default.cmd, в который можно добавить свою логику. Мне её написал ИИ. Пришлось серьёзно заморочиться, чтобы всё отладить. Отмечу несколько важных моментов:

1️⃣ В начало скрипта надо добавить строку:

chcp 65001 >nul 2>&1

Без неё в логах будут крякозябры вместо текста ошибок, что сильно усложнит отладку, если что-то пойдёт не так.
2️⃣ Скрипт должен быть обязательно в кодировке UTF-8 with BOM (UTF-8 со спецификацией). С любой другой кодировкой скрипт не отрабатывал в программе, хотя нормально работал из консоли напрямую.
3️⃣ PowerMaster - 32-х битное приложение. Оно не видит стандартный системный путь до ssh.exe. Надо использовать специальный псевдоним C:\Windows\Sysnative\OpenSSH\ssh.exe.
4️⃣ PowerMaster работает от пользователя System. Ключ для SSH надо положить в директорию C:\Windows\System32\config\systemprofile\.ssh\, назначить пользователя владельцем и удалить все остальные права.

На управляемых системах нужно создать пользователя, который будет запускать shutdown.

Эта простая задача сожрала у меня кучу времени, потому что просто взять и запустить скрипт у меня не получилось. В Apcupsd всё это решалось за 5 минут настройки даже в первый раз. А тут часа 2 колупался, пока все ошибки отладил, учёл нюансы винды и программы.

В итоге подёргал ИБП из розетки, всё корректно отрабатывает. Он, кстати, спокойно тянет 3 обычных системника с БП на 400-500w, не жалуется на перегрузку. Минут 5 с ними работает. С одним - 15-20. Я как раз на него 3 самосбора повесил под тестовый кластер и бэкапы. Плюс ещё 2 машины гасит на втором ИБП. Тот Иппон у меня лет 10 работает, на третьем аккумуляторе уже.

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

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#железо