VictoriaMetrics и VictoriaLogs

В этой инструкции рассматривается развёртывание отказоустойчивых кластеров VictoriaMetrics и VictoriaLogs средствами платформы.

Визион может использовать для хранения метрик внешние серверы VictoriaMetrics и VictoriaLogs. Если вы планируете использовать это решение, разверните Визион в конфигурации для одного узла, а затем выполните переключение, следуя инструкции Смена сервера VictoriaMetrics.

Доступ к мастерам кластеров выполняется через VIP. Для управления им на узлах развёртывается служба keepalived.

Сеть

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

Виртуальное окружение

Для установки некоторых компонентов необходимы коллекции Ansible. Они входят в состав виртуального окружения, включённого в архив ansible-ha-victoria-cluster-<version>.tar.gz.

Если виртуальное окружение /opt/skala-r/vision/server/vision_venv/ не существует:

  1. Распакуйте архив:

    tar -xf ansible-ha-victoria-cluster-<version>.tar.gz

  2. Запустите скрипт создания и активации виртуального окружения:

    sh ansible-ha-victoria-cluster-<version>/venv/activate_venv.sh

    Этот скрипт создаст виртуальное окружение /opt/skala-r/vision/server/vision_venv/ и активирует его, о чём свидетельствует изменившееся приглашение интерпретатора командной строки, например:

    (vision_venv) [root@server /tmp]#

Подготовка к работе

Подготовьте установочный узел к работе:

  1. Активируйте виртуальное окружение:

    source /opt/skala-r/vision/server/vision_venv/bin/activate

  2. Перейдите в директорию с распакованными файлами архива ansible-ha-victoria-cluster-<version>.tar.gz:

    cd ansible-ha-victoria-cluster-<version>/

    Далее имена файлов и директорий указываются относительно этой директории.

  3. Создайте инвентари Ansible.

    • Если VictoriaMetrics и VictoriaLogs развёртываются на одних и тех же узлах, достаточно одного файла.

      Общий инвентарь VictoriaMetrics и VictoriaLogs inventory.yml
      ---
all:
  hosts:
    vl-vm-1.example.com:
      ansible_host: 192.168.0.11
    vl-vm-2.example.com:
      ansible_host: 192.168.0.12
    vl-vm-3.example.com:
      ansible_host: 192.168.0.13
  vars:
    cluster_vip: 192.168.0.14
    ansible_user: "<user>"
    ansible_ssh_pass: "<password>"
    ansible_become_user: "<become_user>"
    ansible_become_pass: "<become_password>"

    • Если VictoriaMetrics развёртывается на своих узлах, а VictoriaLogs на своих, создайте два файла:

      Инвентарь VictoriaLogs inventory-victorialogs.yml
      ---
all:
  hosts:
    vl-1.example.com:
      ansible_host: 192.168.0.11
    vl-2.example.com:
      ansible_host: 192.168.0.12
    vl-3.example.com:
      ansible_host: 192.168.0.13
  vars:
    cluster_vip: 192.168.0.14
    ansible_user: "<user>"
    ansible_ssh_pass: "<password>"
    ansible_become_user: "<become_user>"
    ansible_become_pass: "<become_password>"
      Инвентарь VictoriaMetrics inventory-victoriametrics.yml
      ---
all:
  hosts:
    vm-1.example.com:
      ansible_host: 192.168.0.15
    vm-2.example.com:
      ansible_host: 192.168.0.16
    vm-3.example.com:
      ansible_host: 192.168.0.17
  vars:
    cluster_vip: 192.168.0.18
    ansible_user: "<user>"
    ansible_ssh_pass: "<password>"
    ansible_become_user: "<become_user>"
    ansible_become_pass: "<become_password>"

VictoriaMetrics

Запустите плейбук:

ansible-playbook \
   -i /path/to/inventory \
   playbooks/cluster-vm/deploy.yml

VictoriaLogs

Запустите плейбук:

ansible-playbook \
   -i /path/to/inventory \
   playbooks/cluster-vl/deploy.yml

keepalived

keepalived отслеживает состояние мастеров VictoriaMetrics и VictoriaLogs. Если мастер выходит из строя, keepalived перемещает Virtual IP на новый мастер.

Параметры развёртывания keepalived зависят от того, развёртываются VictoriaMetrics и VictoriaLogs на одних и тех же узлах или на разных.

VictoriaMetrics и VictoriaLogs на одних и тех же узлах

Если VictoriaMetrics и VictoriaLogs развёртываются на одних и тех же узлах:

  1. Файл playbooks/cluster-vip/group_vars/all/keepalived.yml заполните следующим образом:

    ---
keepalived_virtual_router_id: 50
keepalived_virtual_status_command: "/bin/bash -c '/sbin/systemctl is-active --quiet vmauth.service && /sbin/systemctl is-active

  2. Запустите развёртывание, указав путь к файлу общего инвентаря:

    ansible-playbook \
   -i inventory.yml \
   playbooks/cluster-vip/deploy.yml

VictoriaMetrics и VictoriaLogs на разных узлах

Если VictoriaMetrics и VictoriaLogs развёртываются на разных узлах:

  1. Файл playbooks/cluster-vip/group_vars/all/keepalived.yml заполните следующим образом:

    ---
keepalived_virtual_router_id: 50
keepalived_virtual_status_command: "/bin/bash -c '/sbin/systemctl is-active --quiet vlauth.service'"

  2. Запустите развёртывание keepalived на узлах VictoriaLogs:

    ansible-playbook \
   -i inventory-victorialogs.yml \
   playbooks/cluster-vip/deploy.yml

  3. Измените содержимое файла playbooks/cluster-vip/group_vars/all/keepalived.yml:

    ---
keepalived_virtual_router_id: 100
keepalived_virtual_status_command: "/bin/bash -c '/sbin/systemctl is-active --quiet vmauth.service'"

  4. Запустите развёртывание keepalived на узлах VictoriaMetrics:

    ansible-playbook \
   -i inventory-victoriametrics.yml \
   playbooks/cluster-vip/deploy.yml

  5. Деактивируйте виртуальное окружение:

    deactivate

Секреты

В результате выполнения плейбуков в директории playbooks/tmp/secrets/ формируются файлы с конфиденциальными сведениями (секреты), необходимыми для работы кластеров и подключения к ним внешних клиентов.

Сохраните секреты в надёжном месте!

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

  • CAVictoriaExternal.crt — корневой сертификат для внешних подключений к серверу.

  • <vip>_external_client.crt — сертификат для внешних подключений к серверу.

  • <vip>_external_client.key — ключ сертификата для внешних подключений к серверу.

  • <hostname>_vmauth_server.crt — сертификат для серверов vlauth и vmauth, обрабатывающих внешние подключения.

  • <hostname>_vmauth_server.key — ключ сертификата для серверов vlauthи vmauth, обрабатывающих внешние подключения.

  • CAVictoriaInternal.crt — корневой сертификат для внутренних подключений между компонентами кластера.

  • <hostname>_vmauth_client.crt — сертификат для подключения vlauth и vmauth в качестве клиентов.

  • <hostname>_vmauth_client.key — ключ сертификата для подключения vlauth и vmauth в качестве клиентов.

  • <hostname>_vinsert.crt — сертификат для подключения vlinsert в качестве клиента.

  • <hostname>_vinsert.key — ключ сертификата для подключения vlinsert в качестве клиента.

  • <hostname>_vselect.crt — сертификат для подключения vselect в качестве клиента.

  • <hostname>_vselect.key — ключ сертификата для подключения vselect в качестве клиента.

  • <hostname>_vstorage.crt — сертификат для подключения vstorage в качестве клиента.

  • <hostname>_vstorage.key — ключ сертификата для подключения vstorage в качестве клиента.

  • <vip>_global_basic_auth_password — пароль BasicAuth для внутренних подключений между компонентами кластера.

  • <vip>_keepalived_auth_password — пароль keepalived, используемый для авторизации между узлами.

  • <vip>_vmauth_external_user_password — пароль для внешних подключений vision_core и других компонентов Визион к vlauth и vmauth.

Проверка корректности

В приведённых ниже командах используются следующие обозначения:

  • <ca_cert> — путь к корневому сертификату для внешних подключений, playbooks/cluster-vm/tmp/secrets/CAVictoriaExternal.crt.

  • <vip> — VIP, указанный в инвентори-файле.

  • <user> — имя пользователя vlauth или vmauth. По умолчанию в VictoriaLogs и VictoriaMetrics создаётся пользователь vision.

  • <password> — пароль для доступа к vlauth или vmauth. Используйте значение из файла playbooks/cluster-vm/tmp/secrets/vmauth_external_user_password.

  • <port> — порт для подключения:

    • 8427 — VictoriaMetrics.

    • 9427 — VictoriaLogs.

Статусы служб и журналы работы

Убедитесь, что на узлах кластера корректно работают все необходимые службы, а журналы не содержат сообщений об ошибках:

  1. Проверьте статусы служб VictoriaLogs на соответствующих узлах:

    • vlauth.service;

    • vlinsert.service;

    • vlselect.service;

    • vlstorage.service;

  2. Проверьте статусы служб VictoriaMetrics на соответствующих узлах:

    • vmauth.service;

    • vminsert.service;

    • vmselect.service;

    • vmstorage.service;

  3. Проверьте статус службы keepalived.service на всех узлах.

  4. Чтобы убедиться в отсутствии ошибок в журналах работы компонентов кластера, следуйте соответствующей инструкции:

Состояние хранилища

Запрос:

curl -v \
  --cacert <ca_cert> \
  -u <user>:<password> \
  "https://<vip>:<port>/-/healthy"

Ответ должен обладать следующими свойствами:

  • HTTP Status Code: 200 OK.

  • Body: VictoriaLogs is Healthy или VictoriaMetrics is Healthy соответственно.

Запись лога в vlinsert через vlauth

Запрос:

curl -v -X POST \
  -H "Content-Type: application/stream+json" \
  --cacert <ca_cert> \
  -u <user>:<password> \
  --data-binary @- \
 "https://<vip>:<port>/insert/jsonline?_stream_fields=app_name&_time_field=date&_msg_field=log.message" <<EOF
{ "log": { "level": "info", "message": "hello world" }, "date": "0", "app_name": "test" }
{ "log": { "level": "error", "message": "oh no!" }, "date": "0", "app_name": "test" }
EOF

Ответ должен обладать следующими свойствами:

  • HTTP Status Code: 200 OK.

  • Body: отсутствует.

Запись метрики в vminsert через vmauth

Запрос:

curl -v \
  --cacert <ca_cert> \
  -u <user>:<password> \
  --data-binary 'up{test="vminsert_curl"} 1' \
  "https://<vip>:<port>/api/v1/import/prometheus"

Ответ должен обладать следующими свойствами:

  • HTTP Status Code: 204 No Content.

  • Body: отсутствует.

Чтение лога из vlselect через vlauth

Запрос:

curl -v \
  --cacert <ca_cert> \
  -u <user>:<password> \
  "https://<vip>:<port>/select/logsql/query?query=*"

Ответ должен обладать следующими свойствами:

  • HTTP Status Code: 200 OK.

  • Body: отсутствует или содержит корректный JSON с данными.

Чтение метрик из vmselect через vmauth

Запрос:

curl -v \
  --cacert <ca_cert> \
  -u <user>:<password> \
  "https://<vip>:<port>/api/v1/query?query=up"

Ответ должен обладать следующими свойствами:

  • HTTP Status Code: 200 OK.

  • Body: содержит поле status со значением success.

Доступ к интерфейсу VMUI через браузер

vlauth и vmauth проксируют доступ к интерфейсу VMUI с помощью запросов, которые обрабатывают компоненты vlselect и vmselect соответственно. Для проверки работоспособности перейдите по ссылке:

https://<user>:<password>@<vip>:<port>/vmui

Отсутствие ошибок получения данных указывает на корректность выполненных настроек.

Перемещение VIP

Перемещение VIP позволяет убедиться в корректности работы служб keepalived и vip-manager.

Перемещение при остановке keepalived

  1. Найдите узел с VIP:

    ip -br a

  2. Подключитесь к узлу с VIP и остановите службу keepalived:

    systemctl stop keepalived.service

  3. Убедитесь, что VIP переместился на другой узел.

  4. Повторяйте шаги 1—​3 до тех пор, пока VIP не будет перемещён на нужный узел.

  5. Запустите службу keepalived на всех узлах кластера:

    systemctl start keepalived.service

Перемещение при остановке vlauth

  1. Найдите узел с VIP:

    ip -br a

  2. Подключитесь к узлу с VIP и остановите службу vlauth:

    systemctl stop vlauth.service

  3. Убедитесь, что VIP переместился на другой узел.

  4. Повторяйте шаги 1—​3 до тех пор, пока служба vlauth не будет остановлена на всех узлах.

  5. Найдите узел без VIP:

    ip -br a

  6. Запустите сервис vlauth:

    systemctl start vlauth.service

  7. Убедитесь, что VIP перемещён на узел с работающей службой vlauth.

    На перемещение VIP может потребоваться несколько секунд.

  8. Запустите службу vlauth на всех остальных узлах кластера.

Перемещение при остановке vmauth

  1. Найдите узел с VIP:

    ip -br a

  2. Подключитесь к узлу с VIP и остановите службу vmauth:

    systemctl stop vmauth.service

  3. Убедитесь, что VIP переместился на другой узел.

  4. Повторяйте шаги 1—​3 до тех пор, пока служба vmauth не будет остановлена на всех узлах.

  5. Найдите узел без VIP:

    ip -br a

  6. Запустите сервис vmauth:

    systemctl start vmauth.service

  7. Убедитесь, что VIP перемещён на узел с работающей службой vmauth.

    На перемещение VIP может потребоваться несколько секунд.

  8. Запустите службу vmauth на всех остальных узлах кластера.