# 22. Балансировщик: мониторинг и диагностика

[← Оглавление](../README.md) · [← Раздел 21: Балансировщик: конфигурация](21.md)

---

Балансировщик предоставляет набор команд для мониторинга аппаратного состояния, проверки прошивок, диагностики портов, анализа правил фильтрации и контроля групп балансировки. Все команды мониторинга выполняются в **операционном режиме**.

## 22.1. `show hardware info` — CPU, память, вентиляторы, БП, температура

Команда `show hardware info` с различными ключевыми словами отображает состояние аппаратных компонентов балансировщика:

| Команда                          | Описание                                    |
| -------------------------------- | ------------------------------------------- |
| `show hardware info cpu`         | Нагрузка на процессор (микросервер)         |
| `show hardware info memory`      | Состояние оперативной памяти                |
| `show hardware info fans`        | Состояние вентиляторов                      |
| `show hardware info power`       | Состояние блоков питания                    |
| `show hardware info temperature` | Показания температурных датчиков            |
| **`show hardware info all`**     | **Вся информация** по всем компонентам      |

Для быстрой проверки общего состояния платформы удобно использовать `show hardware info all` — команда выводит полную картину по всем аппаратным подсистемам.

> **Практический случай:** именно через мониторинг температурных датчиков была выявлена проблема с зависаниями балансировщиков весной — BMC некорректно считывал показания датчика, ошибочно определял перегрев и выключал микросервер (подробнее — в [разделе 20.4.3](20.md)).

## 22.2. `show mng if` — management-интерфейс

Команда `show mng if` отображает текущее состояние management-интерфейса:

- **IP-адрес**;
- **Маска подсети**;
- **Default gateway**;
- **Состояние интерфейса** (up/down).

Команда полезна для быстрой проверки параметров управления после настройки или перезагрузки устройства.

## 22.3. `show rdp firmware version` — версии прошивок, tries

Команда `show rdp firmware version` выводит полную информацию о состоянии прошивок:

```text
    Current active firmware: A

    Partition A:
      Status:  active
      Version: 2.4.1
      Tries:   0

    Partition B:
      Status:  inactive
      Version: 2.3.8
      Tries:   0
```

| Параметр          | Описание                                                              |
| ----------------- | --------------------------------------------------------------------- |
| **Current active**| Какой раздел (A или B) является текущим активным                      |
| **Status**        | `active` или `inactive` для каждого раздела                           |
| **Version**       | Номер версии прошивки в разделе                                       |
| **Tries**         | Счётчик попыток загрузки с данного раздела                            |

### Параметр Tries

В нормальном состоянии **Tries = 0**. Ненулевое значение означает, что балансировщик предпринимал неудачные попытки загрузки с этого раздела.

Если балансировщик **более 3 раз подряд** за ~20 минут не смог загрузиться с определённого раздела, прошивка считается **ненадёжной** и происходит автоматический rollback на другой раздел (подробнее — в [разделе 21.2.1](21.md)).

Для сброса счётчика используется команда `call rdp firmware reset-tries`.

## 22.4. Состояние портов и трансиверов: SFP-информация, DDM, статистика фреймов

### Информация о трансиверах

Для каждого порта можно вывести информацию об установленном трансивере:

```text
    show port <имя_порта> sfp
```

В выводе отображаются **все четыре линии** (lane) физического порта, даже если задействованы не все. Для каждой линии показаны:

| Параметр                  | Описание                                                   |
| ------------------------- | ---------------------------------------------------------- |
| **Тип трансивера**        | Оптика, DAC (медный кабель прямого подключения) и т.д.     |
| **Справочная информация** | Производитель, модель, серийный номер SFP                  |
| **Уровень сигнала (DDM)** | Мощность в децибелах (только для оптических трансиверов)   |

> **Примечание:** для медных DAC-кабелей (гидр) уровень сигнала **не отображается**, так как DDM-мониторинг применяется только к оптике. Если установлена оптическая гидра — значения мощности будут видны для каждой линии.

### Подробная статистика порта

Для каждого порта доступна детальная статистика на уровне фреймов:

```text
    show port <имя_порта> statistics
```

Вывод содержит подробную информацию:

- Количество полученных и отправленных фреймов;
- Фреймы с ошибками;
- Распределение по размерам фреймов;
- Счётчики различных типов ошибок.

Эта статистика полезна при диагностике проблем с физическим подключением — ошибки на уровне фреймов могут указывать на проблемы с кабелями, трансиверами или несовместимость оборудования.

## 22.5. Статистика правил фильтрации: счётчики пакетов/байт по каждому flow

По каждому правилу фильтрации (flow rule) балансировщик ведёт **счётчики пакетов и байт**, прошедших через данное правило:

```text
    show filters <имя_фильтра> flows <имя_правила>
```

В выводе отображается поле **statistics** с количеством пакетов и байт, которые были заматчены данным правилом.

### Применение для диагностики

Статистика правил — мощный инструмент диагностики. Типовые сценарии:

**Сценарий 1: Проверка наличия трафика**

Если оператор сообщает, что трафик определённого VLAN проходит через площадку, можно убедиться в этом по счётчикам соответствующего правила. Если счётчики растут — трафик действительно проходит через балансировщик.

**Сценарий 2: Исключение ТСПУ как причины проблемы**

Для диагностики можно создать **временное правило** с высоким приоритетом, которое матчит проблемный трафик (например, конкретный VLAN) и выполняет action `bypass`:

```text
    1. Создать правило: match VLAN <номер>, action bypass, высокий приоритет
    2. Применить конфигурацию (apply)
    3. Проверить: изменилось ли поведение трафика?
    4. Проверить счётчики правила: трафик проходит?
```

Если после создания bypass-правила проблема исчезла — причина в обработке на фильтрах, и нужно диагностировать дальше. Если проблема осталась, а счётчики показывают, что трафик проходит через правило — ТСПУ не является причиной.

> **Важно:** после завершения диагностики не забудьте **удалить временное правило** и применить конфигурацию.

## 22.6. Состояние группы балансировки

Команда для просмотра состояния группы балансировки:

```text
    show balance-group <имя_группы>
```

Вывод показывает общее состояние группы и статус каждой filter group внутри неё.

### 22.6.1. Статус filter groups: up/bypass

Каждая filter group (пара портов в сторону фильтра) может находиться в одном из двух состояний:

| Состояние    | Описание                                                            |
| ------------ | ------------------------------------------------------------------- |
| **up**       | Пара портов активна, трафик отправляется на фильтр                  |
| **bypass**   | Пара портов в режиме программного bypass — трафик перекладывается из LAN в WAN и наоборот, не отправляясь на фильтр |

В нормальном рабочем состоянии **все filter groups** должны находиться в состоянии `up`.

Переход в `bypass` происходит автоматически при потере заданного количества последовательных keep-alive пакетов (по умолчанию — 5). Обратный переход в `up` также автоматический — при получении достаточного количества ответных keep-alive пакетов.

### 22.6.2. Time of pass — время прохождения keep-alive пакета

Внутри каждой filter group отображается параметр **time of pass** — время прохождения keep-alive пакета через фильтр:

```text
    Filter Group fg1:
      Status:        up
      Time of pass:  27000 ns
```

| Параметр           | Описание                                                          |
| ------------------ | ----------------------------------------------------------------- |
| **Time of pass**   | Время (в наносекундах) между отправкой keep-alive пакета в LAN-порт и получением его из парного WAN-порта |
| **Time of receipt**| Внутренний timestamp — привязан к внутреннему счётчику, практической ценности для эксплуатации не имеет |

Механизм измерения:

1. Балансировщик отправляет keep-alive пакет в **LAN-порт** filter group;
2. Пакет проходит через фильтр (прозрачно, минуя DPI);
3. Балансировщик получает пакет из **WAN-порта** той же filter group;
4. Фиксируется разница во времени — это и есть **time of pass**.

В нормальном состоянии time of pass составляет порядка **20–30 микросекунд** (20 000–30 000 наносекунд).

> **Важно:** балансировщик **ничего не знает** о работе DPI на фильтрах. Keep-alive пакеты проходят через фильтр прозрачно, без обработки движком DPI. Параметр time of pass отражает исключительно время прохождения пакета через аппаратную часть фильтра.

Если пакеты начинают теряться — time of pass резко возрастает. После потери **5 последовательных** keep-alive пакетов filter group переводится в состояние `bypass`.

### Влияние загрузки фильтра на keep-alive

При высокой загрузке таблиц сессий фильтра (значительно выше рекомендованных 20%) фильтр может начать медленнее обрабатывать трафик и **дропать пакеты**, в том числе keep-alive. Это может привести к «флапингу» filter group — циклическому переключению между `up` и `bypass`.

В такой ситуации оператор **не почувствует флапов** на физических линках (программный bypass не затрагивает физику), но:

- Небольшое количество пакетов может теряться при каждом переключении;
- Часть трафика временно не фильтруется.

Система мониторинга должна отслеживать загрузку таблиц на фильтрах и сигнализировать о приближении к пороговым значениям **до** того, как начнутся проблемы с keep-alive.

## 22.7. Программный байпас: индивидуально для каждой группы портов

Программный bypass на балансировщике может управляться как **автоматически** (по результатам keep-alive), так и **вручную**:

```text
    call balance-group <имя_группы> software-bypass <режим>
```

| Режим        | Описание                                                            |
| ------------ | ------------------------------------------------------------------- |
| **bypass**   | Принудительно перевести группу в режим программного bypass          |
| **primary**  | Вернуть группу в нормальный режим работы (трафик на фильтры)       |

### Индивидуальный bypass для каждой filter group

Ключевое преимущество программного bypass — его **гранулярность**. Bypass включается **индивидуально для каждой filter group**, а не для всей группы балансировки целиком:

```text
    Filter Group fg1: up        ← трафик идёт на фильтр
    Filter Group fg2: bypass    ← трафик байпасится (проблема с этой парой портов)
    Filter Group fg3: up        ← трафик идёт на фильтр
    Filter Group fg4: up        ← трафик идёт на фильтр
```

Это означает, что при проблеме с одним интерфейсом фильтра **не фильтруется** только часть трафика, проходящая через данную пару портов. Весь остальной трафик продолжает нормально обрабатываться.

### Преимущества перед переключением на байпасе

| Критерий                   | Bypass на оптическом байпасе          | Программный bypass на балансировщике    |
| -------------------------- | ------------------------------------- | --------------------------------------- |
| **Флап линков оператора**  | Да — при каждом переключении          | **Нет** — физические линки не затрагиваются |
| **Гранулярность**          | Вся площадка целиком                  | **Каждая пара портов** индивидуально    |
| **Согласование с оператором** | Требуется (работы, окна обслуживания) | **Не требуется** — оператор ничего не замечает |
| **Последствия**            | Весь трафик не фильтруется            | Не фильтруется **только часть** трафика |

> **Опыт эксплуатации:** такое поведение было опробовано при тестировании эшелонированной системы в Сургуте. Вместо переключения трафика на оптическом байпасе (что вызывает флапы линков и недовольство оператора) использовался программный bypass на балансировщике — одной командой трафик уводился с фильтров без каких-либо видимых последствий для оператора.

### Автоматическое восстановление

При автоматическом bypass (по результатам keep-alive):

- Если filter group потеряла keep-alive — автоматически переводится в `bypass`;
- Когда интерфейс восстанавливается и keep-alive снова проходят — filter group **автоматически возвращается** в рабочее состояние (`up`);
- Перебалансировки трафика **не происходит** (при выключенной перебалансировке) — остальные filter groups продолжают работать без изменений.

### Проверка Bypass Watchdog (пилотный проект, Урал)

Для уральского проекта с байпасами GL Sun доступна дополнительная диагностика связи между балансировщиком и байпасом:

| Состояние     | Описание                                                         |
| ------------- | ---------------------------------------------------------------- |
| **active**    | Группа балансировки активна, heartbeat-пакеты отправляются на байпас, байпас отвечает |
| **disconnected** | Группа балансировки неактивна или связь с байпасом потеряна — heartbeat-пакеты не отправляются |

Связь с байпасом GL Sun осуществляется по **протоколу TCP**. При переходе группы балансировки в неактивное состояние отправка heartbeat прекращается.

> **Примечание:** данная диагностика **не актуальна** для федерального проекта с байпасами Silicom, где heartbeat генерируется и проверяется самим байпасом.

---

[← Оглавление](../README.md) · [← Раздел 21: Балансировщик: конфигурация](21.md) · [Раздел 23: Распознавание протоколов (DPI Engine) →](23.md)