Диагностический дамп

Диагностический дамп — это архив с полной информацией о состоянии подсистемы мониторинга для последующего анализа инженерами поддержки. Инструмент автоматически собирает:

логи всех компонентов;
конфигурационные файлы;
системную информацию: CPU, память, диски;
статусы сервисов;
сетевую конфигурацию.

По завершении сбора скрипт автоматически удаляет из данных конфиденциальную информацию: пароли, SSL-сертификаты и приватные ключи.

Для сбора данных используйте скрипт run.sh. Он расположен в директории diagnostic/ дистрибутива.

Чтобы скрипт run.sh работал корректно, в одной директории с ним должен находиться скрипт collect.sh.

Скрипт упаковывает собранные данные в архив, который создаётся в той же директории, что и скрипт run.sh. Данные в архиве упорядочены по директориям:

configs/ — конфигурационные файлы компонентов, агентов и прокси;
logs/ — журналы работы компонентов, агентов и прокси;
sys/ — информация о состоянии памяти, CPU, дисках и сети;
vision/ — информация о процессах и сервисах Визион.

Также в архив помещается журнал работы скрипта — файл diagnostic.log.

Содержимое дампа

Логи компонентов

Таблица 1. Сервер
Компонент	Тип лога	Путь
`etcd`	journal	–
`vision_core`	journal + file	`/opt/skala-r/var/log/vision/journal/journal.log`
`vision_config_updater`	journal + file	`/opt/skala-r/var/log/vision/server/vision_config_updater/`
`vision_taskdaemon`	journal	–
`vision_alertcollector`	journal + file	`/opt/skala-r/var/log/vision/server/vision_alertcollector/`
`vision_iamsyncer`	journal + file	`/opt/skala-r/var/log/vision/server/vision_iamsyncer/`
`vision_logwatcher`	journal + file	`/opt/skala-r/var/log/vision/agent/vision_logwatcher/`
`nginx`	journal	–
`postgresql`	journal	–
`victoriametrics_st`	journal	–
`victorialogs`	journal	–
`grafana`	journal + file	`/opt/skala-r/var/log/vision/server/grafana/`
`alertmanager`	journal	–
`vmalert_st` / `vmalert_vl`	journal	–
`snmp_notifier`	journal	–
`vision_utilizer`	journal + file	`/opt/skala-r/var/log/vision/server/vision_utilizer/`

Таблица 2. Прокси
Компонент	Тип лога	Путь
`vmagent_proxy`	journal + file	`/opt/skala-r/var/log/vision/proxy/vmagent_proxy/`
`vlagent_proxy`	journal + file	`/opt/skala-r/var/log/vision/proxy/vlagent_proxy/`

Таблица 3. Агент
Компонент	Тип лога	Путь
`vmagent_agent` / `vlagent_agent`	journal + file	`/opt/skala-r/var/log/vision/agent/`
`node_exporter`	journal + file	`/opt/skala-r/var/log/vision/agent/node_exporter/`
`postgres_exporter`	journal + file	`/opt/skala-r/var/log/vision/agent/`
`snmp_exporter`	journal + file	`/opt/skala-r/var/log/vision/agent/`
`blackbox_exporter`	journal + file	`/opt/skala-r/var/log/vision/agent/`
`process_exporter`	journal + file	`/opt/skala-r/var/log/vision/agent/`
`ha_cluster_exporter`	journal + file	`/opt/skala-r/var/log/vision/agent/`
`plagent`	journal + file	`/opt/skala-r/var/log/plagent/`

Если файл лога не существует, сбор пропускается с записью в diagnostic.log.

Конфигурационные файлы

/opt/skala-r/etc/vision/server/* — конфигурации сервера;
/opt/skala-r/etc/vision/proxy/* — конфигурации прокси;
/opt/skala-r/etc/vision/agent/* — конфигурации агентов;
/etc/nginx/nginx.conf и site-конфигурации;
конфигурации PostgreSQL (все возможные пути);
etcd.conf (для HA-кластеров);
все .service-файлы systemd.

Системная информация

ps aux — процессы Визион;
systemctl — статус сервисов;
vmstat, free, meminfo, iostat — память;
journalctl -n 10000 — системный журнал;
dmesg — сообщения ядра;
uname -a, date — система и время;
cpuinfo, lscpu — CPU;
df -h, lsblk — диски;
netstat -a — сеть.

Требования

Локальный сбор

Доступ к терминалу сервера Визион.
Права root (или sudo).

Удалённый сбор

SSH-доступ к серверу.
Утилиты ssh и scp.
Настроенный SSH-ключ или возможность ввода пароля.
Утилита ping для проверки доступности.

Кластерный сбор

SSH-доступ к серверу.
Утилиты ssh и scp.
Настроенный SSH-ключ или возможность ввода пароля.
Утилита ping для проверки доступности.
Инвентарь в формате YAML с данными для подключения к узлам кластера.
Сетевая доступность всех узлов кластера.

Одноузловая конфигурация (одиночный сервер)

Локальный сбор

Запустите скрипт на сервере Визион:

cd /home/ms/projects/projects/skala-r/distrib_builder/distrib/diagnostic
./run.sh

Удалённый сбор по SSH

Укажите параметры подключения в команде запуска скрипта:

./run.sh <user> <host> <port>

Здесь:

<user> — название учётной записи;
<host> — IP-адрес или доменное имя узла;
<port> — номер порта.

Если номер порта не указан, используется значение по умолчанию — 22.

Многоузловая конфигурация (High Availability)

Для сбора диагностики со всех узлов HA-кластера за один запуск используйте кластерный режим.

Подготовка инвентаря

Создайте YAML-файл с описанием узлов кластера:

all:
  vars:
    user: "root"
    port: "22"
  hosts:
    postgres1:
      host: "192.168.1.101"
    postgres2:
      host: "192.168.1.102"
    postgres3:
      host: "192.168.1.103"
    core1:
      host: "192.168.1.110"
      user: "admin"
      port: 2222
    core2:
      host: "192.168.1.111"
    core3:
      host: "192.168.1.112"
    victoria1:
      host: "192.168.1.120"
    victoria2:
      host: "192.168.1.121"
    victoria3:
      host: "192.168.1.122"

Структура файла похожа на инвентарь Ansible, однако сам Ansible для сбора дампа не используется.

Параметры файла инвентаря:

Параметр Описание Значение по умолчанию

Параметр	Описание	Значение по умолчанию
`all.vars.user`	Пользователь SSH для всех хостов	`root`
`all.vars.port`	Порт SSH для всех хостов	`22`
`hosts.<name>.host`	IP-адрес или hostname узла	–
`hosts.<name>.user`	Пользователь для конкретного хоста	из `all.vars.user`
`hosts.<name>.port`	Порт для конкретного хоста	из `all.vars.port`

all.vars.user

Пользователь SSH для всех хостов

root

all.vars.port

Порт SSH для всех хостов

22

hosts.<name>.host

IP-адрес или hostname узла

–

hosts.<name>.user

Пользователь для конкретного хоста

из all.vars.user

hosts.<name>.port

Порт для конкретного хоста

из all.vars.port

Хосты со значением host: "[REPLACE_ME]" пропускаются.

Запуск сбора

Укажите путь к инвентарю в команде запуска скрипта:

./run.sh -c -i /path/to/inventory.yml

Здесь:

-c — кластерный режим;
-i <file> — путь к файлу инвентаря.

Структура результатов

После завершения создаётся архив vision_diagnostic_cluster_<дата>_<время>.tar.gz, содержащий следующие файлы:

vision_diagnostic_cluster_2024-01-15_10-30-00/
├── local_diagnostic_2024-01-15_10-30-00.tar.gz
├── postgres1_diagnostic_2024-01-15_10-30-00.tar.gz
├── postgres2_diagnostic_2024-01-15_10-30-00.tar.gz
├── postgres3_diagnostic_2024-01-15_10-30-00.tar.gz
├── core1_diagnostic_2024-01-15_10-30-00.tar.gz
├── core2_diagnostic_2024-01-15_10-30-00.tar.gz
├── core3_diagnostic_2024-01-15_10-30-00.tar.gz
├── victoria1_diagnostic_2024-01-15_10-30-00.tar.gz
├── victoria2_diagnostic_2024-01-15_10-30-00.tar.gz
├── victoria3_diagnostic_2024-01-15_10-30-00.tar.gz
└── <hostname>_FAILED.txt

Файлы ошибок:

<hostname>_FAILED.txt — сбор с узла не удался;
<hostname>_UNREACHABLE.txt — узел недоступен по сети.

Структура архива

Внутри каждого vision_diagnostic_*.tar.gz создаётся следующая структура:

.
├── diagnostic.log
├── vision/
│   ├── processes
│   ├── services
│   ├── skalar_files
│   └── ...
├── sys/
│   ├── ram_vmstat
│   ├── ram_free
│   ├── ram_meminfo
│   ├── ram_iostat
│   ├── sys_journalctl
│   ├── sys_dmesg
│   ├── sys_uname
│   ├── sys_date
│   ├── cpu_cpuinfo
│   ├── cpu_lscpu
│   ├── rom_df
│   ├── rom_lsblk
│   └── net_netstat
├── logs/
│   ├── vision_config_updater/
│   │   ├── journal
│   │   └── audit
│   ├── vision_core/
│   │   ├── journal
│   │   └── audit
│   ├── nginx/
│   ├── postgresql/
│   ├── victoriametrics_st/
│   ├── ...
│   └── plagent/
│       ├── journal
│       └── audit
└── configs/
    ├── vision_config_updater/
    │   └── vision_config_updater.service
    ├── vision_core/
    │   └── vision_core.service
    ├── nginx/
    │   ├── nginx.conf
    │   ├── default.conf
    │   └── vision.conf
    ├── postgres/
    │   ├── postgresql.conf
    │   └── pg_hba.conf
    ├── etcd/
    │   └── etcd.conf
    └── ...