⚡️Серверная ОС SelectOS теперь включена в реестр российского ПО Минцифры. Её можно использовать в корпоративной инфраструктуре и при этом получать поддержку от вендора.
Из преимуществ:
🔹поддержка по SLA,
🔹предсказуемая совместимость с 500+ конфигурациями выделенных серверов,
🔹доступ к расширенной документации с помощью ИИ-ассистента в manpages
Скачайте бесплатно и протестируйте у себя: https://slc.tl/5kg3c
Реклама. АО "Селектел". erid:2W5zFJM5KXn
Из преимуществ:
🔹поддержка по SLA,
🔹предсказуемая совместимость с 500+ конфигурациями выделенных серверов,
🔹доступ к расширенной документации с помощью ИИ-ассистента в manpages
Скачайте бесплатно и протестируйте у себя: https://slc.tl/5kg3c
Реклама. АО "Селектел". erid:2W5zFJM5KXn
👎50👍27
Продолжу тему со сбором логов в 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
👍71👎2
config.alloy
1.3 KB
Конфигурация к заметке выше 👆👆👆👆👆👆👆👆
То же самое есть в репозитории: https://gitflic.ru/project/serveradmin/grafana-loki
То же самое есть в репозитории: https://gitflic.ru/project/serveradmin/grafana-loki
👍27👎1
Очередная подборка статей авторов, которые согласились в ней участвовать. Кто не понимает, о чём идёт речь, может прочитать прошлые публикации по этой теме (раз, два).
⇨ Initramfs в Astra Linux на практике. Загрузка по USB ключу.
Хороший пример для практического понимания принципа загрузки ОС на базе Linux. Эти знания пригодятся, когда надо будет разобраться, почему система не грузится, к примеру, после восстановления или переноса на другом гипервизоре. Автор настроил запрет загрузки ОС, если не уставлена определённая флешка. Отдельно отмечу, что очень приятно видеть mcedit на скринах 😁.
⇨ Настройка восстановления пароля в Authentik
⇨ Настройка процессов регистрации и приглашений пользователей в Authentik
⇨ Настройка двухфакторной аутентификации в Authentik
⇨ Настройка Cloudflare Turnstile для защиты формы входа в Authentik без CAPTCHA
Очередные статьи про настройку Authentik. У автора большой цикл статей и видео на эту тему. Тема непростая для самостоятельного изучения, так что материалы вам сильно помогут, если осваиваете этот продукт.
⇨ Сети в Docker
⇨ Docker Compose — установка и базовое использование
Тоже продолжение цикла на заявленную тематику. У автора несколько заметок про основы докера.
⇨ Как установить Passbolt на Ubuntu 24.04
⇨ Passbolt: базовая настройка и начало работы
Установка и настройка бесплатного менеджера паролей Passbolt с открытым исходным кодом. Он позволяет совместно вести базу данных с паролями, управлять учётными записями для доступа к ним.
⇨ Linux. Утилиты. Нестандартные. convert
Пример конвертации изображений из директории в единый pdf файл с помощью консольной утилиты.
⇨ FreeBSD. Установка
⇨ FreeBSD. Первоначальная настройка
Краткие инструкции по установке и настройке FreeBSD. Мне уже очень давно хочется сесть и написать цикл статей по FreeBSD. Нравилась эта система, скучаю по ней. Я её неплохо знал, так как не просто интересовался, а поднимал и администрировал реальные сервисы на ней - почтовый, веб, шлюз, мониторинг и т.д. Делал у заказчиков миграции с FreeBSD, когда они ещё попадались, на Linux.
⇨ SSH Pilot - Современный менеджер SSH сессий для Linux
Linux не балует пользователей удобными менеджерами подключений. Это обзор на один из них.
⇨ PostgreSQL. Troubleshooting. Data corrupted: 7 ERROR: invalid page in block
Решение очень неприятной ошибки, когда в логе ты видишь Data corrupted. Часто это означает, что надо расчехлять бэкапы. В данном случае обошлось без этого. Как я понял, данные не пострадали, просто невозможно было записать новые.
Если кто-то из авторов хочет присоединиться к этой подборке, то пишите мне в личные сообщения.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#статьи
⇨ Initramfs в Astra Linux на практике. Загрузка по USB ключу.
Хороший пример для практического понимания принципа загрузки ОС на базе Linux. Эти знания пригодятся, когда надо будет разобраться, почему система не грузится, к примеру, после восстановления или переноса на другом гипервизоре. Автор настроил запрет загрузки ОС, если не уставлена определённая флешка. Отдельно отмечу, что очень приятно видеть mcedit на скринах 😁.
⇨ Настройка восстановления пароля в Authentik
⇨ Настройка процессов регистрации и приглашений пользователей в Authentik
⇨ Настройка двухфакторной аутентификации в Authentik
⇨ Настройка Cloudflare Turnstile для защиты формы входа в Authentik без CAPTCHA
Очередные статьи про настройку Authentik. У автора большой цикл статей и видео на эту тему. Тема непростая для самостоятельного изучения, так что материалы вам сильно помогут, если осваиваете этот продукт.
⇨ Сети в Docker
⇨ Docker Compose — установка и базовое использование
Тоже продолжение цикла на заявленную тематику. У автора несколько заметок про основы докера.
⇨ Как установить Passbolt на Ubuntu 24.04
⇨ Passbolt: базовая настройка и начало работы
Установка и настройка бесплатного менеджера паролей Passbolt с открытым исходным кодом. Он позволяет совместно вести базу данных с паролями, управлять учётными записями для доступа к ним.
⇨ Linux. Утилиты. Нестандартные. convert
Пример конвертации изображений из директории в единый pdf файл с помощью консольной утилиты.
⇨ FreeBSD. Установка
⇨ FreeBSD. Первоначальная настройка
Краткие инструкции по установке и настройке FreeBSD. Мне уже очень давно хочется сесть и написать цикл статей по FreeBSD. Нравилась эта система, скучаю по ней. Я её неплохо знал, так как не просто интересовался, а поднимал и администрировал реальные сервисы на ней - почтовый, веб, шлюз, мониторинг и т.д. Делал у заказчиков миграции с FreeBSD, когда они ещё попадались, на Linux.
⇨ SSH Pilot - Современный менеджер SSH сессий для Linux
Linux не балует пользователей удобными менеджерами подключений. Это обзор на один из них.
⇨ PostgreSQL. Troubleshooting. Data corrupted: 7 ERROR: invalid page in block
Решение очень неприятной ошибки, когда в логе ты видишь Data corrupted. Часто это означает, что надо расчехлять бэкапы. В данном случае обошлось без этого. Как я понял, данные не пострадали, просто невозможно было записать новые.
Если кто-то из авторов хочет присоединиться к этой подборке, то пишите мне в личные сообщения.
———
ServerAdmin:
#статьи
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
ServerAdmin.ru
Решил провести небольшой эксперимент и поддержать авторов, которые ведут блоги по IT тематике. Думаю, среди читателей моего канала такие найдутся. В конечном счёте цель написания статей в публичном доступе - их прочтение другими людьми. Я хочу попробовать…
1👍55👎2
В своих заметках и статьях про почтовый сервер я ни разу не касался темы резервного сервера, который в рамках возможностей DNS записей вида MX реализуется очень просто. Для каждого домена могут быть указаны несколько почтовых серверов, используя разные приоритеты. Например:
Нашёл случайный пример. Для домена прописаны 2 сервера с разными приоритетами: 20 и 30. У кого приоритет меньше - туда по умолчанию отправляется письмо. Если первый сервер из списка недоступен, письмо отправляется на следующий в списке приоритетов сервер.
На практике я не знаю, насколько активно сейчас это применяется. Я проверил с десяток популярных доменов и только у 1С нашёл 2 сервера. В основном у всех один, либо несколько но с одинаковыми приоритетами для распределения нагрузки. Думаю, я знаю, в чём причина.
Когда я только начинал настраивать почтовые сервера, делал резервные сервера и MX записи к ним. На практике это приводило к серьёзным заботам и хлопотам:
1️⃣ По хорошему, вам нужно синхронизировать информацию о ящиках и пользователям между двумя серверами. Можно этого не делать и собирать всю почту в один ящик-ловушку для всех писем домена, но потом придётся каким-то образом раскладывать её по пользователям.
2️⃣ В случае, если ваш основной сервер по каким-то причинам был недоступен и письма попали на резервный, вам придётся потом каким-то образом вернуть эти письма на основной в ящики пользователей. Решения для этого есть - тот же fetchmail. Он может на основании адреса получателя раскладывать письма по пользователям. Но всё это надо поддерживать в актуальном состоянии, следить, что нормально работает. На практике это не так то просто реализовать, если это не какое-то готовое решение.
3️⃣ На резервный MX сервер спамеры могут слать спам вопреки более высокому приоритету основного сервера. Это отдельные хлопоты по администрированию.
Надо ещё понимать особенность обмена письмами по SMTP. Стандартной настройкой почтовых серверов является многократные попытки доставить почту. Если у вас упал почтовый сервер, то отправитель, не доставив с первого раза письмо, будет пытаться доставить его ещё какое-то время. Причём существенное время, если администратор сервера отправителя для каких-то целей сильно не урезал время нахождения недоставленного письма в очереди. Обычно письма в очереди на отправку с периодическими попытками доставить находятся день-два, могут и больше.
При таких вводных получается, что даже если ваш почтовый сервер недоступен час-два, с большой долей вероятности вы не потеряете переписку. Все письма упадут в почтовые ящики пользователей, когда сервер вернётся в онлайн. И вам не придётся потом разбираться с синхронизацией почтовых ящиков между двумя серверами.
Собственно, я поэтому и перестал держать резервные сервера, когда один раз столкнулся с такой ситуацией. За пару часов на резервный сервер нападало писем, которые потом нужно было возвращать на основной. Вроде бы и хорошо, что ничего не потерял, но на деле я бы скорее всего и так ничего бы не потерял. Тем более если это рядовой сервер с перепиской пользователей. Обычно потеря письма некритична. Бывает, что письма не доходят. Если письмо не дошло до адресата из-за недоступности сервера, отправитель получит об этом уведомление.
Крупные же компании, где к почте предъявляются высокие требования по доступности, насколько я понимаю, предпочитают настраивать отказоустойчивые кластера основного сервера, а не выстраивать инфраструктуру с основным и резервными, так как это приводит к описанным выше хлопотам. Либо же это должно быть готовое программное обеспечение, которое автоматически реализует такую схему работы. Мне таковое неизвестно.
❗️Написанное выше исключительно моё мнение и опыт. Не претендую на правоту и истину. Если кто-то поделится своим опытом настройки основного и резервного MX серверов, с удовольствием прочитаю и приму к сведению.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#mailserver
# dig 1c.ru MX +short20 relay.1c.ru.30 mx1-ksmg.1c.ru.Нашёл случайный пример. Для домена прописаны 2 сервера с разными приоритетами: 20 и 30. У кого приоритет меньше - туда по умолчанию отправляется письмо. Если первый сервер из списка недоступен, письмо отправляется на следующий в списке приоритетов сервер.
На практике я не знаю, насколько активно сейчас это применяется. Я проверил с десяток популярных доменов и только у 1С нашёл 2 сервера. В основном у всех один, либо несколько но с одинаковыми приоритетами для распределения нагрузки. Думаю, я знаю, в чём причина.
Когда я только начинал настраивать почтовые сервера, делал резервные сервера и MX записи к ним. На практике это приводило к серьёзным заботам и хлопотам:
Надо ещё понимать особенность обмена письмами по SMTP. Стандартной настройкой почтовых серверов является многократные попытки доставить почту. Если у вас упал почтовый сервер, то отправитель, не доставив с первого раза письмо, будет пытаться доставить его ещё какое-то время. Причём существенное время, если администратор сервера отправителя для каких-то целей сильно не урезал время нахождения недоставленного письма в очереди. Обычно письма в очереди на отправку с периодическими попытками доставить находятся день-два, могут и больше.
При таких вводных получается, что даже если ваш почтовый сервер недоступен час-два, с большой долей вероятности вы не потеряете переписку. Все письма упадут в почтовые ящики пользователей, когда сервер вернётся в онлайн. И вам не придётся потом разбираться с синхронизацией почтовых ящиков между двумя серверами.
Собственно, я поэтому и перестал держать резервные сервера, когда один раз столкнулся с такой ситуацией. За пару часов на резервный сервер нападало писем, которые потом нужно было возвращать на основной. Вроде бы и хорошо, что ничего не потерял, но на деле я бы скорее всего и так ничего бы не потерял. Тем более если это рядовой сервер с перепиской пользователей. Обычно потеря письма некритична. Бывает, что письма не доходят. Если письмо не дошло до адресата из-за недоступности сервера, отправитель получит об этом уведомление.
Крупные же компании, где к почте предъявляются высокие требования по доступности, насколько я понимаю, предпочитают настраивать отказоустойчивые кластера основного сервера, а не выстраивать инфраструктуру с основным и резервными, так как это приводит к описанным выше хлопотам. Либо же это должно быть готовое программное обеспечение, которое автоматически реализует такую схему работы. Мне таковое неизвестно.
❗️Написанное выше исключительно моё мнение и опыт. Не претендую на правоту и истину. Если кто-то поделится своим опытом настройки основного и резервного MX серверов, с удовольствием прочитаю и приму к сведению.
———
ServerAdmin:
#mailserver
Please open Telegram to view this post
VIEW IN TELEGRAM
👍73👎1
Приключилась со мной на днях неприятная история. Расскажу о ней. Возможно, кому то это позволит сохранить время и нервы в похожей ситуации.
Был вечер, закончил все свои дела, собирался потихоньку спать. Приходит уведомление в Telegram, что недоступен один из сайтов. Потом второй. В Телеграме у меня очень мало уведомлений, только ключевые о конечных точках так сказать. Подобные уведомления должны сопровождаться более многочисленными оповещениями от Zabbix в почту. Захожу туда, там пусто. Проверяю сайты - реально недоступны, соединения сбрасываются.
Пробую зайти в мониторинг по доменному имени, не получается. Поясню, что сайты, мониторинг, некоторая другая инфраструктура располагаются в ЦОД на своих серверах на услуге colocation. Там пачка внешних IP адресов, софтовый шлюз на Linux и для подстраховки ещё один физический в стойке на Mikrotik.
Подключаюсь к шлюзу по VPN (OpenVPN), попадаю во внутреннюю инфраструктуру. Всю её вижу, никаких проблем с доступностью. Открываю Zabbix по локальному IP адресу машины, где он работает, попадаю в веб интерфейс. Там всё красное, куча алертов на разные темы. Невозможно понять, что происходит. Обращаю внимание на растущую очередь сообщений на почтовом сервере, они не уходят. Это в основном уведомления от мониторинга.
Запускаю у себя почтовый клиент, нормально подключаюсь к серверу, вижу новую почту. Посмотрел выборочно некоторые логи сервисов, у кого-то что-то работает, у кого-то нет. Не понимаю, что происходит. Пытаюсь сфокусироваться на какой-то одной проблеме, чтобы её решить. Параллельно замечаю, что по внешнему IP адресу шлюза не могу подключиться к нему по SSH ни из одной локации, добавленной в белый список. То есть по внутреннему адресу через VPN я на него захожу, а по внешнему не получается. Соединение происходит, получаю приветствие от SSH сервера, а дальше сеанс не открывается. То есть с сетевой связностью проблем нет. Телнетом я нормально подключаюсь к SSH порту.
В первую очередь захотел разобраться с сайтами. На шлюзе стоит проброс порта на Nginx Proxy, с него уже на веб сервер. В логах прокси пусто, запросы не приходят. При этом на шлюзе я вижу, что по правилам проброса через NAT летят пакеты, счётчики растут. Ситуация странная.
В первую очередь подумал на шлюз, что с ним какие-то проблемы. Там старая уже неподдерживаемая система CentOS 7. Аптайм ОЧЕНЬ большой. Всю эту структуру когда-то давно настроил я, но последние несколько лет развитием и обновлением не занимался. Задач и финансов под это дело не было. Шлюз полностью скрыт от посторонних глаз и доступ туда сильно ограничен, так что реальных проблем это не доставляло.
Проверил у шлюза логи, таблицу conntrack на переполнение, сетевые соединения, нагрузку, что-то ещё. Уже не помню точно. Ничего подозрительного не заметил. Нигде ничего не переполнено, не нагружено, ошибок нет. Шлюз как-будто бы в порядке. Перезапустил сервис iptables - не помогло. Внешне всё выглядит так, как-будто соединения где-то внутри iptables или сервера застревают.
Решил, что от большого аптайма системе стало плохо и её надо перезагрузить. Так как это шлюз и точка входа в инфраструктуру, сделать это надо аккуратно. Все IPMI тоже скрыты за VPN, прямого доступа нет. Проверил на всякий случай резервный шлюз. Предупредил администратора, который на месте (офис и ЦОД - одно здание) всё это поддерживает, чтобы он был готов если что утром приехать пораньше и начать разбираться с проблемой.
Перезагрузка не помогла, а точнее вообще всё развалила. Не поднялись VPN с филиалами, которые до перезагрузки работали. Мониторинг покраснел ещё сильнее. Всё, что не работало, так и продолжало не работать. При этом я лично нормально подключился по VPN. Плюс, видел по логам VPN сервера, что некоторые клиенты тоже подключились, в том числе из-за границы.
Была ночь за окном, на термометре -35. Всё это меня вообще сбило с толку, и я взял паузу, чтобы обдумать ситуацию. А как я её решил, читайте ниже. Тут лимит на длину публикации исчерпан.
👇👇👇👇👇👇👇👇
#история #цод
Был вечер, закончил все свои дела, собирался потихоньку спать. Приходит уведомление в Telegram, что недоступен один из сайтов. Потом второй. В Телеграме у меня очень мало уведомлений, только ключевые о конечных точках так сказать. Подобные уведомления должны сопровождаться более многочисленными оповещениями от Zabbix в почту. Захожу туда, там пусто. Проверяю сайты - реально недоступны, соединения сбрасываются.
Пробую зайти в мониторинг по доменному имени, не получается. Поясню, что сайты, мониторинг, некоторая другая инфраструктура располагаются в ЦОД на своих серверах на услуге colocation. Там пачка внешних IP адресов, софтовый шлюз на Linux и для подстраховки ещё один физический в стойке на Mikrotik.
Подключаюсь к шлюзу по VPN (OpenVPN), попадаю во внутреннюю инфраструктуру. Всю её вижу, никаких проблем с доступностью. Открываю Zabbix по локальному IP адресу машины, где он работает, попадаю в веб интерфейс. Там всё красное, куча алертов на разные темы. Невозможно понять, что происходит. Обращаю внимание на растущую очередь сообщений на почтовом сервере, они не уходят. Это в основном уведомления от мониторинга.
Запускаю у себя почтовый клиент, нормально подключаюсь к серверу, вижу новую почту. Посмотрел выборочно некоторые логи сервисов, у кого-то что-то работает, у кого-то нет. Не понимаю, что происходит. Пытаюсь сфокусироваться на какой-то одной проблеме, чтобы её решить. Параллельно замечаю, что по внешнему IP адресу шлюза не могу подключиться к нему по SSH ни из одной локации, добавленной в белый список. То есть по внутреннему адресу через VPN я на него захожу, а по внешнему не получается. Соединение происходит, получаю приветствие от SSH сервера, а дальше сеанс не открывается. То есть с сетевой связностью проблем нет. Телнетом я нормально подключаюсь к SSH порту.
В первую очередь захотел разобраться с сайтами. На шлюзе стоит проброс порта на Nginx Proxy, с него уже на веб сервер. В логах прокси пусто, запросы не приходят. При этом на шлюзе я вижу, что по правилам проброса через NAT летят пакеты, счётчики растут. Ситуация странная.
В первую очередь подумал на шлюз, что с ним какие-то проблемы. Там старая уже неподдерживаемая система CentOS 7. Аптайм ОЧЕНЬ большой. Всю эту структуру когда-то давно настроил я, но последние несколько лет развитием и обновлением не занимался. Задач и финансов под это дело не было. Шлюз полностью скрыт от посторонних глаз и доступ туда сильно ограничен, так что реальных проблем это не доставляло.
Проверил у шлюза логи, таблицу conntrack на переполнение, сетевые соединения, нагрузку, что-то ещё. Уже не помню точно. Ничего подозрительного не заметил. Нигде ничего не переполнено, не нагружено, ошибок нет. Шлюз как-будто бы в порядке. Перезапустил сервис iptables - не помогло. Внешне всё выглядит так, как-будто соединения где-то внутри iptables или сервера застревают.
Решил, что от большого аптайма системе стало плохо и её надо перезагрузить. Так как это шлюз и точка входа в инфраструктуру, сделать это надо аккуратно. Все IPMI тоже скрыты за VPN, прямого доступа нет. Проверил на всякий случай резервный шлюз. Предупредил администратора, который на месте (офис и ЦОД - одно здание) всё это поддерживает, чтобы он был готов если что утром приехать пораньше и начать разбираться с проблемой.
Перезагрузка не помогла, а точнее вообще всё развалила. Не поднялись VPN с филиалами, которые до перезагрузки работали. Мониторинг покраснел ещё сильнее. Всё, что не работало, так и продолжало не работать. При этом я лично нормально подключился по VPN. Плюс, видел по логам VPN сервера, что некоторые клиенты тоже подключились, в том числе из-за границы.
Была ночь за окном, на термометре -35. Всё это меня вообще сбило с толку, и я взял паузу, чтобы обдумать ситуацию. А как я её решил, читайте ниже. Тут лимит на длину публикации исчерпан.
👇👇👇👇👇👇👇👇
#история #цод
👍98👎1
Это продолжение. Начало выше 👆👆👆👆👆👆👆👆
Походил по кабинету, посмотрел в окно, прикинул, что теперь делать. Ситуация нестандартная и неприятная. Утром вся работа организации встанет.
Я вроде бы неплохо всё настроенное знаю, но не понимаю, как решить проблему и самое главное, а в чём собственно проблема? Идея была смотреть дампы трафика, но я трезво оценивал свои возможности. Постоянной практики анализа дампов у меня нет. Что я там должен увидеть и понять?
Решил зайти с другой стороны и обратиться к поддержке хостера. Хоть я и не рассчитывал особо на помощь, так как ночью обычно все существенные проблемы откладывают на утро, но решил попытаться. С удивлением обнаружил, что сайт хостера открывается через раз, а личный кабинет вообще не работает.
Нашёл телефон горячей линии. Повезло, что он круглосуточный и там сидит живой человек. Он подтвердил, что вроде как реально наблюдаются какие-то проблемы и дал прямой контакт в ЦОД, куда можно позвонить ответственному человеку. Позвонил туда и он подтвердил, что наблюдаются сетевые проблемы с частью провайдеров. Это и объясняло то, что я сам и некоторые клиенты нормально подключались по VPN, а часть - нет.
Со слов сотрудника ЦОДа, они стали наблюдать проблемы примерно в то же время, что я получил уведомления от мониторинга. Точную причину они пока не знают, но подозревают, что это проблемы с ТСПУ Роскомнадзора. Они оставили им заявку и ждут рассмотрения.
В этот момент я расслабился и понял, что ничего делать больше не надо и можно спать. У меня всё работает нормально, а проблемы на другой стороне. Написал отбой другому администратору и лёг спать.
Утром встал, проверил, всё уже работает. Все VPNы поднялись, почтовая очередь рассосалась, сайты и всё остальное работают. В чём была реальная причина проблем - не знаю. Может ТСПУ, может что-то ещё.
Подобная история - наглядная иллюстрация минусов работы в поддержке инфраструктуры/эксплуатации. Никогда не знаешь, где возникнут проблемы. Постоянно сидишь на пороховой бочке. Даже если ты всё настроишь идеально, зарезервируешь, замониторишь, может возникнуть внешний фактор, а разбираться всё равно придётся тебе.
В общем, если столкнётесь с похожей проблемой, посмотрите в сторону этой истории. Если бы у меня сразу отвалилась VPN, я бы может и подумал в первую очередь на ТСПУ. Но у меня отвалились сайты, не работали подключения по SSH, часть почты не ходила, а VPNы отвалились уже потом после перезагрузки. Судя по всему установленные соединения держались, а новые уже не могли установиться. Хотя не везде и не со всеми.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#история #цод
Походил по кабинету, посмотрел в окно, прикинул, что теперь делать. Ситуация нестандартная и неприятная. Утром вся работа организации встанет.
Я вроде бы неплохо всё настроенное знаю, но не понимаю, как решить проблему и самое главное, а в чём собственно проблема? Идея была смотреть дампы трафика, но я трезво оценивал свои возможности. Постоянной практики анализа дампов у меня нет. Что я там должен увидеть и понять?
Решил зайти с другой стороны и обратиться к поддержке хостера. Хоть я и не рассчитывал особо на помощь, так как ночью обычно все существенные проблемы откладывают на утро, но решил попытаться. С удивлением обнаружил, что сайт хостера открывается через раз, а личный кабинет вообще не работает.
Нашёл телефон горячей линии. Повезло, что он круглосуточный и там сидит живой человек. Он подтвердил, что вроде как реально наблюдаются какие-то проблемы и дал прямой контакт в ЦОД, куда можно позвонить ответственному человеку. Позвонил туда и он подтвердил, что наблюдаются сетевые проблемы с частью провайдеров. Это и объясняло то, что я сам и некоторые клиенты нормально подключались по VPN, а часть - нет.
Со слов сотрудника ЦОДа, они стали наблюдать проблемы примерно в то же время, что я получил уведомления от мониторинга. Точную причину они пока не знают, но подозревают, что это проблемы с ТСПУ Роскомнадзора. Они оставили им заявку и ждут рассмотрения.
В этот момент я расслабился и понял, что ничего делать больше не надо и можно спать. У меня всё работает нормально, а проблемы на другой стороне. Написал отбой другому администратору и лёг спать.
Утром встал, проверил, всё уже работает. Все VPNы поднялись, почтовая очередь рассосалась, сайты и всё остальное работают. В чём была реальная причина проблем - не знаю. Может ТСПУ, может что-то ещё.
Подобная история - наглядная иллюстрация минусов работы в поддержке инфраструктуры/эксплуатации. Никогда не знаешь, где возникнут проблемы. Постоянно сидишь на пороховой бочке. Даже если ты всё настроишь идеально, зарезервируешь, замониторишь, может возникнуть внешний фактор, а разбираться всё равно придётся тебе.
В общем, если столкнётесь с похожей проблемой, посмотрите в сторону этой истории. Если бы у меня сразу отвалилась VPN, я бы может и подумал в первую очередь на ТСПУ. Но у меня отвалились сайты, не работали подключения по SSH, часть почты не ходила, а VPNы отвалились уже потом после перезагрузки. Судя по всему установленные соединения держались, а новые уже не могли установиться. Хотя не везде и не со всеми.
———
ServerAdmin:
#история #цод
Please open Telegram to view this post
VIEW IN TELEGRAM
7👍209👎1
🔝 ТОП постов за прошедший месяц январь. Публикаций было немного, но решил не нарушать порядок, чтобы что-то интересное не затерялось. Я пересмотрел своё отношение к ведению канала и решил снизить активность. Поднадоело за столько лет, переключусь на другие дела.
Несколько лет практически без перерыва публиковал по 1-2 заметки каждый день, причём по нарастающей в плане проработки материала и его объёма. Перечитываю заметки за 20-21-е года. Это небо и земля по сравнению с сегодняшними. Подумать только, я уже 5+ лет пишу сюда каждый будний день 😱.
Все самые популярные публикации по месяцам можно почитать со соответствующему хэштэгу #топ. Отдельно можно посмотреть ТОП за прошлые года: 2023 и 2024 и 2025.
Пользуясь случаем, хочу попросить проголосовать за мой канал, так как это открывает некоторые дополнительные возможности по настройке: https://xn--r1a.website/boost/srv_admin.
📌 Больше всего пересылок:
◽️2FA в виде OTP для RDP соединений в Windows (629)
◽️Как вернуть IE в Windows 11 (530)
◽️Сетевой сканер Scanopy (486)
◽️Игра Tower Networking Inc. - симулятор провайдера (467)
◽️Выпуск сертификатов Let's Encrypt для IP адресов (437)
📌 Больше всего комментариев:
◽️Опрос на тему Desktop Environment в Linux (208)
◽️Выпуск сертификатов Let's Encrypt для IP адресов (134)
◽️Обзор DNS сервера Technitium DNS (63)
📌 Больше всего реакций:
◽️Как вернуть IE в Windows 11 (287)
◽️Выпуск сертификатов Let's Encrypt для IP адресов (213)
◽️2FA в виде OTP для RDP соединений в Windows (211)
📌 Больше всего просмотров:
◽️Как вернуть IE в Windows 11 (11880)
◽️Проблемы с песочницей Windows (9350)
◽️Сертификаты для аутентификации в Angie (9200)
#топ
Несколько лет практически без перерыва публиковал по 1-2 заметки каждый день, причём по нарастающей в плане проработки материала и его объёма. Перечитываю заметки за 20-21-е года. Это небо и земля по сравнению с сегодняшними. Подумать только, я уже 5+ лет пишу сюда каждый будний день 😱.
Все самые популярные публикации по месяцам можно почитать со соответствующему хэштэгу #топ. Отдельно можно посмотреть ТОП за прошлые года: 2023 и 2024 и 2025.
Пользуясь случаем, хочу попросить проголосовать за мой канал, так как это открывает некоторые дополнительные возможности по настройке: https://xn--r1a.website/boost/srv_admin.
📌 Больше всего пересылок:
◽️2FA в виде OTP для RDP соединений в Windows (629)
◽️Как вернуть IE в Windows 11 (530)
◽️Сетевой сканер Scanopy (486)
◽️Игра Tower Networking Inc. - симулятор провайдера (467)
◽️Выпуск сертификатов Let's Encrypt для IP адресов (437)
📌 Больше всего комментариев:
◽️Опрос на тему Desktop Environment в Linux (208)
◽️Выпуск сертификатов Let's Encrypt для IP адресов (134)
◽️Обзор DNS сервера Technitium DNS (63)
📌 Больше всего реакций:
◽️Как вернуть IE в Windows 11 (287)
◽️Выпуск сертификатов Let's Encrypt для IP адресов (213)
◽️2FA в виде OTP для RDP соединений в Windows (211)
📌 Больше всего просмотров:
◽️Как вернуть IE в Windows 11 (11880)
◽️Проблемы с песочницей Windows (9350)
◽️Сертификаты для аутентификации в Angie (9200)
#топ
👍62👎1
⇨ Termix — Возьмите управление сервером в свои руки.
Обзор интересной системы для доступа к серверам через браузер. Это аналог Apache Guacamole. Я писал о нём год назад, когда он только вышел. Сейчас посмотрел, изменений не так много. Продукт выглядит удобным, но местечковым, не для большого прода, скорее для себя или небольшого коллектива.
⇨ ALT Linux 11 сервер видеонаблюдения zoneminder + MySQL + apache
Инструкция по настройке бесплатного софтового видеорегистратора Zoneminder. Я лично себе настроил Frigate и очень доволен. Разобрался в нюансах, постоянно пользуюсь. Думаю, сделаю ещё одну заметку по нему.
⇨ Восстановление GRUB и MBR в Linux
Автор ломает таблицу разделов, соответственно, загрузку, а потом всё восстанавливает с помощью загрузочного ISO и утилиты testdisk. Я когда-то давно писал статью на эту тему.
⇨ Восстановление GPT, GRUB, NVRAM в режиме UEFI (без Secure Boot) в Linux
Продолжение и усложнение предыдущей темы.
⇨ Установка ALT Linux 11 на Repka Pi4
Установка ОС на известный в нашей стране одноплатник Repka Pi4. Всё руки не доходят написать производителям. Может подарят мне тоже на обзор. Покупать смысла нет, а так, поиграться и заметку сделать можно было бы. У Альта сборка есть под этот одноплатник.
⇨ ALT Linux 11 обновление PVE с 8 на 9
Наглядная процедура обновления PVE на Альте. Если я правильно понял, это платная редакция виртуализации от Альта, потому что все используемые репозитории в видео его же.
⇨ Настройка Eltex ESR-15VF для двух провайдеров в режиме балансировки
Ни разу в руках не держал и не работал с устройствами этой фирмы. Было любопытно посмотреть, что они из себя представляют. Автор в режиме реального времени всё настроил. Настройка выглядит простой. На рабочем столе тестового компа ярлык на игру Мир Танки 😁.
⇨ Разбор инфраструктуры реального проекта. Стоит ли внедрять Kubernetes?
Интересное видео. Заголовок привлёк, а на деле там переводят в режим HA магазин на Wordpress, который сейчас работает на одиночном сервере. Мне эта тема хорошо знакома, новое для себя не вынес, но было интересно послушать автора. Забавно увидеть, как заказчика с инфры за 15к рублей в месяц хотели пересадить в кубер за 195к + оплата работы и поддержки.
⇨ Dockhand. Лучший докер менеджер!?
Я уже упоминал ранее про этот менеджер. Внешне и функционально он выглядит интереснее Portainer.
⇨ ASUS GX10 (NVIDIA DGX Spark): честный тест для инференса нейросетей
Обзор NVIDIA DGX Spark (ASUS GX10), компактного компьютера для нейросетей с 128 ГБ памяти и его тесты на реальных задачах. Цена в России сейчас ~ 350 000₽.
⇨ Всё закончилось, работ нет. Ухожу из АйТи после 20 лет. Серия первая
⇨ Конец АйТи в Америке. Работы кончились. Вторая серия
⇨ Из программиста в короля мусора в Америке! Третья серия
⇨ Из программиста в грузчика на пикап траке, 4 серия
Сериал от русского программиста Романа Пушкина из Сан-Франциско. Я уже как-то упоминал его у себя на канале. Он уже давно не может найти нормальную работу по специальности, поэтому купил пикап и начинает подрабатывать переездами и вывозом мусора. Не знаю, насколько соответствует действительности всё то, что он рассказывает, но как минимум мне смотреть интересно. А как максимум заставляет задуматься, что кризис в ИТ нас настигнет в ближайшем будущем. И его признаки видны уже сейчас. Работы всё меньше - резюме всё больше. 10 раз подумайте, прежде чем увольняться сейчас и искать что-то другое. Можно и не найти. Тенденция общемировая, не только наша. У нас наоборот всё это с запозданием идёт из-за региональной специфики и отсутствия мигрантов-айтишников со знанием русского языка.
———
ServerAdmin:
#видео
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Termix - Take back your server management.
=== Links ===
Show Notes
https://wiki.opensourceisawesome.com/books/local-and-remote-server-management/page/install-termix
Termix Project
https://github.com/Termix-SSH/Termix
Get the AwesomeOpenSource Merchandise
https://osia.printify.me
Support my Channel…
Show Notes
https://wiki.opensourceisawesome.com/books/local-and-remote-server-management/page/install-termix
Termix Project
https://github.com/Termix-SSH/Termix
Get the AwesomeOpenSource Merchandise
https://osia.printify.me
Support my Channel…
1👍50👎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👍51👎1
grafana-loki-postfix.zip
3 KB
Файлы к предыдущей заметке по настройке сбора логов Postfix в Loki с помощью Alloy. Здесь представлен дашборд для Grafana и настройки Alloy в качестве сборщика текстового лога на почтовом сервере.
👍33👎1
Это ваше приглашение на Deckhouse User Community meetup #4
Кому: инженерам, которые работают с Kubernetes
Когда: 26 февраля
Где: Москва, офлайн
На митапе узнаете о запуске Kubernetes поверх любых операционных систем, о реальном опыте эксплуатации платформы в одиночку, о домашней виртуализации на бюджетном железе и о практичном подходе к безопасности.
Киллер-фича события — интерактивная зона «Попробуй сам» с развёрнутым кластером Deckhouse Kubernetes Platform Community Edition. Протестируйте платформу своими руками, а инженеры Deckhouse помогут разобраться.
Регистрация
Кому: инженерам, которые работают с Kubernetes
Когда: 26 февраля
Где: Москва, офлайн
На митапе узнаете о запуске Kubernetes поверх любых операционных систем, о реальном опыте эксплуатации платформы в одиночку, о домашней виртуализации на бюджетном железе и о практичном подходе к безопасности.
Киллер-фича события — интерактивная зона «Попробуй сам» с развёрнутым кластером Deckhouse Kubernetes Platform Community Edition. Протестируйте платформу своими руками, а инженеры Deckhouse помогут разобраться.
Регистрация
👍12👎2
Сколько лет использую Proxmox VE и только недавно столкнулся с тем, что у него виртуалку может прибить OOM Killer, если на хосте мало памяти. При этом в момент запуска очередной виртуалки, для которой не хватает памяти, не будет никаких предупреждений на этот счёт. Она молча запустится, а через несколько секунд будет случайным образом прибита одна из запущенных ранее.
Я уже подзабыл, как в других гипервизорах обрабатывается подобная ситуация. Hyper-V вроде бы не даёт запустить виртуальную машину, если для её работы нет свободной памяти. Я всегда всё везде с запасом распределяю, поэтому практически не сталкиваюсь с такими ситуациями.
А тут прошляпил. Добавил виртуалку, запустил, настраиваю. Через некоторое время вижу от мониторинга сообщение, что один сервис лёг, его виртуалка недоступна. Вначале даже не понял, в чём дело. Запустил её снова, зашёл, всё проверил. В логах чисто, как-будто её аварийно вырубили, что на самом деле и произошло.
Пошёл проверять гипервизор и там в логах увидел, что виртуалку аварийно прибил OOM Killer почти сразу после запуска новой, для которой не было свободной памяти.
Странно, что в самой платформе управления виртуальными машинами нет никаких проверок на этот счёт. Можно было бы предупредить либо во время создания, либо при запуске, что на гипервизоре не хватает памяти для нормальной работы всех запущенных виртуальных машин. Для общего хранилища такое предупреждение выводится, когда суммарно забронированное место для всех дисков превышает реальный объём хранилища. А для оперативной памяти предупреждений нет.
Будьте аккуратны при распределении памяти между виртуальными машинами в PVE. Я теперь внимательнее буду это делать и проверять всё вручную. Аварийно прибить виртуальную машину - сильный ход. Понятно, что это встроенный механизм в Linux, но я думал под систему виртуализации его как-то изменили и доработали, чтобы такого не было. Как оказалось - нет. Ни предупреждения, ни завершения работы, ни заморозки. Просто сразу kill.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#proxmox
Я уже подзабыл, как в других гипервизорах обрабатывается подобная ситуация. Hyper-V вроде бы не даёт запустить виртуальную машину, если для её работы нет свободной памяти. Я всегда всё везде с запасом распределяю, поэтому практически не сталкиваюсь с такими ситуациями.
А тут прошляпил. Добавил виртуалку, запустил, настраиваю. Через некоторое время вижу от мониторинга сообщение, что один сервис лёг, его виртуалка недоступна. Вначале даже не понял, в чём дело. Запустил её снова, зашёл, всё проверил. В логах чисто, как-будто её аварийно вырубили, что на самом деле и произошло.
Пошёл проверять гипервизор и там в логах увидел, что виртуалку аварийно прибил OOM Killer почти сразу после запуска новой, для которой не было свободной памяти.
Странно, что в самой платформе управления виртуальными машинами нет никаких проверок на этот счёт. Можно было бы предупредить либо во время создания, либо при запуске, что на гипервизоре не хватает памяти для нормальной работы всех запущенных виртуальных машин. Для общего хранилища такое предупреждение выводится, когда суммарно забронированное место для всех дисков превышает реальный объём хранилища. А для оперативной памяти предупреждений нет.
Будьте аккуратны при распределении памяти между виртуальными машинами в PVE. Я теперь внимательнее буду это делать и проверять всё вручную. Аварийно прибить виртуальную машину - сильный ход. Понятно, что это встроенный механизм в Linux, но я думал под систему виртуализации его как-то изменили и доработали, чтобы такого не было. Как оказалось - нет. Ни предупреждения, ни завершения работы, ни заморозки. Просто сразу kill.
———
ServerAdmin:
#proxmox
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍124👎2
Пришло время обновить подборку хостингов, которые использую сам. То есть это не рекламная публикация, которую у меня кто-то заказал. Это моя инициатива и тут представлены хостеры, у которых в настоящее время у меня есть какие-то сервисы. Все ссылки реферальные.
📌 Selectel – много и давно взаимодействую с этим хостером. Использовал у него разные услуги, но основное – аренда дедиков и S3 хранилище, плюс бесплатная – DNS хостинг. Сейчас ещё и домены сюда переношу по мере окончания делегирования у других регистраторов.
Недавно у хостера появилась пока ещё уникальная (не видел у других) возможность использовать Terraform для настройки дедиков. Я писал об этом статью с примерами. Для серверов есть аукцион, где можно взять сервер дешевле основного ценника на 10-20%.
По надёжности и поддержке особых претензий нет. Обычно всё чётко, поддержка адекватно воспринимает текст, отвечает нешаблонно. Можно о чём-то договориться, попросить скидки, помочь в каком-то вопросе. Были всякие нюансы и косяки. Писал об этом в том числе и тут. Например, не так давно моему клиенту по ошибке удалили учётную запись, потом восстановили. Перед новым годом я не смог себе дедик на год оплатить, ушёл с нерешённой проблемой в праздники. Но после них всё нормально разрулили в мою пользую.
У Selectel есть акция. Через меня для новых клиентов можно получить 4000 бонусов. Для этого нужно зарегистрироваться по моей ссылке, прислать мне свой ID из личного кабинета и я смогу заказать для него промокод. На момент написания заметки я ни разу такие промокоды не получал, поэтому не знаю, как на практике это работает. Надеюсь, что нормально. Кто хочет, может попробовать.
📌 IHC – на VPS этого хостера уже давно живёт мой сайт. Не могу сказать чего-то особенного про него, кроме того, что они давно на рынке и в каких-то серьёзных инцидентах замечены не были. Проблем у меня с ними не возникало. Переехал, с тех пор просто всё работает. Даже в техподдержку ни разу не писал. Набор услуг типовой, как и цены. Есть VPS в Нидерландах и Гонконге. Так что если вам просто нужна VPS или виртуальный хостинг под типовые задачи, пользуйтесь.
📌 Serverspace – использовал раньше под VPS в США. Сейчас необходимости в них нет, осталась ровно одна под заблокированные для нас ресурсы. Хостер интересный со своими разработками (vStack). Когда кому-то советую, часто слышу отзывы, что дорого и скорость 50 мегабит по умолчанию. Поясняю. Это не low coster. Там мощное серверное железо (например, Xeon Gold, серверные диски и т.д.), гарантированный канал, API, свой CLI, Terraform-провайдер, виртуальные сети для VPS и т.д.
📌 RUVDS – обычный хостер. Они одно время активно развивались и пиарились. Последнее время особо не вижу новостей и нововведений. У меня уже много лет работает виртуалка за 40 р., полученная по одной из акций. Из услуг использую только VDS с большим диском. Удобно для бэкапов и мониторинга. Арендуется обычная виртуалка, например 2 CPU, 4 RAM, 20 Гб системный диск и 1 TB дополнительный диск. На неё ставится внешний мониторинг и копируются бэкапы. Когда такую услугу добавили, у других не видел. Сейчас такие виртуалки много где можно заказать. Из плюсов – много разных локаций внутри страны и за рубежом.
📌 Simplecloud – здесь арендую виртуалки с почасовой оплатой для тестов. Можно взять сразу что-то мощное (создаётся виртуалка за 2-3 минуты), сделать всё, что нужно, а потом удалить. Виртуалка поднимается сразу на рабочем поддомене и можно тут же сертификат Let's Encrypt заказать, что очень удобно.
📌 Ihor – в прошлом он был популярен за счёт низких цен и активного маркетинга, но всё растерял после борьбы за него между собственниками. ЦОД был в дауне около недели и все разбежались, в том числе и я. У меня там были и виртуалки, и дедики. Осталась парочка VPS. С тех пор, как всё утряслось, не было вообще никаких проблем. Работает стабильно, цены по прежнему очень низкие. У этого хостера интересно трафик зарубеж ходит 😉, что в настоящее время полезно.
#хостинг #подборка
📌 Selectel – много и давно взаимодействую с этим хостером. Использовал у него разные услуги, но основное – аренда дедиков и S3 хранилище, плюс бесплатная – DNS хостинг. Сейчас ещё и домены сюда переношу по мере окончания делегирования у других регистраторов.
Недавно у хостера появилась пока ещё уникальная (не видел у других) возможность использовать Terraform для настройки дедиков. Я писал об этом статью с примерами. Для серверов есть аукцион, где можно взять сервер дешевле основного ценника на 10-20%.
По надёжности и поддержке особых претензий нет. Обычно всё чётко, поддержка адекватно воспринимает текст, отвечает нешаблонно. Можно о чём-то договориться, попросить скидки, помочь в каком-то вопросе. Были всякие нюансы и косяки. Писал об этом в том числе и тут. Например, не так давно моему клиенту по ошибке удалили учётную запись, потом восстановили. Перед новым годом я не смог себе дедик на год оплатить, ушёл с нерешённой проблемой в праздники. Но после них всё нормально разрулили в мою пользую.
У Selectel есть акция. Через меня для новых клиентов можно получить 4000 бонусов. Для этого нужно зарегистрироваться по моей ссылке, прислать мне свой ID из личного кабинета и я смогу заказать для него промокод. На момент написания заметки я ни разу такие промокоды не получал, поэтому не знаю, как на практике это работает. Надеюсь, что нормально. Кто хочет, может попробовать.
📌 IHC – на VPS этого хостера уже давно живёт мой сайт. Не могу сказать чего-то особенного про него, кроме того, что они давно на рынке и в каких-то серьёзных инцидентах замечены не были. Проблем у меня с ними не возникало. Переехал, с тех пор просто всё работает. Даже в техподдержку ни разу не писал. Набор услуг типовой, как и цены. Есть VPS в Нидерландах и Гонконге. Так что если вам просто нужна VPS или виртуальный хостинг под типовые задачи, пользуйтесь.
📌 Serverspace – использовал раньше под VPS в США. Сейчас необходимости в них нет, осталась ровно одна под заблокированные для нас ресурсы. Хостер интересный со своими разработками (vStack). Когда кому-то советую, часто слышу отзывы, что дорого и скорость 50 мегабит по умолчанию. Поясняю. Это не low coster. Там мощное серверное железо (например, Xeon Gold, серверные диски и т.д.), гарантированный канал, API, свой CLI, Terraform-провайдер, виртуальные сети для VPS и т.д.
📌 RUVDS – обычный хостер. Они одно время активно развивались и пиарились. Последнее время особо не вижу новостей и нововведений. У меня уже много лет работает виртуалка за 40 р., полученная по одной из акций. Из услуг использую только VDS с большим диском. Удобно для бэкапов и мониторинга. Арендуется обычная виртуалка, например 2 CPU, 4 RAM, 20 Гб системный диск и 1 TB дополнительный диск. На неё ставится внешний мониторинг и копируются бэкапы. Когда такую услугу добавили, у других не видел. Сейчас такие виртуалки много где можно заказать. Из плюсов – много разных локаций внутри страны и за рубежом.
📌 Simplecloud – здесь арендую виртуалки с почасовой оплатой для тестов. Можно взять сразу что-то мощное (создаётся виртуалка за 2-3 минуты), сделать всё, что нужно, а потом удалить. Виртуалка поднимается сразу на рабочем поддомене и можно тут же сертификат Let's Encrypt заказать, что очень удобно.
📌 Ihor – в прошлом он был популярен за счёт низких цен и активного маркетинга, но всё растерял после борьбы за него между собственниками. ЦОД был в дауне около недели и все разбежались, в том числе и я. У меня там были и виртуалки, и дедики. Осталась парочка VPS. С тех пор, как всё утряслось, не было вообще никаких проблем. Работает стабильно, цены по прежнему очень низкие. У этого хостера интересно трафик зарубеж ходит 😉, что в настоящее время полезно.
#хостинг #подборка
1👍55👎8
У меня было очень много заметок про менеджеры подключений. В первую очередь потому, что эта тема актуальна для меня. Я постоянно ищу что-то более удобное и подходящее. И эта публикация не исключение. Я недавно сделал масштабный переезд всех своих настроек в Remote Desktop Manager.
Я ранее не раз упоминал про него. Это такой тяжеловесный комбайн всё в одном. Мне он изначально не очень понравился, потому что там слишком много всего, что мне не нужно, плюс, он очень тормозной. Но, пройдя по кругу по всем подобным программам, не нашёл ничего лучше.
В последний год я больше всего пользовался Xshell и MobaXterm. Я не буду подробно про них рассказывать, можно почитать прошлые заметки. Скажу, чем они мне не подошли.
Вообще говоря, Xshell меня по функциональность полностью устраивает. Я очень долго её использую, начиная с 5-й версии. Но в последнем релизе в неё поселили мерзопакостную вещь. В какой-то момент она перестаёт запускаться и требует обновиться. Пока не обновишь, работать не будет. По мне так это бомба замедленного действия. Рано или поздно что-то случится, например, её опять решат сделать платной, и на этом всё закончится.
MobaXterm на первый взгляд тоже всем хороша. Я стал на неё переползать, когда понял, что с Xshell каши больше не сварить, надо искать замену. Но в ней меня донимает один баг с RDP. Иногда после сворачивания и разворачивания программы с открытыми RDP соединениями, в них меняется на мгновение размер экрана, а потом возвращается к первоначальному размеру. Но за это время на удалённом столе успевают разъехаться ярлыки и уменьшиться в размере все открытые окна. Потом их надо опять разворачивать. Вроде мелочь, но раздражает, когда ни с того ни с сего опять это произойдёт. Ну и по мелочи есть некоторые замечания.
В итоге я уже пару недель постоянно использую Remote Desktop Manager. Перенёс туда большую часть соединений. Из MobaXterm и mRemoteNG есть автоматический импорт. Он нормально отработал, почти без ручных правок всё перенёс. Для Xshell, к сожалению, импорта нет, приходится всё руками оттуда переносить.
➖ Основной минус RDM я назвал - сама программа тормозная и не очень отзывчивый интерфейс. Но в целом привыкаешь. И если никаких других проблем не будет, то можно смириться.
Перечислю теперь плюсы:
🟢 В RDM можно перенести вообще все соединения - RDP, SSH, VNC и прочие стандартные вещи. Помимо этого туда можно добавить подключения к Mikrotik через Winbox, веб интерфейс Proxmox. Причём RDM умеет сам находить формы для ввода логина с паролем, плюс, игнорировать предупреждение о сертификатах. Получаем полностью автоматический вход в веб интерфейс Proxmox. Это очень удобно. У меня для Прокмоксов отдельный браузер есть, куда я импортирую все сертификаты и сохраняю учётные данные, чтобы не вводить их каждый раз. Чисто технический браузер, форк Firefox (WaterFox). Теперь он больше не нужен.
🟢 Есть портированная версия, базу с подключениями можно разместить на облачном диске.
🟢 Есть шифрование подключений с помощью мастер пароля, который нужно вводить при запуске.
🟢 Гибкие настройки структуры и самих соединений. Такое ощущение, что в программе есть всё, что только можно придумать по этой теме. Я настроил всё, что мне нужно было.
Так что теперь я в основном использую Remote Desktop Manager. Настроил там все шрифты, цвета и т.д. как обычно делаю. Выглядит симпатично и удобно. Попробуйте, если выбираете себе менеджер соединений. Не факт, что тут тоже не всплывут какие-то баги. Но пока не сталкивался.
Лучшие на мой взгляд аналоги я уже перечислил:
🔹Xshell
🔹MobaXterm
🔹mRemoteNG
Всё остальное понравилось меньше:
▪️Remmina (Linux)
▪️Ásbrú Connection Manager (Linux)
▪️Royal TS/X
▪️WindTerm
▪️Tabby
▪️XPipe
▪️Snowflake
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#менеджеры_подключений
Я ранее не раз упоминал про него. Это такой тяжеловесный комбайн всё в одном. Мне он изначально не очень понравился, потому что там слишком много всего, что мне не нужно, плюс, он очень тормозной. Но, пройдя по кругу по всем подобным программам, не нашёл ничего лучше.
В последний год я больше всего пользовался Xshell и MobaXterm. Я не буду подробно про них рассказывать, можно почитать прошлые заметки. Скажу, чем они мне не подошли.
Вообще говоря, Xshell меня по функциональность полностью устраивает. Я очень долго её использую, начиная с 5-й версии. Но в последнем релизе в неё поселили мерзопакостную вещь. В какой-то момент она перестаёт запускаться и требует обновиться. Пока не обновишь, работать не будет. По мне так это бомба замедленного действия. Рано или поздно что-то случится, например, её опять решат сделать платной, и на этом всё закончится.
MobaXterm на первый взгляд тоже всем хороша. Я стал на неё переползать, когда понял, что с Xshell каши больше не сварить, надо искать замену. Но в ней меня донимает один баг с RDP. Иногда после сворачивания и разворачивания программы с открытыми RDP соединениями, в них меняется на мгновение размер экрана, а потом возвращается к первоначальному размеру. Но за это время на удалённом столе успевают разъехаться ярлыки и уменьшиться в размере все открытые окна. Потом их надо опять разворачивать. Вроде мелочь, но раздражает, когда ни с того ни с сего опять это произойдёт. Ну и по мелочи есть некоторые замечания.
В итоге я уже пару недель постоянно использую Remote Desktop Manager. Перенёс туда большую часть соединений. Из MobaXterm и mRemoteNG есть автоматический импорт. Он нормально отработал, почти без ручных правок всё перенёс. Для Xshell, к сожалению, импорта нет, приходится всё руками оттуда переносить.
Перечислю теперь плюсы:
🟢 В RDM можно перенести вообще все соединения - RDP, SSH, VNC и прочие стандартные вещи. Помимо этого туда можно добавить подключения к Mikrotik через Winbox, веб интерфейс Proxmox. Причём RDM умеет сам находить формы для ввода логина с паролем, плюс, игнорировать предупреждение о сертификатах. Получаем полностью автоматический вход в веб интерфейс Proxmox. Это очень удобно. У меня для Прокмоксов отдельный браузер есть, куда я импортирую все сертификаты и сохраняю учётные данные, чтобы не вводить их каждый раз. Чисто технический браузер, форк Firefox (WaterFox). Теперь он больше не нужен.
🟢 Есть портированная версия, базу с подключениями можно разместить на облачном диске.
🟢 Есть шифрование подключений с помощью мастер пароля, который нужно вводить при запуске.
🟢 Гибкие настройки структуры и самих соединений. Такое ощущение, что в программе есть всё, что только можно придумать по этой теме. Я настроил всё, что мне нужно было.
Так что теперь я в основном использую Remote Desktop Manager. Настроил там все шрифты, цвета и т.д. как обычно делаю. Выглядит симпатично и удобно. Попробуйте, если выбираете себе менеджер соединений. Не факт, что тут тоже не всплывут какие-то баги. Но пока не сталкивался.
Лучшие на мой взгляд аналоги я уже перечислил:
🔹Xshell
🔹MobaXterm
🔹mRemoteNG
Всё остальное понравилось меньше:
▪️Remmina (Linux)
▪️Ásbrú Connection Manager (Linux)
▪️Royal TS/X
▪️WindTerm
▪️Tabby
▪️XPipe
▪️Snowflake
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#менеджеры_подключений
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
2👍97👎1