В последнее время я переехал в другой проект, который полностью работает в Kubernetes на Azure AKS. Я честно пытался использовать Azure Monitor для мониторинга инфраструктуры и приложения. Но оно не смогло.

Поэтому я решил вернуться к своему любимом Zabbix, запустить его в Кубернетесе, отправлять письма и сообщения в Microsoft Teams и показывать графики в Grafana.

Ну, само собой, возник вопрос, как его деплоить в Kubernetes, как настраивать, как заливать кастомные скрипты?

Когда вы создаете Azure Kubernetes Service кластер (AKS), вы можете указать сервис Log Analytics для логирования и мониторинга ресурсов внутри кластера: подов, сервисов и т.д. Эта штука устанавливает агент Log Analytics (там будет несколько подов и сопуствующие ресурсы типа config maps), которые потом будут отправлять вывод stdout и stderr в Log Analytics.

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

Я использую 'boky/postfix' образ для отправки электронной почты со своего Kubernetes-кластера. Недавно система сканирования сообщила о наличии уязвимости в пакете 'py3-setuptools', которую можно закрыть, обновив пакет до последней версии.

Как обычно, я иду в свой кастомный Dockerfile и обновляю свою строку для принудительного обновления пакета...

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

Ниже вот команды, как можно это быстренько посмотреть из консоли (будет работать почти для всех дистрибутивов, на самом деле):

Если ваш Kubernetes кластер Azure AKS уже достаточно старый, особенно в DEV-окружениях, он обязательно когда-нибудь начнет заполнять дисковое пространство, приближаясь к критическим цифрам. Дело в том, что AKS хранит образы контейнеров на диске.

Я не смог найти, как часто AKS запускает какой-то свой процесс очистки (но он это делает, конечно же). Однако, в моем случае, в какой-то момент времени, потребление диска достигло 80% и не хотело останавливаться. Ниже описываю, как можно запустить процесс очистки вручную.

Z - это Zabbix

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

Возвращаясь на землю, Azure Cloud - классная платформа, с кучей фишек и возможностей (и ограничений :-)), но тем не менее, у нее нет "настоящего" решения для мониторинга. Ни для виртуальных машин, ни для других ресурсов. Можно возразить - есть OMS и Azure Monitor, но я сталкивался с кучей проблем и ограничений в попытках настроить их, что решил, что самое лучшее - разработать велосипед свое собственное решение, которое будет отвечать моим запросам.

Сегодня я попробую описать мое предложение по мониторингу: высоко доступное, бесплатное и облачное.