Просмотр кода страницы Лучшие практики оптимизации затрат на сетевой мониторинг


= Лучшие практики оптимизации затрат на сетевой мониторинг =
Затраты на сетевой мониторинг могут быстро расти по мере расширения охвата устройств, добавления интерфейсов и выбора дополнительных наборов функций. Это руководство помогает выявить ключевые факторы затрат и принять целенаправленные меры для их снижения без ущерба для видимости.

Основной фактор затрат — приём метрик. Поскольку хранение включено бесплатно в течение первых 15 месяцев, а запросы включены бесплатно, ваш счёт определяется тем, что вы собираете, — а не тем, как долго вы это храните или как часто запрашиваете.

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

Чтобы применить этот подход на практике, это руководство проведёт вас через:

* '''Понимание затрат на приём''': как рассчитывается приём сетевого мониторинга и что определяет объём.
* '''Выявление основных факторов затрат''': как использовать запросы '''DQL''' для определения устройств, интерфейсов и наборов функций, вносящих наибольший вклад в ваши затраты, до расширения охвата.
* '''Снижение приёма на источнике''': как снизить затраты путём отключения неиспользуемых наборов функций и фильтрации интерфейсов, не требующих мониторинга.
* '''Поддержание контроля затрат со временем''': как проверять кардинальность и использовать распределение затрат, чтобы оставаться под контролем по мере роста вашей среды.

== Основные концепции ==
Вы должны понимать эти основные концепции перед подключением и оптимизацией сетевого мониторинга в '''Ключ-АСТРОМ'''.
{| class="wikitable"
!Термин
!Определение
|-
|Набор функций
|Набор функций — это группа ключей метрик, определённых в разделе '''Расширения'''. Вы можете ограничить мониторинг одним из наборов функций. Стандартный набор функций нельзя отменить; его метрики собираются всегда.
|-
|Рекомендуемый набор функций
|Набор функций, который значительно улучшает наблюдаемость устройства. Он не является обязательным и может быть отменён.
|-
|Интерфейс
|Интерфейс — это интерфейс сетевого устройства (физический или логический). Метрики разделяются по интерфейсам, создавая один временной ряд на интерфейс.
|}

== Понимание затрат ==

=== Как Ключ-АСТРОМ выставляет счёт за сетевой мониторинг ===
Приём метрик тарифицируется на основе количества сохранённых точек данных метрик. Увеличение количества точек данных метрик напрямую ведёт к более высокому потреблению.

Количество принимаемых точек данных метрик зависит от трёх факторов:

* Количество метрик
* Кардинальность
* Интервалы сбора

Любое увеличение этих факторов ведёт к более высокому потреблению. Чем больше наборов функций выбрано, тем больше метрик собирается. Чем больше устройств и интерфейсов отслеживается, тем больше временных рядов создаёт каждая метрика.

Например, метрика, разделённая по размерностям (таким как устройство и интерфейс), создаёт один временной ряд для каждой отдельной комбинации. Чем больше комбинаций, тем выше кардинальность и тем больше точек данных генерируется за цикл сбора.

Интервалы сбора фиксированы на 1 минуту для всех метрик сетевого мониторинга. Вы не можете настроить интервал сбора для этих расширений.

=== Выбирайте только нужные наборы функций ===
Метрики сетевого мониторинга организованы в наборы функций, которые охватывают базовые и расширенные потребности сетевой наблюдаемости. В дополнение к всегда включённому стандартному набору функций выбирайте только те наборы функций, которые вам нужны в данный момент. Это снижает начальные затраты и шум оповещений.

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

'''Управление наборами функций'''

# Перейдите в раздел '''Расширения'''.
# Выберите расширение и перейдите в '''Конфигурации мониторинга'''.
# Выберите конфигурацию мониторинга и выберите > '''Редактировать'''.
# Выберите нужные наборы функций.
# Выберите '''Сохранить''', чтобы сохранить конфигурацию.

=== Базовый мониторинг устройств и интерфейсов ===
Базовый мониторинг устройств и интерфейсов для всех интерфейсов в сети.

'''Стандартный набор функций всегда включён и не может быть отменён.'''

Собираемые метрики: 4 метрики на устройство + 2 метрики на собранный интерфейс.
{| class="wikitable"
!Метрика
!Описание
|-
|Sysuptime
|Время в тиках с момента запуска устройства (1/100 с)
|-
|CPU usage
|'''CPU''' (%)
|-
|Memory used
|Используемая память плоскости управления (КБ)
|-
|Memory free
|Свободная память плоскости управления (КБ)
|-
|Memory total
|Общая память плоскости управления (КБ)
|-
|Interface administrative status
|—
|-
|Interface operational status
|—
|}
Если нужны только данные плоскости управления ('''CPU''', память), вы можете удалить сбор интерфейсов с помощью фильтра.

'''Пример расчёта'''

При выборе только стандартного набора функций собираются 4 метрики на устройство и 2 метрики на интерфейс для всех интерфейсов, которые административно активны (то есть интерфейс включён, в отличие от «административно отключён» для отключённых интерфейсов).

В приведённом ниже примере используется сеть из 10 000 устройств:

* '''Этажный коммутатор''': подключает ПК сотрудников; 2 восходящих и 48 нисходящих интерфейсов; 26 интерфейсов административно активны.
* '''Коммутатор агрегации''': агрегирует трафик из нескольких местоположений.
* '''Пограничный маршрутизатор''': подключает удалённое местоположение к интернету; 2 восходящих (проводной и 5G резервный) и 2 нисходящих интерфейса.

{| class="wikitable"
!Тип устройства
!Количество
!Собираемые интерфейсы на устройство
|-
|Этажный коммутатор
|3 000
|26
|-
|Коммутатор агрегации
|1 000
|30
|-
|Пограничный маршрутизатор
|6 000
|4
|}
Оценочное потребление:

* '''Общее количество временных рядов: 304 000'''

   * Этажные коммутаторы: 168 000 = (3 000 × 4 метрики) + (3 000 × 26 интерфейсов × 2 метрики)
   * Коммутаторы агрегации: 64 000 = (1 000 × 4 метрики) + (1 000 × 30 интерфейсов × 2 метрики)
   * Пограничные маршрутизаторы: 72 000 = (6 000 × 4 метрики) + (6 000 × 4 интерфейса × 2 метрики)

* '''Объём приёма метрик в месяц: 304 000 × 60 мин × 24 ч × 30 дней = 13,1 млрд точек данных метрик'''

=== Объём трафика и базовое здоровье ===
Объём трафика на интерфейс и общеизвестные индикаторы здоровья для наиболее важных интерфейсов.

Выберите набор функций '''Interfaces'''. Этот набор функций обогащает общие сущности интерфейсов, собранные стандартным набором функций, новыми метриками; он не создаёт новые сущности.

Собираемые метрики: 7 метрик на собранный интерфейс.
{| class="wikitable"
!Ключ метрики
!Описание
|-
|Incoming traffic
|Количество байтов, входящих в интерфейс
|-
|Outgoing traffic
|Количество байтов, покидающих интерфейс
|-
|Inbound errors
|Количество входящих пакетов/блоков передачи с ошибками
|-
|Outbound errors
|Количество исходящих пакетов/блоков передачи с ошибками
|-
|Inbound discards
|Количество отброшенных входящих пакетов
|-
|Outbound discards
|Количество отброшенных исходящих пакетов
|-
|Interface last change
|Последняя временная метка (тики), когда изменился рабочий статус интерфейса
|}
'''Пример расчёта'''

При выборе стандартного набора функций и набора '''Interfaces''' собираются 4 метрики на устройство и 9 метрик на интерфейс для всех интерфейсов, которые административно активны. В этом сценарии отслеживаются только 5 наиболее важных интерфейсов на устройство с использованием механизма фильтрации интерфейсов, доступного для всех сетевых расширений.
{| class="wikitable"
!Тип устройства
!Количество
!Собираемые интерфейсы на устройство
|-
|Этажный коммутатор
|3 000
|5
|-
|Коммутатор агрегации
|1 000
|5
|-
|Пограничный маршрутизатор
|6 000
|5
|}
Оценочное потребление:

* '''Общее количество временных рядов: 490 000'''

   * Все типы устройств: 490 000 = (10 000 × 4 метрики) + (10 000 × 5 интерфейсов × 9 метрик)

* '''Объём приёма метрик в месяц: 490 000 × 60 мин × 24 ч × 30 дней = 21,2 млрд точек данных метрик'''

=== Метрики пакетов ===
Метрики пакетов и расчёт коэффициента ошибок на пакет.

Выберите набор функций '''Advanced Interfaces'''. Этот набор функций обогащает метрики, собранные стандартным набором функций и набором '''Interfaces''', новыми метриками; он не создаёт новые сущности.

Набор функций '''Advanced Interfaces''' предназначен для использования вместе с набором функций '''Interfaces'''. Его также можно использовать отдельно, если нужны только счётчики пакетов.

Собираемые метрики: 7 метрик на собранный интерфейс.
{| class="wikitable"
!Метрика
!Описание
|-
|Inbound Unicast
|Количество входящих одноадресных пакетов
|-
|Outbound Unicast
|Количество исходящих одноадресных пакетов
|-
|Inbound Multicast
|Количество входящих многоадресных пакетов
|-
|Outbound Multicast
|Количество исходящих многоадресных пакетов
|-
|Inbound Broadcast
|Количество входящих широковещательных пакетов
|-
|Outbound Broadcast
|Количество исходящих широковещательных пакетов
|-
|CRC errors
|Количество входных пакетов с ошибками циклической избыточности
|}
'''Пример расчёта'''

При выборе стандартного набора функций, наборов '''Interfaces''' и '''Advanced Interfaces''' собираются 4 метрики на устройство и 16 метрик на интерфейс. Собираются только важные интерфейсы, которые административно активны.

* Этажный коммутатор: 2 восходящих интерфейса
* Коммутатор агрегации: собираются все интерфейсы, так как каждый критичен для здоровья сети
* Пограничный маршрутизатор: 2 восходящих интерфейса (проводной и 5G резервный)

{| class="wikitable"
!Тип устройства
!Количество
!Собираемые интерфейсы на устройство
|-
|Этажный коммутатор
|3 000
|2
|-
|Коммутатор агрегации
|1 000
|30
|-
|Пограничный маршрутизатор
|6 000
|2
|}
Оценочное потребление:

* '''Общее количество временных рядов: 808 000'''

   * Этажные коммутаторы: 108 000 = (3 000 × 4 метрики) + (3 000 × 2 интерфейса × 16 метрик)
   * Коммутаторы агрегации: 484 000 = (1 000 × 4 метрики) + (1 000 × 30 интерфейсов × 16 метрик)
   * Пограничные маршрутизаторы: 216 000 = (6 000 × 4 метрики) + (6 000 × 2 интерфейса × 16 метрик)

* '''Объём приёма метрик в месяц: 808 000 × 60 мин × 24 ч × 30 дней = 34,9 млрд точек данных метрик'''

=== Устаревшие устройства или устройства с ограниченными ресурсами ===
Поддерживается только расширениями '''Generic Cisco''' и '''SNMP generic'''.

Мониторинг старых устройств или устройств с ограниченными ресурсами.

Выберите набор функций '''Interfaces 32-bit'''. Для устройств, где 64-битные счётчики интерфейсов не отвечают, этот набор функций предоставляет метрики, эквивалентные набору '''Interfaces'''.

32-битные счётчики интерфейсов подвержены переполнению и могут периодически выдавать неверные значения метрик в зависимости от объёма трафика.

Собираемые метрики: 2 метрики на собранный интерфейс.
{| class="wikitable"
!Метрика
!Описание
|-
|Octets received
|Общее количество октетов, полученных на интерфейсе, включая символы кадрирования
|-
|Octets transmitted
|Общее количество октетов, переданных с интерфейса, включая символы кадрирования
|}

=== Протоколы маршрутизации: OSPF и EIGRP ===
Поддерживается только расширением '''Generic Cisco'''.

Видимость протокола маршрутизации.

Выберите наборы функций '''OSPF''' и/или '''EIGRP''' в зависимости от ваших потребностей. Каждый набор функций охватывает один протокол маршрутизации, чтобы обеспечить гранулярность и учесть конфигурации устройств. Они используют специфичные для устройства сущности и создают одну сущность на устройство.

Собираемые метрики: 1 метрика на соседа.
{| class="wikitable"
!Метрика
!Описание
|-
|OSPF neighbor state
|Состояние отношения с этим соседом
|-
|EIGRP peer smooth round trip time
|Вычисленное сглаженное время кругового пути для пакетов к пиру и от него (мс)
|}

=== Мониторинг BGP ===
Поддерживается только расширением '''Generic Cisco'''.

Доступны два набора функций '''BGP''':

'''Вариант 1: BGP (стандартный)''' Выберите набор функций '''BGP''' для максимальной совместимости.

Собираемые метрики: 3 метрики на '''BGP'''-пира.
{| class="wikitable"
!Метрика
!Описание
|-
|BGP peer connection state
|Состояние подключения пира набора функций '''BGP'''
|-
|BGP peer admin status
|Желаемое состояние '''BGP'''-подключения
|-
|BGP peer established time
|Как долго (в секундах) этот пир находится в установленном состоянии или как давно он был последний раз установлен
|}
'''Вариант 2: Cisco BGP''' Выберите набор функций '''Cisco BGP''', чтобы охватить устройства Cisco, не поддерживающие общие '''BGP''' '''MIB'''.

Собираемые метрики: 5 метрик на '''BGP'''-пира.
{| class="wikitable"
!Метрика
!Описание
|-
|Cisco BGP peer established time
|Как долго (в секундах) этот пир находится в установленном состоянии или как давно он был последний раз установлен
|-
|Cisco BGP updates received
|Количество сообщений BGP UPDATE, полученных от пира
|-
|Cisco BGP updates sent
|Количество сообщений BGP UPDATE, отправленных пиру
|-
|Cisco BGP peer state
|Состояние подключения '''BGP'''-пира
|-
|Cisco BGP peer admin status
|Желаемое состояние '''BGP'''-подключения
|}

== Понимание приёма сетевых метрик ==
Перед оптимизацией приёма метрик определите, какие сетевые метрики принимаются и хранятся в '''Ключ-АСТРОМ''', и как они распределены по вашей организации.

Приведённые ниже запросы '''DQL''' можно выполнять в '''Ключ-АСТРОМ''' с помощью '''Notebooks''', '''Дашбордов''' или '''Workflows'''.

=== 1. Поиск источников сетевых метрик с высокой кардинальностью ===
Определите, какие источники сетевых метрик вносят наибольший вклад в кардинальность ваших метрик. Это помогает определить, какие источники метрик принимают больше всего метрик, чтобы целенаправить усилия по оптимизации туда, где они дадут наибольший эффект.

Команда <code>metrics</code> сканирует максимум 100 000 рядов. Для больших сред результаты могут быть усечены. Если вы достигли этого лимита, используйте запросы на следующем шаге, чтобы сузить область запроса.<pre>
metrics
| filter contains(dt.metrics.source, "f5")
    or contains(dt.metrics.source, "snmp")
    or contains(dt.metrics.source, "cisco")
    or contains(dt.metrics.source, "palo-alto")
    or contains(dt.metrics.source, "netscaler")
    or contains(dt.metrics.source, "meraki")
    or contains(dt.metrics.source, "forti")
    or contains(dt.metrics.source, "firewall")
    or contains(dt.metrics.source, "switch")
    or contains(dt.metrics.source, "alteon")
| summarize count = count(), by: { dt.metrics.source }
| sort count desc
</pre>

=== 2. Детализация по ключам метрик ===
Определив источники с высокой кардинальностью, отфильтруйте по этим атрибутам и изучите отдельные ключи метрик, чтобы увидеть, какие конкретные метрики вносят наибольший вклад в кардинальность.<pre>
metrics
| filter dt.metrics.source == "metric_source_name"
| summarize count = count(), by: {metric.key}
| sort count desc
</pre>

=== 3. Анализ конкретного ключа метрики ===
Используйте команду <code>timeseries</code> для получения кардинальности конкретного ключа метрики.<pre>
timeseries count(metric.key, scalar: true)
</pre>

== Оптимизация затрат ==
Снизьте затраты на сетевой мониторинг, уменьшив количество принимаемых точек данных метрик.

Оптимизацию можно применять на двух уровнях:

* '''На источнике''': в разделе '''Расширения''' настройте конфигурации мониторинга, чтобы удалить ненужные наборы функций или сократить количество отслеживаемых интерфейсов.
* '''В Ключ-АСТРОМ''': с помощью '''OpenPipeline''' выборочно отбрасывайте метрики, когда гранулярность набора функций недостаточна.

Приведённая ниже лучшая практика объясняет, как оптимизировать на источнике.

=== Отбрасывание метрик и снижение кардинальности метрик ===
Выбирайте интерфейсы на основе ваших сценариев использования. Для большинства корпоративных коммутаторов или маршрутизаторов удалённых офисов это означает восходящие интерфейсы и, опционально, критически важные интерфейсы, такие как видеоконференцсвязь или точки беспроводного доступа. Менее важные интерфейсы можно отслеживать через '''Syslog''' только на предмет доступности.

# Перейдите в раздел '''Расширения'''.
# Выберите расширение и перейдите в '''Конфигурации мониторинга'''.
# Выберите конфигурацию мониторинга и выберите > '''Редактировать'''.
# '''Отбрасывание метрик''': отключите ненужные наборы функций.
# '''Снижение кардинальности''': добавьте фильтр псевдонимов интерфейсов, чтобы собрать целевой набор интерфейсов (например, восходящие каналы и критические каналы WAN). По умолчанию съёмный фильтр собирает интерфейсы только в том случае, если они административно активны.
# Выберите '''Сохранить''', чтобы сохранить конфигурацию.

== Управление затратами ==

=== Непрерывная проверка сетевых метрик ===
Непрерывно проверяйте кардинальность и интервалы приёма в рамках ваших процессов '''CI/CD'''. Изменения в инструментировании или конфигурации могут непреднамеренно привести к чрезмерной кардинальности, слишком частому сбору метрик или сдвигам в поведении данных, что увеличивает затраты на приём.

Используйте '''Ключ-АСТРОМ''' для автоматизации этих проверок. Проверяйте запросы '''DQL''' через '''Site Reliability Guardian''' ('''SRG'''), интегрированный в рабочие процессы конфигурации, чтобы обнаруживать аномалии данных на ранней стадии. Оценки '''SRG''' могут предупредить вас, когда новый код или изменения конфигурации изменяют кардинальность, интервалы сбора или другие аспекты профиля телеметрии.

Непрерывная проверка позволяет командам исправлять инструментирование или корректировать конфигурацию сетевого мониторинга до того, как изменения попадут в производство.

=== Обеспечение распределения затрат ===
Распределяйте затраты на сетевой мониторинг по конкретным центрам затрат или продуктам. Перейдите в конфигурации мониторинга и добавьте атрибуты распределения затрат (<code>dt.cost.costcenter</code> или <code>dt.cost.product</code>) в качестве метаданных.

=== Проверка бизнес-ценности наборов функций ===
Чтобы минимизировать объём точек данных и снизить затраты, оставляйте только те наборы функций, которые поддерживают определённые сценарии использования.