# Первичный Траблшут в KUMA (Troubleshoot)
### Проверка статуса основных компонентов
Основные службы KUMA:
```bash=
systemctl status kuma-collector-ID_СЕРВИСА.service
systemctl status kuma-correlator-ID_СЕРВИСА.service
systemctl status kuma-storage-ID_СЕРВИСА.service
systemctl status kuma-core-ID_СЕРВИСА.service
systemctl status kuma-metrics-ID_СЕРВИСА.service
```
В версии KUMA 3.2 сервис ядра изменил название на **kuma-core-00000000-0000-0000-0000-000000000000.service**
ID\_СЕРВИСА можно скопировать в веб-интерфейсе системы, в разделе Активные сервисы, выделив в checkbox нужный сервис, затем нажав кнопку скопировать ID.
[](https://kb.kuma-community.ru/uploads/images/gallery/2023-08/I9Nimage.png)
Перед рестартом коры (в версии KUMA 3.2) необходимо убедиться, что БД SQLite не находится в обслуживающем режиме (VACUUM), для этого перед рестартом убедитесь, что после выполенения команды **sqlite3 /opt/kaspersky/kuma/core/00000000-0000-0000-0000-000000000000/raft/sm/db 'PRAGMA locking\_mode;'** получаете ответ `normal`
---
### Проверка журнала ошибок KUMA
`/opt/kaspersky/kuma/<Компонент>//log/<Компонент>`
Пример:
`/opt/kaspersky/kuma/storage//log/storage`
Для неактуальных версий (2.0 и ниже):
- `journalctl –xe`
- Журнал ошибок Click-House: `/opt/kaspersky/kuma/clickhouse/logs/clickhouse-server.err.log`
---
### Вывод ошибок сервиса в консоль
В случае отсутствия информации в журналах целесообразно вывести информацию в консоль. Проверяем статус сервиса и копируем его параметры запуска:
[](https://kb.kuma-community.ru/uploads/images/gallery/2023-08/vVKimage.png)
**Останавливаем сервис**, переходим в папку `cd /opt/kaspersky/kuma/` и запускаем следующим образом, пример команды ниже:
```bash
sudo -u kuma /opt/kaspersky/kuma/kuma collector --id cef0527c-25ad-4490-a8ce-bf9ab2af71ee --core https://test-kuma.sales.lab:7210 --api.port 7276
```
---
### Пустые метрики
Для версий ниже 3.2
В случае если раздел метрик пустой (отсутствуют значения на дашбордах), то проверьте указан ли IP и hostname сервера KUMA в файле /etc/hosts, если нет то добавьте.
Перезапустите службы:
```bash
systemctl restart kuma-victoria-metrics.service
systemctl restart kuma-grafana.service
```
Либо присутствует конфликт со службой Cockpit на Oracle Linux.
Она слушает тот же порт 9090, что и Victoria Metrics. Останови Cockpit и посмотри, поднимутся ли метрики.
Либо проблема из-за наличия прокси между ядром и АРМом, с которого к вебке подключались.
---
### Проверка прослушивания порта, например, 5144
```bash
netstat –antplu | grep 5144
```
---
### Работа с портами на МЭ (firewall-cmd)
Проверка открытых портов на МЭ:
```bash
firewall-cmd --list-ports
```
Добавление порта 7210 на МЭ:
```bash
firewall-cmd --add-port=7210/tcp --permanent
```
Применение настроек:
```bash
firewall-cmd --reload
```
---
### Проверка получения событий на порту 5144 в ASCII
```bash
tcpdump -i any port 5144 -A
```
---
### Отправка тестового события на порт 5144, для проверки работы коллектора
Для TCP:
```bash
nc 127.0.0.1 5144 <<< 'CEF:0|TESTVENDOR|TESTPRODUCT|1.1.1.1|TEST_EVENT|This is a test event|Low|message="just a test coming through"'
```
Для UDP:
```bash
nc -u 127.0.0.1 5144 <<< 'CEF:0|TESTVENDOR|TESTPRODUCT|1.1.1.1|TEST_EVENT|This is a test event|Low|message="just a test coming through"'
```
В случае наличия в сыром событии двух типов кавычек ' и ", то целесообразно отпралять событие из файла (для этого тестовое событие запишите в файл 1 строку).
```
cat test.txt | nc -u 127.0.0.1 5144
```
Для HTTP:
```bash
curl -X POST -d "Your message here" http://localhost:/path
```
Если многострочное событие в файле с разделителем \\0:
```bash
truncate -s +1 sample
curl http://:/input --data-binary "@/root/sample"
```
---
### Статус службы красный / Ошибка на компоненте
Переписать / перепроверить учетные данные (если используются) используемые в коннекторе на коллекторе. Проверить владельца папки службы, должно быть **kuma:kuma**
Посмотреть статус сервиса через консоль ssh. В случае если он запущен остановить:
```bash
systemctl stop kuma-collector-ID_СЕРВИСА.service
```
запустить вручную (`--api.port` выбирайте любой свободный), и посмотреть есть ли ошибки при запуске:
```bash
/opt/kaspersky/kuma/kuma collector --id ID_СЕРВИСА --core https://FQDN_KUMA:7210 --api.port 7225
```
Если будут ошибки, они явно отразятся в консоли.
Для сервисов без ID, сначала смотрим параметры запуска службы, например:
[](https://kb.kuma-community.ru/uploads/images/gallery/2023-08/dG7image.png)
Затем делаем стоп службы и запускаем строку запуска от пользователя KUMA:
Для версий ниже 3.2
```
sudo -u kuma /opt/kaspersky/kuma/kuma core --external :7220 --internal :7210 --mongo mongodb://localhost:27017
```
---
### Ручная очистка пространства хранилища
Если место на сервере хренения заканчивается, но еще не закончилось.
Выберите в активных сервисах - сервис хранилища (storage) и нажмите на кнопку смотреть разделы. Удаляйте наиболее старые партиции.
Далее (чтобы в будущем не заполнялось):
1. Resources/Storage - уменьшаем ретеншен период
2. после этого рестарт сервисов KUMA Storage. Изменения применятся примерно в течение часа и место освободится.
---
### Закончилось дисковое пространство
Если место уже закончилось.
- При all-in-one инсталляции в web консоль KUMA уже не пустит. Для all-in-one последовательность действий следующая:
- Останавить все сервисы `systemctl stop kuma-*`
- Удалить буферы коллекторов и коррелятора: `rm -rf /opt/kaspersky/kuma/collector/*/buffers/*` и `rm -rf /opt/kaspersky/kuma/correlator/*/buffers/`
- Удалить кеш обогащения (если есть) коллекторов и коррелятора: `rm -rf /opt/kaspersky/kuma/collector/*/cache/enrichment/*` и `rm -rf /opt/kaspersky/kuma/correlator/*/cache/enrichment/`
- Удалить лог файлы clickhouse: `rm -rf /opt/kaspersky/kuma/storage/*/logs/`
- запустить сервис clickhouse: `systemctl start kuma-storage*`
- запустить сервисы core: `systemctl start kuma-core-00000000-0000-0000-0000-000000000000`
- залогиниться в web консоль KUMA, удалить лишние партиции (см. предыдущий пункт траблшута)
- Стартуем оставшиеся сервисы KUMA (`kuma-metrics-.service`, `kuma-collector-*`, `kuma-correlator-`)
- Если серверы хранения находятся отдельно:
- Остановить все коллекторы и корреляторы. Никакие новые события не должны отправляться в Storage.
- На серверах хранения остановить сервис kuma-storage
- очистить файлы журналов `rm -rf /opt/kaspersky/kuma/storage/*/logs/`
- очистить файлы буфера `rm -rf /opt/kaspersky/kuma/storage/*/buffers/`
- Запустить сервис `systemctl start kuma-storage-`
- Залогиниться в web консоль KUMA, удалить лишние партиции (см. предыдущий пункт траблшута)
Далее (чтобы в будущем не заполнялось) в KUMA с версии 3.2: В Параметры - Мониторинг сервисов - Хранилище, выставьте нужные значения по оповещениям и ротации.
Для полной очитки данных хранилища (выполнять на хранилищах и киперах):
- systemctl stop kuma-storage-\*.service
- rm -rf /opt/kaspersky/kuma/clickhouse/data
- rm -rf /opt/kaspersky/kuma/clickhouse/coordination
- rm -rf /opt/kaspersky/kuma/clickhouse/logs/
- Иногда полезно чистить
- rm -rf /opt/kaspersky/kuma/clickhouse/tmp/
- rm -rf /opt/kaspersky/kuma/storage/\*/buffers/
- systemctl start kuma-storage-\*.service
---
### Создание сервисов в случае их отсутствия
Если в разделе **Ресурсы – Активные сервисы** отсутствуют что-либо, то необходимо создать необходимые службы.
#### Создаем сервис хранилища
Перейдите в **Ресурсы – Хранилища** затем нажать на кнопку **Добавить хранилище** придумайте название и затем укажите количество дней хранения событий и событий аудита (от 365 дней срок хранения аудита), затем нажмите **Сохранить**.
Публикуем созданный сервис **Ресурсы – Активные сервисы** затем выбрать созданный ранее сервис и нажать на кнопку Создать сервис.
Скопируйте идентификатор сервиса:
[](https://kb.kuma-community.ru/uploads/images/gallery/2023-08/cVWimage.png)
Выполните команду в консоли:
В случае использования ядра в кластере **Raft** в параметре **--core** необходимо указать адреса всех серверов ядра через запятую.
```bash
/opt/kaspersky/kuma/kuma storage --id <ВАШ_ИДЕНТИФИКАТОР> --core https://:7210 --api.port 7230 --install
```
В разделе **Ресурсы – Активные сервисы** убедитесь, что служба работает более 30 секунд с «зеленым» статусом индикатора:
[](https://kb.kuma-community.ru/uploads/images/gallery/2023-08/sCSimage.png)
Далее создадим точку назначения, которая используется в маршрутизации событий, перейдите в **Ресурсы – Точки назначения**, затем нажмите на кнопку **Добавить точку назначения**. Придумайте название и затем в поле URL укажите FQDN и порт службы хранилища, например: `kuma-1-5-1.sales.lab:7230`, затем нажмите **Сохранить**.
Аналогичные действия понадобятся для установки остальных компонентов, только в интерфейсе будет доступна команда, которую необходимо будет выполнить для установки службы.
---
#### Создаем сервис коррелятора
Развернем коррелятор, перейдите в **Ресурсы – Корреляторы**, нажмите на кнопку Добавить коррелятор и затем пройдите по мастеру настроек, на шаге добавления маршрутизации добавьте точку назначения ранее созданного хранилища:
[](https://kb.kuma-community.ru/uploads/images/gallery/2023-08/seoimage.png)
На последнем шаге нажмите кнопку **Сохранить и создать сервис**, в случае отсутствия ошибок появится командная строка для установки службы, скопируйте ее и выполните по ssh.
[](https://kb.kuma-community.ru/uploads/images/gallery/2023-08/4AXimage.png)
Аналогично по мастеру создаются коллекторы для приема или получения событий с источников.
---
### Ошибка скрипта при установке - ipaddr
Если при установке возникает следующая ошибка (пишется в конце исполнения скрипта):
[](https://kb.kuma-community.ru/uploads/images/gallery/2023-08/RB7image.png)
То попробуйте установить нужную библиотеку для python, это было в требованиях https://support.kaspersky.com/KUMA/1.6/ru-RU/231034.htm, в случае отсутствия возможности это сделать то закомментируйте (вставьте # перед строками) следующие строки в файле `kuma-ansible-installer/tasks/validate-inventory.yml`:
```
#- name: Ensure there is no IP as hostname
# loop: "{{ groups.all }}"
# when: item | ansible.netcommon.ipaddr
# fail:
# msg: |
# host: {{ item }}
# error: Hostname expected
```
---
### Слушать на 514 порту (порты < 1024)
По умолчанию это невозможно, так работает Linux. Для обхода этого в описании сервиса:
```
/usr/lib/systemd/system/kuma-collector-
```
Добавьте значение ниже тега \[Service\]
```
AmbientCapabilities=CAP_NET_BIND_SERVICE
```
Затем запустите команду ниже для обновления параметров сервиса
```
systemctl daemon-reload
```
---
### Не запускается хранилище после перезагрузки в версии от 2.1
Прописать следующую команду в SSH консоли:
```bash
sudo -u kuma touch /opt/kaspersky/kuma/clickhouse/data/flags/force_restore_data
```
---
### Ошибка БД ClickHouse Table read only replicas
Ошибка в логах хранилища выглядит так: 
Зайдите в клиент ClickHouse:
```
/opt/kaspersky/kuma/storage//deps/clickhouse/bin/client.sh
```
Выполните команду:
```
system restart replica on cluster kuma kuma.events_local_v2
```
Для выхода из клиента нажмите **Ctrl+D**.
---
### Ошибка ZooKeeper - KEEPER\_EXCEPTION
Убедиться, что ipv6 включен:
```bash
ping ::1
```
Убедиться, что у вас корректное содержимое в /etc/hosts, смотрите этап [**подготовки** ](https://kb.kuma-community.ru/books/ustanovka-i-obnovlenie/page/podgotovka-os-pered-ustanovkoi-i-trebovaniia)п. 8
Очистить Coordination Zookeeper и наработки хранилища (удаляет все события):
```bash
systemctl stop kuma-storage-.service
rm -rf /opt/kaspersky/kuma/storage//data/*
rm -rf /opt/kaspersky/kuma/storage//tmp/*
rm -rf /opt/kaspersky/kuma/clickhouse/coordination/*
systemctl start kuma-storage-.service
```
Иногда требуется (в случае если ошибка остаеся):
```bash
sudo -u kuma touch /opt/kaspersky/kuma/clickhouse/data/flags/force_restore_data
```
Либо:
```
/opt/kaspersky/kuma/clickhouse/bin/client.sh
system restore replica on cluster kuma kuma.events_local_v2
```
---
### Признаки нехватки выделенных ресурсов
Описание метрик доступно тут: [https://kb.kuma-community.ru/books/kuma-how-to/page/opisanie-metrik-v-kuma](https://kb.kuma-community.ru/books/kuma-how-to/page/opisanie-metrik-v-kuma)
#### Универсальный показатель Load
[](https://kb.kuma-community.ru/uploads/images/gallery/2024-05/ealimage.png)
Мощностей не хвататет, если на нодах высокий LA (Load average), утилизация CPU доходит до 100%, нагрузка зависит не только от потока (EPS) зависит, но и от профиля использования (количество обогащений, интеграций, используемых правил и т.д.). Средние значения нагрузки (Load averages):
- Если значения равны 0.0, то система в состоянии простоя
- Если среднее значение для 1 минуты выше, чем для 5 или 15, то нагрузка растёт
- Если среднее значение для 1 минуты ниже, чем для 5 или 15, то нагрузка снижается
- Если значения нагрузки выше, чем количество (виртуальных) процессоров, то могут быть проблемы с производительностью (в зависимости от ситуации)
#### Проблема с производительностью диска на хранилище по метрикам
Накапливается буфер в точках назначения, на рисунке ниже хранилище не справляется с потоком, в норме буфер не накапливается при доступности хранилища:
Загрузка CPU и RAM доходит до 100% или близко к этому значению:
В случае использования кластера хранилищ растут очереди распределенных запросов и мерджи:
Хранилища выпадают в режим только для чтения:
Может быть полезно для хранилища при нагрузках или плохой производительности:
- Работа с объемом буфера для записи в хранилище и временем ожидания, изменение парметров хранилища (во вкладке дополнительно службы хранилища):
- Если в метриках по хранилищу Batch Size крайне низок по сравнению со 128 МБ, то следует увеличить Интервал очистки буфера (по умолчанию 1 сек). Данные сбрасываются в хранилище либо по достижению определенного размера или по таймауту и задача найти этакий баланс между размером пачки и интервалом очистки. Хранилище не любит работать часто с мелкими фрагментами данных.
- Размер буфера (Batch Size) по умолчанию он 128 МБ, увеличить в большую сторону.
- Вынесение и использование отдельных машин с ролью keeper
- Использование более производительного RAID массива
- Использование более производительного дискового носителя
- Использование дополнительного шарда для повышения производительности
Также оценить нагрузку на диск можно командой `top` в ОС Linux, отслеживая параметр wa (wa: io wait cpu time (or) % CPU time spent in wait on disk) — показывает процент операций, готовых быть выполненных процессором, но находящихся в состоянии ожидания от диска. Допустимое значение < 0.5, в идеале 0.
Требования к хранилищу - [**тут**](https://kb.kuma-community.ru/link/21#bkmrk-%D0%A2%D1%80%D0%B5%D0%B1%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F-%D0%B4%D0%BB%D1%8F-%D0%A5%D1%80%D0%B0%D0%BD%D0%B8)
Устройство кластера хранилищ - [**тут**](https://kb.kuma-community.ru/books/kuma-how-to/page/ustroistvo-klastera-xranilishha)
#### Проблема с производительностью сервисов (особенно коррелятор), большой Output Latency
Если CPU заняты не полностью (не на 100%), а Latency существенный (более 1-2 сек) — проблема вероятней всего в сети. Ниже пример допустимого Output Latency.
Для подверждения, что проблема именно в сети, установите коррелятор локально (что бы события не через сетевой интерфейс летели, а через localhost) на сервер с коллекторами, и подайте туда поток событий с аналогичной нагрузкой. Также полезно ознакомиться с разделом ниже.
#### Проблема с производительностью сервисов (особенно коррелятор), большьшая нагрузка на CPU, памяти и периодические перезапуски службы
Большое кол-во коллекторов (> 100 шт.) перенаправляют события на коррелятор. Высокая загрузка CPU на серверах и большое количество отправляемых пакетов с коллекторов приводит к общей деградации серверов со службой коррелятора по CPU и памяти (корреляторы перезапускаются каждые 5 минут). Пример поведения по метрикам:
Для решения проблемы были внесены изменения в точку назначения коррелятора, увеличив время ожидания соединения до 300-400 сек (задача найти этакий баланс между размером пачки и скоростью обработки/времени задержки). Множество мелких вставок данных от множества коллекторов в коррелятор хуже, лучше редкие и пачки объемней. Утилизация памяти на серверах со службой коррелятора выше 50% в течение для не поднималась.
Если CPU потребляются не на 100%, но при этом увеличивается время задержки обработки или нестабильное потребление ОЗУ, то можно:
- попробовать подобрать оптимальное (больше не значит производительней - используйте метод научного тыка) число рабочих процессов / workers для службы, количество воркеров должно быть идентичным для совместно работающих служб, например, на коллеккторе и его точке назначения - корреляторе.
- в случае когда соединений к коллектору становится очень много, то стандартное значение буфера (нуль = 1Мб) приводит к увеличению потребления оперативной памяти, так как память выделяется под каждое соединение. Рекомендуемое значение = размер события + небольшой запас в байтах (можно посмотреть в метриках в разделе нормализация - Raw & Normalized event size). Настройка выполняется на коллекторе "Транспорт - Дополнительные - Размер буфера")
Также полезным будет события от множества коллекторов отправлять в маршрутизатор событий (отдельный служба в KUMA) для реализации отдачи потока событий от одной точки.
Также это один из поводов дополнительно увеличить доступные коррелятору вычислительные ресурсы, либо разделить имеющиеся правила на N независимых групп, разместив каждую группу правил на отдельной группе корреляторов, если решение выше не сильно помогло.
---
### Профилирование нагрузки служб
Профилирование необходимо для более глубокого изучения проблем связанных с нагрузкой и ресурсами.
1\. Включить профилирование для сервиса, отредактируйте файл сервиса
```bash
/usr/lib/systemd/system/kuma--.service
```
В файле необходимо найти параметр `ExecStart=` и дописать в конце `--pprof` после этого выполнить `systemctl daemon-reload` и перезапустить (restart) сервис.
2\. Команда для сбора профиля данных по памяти
```bash
curl http://127.0.0.1:7211/debug/pprof/heap > /tmp/heap.out
```
3\. Команда для сбора профиля данных по процессору
```bash
curl http://127.0.0.1:7211/debug/pprof/profile?seconds=30 > /tmp/cpuprof.out
```
4\. Расшифровка профиля. Потребуется установленный Go из папки с бинарем go (загружаете для своей ОС [https://go.dev/dl/](https://go.dev/dl/)) запускается команда (в результате будет сгенерирована картинка с профайлером):
```bash
go tool pprof -png /tmp/heap.out
```
Пример результата:
Другие профили:
```
curl -o allocs.out http://127.0.0.1:7211/debug/pprof/allocs
curl -o block.out http://127.0.0.1:7211/debug/pprof/block
curl -o cmdline.out http://127.0.0.1:7211/debug/pprof/cmdline
curl -o goroutine.out http://127.0.0.1:7211/debug/pprof/goroutine
curl -o mutex.out http://127.0.0.1:7211/debug/pprof/mutex
curl -o threadcreate.out http://127.0.0.1:7211/debug/pprof/threadcreate
curl -o trace.out http://127.0.0.1:7211/debug/pprof/trace?seconds=30
```
---
### Мониторинг работы ядра в кластере Kubernetes
Посмотреть логи сервисов KUMA:
```bash
k0s kubectl logs -f -l app=core --all-containers -n kuma
```
На хосте контроллера можно посмотреть какие сервисы запущены:
```bash
k0s kubectl get pods --all-namespaces
```
По команде выше, в столбце NAMESPACE нам интересна строка kuma, в этой строке берем значение столбца NAME для просмотра конфигурации используем команду:
```bash
k0s kubectl get pod core-deployment-984fd44df-5cfk5 -n kuma -o yaml | less
```
Получить список рабочих узлов:
```bash
k0s kubectl get nodes
```
Получить расширенную инфу по рабочему узлу, в т.ч. потребление:
```bash
k0s kubectl describe nodes kuma-4.local
```
Зайти в командную строчку пода core-\*:
```bash
k0s kubectl exec --stdin --tty core-deployment-984fd44df-gqzlx -n kuma -- /bin/sh
```
Потребление ресурсов контейнеров внутри пода:
```bash
k0s kubectl top pod core-deployment-984fd44df-gqzlx -n kuma --containers
```
Для более удобного управления кластером используйте утилиту k9s - https://github.com/derailed/k9s
После установки ядра в кластере в папке установки прописывается конфиг, например, `/root/kuma-ansible-installer/artifacts/k0s-kubeconfig.yml`. Его надо “скормить” k9s командой: `export KUBECONFIG=/root/kuma-ansible-installer/artifacts/k0s-kubeconfig.yml`
Для персистентности переменной KUBECONFIG, необходимо выполнить команду:
```
echo "KUBECONFIG=/root/kuma-ansible-installer/artifacts/k0s-kubeconfig.yml" >> /etc/environment
```
Проверить переменные окружения можно командой:
```
export -p
```
Далее можно запустить утилиту (ее можно загрузить **[отсюда](https://box.kaspersky.com/f/9a7d035ee9724966987e/)**) просто указав на исполняемый файл `./k9s`
Небольшие подсказки по горячим клавишам k9s:
- `?` — Посмотреть хелп по командам
- `Shift+F` — Настроить порт форвардинг (например, для longhorn-ui)
- `:` — для ручного ввода команд, ESC для выхода
- `:events` — Смотреть события кубера
- `:pods` — Смотреть поды кубера (стандартное отображние)
Общий подход по траблшутингу k8s:
[](https://kb.kuma-community.ru/uploads/images/gallery/2023-11/npeimage.png)