Интересно как-то у меня выходит - мои пет проекты получаются случайно. Нет финальной цели, есть только импульс: "О! А это звучит интересно, как же это можно сделать?". И все: "сон для слабаков", "пиво в пятницу? конечно не буду!" и все в таком духе. Как говорится - есть только путь. И это история началась примерно так же... Вечерело На работе мне было нечем заняться, нужно было поставить некоторое количество сервером и сервисов на мониторинг, но из-за большой бюрократии в компании сделать это было не просто, да и сама мониторинговая система работала на базе SNMP, вот только где взять SNMP у самописного сервиса? И тут в голову пришла гениальная идея попробовать самому. К тому же сложным это не выглядело: мониторинг портов, http и куда-нибудь отправить алерт. "Почему бы и не да" - подумал я, к тому же больше познаю Python. И так появился он...

Простенький мониторинг, который как-то, что-то делает, что-то показывает и даже консольная тулза есть:

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

Установить один сервер раз в месяц — не особенная проблема. Но что делать, если приходится добавлять по 100 серверов в месяц в разные локации? Мы в EdgeCloud для себя ответили на этот вопрос созданием пайплайнов для деплоя серверов. Благодаря этому гениальному решению, как правило, нам даже не приходится заходить на серверы — всё сделает автоматизация.

Всем привет! Я Павел Логинов, руководитель группы облачный решений EdgeЦентр. Сегодня расскажу вам о нашем кастомном мониторинге гипервизоров: как мы его сделали, как он работает и какую пользу приносит нам и нашим клиентам.

У каждого из нас рано или поздно появляется задача о мониторинге гипервизоров на предмет их работы «изнутри». Нет? Странные вы какие-то.

А вот у нас в компании иногда возникали такие ситуации: на улице +20 градусов, но ощущается как +10. По нашим приборам всё хорошо. Но клиент нашего облака, который арендует у нас виртуальную машину, жалуется: сеть медленно работает, или диск, или процессор. Приходилось идти и разбираться, в чём дело. Это отнимало время. И клиенты были недовольны. К тому же объемы росли. На данный момент у нас 5 регионов с Openstack и больше 250 гипервизоров.

В какой-то момент мы решили, что дальше так жить нельзя. И сделали собственный мониторинг гипервизоров — систему, с помощью которой мы теперь узнаём о проблемах не от клиентов или L1, а (вот это достижение!) из алертов.

Я достаточно давно, уже больше 18 лет (капец я уже старый :`( ), использую консоль. Пробовал разные оболочки: bash, sh, zsh, ksh, но остановился на тех, что стоят по умолчанию на системах. Пожалуй, это моя лень, перенастраивать оболочки и терминалы под себя - никогда не было моим любимым занятием. А ещё меня всегда бесило редактирование конфигов: ок, если открыл, нашел нужный кусок, поправил, закрыл, перезагрузил сервис, а вот если: открыл, нашел нужный кусок, поправил, закрыл, перезагрузил сервис, а оно не работает... и опять: открыл, нашел нужный кусок, поправил, закрыл, перезагрузил сервис и так пока не заработает, N-ое количество раз.

Да, для этого можно открыть несколько терминалов: редактировать в одном, перезапускать в другом. Но тут тоже есть свои минусы, один из них - захламляется терминал вкладками.

Как вы наверное уже поняли - я ленивый админ, который любит красивенькие (и не очень) GUI. Поэтому, начав плотно работать с HAProxy, мне быстро надоело постоянно править конфиг на нескольких серверах. И, не обнаружив на просторах интернета ничего подходящего, я решил написать свой (ага, очень ленивый - 5 лет уже закончить не могу).

Общаясь с одним из пользователей Roxy-WI, я спросил: “А зачем тебе оно вообще?”, в ответ получил хорошую фразу: “Чтобы в консоль не лазить”. И я задумался. Действительно, после создания пользователя для подключения сервера к Roxy-WI (или можно без этого шага, если root нам не страшен) больше нет необходимости заходить на сервер. 

Смотрите сами.

Допустим, мы захотели развернуть новый HA кластер с HAProxy/Nginx/Apache на новых серверах, и нам для этого надо всего-лишь заполнить пару полей и выбрать пару галочек:

С самого начал работы над Roxy-WI мы думали о максимальном упрощении жизни пользователя с помощью веб-интерфейса. Поэтому мы решили добавить в продукт возможность работы с  WAF (Web Application Firewall), чтобы обеспечить защиту веб-сервисов от разного рода вредоносной активности. Естественно, всё то мы старались сделать максимально просто, чтобы даже начинающий пользователь смог без проблем всё настроить.

Продолжаем цикл статей о возможностях Roxy-WI. Сегодня мы поговорим ещё об одном важном наборе функций, связанных с управлением сервисами (а именно ― HAproxy и Nginx) в docker-контейнерах. Мы старались сделать эту функцию максимально простой и удобной в использовании. О том, что у нас получилось, и пойдёт речь ниже.

Продолжаем серию публикаций о нашем веб-интерфейс для HAProxy. Сегодня мы поговорим о специализированном сервис под названием Checker,

предназначенном для мониторинга сервисов HAProxy и Nginx, а также бэкендов HAProxy. Если один из сервисов падает, то Checker рассылает уведомления через Telegram или Slack.

Это очень удобно: не нужно "прикручивать" сторонний инструмент мониторинга, да и умеет Checker (причём из коробки) гораздо больше. Впрочем, обо всём по порядку.

О том, как написать Web GUI для HAProxy, мы уже говорили в двух статьях (1 и 2). С момента публикации последней статьи прошёл год; сейчас, по прошествии времени, очевидно, что о многих вещах (важных и полезных) мы так и не рассказали подробно.  Сегодня мы возвращаемся на Хабр - и постараемся публиковать статьи на более или менее регулярной основе. В этих статьях мы подробно расскажем о специфике работы c Roxy-WI, о возможностях и преимуществах нашего решения. Начнём с набора функций, о котором мы в предыдущих статьях упоминали, но мало. Речь идёт о работе с конфигурационными файлами.