Zabbix Server

Поддержка автомасштабирования # эксперт

Как автомасштабирование AWS работает с Zabbix?

Чтобы обрабатывать автомасштабирование из Zabbix, нужно учесть три момента:

1. Добавить новый инстанс в Zabbix, когда он появляется. Это делается автоматической регистрацией активных агентов Zabbix (6.4, 6.0, 4.0). Так при появлении нового инстанса Zabbix автоматически добавляет его как новый узел.
2. Сохранить ID инстанса в инвентаре Zabbix. Когда инстанс исчезает (scale in), мы получаем сообщение с его ID, поэтому он должен быть в инвентаре узла, чтобы найти и удалить узел.
3. Получать сообщения о масштабировании от AWS. При событии масштабирования AWS публикует сообщение SNS в заданный вами топик. Подключив этот топик к очереди SQS, мы можем читать сообщения из Zabbix и удалять инстансы, покидающие группы масштабирования.

Настроить клиент

Для подготовки клиентов к автомасштабированию в Zabbix нужны два шага: настроить агент Zabbix и добавить файл с пользовательским параметром для элемента instance_id.

Настройка агента Zabbix

Помимо любых других нужных вам изменений, в локальном файле конфигурации агента Zabbix (обычно /etc/zabbix/zabbix_agentd.conf) нужно поменять шесть пунктов:

• Закомментировать параметр Server.
• Добавить ServerActive=YOUR__ZABBIX__IP__ADDRESS, чтобы задать активный сервер.
• Закомментировать параметр Hostname.
• Установить параметр StartAgents в 0.
• Установить параметр HostnameItem в system.hostname.
• Установить параметр HostMetadataItem в system.uname.

С такой конфигурацией клиент Zabbix работает в активном режиме (сам отправляет данные серверу и не получает от него проверок). Кроме того, Zabbix использует имя машины как имя узла, поэтому его не нужно менять при каждом запуске нового сервера. Наконец, Zabbix отправляет вывод uname как метаданные: инстансы AWS используют особое ядро, поэтому в нём встречается значение aws, по которому можно регистрировать сервер.

Параметр instance_id

По умолчанию новый сервер из группы автомасштабирования привязывается в Zabbix к специальному шаблону AWS EC2 Template, где есть элемент instance_id, связанный с полем alias инвентаря. Чтобы его наполнять, добавьте в клиент Zabbix пользовательский параметр, создав файл:

UserParameter=aws.ec2.instance_id,curl -s http://169.254.169.254/latest/meta-data/instance-id

Настроить сервер

После настройки клиентов следующий шаг — настроить сервер на удаление исчезнувших инстансов. Самый быстрый и простой путь состоит из двух шагов: отправлять сообщения о масштабировании в очередь SQS и настроить сервер на её чтение.

Отправка сообщений о масштабировании в очередь SQS

Нам нужно, чтобы уведомления сервиса автомасштабирования сохранялись в очереди SQS — ради надёжности и масштаба. Поскольку автомасштабирование AWS отправляет уведомления в топик SNS, требуется:

• Создать топик SNS.
• Создать очередь SQS.
• Настроить SNS на доставку сообщений в SQS.
• Создать пользователя IAM, который может читать сообщения.

Так как такая настройка непроста, можно воспользоваться нашим стеком CloudFormation, чтобы создать все элементы в нужном регионе. После развёртывания на вкладке Outputs будут четыре значения, которые стоит записать:

• SNSTopicARN: ARN созданного топика SNS.
• SQSQueueURL: URL очереди SQS.
• SQSReadIAMUserAccessKey и SQSReadIAMUserSecretKey: ключ и секрет пользователя IAM.

Эти данные нужны для настройки. Отредактируйте файл /etc/zabbix/zabbix_ami.yml в блоке вида:

sqs:
  delay_seconds: 60
  default_region: us-east-1
  queues:
    - url:
      access_key_id:
      secret_access_key:
      region:

Для каждой очереди SQS с уведомлениями о масштабировании добавьте элемент массива по образцу существующего, подставив значения из CloudFormation. Подробнее об этом файле — в разделе важные файлы.

Важные файлы # эксперт

В образе Zabbix есть несколько особых файлов, о которых стоит знать.

/etc/zabbix/zabbix_ami.yml

Это самый важный файл: он управляет настройкой особых возможностей — проверок масштабирования и уведомлений SNS. Пример (с вымышленными данными):

zabbix:
  api:
    user: autoscaler_api_user
    password: i-073672daf01037aea94
sns:
  aws:
    access_key_id: AKK4L6A3OXZZ5HE2POQRU7V
    secret_access_key: cICycAg26hSDpsJwbhZjbaaYlt4Tz3n1xqE7Oxp6X2Hf
    region: us-east-1
  topics:
    not_classified: arn:aws:sns:us-east-1:000000000:Zabbix-General-SNS
    information:    arn:aws:sns:us-east-1:000000000:Zabbix-General-SNS
    warning:        arn:aws:sns:us-east-1:000000000:Zabbix-General-SNS
    average:        arn:aws:sns:us-east-1:000000000:Zabbix-General-SNS
    high:           arn:aws:sns:us-east-1:000000000:Zabbix-General-SNS
    disaster:       arn:aws:sns:us-east-1:000000000:Zabbix-General-SNS
sqs:
  delay_seconds: 60
  default_region: us-east-1
  queues:
    - url: https://sqs.us-east-1.amazonaws.com/000000000/zabbix-pro-sqs-queue
      access_key_id: AKIA3OXZZ5HEWUR5A16CNWH
      secret_access_key: 8ttYO3Ba9K6p0C+aj3fH5cDt2eRLHmlkHbMtlrpv18S7KRbC
      region: us-east-1

Сейчас в файле три раздела:

• zabbix: поскольку для удаления устаревших узлов нужно обращаться к серверу Zabbix, требуется доступ к API. Для этого создаётся отдельный пользователь, его данные указываются здесь.
• sns: конфигурация, необходимая для отправки тревог через SNS. Здесь задаются данные пользователя IAM и используемые топики SNS.
• sqs: конфигурация обработки сообщений о масштабировании в AWS. Здесь задаётся, как часто опрашивать очередь (delay_seconds), и список очередей.

/var/log/zabbix-sqs-reader/zabbix-sqs-reader.log

В этом файле записываются события автомасштабирования, прочитанные из SQS.

До настройки вы увидите сообщение Ops! It looks like the file /etc/zabbix/zabbix_ami.yml hasn't been configured yet. We better sleep for 5 minutes. — это нормально, оно исчезнет после настройки zabbix_ami.yml.

Обновления образа # эксперт

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

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

Обновление вкратце

Процесс обновления нашего образа довольно прост:

• Сделать дамп текущей базы данных.
• Запустить новый образ с последней стабильной версией.
• Загрузить дамп базы на новый инстанс.
• Запустить наш скрипт миграции.

Так одновременно работают старая и новая версии, и можно провести все необходимые проверки, прежде чем переносить EIP этого инстанса или постепенно переводить клиентов.

Процесс обновления

Шаг 1: резервная копия сервера-источника

Первый шаг — сделать образ сервера-источника, чтобы исключить случайную потерю данных. Можно воспользоваться руководством AWS по созданию AMI.

Шаг 2: дамп базы и версия Zabbix

Подключаемся к инстансу по SSH и становимся root:

sudo /bin/su -

Затем выгружаем базу данных в файл:

mysqldump zabbix > zabbix_origin_database.sql

Наконец, скачиваем полученный файл на свою машину, чтобы потом загрузить на новый сервер. Также запишите текущую версию Zabbix: её видно в веб-интерфейсе, это число вида 4.0, 4.2, 4.4 или 5.4.

Шаг 3: запустить новый инстанс Zabbix

Следующий шаг — создать новый инстанс Zabbix из последней стабильной версии образа, которую можно найти в нашем профиле продавца на AWS Marketplace. Минимально требуется версия 6.0 нашего образа Zabbix.

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

Шаг 4: обновить базу данных

Чтобы залить текущую базу, обновить её до новой версии и добавить нужные настройки, используем скрипт /opt/tools/bin/zabbix-ami-upgrade.sh. Запускать его нужно от пользователя ubuntu, указав исходную версию Zabbix и файл дампа. Например, при переходе с Zabbix 4.0:

/opt/tools/bin/zabbix-ami-upgrade.sh 4.0 zabbix_origin_database.sql

Процесс сообщает о каждом выполненном шаге, а по завершении можно продолжать работу с новым сервером Zabbix.

Шаг 5: зайти в веб-интерфейс

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

Шаг 6: перенести особые настройки и перенастроить клиентов

Когда база работает, учтите и другие настройки, которые могли быть на сервере, например:

• Скрипты мониторинга.
• Дополнительные системные пакеты.
• Установленные сертификаты SSL.

Также стоит перенести EIP, настроенный для этого инстанса, чтобы клиентов не пришлось менять.

Если EIP не используется, самое время начать: иначе придётся менять IP нового сервера на всех клиентах.