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

В этой статье мы кратко рассмотрим варианты установки федерации Prometheus, Alertmanager и Node Exporter, остановимся на некоторых особенностях и конфигурации. Можно использовать установку из docker-compose файла или же развернуть систему в Kubernetes-кластере. Наша задача — собирать метрики серверов и сервисов инфраструктуры компании, хранить их, реагировать на алерты. Для решения этих задач необходима база данных.

Мы выбрали Prometheus по ряду причин: 

Разрабатываем и применяем удобную схему для перевода серверов со старой инфраструктуры oVirt Engine 4.2 на новую — oVirt Engine 4.5. 

У нас в компании Hostkey возникла необходимость в переводе серверов со старой инфраструктуры oVirt Engine версии 4.2 на новую инфраструктуру oVirt Engine версии 4.5. Эта миграция не просто смена минорного релиза — изменилось очень многое:

• появились новые фичи и доработки в API;
• был осуществлен переход на EL8.

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

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

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

Мы рассматривали несколько сервисов, обеспечивающих мониторинг файлов и в итоге остановились на Wazuh. На то есть несколько причин:

1.  Высокое качество клиента. Клиентская часть Wazuh оказалась наименее ресурсозатратной, но при этом стабильной и надежной. Механизм обнаружения, просмотра и сравнения соответствия безопасности с открытым исходным кодом важен, но вторичным ПО. Соответственно, он не должен нагружать сервер. Если 50% ресурса сервера идет на мониторинг, значит, что-то работает не так.  

2. Развитость и поддержка клиента. Он работает на нескольких платформах, в том числе на Windows и Linux.

3. Итоговый интерфейс построен на Open Distro. У нас в инфраструктуре уже использовался логгер на Open Distro (со временем мы перешли на OpenSearch). Это решение показалось нам интересным и комфортным с точки зрения минимизации средств поддержки, поскольку используется платформа, с которой мы хорошо знакомы.

Изначально мы искали решение для ОС семейства Linux, но Wazuh оказался универсальным решением. Ниже будет описан опыт администратора Windows. О специфике использования Wazuh на ОС семейства Linux мы расскажем в отдельной статье.

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

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

Мы в компании Hostkey не стали изобретать велосипед и построили нашу систему на базе Open Distro. В этой статье мы расскажем о варианте архитектуры этого решения, которое благодаря использованию брокера AMQP RabbitMQ обеспечивает отказоустойчивость и минимальные потери лог-данных при сбоях.