6. Наблюдаемость#

Ночью у основного маршрутизатора провайдера бесшумно вышел из строя модуль вентилятора. Никаких оповещений не поступило. Подсистема управления температурой на линейных картах обнаружила повышение температуры и начала снижать тактовую частоту пересылочных ASIC для защиты оборудования. Пропускная способность на производственном транзитном канале упала на 40%. Система мониторинга ничего не увидела: тепловые датчики, которые она опрашивала, были установлены на шасси супервайзера, а не на отдельных линейных картах. SNMP-опросы выполнялись каждые пять минут и сообщали об устройстве как о работоспособном. Счётчики интерфейсов показывали сниженную пропускную способность, но никакого порога для такого паттерна не было настроено, потому что канал всегда был значительно ниже максимальной ёмкости.

Три часа спустя нарушение SLA клиента создало тикет. Дежурный инженер подключился к маршрутизатору по SSH, обнаружил в локальном журнале тревог информацию об отказе вентилятора и перезапустил модуль. Контроллер вентилятора перезапустился, и дросселирование по температуре прекратилось в течение нескольких минут. Трафик восстановился. Нарушение SLA было задокументировано, клиент уведомлён, инцидент закрыт.

Первопричина так и не была установлена. К моменту начала расследования маршрутизатор уже несколько часов работал в штатном режиме. Температурных данных с линейных карт не было, записей о событии дросселирования не было, и никакой возможности соотнести снижение пропускной способности с отказом вентилятора в какой-либо системе мониторинга тоже не было. В отчёте об инциденте был сделан вывод: «предполагаемая аппаратная проблема, устранена аппаратным сбросом». Через шесть месяцев то же самое произошло на другом маршрутизаторе.

Проблема была не в отсутствующем пороге. У команды были тысячи порогов. Проблема была в неполном охвате: система мониторинга собирала данные из источников, которые всегда опрашивались, а не из каждого источника, способного влиять на поведение устройства. Тепловые данные с линейных карт были доступны через gNMI на всех трёх типах шасси в парке. Никто не настроил путь сбора, потому что никто не написал инструкцию для случая отказа вентилятора.

Традиционный сетевой мониторинг следит за сломанными вещами: интерфейс поднят? CPU выше 90%? Этот сервис отвечает? Это полезно, но реактивно: вы наблюдаете за сбоем.

Наблюдаемость - это другое. Она даёт понимание почему что-то ломается или вот-вот сломается. Это не просто «устройство недоступно», а «почему оно недоступно, что ломается из-за этого, каков бизнес-эффект». При сетевой автоматизации наблюдаемость становится петлёй обратной связи: вы наблюдаете что-то, система это обнаруживает, решает, как реагировать, принимает меры и проверяет, сработало ли исправление. Этот повторяющийся цикл называется «замкнутой автоматизацией».

В этой главе рассматривается всё необходимое для понимания происходящего в вашей сети: какие данные собирать, как их собирать, как хранить, как создавать оповещения и как отображать их для людей так, чтобы это реально помогало принимать решения.

Здесь мы рассматриваем два строительных блока: Collector и Observability, поскольку они тесно связаны между собой.

Используете ли вы традиционную монолитную платформу (SolarWinds, LibreNMS), облачный сервис (Datadog, New Relic) или собираете собственный стек из компонентов с открытым исходным кодом (Prometheus, Grafana и т.д.), базовая архитектура одинакова. Понимание этих паттернов помогает выбрать правильный подход для вашего масштаба и вашей команды.

Этот раздел находится под сильным влиянием книги Modern Network Observability издательства Packt, которую я написал в соавторстве с Дэвидом Флоресом и Джошем Вандераа. Если вы хотите получить практический опыт и изучить реализацию на стеке TPG (Telegraf-Prometheus-Grafana) и других инструментах, я настоятельно рекомендую её.

6.1. Основы#

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

6.1.1. Контекст#

Вы, вероятно, уже мониторите свою сеть. Используете Simple Network Management Protocol (SNMP), смотрите на System Logging Protocol (Syslog), имеете дашборды, показывающие загрузку каналов. Это мониторинг: он говорит вам, работает ли всё.

Но автоматизации нужно больше. Когда ваша сеть изменяется (потому что её изменила автоматизация), вам нужно немедленно знать, не сломало ли это что-то. Когда вы получаете оповещение, вам нужен контекст: каких клиентов это затрагивает? Какие сервисы отказали? Каков радиус поражения? Традиционный мониторинг даёт вам тревоги. Автоматизации нужна аналитика.

Вот ключевое различие:

• Мониторинг: интерфейс поднят? CPU высокий? Простые вопросы да/нет.
• Наблюдаемость: почему интерфейс упал? На что это влияет? Как это исправить автоматически? Что произошло исторически, что привело к этому?

Наблюдаемость питает автоматизацию. Ваша система наблюдает сеть, обнаруживает проблемы, решает, что делать, принимает меры и проверяет, сработало ли исправление. Этот повторяющийся цикл и называется «замкнутой автоматизацией».

Традиционные инструменты мониторинга (большие монолитные, вроде SolarWinds) пытаются делать всё в одном продукте. Это можно заставить работать, но часто вы платите за функции, которые вам не нужны, и ограничены в функциях, которые нужны. Альтернатива - построение наблюдаемости из компонентов: выбрать сборщик, подходящий для ваших устройств, хранилище, масштабирующееся с вашими данными, оповещение, вписывающееся в рабочие процессы автоматизации. Это сложнее собрать, но значительно гибче.

В этой главе рассматриваются оба подхода и паттерны, работающие независимо от выбора.

Первый выбор касается того, как работает платформа:

• Монолитная (SolarWinds, LibreNMS): один продукт делает всё. Установить, настроить и работать. Хорошо, если ваша сеть прямолинейна и у вас нет DevOps-опыта. Плохо, если вам нужна гибкость или сеть нестандартная: вы привязаны к их модели.

• Облачная SaaS (Datadog, New Relic, Kentik): они запускают всё за вас. Быстро развернуть, никаких инфраструктурных головных болей, красивые дашборды из коробки. Но вы платите ежемесячно в зависимости от объёма, ваши данные хранятся на их серверах (важно для некоторых режимов соответствия), и когда вы упираетесь в их ограничения - вы в тупике. Я видел команды, тратящие $50K/месяц на SaaS-наблюдаемость и недоумевающие, почему финансовый директор недоволен.

• Самостоятельная сборка (Prometheus + Grafana, или стек Telegraf-Prometheus-Grafana (TPG)): полная гибкость, нет привязки к поставщику, лучшая экономика при масштабировании. Но теперь вы сами эксплуатируете базы данных, очереди сообщений и инфраструктуру сборщиков. Если у вас нет людей, умеющих это поддерживать, вы потратите больше времени на починку системы наблюдаемости, чем на починку сети.

Настоящий вопрос: есть ли у вас команда для этого? Если да - стройте. Если нет - покупайте. Не обманывайте себя насчёт того, к какой категории относитесь.

После этого выбора возникают ещё два вопроса:

• Где это будет работать? На собственных серверах (вы всё контролируете, но сами эксплуатируете), в облаке (они эксплуатируют, но ваши данные покидают сеть) или гибридно (часть локально, часть в облаке)?
• Какова модель затрат? За устройство? За принятую метрику? Фиксированная подписка? Эти решения быстро набирают вес, когда вы собираете миллионы точек данных в минуту.

6.1.2. Цели#

Вашей системе наблюдаемости необходимо делать семь вещей:

1. Наблюдать за всем автоматически. Подключилось новое устройство? Оно должно начать передавать данные без ручной регистрации. Новый сервис вышел в онлайн? За ним уже наблюдают. Для этого требуется интеграция с Источником истины, чтобы наблюдаемость знала, что существует.

2. Работать с гетерогенными средами при хорошем качестве данных. В вашей сети, вероятно, есть Cisco, Arista, Juniper, облачные провайдеры, Linux-серверы, контейнеры. У каждого свои способы передачи данных. И забудьте про 5-минутные интервалы: при внесении изменений автоматизацией нужны данные в почти реальном времени.

3. Коррелировать данные между уровнями. Сервер работает медленно. Это перегрузка сети или проблема с базой данных? Нужны данные с сетевых устройств, серверов, приложений - все говорящие на одном языке, чтобы можно было прослеживать связи между ними.

4. Масштабироваться без деградации. Сети растут. При сборе миллиона метрик в секунду традиционные архитектуры разрушаются. Нужны системы, спроектированные для масштаба с первого дня.

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

6. Обнаруживать проблемы и устранять их автоматически. В большинстве случаев автоматизация должна реагировать на проблемы без ожидания человека. Только когда автоматизация не может разобраться - кого-то нужно уведомить. И это оповещение должно объяснять, что не так, а не просто показывать сырые числа.

7. Показывать людям то, что им нужно видеть. Дашборд бесполезен, если он показывает слишком много или не то. Дайте команде сетевых операций их представление, бизнесу - его, инженерам - своё. Каждый человек получает то, что помогает ему выполнять работу.

6.1.3. Столпы#

Каждая цель требует конкретных строительных блоков. Вот что нужно:

1. Знать, за чем наблюдать. В Источнике истины есть все устройства, сервисы, учётные данные. Наблюдаемость должна автоматически получать эти данные, чтобы сборщики знали, что мониторить. Когда вы добавляете устройство в SoT - мониторинг включается автоматически.

2. Собирать данные эффективно. Нужны несколько методов сбора: Simple Network Management Protocol (SNMP) для старого оборудования, потоковая передача gRPC Network Management Interface (gNMI) для современных устройств, System Logging Protocol (Syslog) для событий, потоки (NetFlow, IP Flow Information Export (IPFIX)) для трафика, возможно захват пакетов для глубокого анализа. Разные инструменты, разные скорости, разное богатство данных. Хорошая новость: не нужно выбирать только один.

3. Нормализовать всё. Метрики Arista выглядят иначе, чем метрики Cisco, которые выглядят иначе, чем метрики облачных провайдеров. Логи - неструктурированный текст, потоки - бинарные данные. Нужен уровень, переводящий всё это в общий язык и добавляющий контекст (какое устройство, какой клиент, какой сервис).

4. Надёжно перемещать данные в масштабе. Традиционные конвейеры мониторинга последовательны: сборщик - процессор - хранилище. В масштабе это узкое место. Нужны шины сообщений и потоковые платформы, разделяющие каждый этап для независимого масштабирования.

5. Хранить данные умно. Данные временных рядов (метрики) требуют оптимизированных баз данных. Логи - другого решения. Нужно выполнять запросы к миллионам точек данных за миллисекунды. Не все базы данных равны в этом.

6. Превращать данные в действия. Сырые метрики не запускают автоматизацию. Нужны правила: «если CPU > 90%, проверить, не плановое ли это обслуживание, если нет - выполнить эти шаги». И эти правила поступают в оркестратор автоматизации или систему оповещения.

7. Отображать данные визуально. Данные бесполезны, если на них никто не смотрит. Нужны дашборды, но умные: разные представления для разных людей, возможность детализации, отображение трендов и сравнений.

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

6.1.4. Область применения#

В дополнение к целям, введённым выше, есть другие аспекты, также входящие в ответственность Наблюдаемости:

• Различные уровни наблюдения, адаптированные к перспективам пользователей (технической, операционной, бизнесовой)
• Интеграция с CI/CD конвейерами, обеспечивающая обратную связь для автоматического тестирования и валидации
• Наблюдаемость самой системы автоматизации (мета-мониторинг Collectorов, процессоров и систем оповещения)

Однако с другой стороны, есть функции, принадлежащие другим компонентам архитектуры:

• Определение сетевого намерения: как должна выглядеть сеть (ответственность Намерения/SoT)
• Выполнение сетевых изменений: фактическая реализация исправления (ответственность Executor)
• Оркестрация сложных рабочих процессов: координация многошаговых исправлений в нескольких системах (ответственность Orchestrator)

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

Переход к современной наблюдаемости требует тщательного планирования. Не рассматривайте это как простую замену одного инструмента мониторинга другим; нужно трансформировать мышление. С большей мощью приходит большая ответственность, и вам предстоит больше выбирать и настраивать.

После этого начального введения, раскрывающего ключевые концепции блока Наблюдаемости, перейдём к каждой функциональной возможности.

6.2. Функциональные возможности#

Семь целей и столпов реализуются через семь основных функциональных возможностей. Каждая функциональная возможность соответствует цели и поддерживающему её столпу, создавая прямую цепочку от бизнес-требований до технической реализации:

1. Инвентарь: потребляет намерение из SoT и предоставляет метаданные, списки устройств и цели сбора всем нижестоящим компонентам.
2. Collector: получает наблюдаемые данные из сети с использованием нескольких протоколов и методов сбора - как вытягивающих (опрос), так и получающих (потоковая передача).
3. Процессор: нормализует гетерогенные данные в общую схему и обогащает их контекстными метаданными (теги, связи, бизнес-контекст), а также выполняет другие операции с данными.
4. Распределение: разделяет производителей данных от потребителей с использованием распределённых асинхронных паттернов. Надёжно перемещает данные и события от Collectorов через процессоры в системы персистентности и оповещения.
5. Персистентность: хранит нормализованные данные в базах данных, оптимизированных для эффективного приёма, хранения и запросов в масштабе.
6. Оповещение: анализирует сохранённые данные с использованием гибких правил и порогов для обнаружения интересующих условий, генерируя события, запускающие внешние системы (автоматизацию или уведомления людей).
7. Визуализация: отображает наблюдаемые данные и сработавшие события в виде дашбордов, отчётов и других визуальных интерфейсов, адаптированных для разных аудиторий и вариантов использования.

graph LR

    %% --- Subgraphs ---
    subgraph Goals
        direction TB
        A1[Observe all the network with minimal human effort]
        A2[Support heterogeneous network environments with enough data and accuracy]
        A3[Observe data from different IT layers with context]
        A4[Handle massive-scale network scenarios]
        A5[Offer access to observability data for sophisticated analysis in near real-time]
        A6[Be proactive to detect network issues and reduce time to recover]
        A7[Create tailored user-oriented visualizations]
    end

    subgraph Pillars
        direction TB
        B1[Close integration with SoT to understand what needs to be monitored]
        B2[Ability to collect data via different protocols supporting very frequent/on-demand updates]
        B3[Normalization of heterogeneous data with contextual metadata for richer analysis]
        B4[Scalable data distribution systems to support scale-out architectures]
        B5[Persistence layer supporting time-series data and powerful query languages]
        B6[Flexible rule definitions and routing scenarios with external system integration]
        B7[Custom visualizations and integration of multiple data stores]
    end

    subgraph Functionalities
        direction TB
        C1[Inventory]
        C2[Collector]
        C3[Processor]
        C4[Distribution]
        C5[Persistence]
        C6[Alerting]
        C7[Visualization]
    end


    %% --- Row connections ---
    A1 --> B1 --> C1
    A2 --> B2 --> C2
    A3 --> B3 --> C3
    A4 --> B4 --> C4
    A5 --> B5 --> C5
    A6 --> B6 --> C6
    A7 --> B7 --> C7

    %% --- Row gradient classes ---
    classDef row1 fill:#eef7ff,stroke:#4a90e2,stroke-width:1px;
    classDef row2 fill:#ddeeff,stroke:#4a90e2,stroke-width:1px;
    classDef row3 fill:#cce5ff,stroke:#4a90e2,stroke-width:1px;
    classDef row4 fill:#b3d8ff,stroke:#4a90e2,stroke-width:1px;
    classDef row5 fill:#99ccff,stroke:#4a90e2,stroke-width:1px;
    classDef row6 fill:#80bfff,stroke:#4a90e2,stroke-width:1px;
    classDef row7 fill:#66b2ff,stroke:#4a90e2,stroke-width:1px;

    %% --- Apply classes per row ---
    class A1,B1,C1 row1;
    class A2,B2,C2 row2;
    class A3,B3,C3 row3;
    class A4,B4,C4 row4;
    class A5,B5,C5 row5;
    class A6,B6,C6 row6;
    class A7,B7,C7 row7;

Эти компоненты можно рассматривать как конвейер данных или ETL (Extract, Transform and Load — извлечение, преобразование и загрузка), как показано на следующей диаграмме:

flowchart TB
    A[Network] --> B[Collector]

    subgraph Observability
       direction LR
       B --> C[Distribution] -->  D[Persistence]
       B -.-> P[Processing]
       C -.-> P
       D -.-> P
       D --> E[Alerting]
       E -.-> P
       D --> G[Visualization]
       X[Inventory] -.-> B
       X -.-> G
       X -.-> P
    end

    E -.-> F[Orchestration]
    G -.-> H[Presentation]
    Y[SoT] -.-> X

Рисунок 1: Конвейер наблюдаемости.

6.2.1. Инвентарь#

Компонент инвентаря отвечает на простой вопрос: за чем мне следует наблюдать?

Эти данные у вас уже есть: они находятся в вашем Источнике истины. Там есть имена устройств, IP-адреса, что они из себя представляют, активны ли они, учётные данные. Не дублируйте это вручную. Получайте автоматически.

Что нужно от вашего SoT:

• Уникальное имя или ID для каждого устройства или сервиса (чтобы знать, что это то устройство, которое вы думаете)
• Как до него добраться: IP-адрес, имя хоста и учётные данные (если нужно активно получать данные)
• Что это такое: тип и производитель (чтобы знать, какие Collectorы с ним работают)
• Активно ли оно: запланировано, активно или выводится из эксплуатации (чтобы не создавать оповещения при ожидаемых простоях)

Помимо основного, может потребоваться:

• ОС или специфика устройства: некоторые устройства используют разные протоколы, некоторые старые и требуют специальной обработки
• Контекст: кто владелец, где расположено, от каких клиентов зависит (полезно для фильтрации оповещений и дашбордов)

Зачем автоматизировать это вместо ручного ведения списка? Потому что люди забывают обновлять списки. Устройства добавляются, никто не сообщает мониторингу, и внезапно теряется видимость. Но если наблюдаемость читает из SoT, то при добавлении устройства туда оно автоматически начинает мониториться.

Вытягивание или получение?

• Вытягивание (Pull): наблюдаемость периодически проверяет SoT на обновления. Просто, но если что-то меняется в середине интервала - вы это пропустите.
• Получение (Push): когда SoT меняется, он автоматически сигнализирует наблюдаемости (webhooks, шина сообщений). Быстрее и надёжнее.

Если у вас хорошие данные в SoT и реальная интеграция (не ручное копирование), инвентарь становится автоматическим и вы никогда не упускаете наблюдение за новым устройством.

6.2.2. Сборщики#

Данные должны откуда-то поступать. Collectorы - это мосты между вашей сетью и платформой Observability. Они отвечают за получение (или приём) данных от устройств и их передачу в конвейер. Без эффективных Collectorов всё нижестоящее бесполезно.

С точки зрения того, кто управляет потоком данных, существует два принципиальных подхода:

• Пассивный или получение (Push): ваши устройства отправляют данные сборщику. Например, syslog-серверы получают сообщения от маршрутизаторов или IPFIX-коллекторы слушают записи о потоках. Устройство решает, что отправлять и когда.
• Активный или опрос (Poll): Collector запрашивает данные у устройств. Он подключается к каждому устройству и получает информацию через Simple Network Management Protocol (SNMP), gRPC Network Management Interface (gNMI), Representational State Transfer (REST) Application Programming Interface (API) или подписывается на потоковые данные. Collector в контроле: он решает, что запросить и когда.

Сборщики также можно классифицировать по способу развёртывания:

• Без агентов: нет ПО для установки на устройства. Центральный сервер сборщика (обычно запущенный где-то ещё) подключается к каждому устройству индивидуально. Просто для начала, но может стать узким местом при масштабировании.
• На основе агентов: установка небольшого агента на каждое устройство или сервис. Агенты отправляют данные в центральное место или получают их напрямую из локальных источников. Более распределённо, проще масштабировать, но больше движущихся частей для управления.

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

• Плоскость управления: состояние устройства, чтение данных о конфигурации, журналах или сетевой статистике. Протоколы в этой группе: Simple Network Management Protocol (SNMP), System Logging Protocol (Syslog), gRPC Network Management Interface (gNMI), NETCONF, RESTCONF.
• Плоскость контроля: здесь работают распределённые протоколы, определяющие пересылку пакетов в сети, такие как таблицы пересылки уровня 2 или 3. Несколько примеров протоколов плоскости контроля: OSPF, IS-IS, BGP. Эти плоскости можно наблюдать с помощью таких техник, как Ping или Traceroute, или протоколов телеметрии, таких как BMP.
• Плоскость пересылки: здесь перемещаются пакеты (например, через сетевые интерфейсы), и это наиболее требовательная плоскость с точки зрения объёма и скорости данных. Естественно, при наблюдении за ней также критически важно не влиять на основную цель плоскости - пересылку пакетов. В эту группу входят TcpDump, IPFIX, sFlow, Netflow, Cisco SLA, PSAMP и eBPF.
• Внешние данные: эта категория включает всё, что не специфично для сетевых устройств. Например, информация от провайдера канала и контактные данные для конкретного интерфейса из внешней системы управления активами или физических IoT-датчиков могут входить в это широкое поле.

flowchart TB
    subgraph Network Device/Service
        direction TB
        A[Management Plane]
        B[Control Plane]
        C[Forwarding Plane]
        A --> B
        B --> C
    end

    D[External data]

Рисунок 2: Область применения сборщика.

Прекратите парсить вывод Command Line Interface (CLI). Я знаю, что вы это делаете. Мы все это делали. Но сейчас 2026 год, и каждый крупный производитель поддерживает полноценную телеметрию.

Парсинг CLI хрупок (производители меняют формат вывода), медленен (парсинг экрана и текста дорогостоящ), ненадёжен (случайные тайм-ауты команд) и плохо масштабируется. Если ваше устройство настолько старое, что у него есть только CLI, либо замените его, либо смиритесь с ограниченной наблюдаемостью. Не стройте весь стек мониторинга вокруг наименьшего общего знаменателя.

В конечном счёте всё сводится к двум ключевым вопросам о том, что вы собираете:

• Что собирать: метрики? Логи? Записи о потоках? У каждого разные модели данных. SNMP имеет MIB, современное оборудование говорит через gNMI, приложения используют OpenTelemetry. Мечта - универсальный стандарт, позволяющий коррелировать данные по всему, но его ещё нет. Поэтому, возможно, придётся строить собственный трансляционный уровень, превращающий все эти форматы в нечто согласованное (именно это делает слой обработки).
• Как получить: какой протокол? SNMP стар, но стабилен, gNMI современен и непрерывно передаёт данные, IPFIX захватывает реальные потоки. Зависит от того, что вы пытаетесь наблюдать.

Следующая таблица суммирует, что можно собирать, и доступные инструменты:

Таблица 1: Данные и протоколы для сбора.

Для более глубокого понимания различных вариантов обратитесь к книге Modern Network Observability.

Сбор сетевых данных применим к центрам обработки данных, магистральным сетям ISP, облачным сетевым сервисам, интерфейсам ядра Linux или сырым пакетам. Зависит от вашей среды.

Вот ключевое правило: прежде чем решать, что собирать, начните с проблемы, которую пытаетесь решить. Это решение определяет всё остальное. Вы обнаруживаете насыщение интерфейсов? Мониторите сходимость BGP? Отслеживаете DDoS-трафик? Ваша проблема определяет, какие данные нужны и как часто.

Для увеличения частоты сбора данных (в некоторых случаях интересной) или конвергенции методов сбора - вот несколько паттернов, получающих всё большее распространение:

Потоковая телеметрия

Устройства непрерывно передают данные с использованием моделей YANG. Вы настраиваете подписки, и данные поступают в реальном времени. Два варианта:

• Dial-In: сборщик просит устройство начать потоковую передачу (инициирует сборщик).
• Dial-Out: устройство предварительно настроено на передачу к вам (инициирует устройство).

Значительно меньше задержки, чем при опросе, а устройство сохраняет контроль над потоком.

flowchart TB
    A[Collector]
    B[Device]
    A -.->|Dial-In| B
    B -->|Streaming| A
    B -.->|Dial-Out| A

Рисунок 3: Потоковая телеметрия.

Метрики, доступные через Hypertext Transfer Protocol (HTTP)

HTTP-скрейпинг (метрики на основе вытягивания) прост и хорошо масштабируется. SNMP делает это, но всё чаще сетевые ОС предоставляют метрики напрямую через Hypertext Transfer Protocol (HTTP) в формате Prometheus. Проще для Collectorов, не нужен специальный разбор Management Information Base (MIB) Simple Network Management Protocol (SNMP). SONiC, Cumulus, Arista EOS и другие предоставляют метрики таким образом.

Таблица 2: Метрики, доступные через HTTP.

Подход скрейпинга обеспечивает малую задержку и метрики почти в реальном времени, богатые метки и сбор на основе вытягивания (централизованный контроль частоты/тайм-аута), хорошо интегрируясь с наблюдаемостью облачного масштаба.

OpenTelemetry

OpenTelemetry - это нейтральный к производителю стандарт и набор инструментов для сбора, обработки и экспорта данных телеметрии. Думайте о нём как об общем языке телеметрии и конвейере, унифицирующем метрики, логи и трейсы в сетях, системах и приложениях.

Он не заменяет сетевые протоколы, такие как SNMP, NetFlow, gNMI или BMP. Вместо этого он стандартизирует представление и транспортировку телеметрии после сбора.

В традиционном сетевом мониторинге модели данных разнородны и используют специфичные для производителя схемы и именование, что затрудняет корреляцию между уровнями (сеть - система - приложение). В противовес этому OpenTelemetry помогает, предоставляя:

• Общую модель данных для метрик, логов и трейсов
• Стандартный транспортный протокол (OpenTelemetry Protocol (OTLP)) поверх gRPC Remote Procedure Call (gRPC) или Hypertext Transfer Protocol (HTTP)
• Единый конвейер обработки для нескольких типов сигналов

Grafana Alloy или Telegraf - примеры Collectorов, реализующих OpenTelemetry Protocol (OTLP). Они собирают данные из разных экспортеров и передают в разные бэкенды: метрики (совместимые с Prometheus Time Series Database (TSDB)), логи (Loki, Elasticsearch, ClickHouse) и трейсы (Tempo, Jaeger).

Это подводит нас к финальному соображению об общей структуре современных подключаемых сборщиков со стадиями Input, Processor и Output. Например, в Telegraf OTLP является вариантом для плагина вывода.

OpenTelemetry как архитектурный выбор

Принятие OpenTelemetry - это не просто решение об инструментах: это архитектурное решение о том, как унифицировать конвейер наблюдаемости. Выбор между двумя подходами:

Нативный для протоколов: каждый тип сигнала проходит через свой нативный протокол от начала до конца (gNMI в Prometheus, syslog в Elasticsearch, NetFlow в ClickHouse). Каждый конвейер оптимизирован для своего сигнала. Ценой является наличие нескольких независимых конвейеров без общей модели данных, что делает корреляцию между типами сигналов дорогостоящей.

Нативный для OTel: сигналы преобразуются в OpenTelemetry Protocol (OTLP) как можно раньше и проходят через единый конвейер в унифицированный бэкенд. Корреляция между метриками, логами и трейсами естественна, поскольку они разделяют модель данных. Ценой является то, что поддержка OTel в сетевых устройствах ещё развивается: большинство производителей не генерируют OTLP нативно, требуя адаптерного уровня (gNMI в OTel, SNMP в OTel), добавляющего операционную сложность.

Практическая рекомендация для сред сетевой автоматизации сегодня: принять OTel для сигналов, смежных с приложениями, где поддержка производителей сильна (телеметрия платформы автоматизации, работоспособность сервисов, структурированные логи приложений), и продолжить использовать протоколо-нативные конвейеры для традиционной сетевой телеметрии (опрос SNMP, потоковая передача gNMI) до тех пор, пока поддержка OTel на стороне устройств не повзрослеет. Проектируйте конвейер для одновременного поддержания обоих подходов, а не для принудительной преждевременной стандартизации, требующей адаптеров для каждого сетевого устройства.

Тенденция очевидна: OpenTelemetry в конечном итоге станет стандартом для всех данных наблюдаемости. Начало с него для самой платформы автоматизации (мета-мониторинг из Главы 5) - это низкорисковый первый шаг, позволяющий набрать опыт до распространения на сетевые устройства.

Архитектура сборщика

Упрощённо, каждый сборщик можно разбить на три части (иногда они подключаемые, иногда жёстко закодированы).

flowchart LR
    A[INPUT] --> B[PROCESSOR] --> C[OUTPUT]

Рисунок 4: Архитектура сборщика.

• Input (Вход): определяет, что нужно наблюдать и при каких параметрах.
• Processor (Процессор): хотя он опционален, очень удобен, как только данные поступают в конвейер, для обеспечения согласованности структуры данных. Обработка может стать очень сложной и влиять на производительность при масштабировании, поэтому не всю обработку нужно делать на этом уровне.
• Output (Выход): определяет, как сборщик передаёт данные в конвейер. Он может отправлять их напрямую в другие блоки, например в обработку или персистентность, или использовать компонент распределения для масштабирования.

Существует много сборщиков (каждый с разными возможностями), таких как Telegraf, Grafana Alloy, gNMIc, PMACCT, goflow и другие, но они используют схожую архитектуру. При выборе (иногда может потребоваться несколько) подходите так:

1. Возможности устройств: какие протоколы поддерживают ваши устройства?
2. Объём данных: большой объём требует потоковой передачи; малый объём может использовать опрос.
3. Требования к задержке: почти реальное время против традиционных интервалов.
4. Навыки команды и совместимость с вашим бэкендом.

Все «полные» решения для сетевой наблюдаемости, такие как Suzieq, Kentik и другие, также реализуют встроенный сборщик для охватываемых данных наблюдаемости.

После сбора данных следует шаг Процессора, управляющего данными на различных стадиях конвейера.

6.2.3. Процессор#

Сырые данные от сборщиков неопрятны. Разные устройства по-разному экспортируют метрики, логи - неструктурированный текст, значения могут быть в разных единицах. Уровень процессора очищает это и делает пригодным для использования.

Цель: как только данные получены, они должны соответствовать общим стандартам для конвергенции сигналов из нескольких источников, их корреляции и обогащения дополнительным контекстом. Без этого шага обработки конвейеры наблюдаемости быстро фрагментируются, становятся трудными для запросов и дорогими в эксплуатации. Существует несколько возможностей для обработки в зависимости от масштаба, сложности и операционных требований.

Ниже приведены распространённые операции обработки, применимые к конвейерам наблюдаемости.

6.2.3.1. Нормализация / Трансформация#

Данные поступают в разных форматах. Arista отправляет метрики одним способом, Cisco - другим, syslog - текст, NetFlow - бинарные данные. Нормализация переводит всё это в общий формат, чтобы ваш бэкенд не понимал 50 разных диалектов.

Структурирование

Устройства передают данные так, как им удобно. Ваша задача - перевести это в формат, удобный для анализа:

• На основе логов:

  Mar 18 14:22:11 leaf01 IFACE-5-STATE: swp1 oper-state changed from UP to DOWN

  преобразуется в

  {
  "timestamp": "2025-03-18T14:22:11Z",
  "level": "INFO",
  "device": "leaf01",
  "component": "interface",
  "event": "oper_state_change",
  "interface": "swp1",
  "previous_state": "UP",
  "current_state": "DOWN"
  }

• На основе метрик: <имя метрики>{<метки>} <значение>

  interface_admin_state{hostname="leaf01", ifname="swp1"} 1
  interface_oper_state{hostname="leaf01", ifname="swp1"} 0
  interface_speed_bps{hostname="leaf01", ifname="swp1"} 100000000000
  interface_in_errors_total{hostname="leaf01", ifname="swp1"} 0
  interface_out_errors_total{hostname="leaf01", ifname="swp1"} 12

• На основе таблиц: некоторые инструменты (например, Suzieq) организуют данные в табличные, индексированные по времени представления состояния:

  | hostname | ifname | adminState | operState | speed | inErrors | outErrors | timestamp |
  |----------|--------|------------|-----------|-------|----------|-----------|-----------|
  | leaf01   | swp1   | up         | up        | 100G  | 0        | 0         | t1        |
  | leaf01   | swp1   | up         | down      | 100G  | 0        | 12        | t2        |

Переименование и выравнивание

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

Openconfig: /interfaces/interface/state/oper-status value: UP tags: source=192.0.2.1 and interface_name=eth1
SNMP: ifOperStatus{ifName="GigabitEthernet0/1", device="router01"} 1
Native Prometheus: interface_oper_state{interface="swp1", host="leaf01"} 1

Нормализация выравнивает их в согласованную модель, включая имя объекта, переименование меток и значение (используя одинаковое преобразование единиц):

intf_oper_state{name="eth1", device="192.0.2.1"} 1
intf_oper_state{name="GigabitEthernet0/1", device="router01"} 1
intf_oper_state{name="swp1", device="leaf01"} 1

6.2.3.2. Обогащение#

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

Существуют два основных подхода к обогащению:

• Расширение данных: добавление дополнительных метаданных или меток к наблюдаемым данным для их дополнения. Эти данные могут быть статическими (например, org=my-company) для маркировки всех ваших данных, динамическими на основе контекста сбора (например, collector_id=1234) или динамическими на основе самих наблюдаемых данных (например, по hostname=rtr-1 создать метку location=BCN-01 путём корреляции с SoT).

  intf_oper_state{
      name="swp1", 
      device="leaf01",
      role="leaf",
      location="BCN0001"
  } 1

• Создание новых данных: следуя паттерну «info metrics» экосистемы Prometheus, можно генерировать метрики, не представляющие реальное состояние, а целевое. Эти метрики полезны на последующих стадиях конвейера наблюдаемости для добавления большего числа измерений к анализу, как вы узнаете в разделе об Оповещении.

  device_info{
      name="leaf1",
      role="leaf",
      vendor="arista",
      model="7050SX3",
      platform="eos",
      os_version="4.29.2F",
      location="BCN0001",
      rack="AB1",
      rack_unit="U32",
      environment="prod"
  } 1

  Info-метрики - любопытный тип данных, где релевантные данные находятся не в значении (например, 1 в предыдущих метриках), а в метках. Этот приём позволяет повторно использовать Time Series Database (TSDB), не поддерживающие некоторые типы значений (например, строки).

Оба подхода добавляют метки и контекст. Это мощно для оповещений и анализа. Но есть цена:

• Кардинальность: каждая новая метка умножает ваши временные ряды. Устройство × интерфейсы × метрики - уже высокая кардинальность. Добавляйте метки небрежно - и хранилище взрывается, запросы замедляются. Будьте продуманны.
• Частота обновления: стойки устройств и IP-адреса управления не меняются каждую секунду. Не опрашивайте данные обогащения так же часто, как волатильные метрики. Обновления, управляемые событиями, работают лучше - меньше запросов к Источнику истины.
• Устойчивость: если Источник истины недоступен, обогащение прекращается. Кэшируйте его, чтобы продолжать работу, пусть и в деградированном режиме. Ваша автоматизация зависит от этих данных, поэтому сделайте их надёжными.

6.2.3.3. Трансформация / Деривация / Агрегация#

Берёте сырые метрики и получаете из них новые. Пример: объединить весь входящий трафик интерфейсов коммутаторов leaf и spine в единую метрику «использованная пропускная способность фабрики» для трендов. Вы комбинируете существующие данные для ответа на более широкие вопросы или для питания дашбордов. В Prometheus это называется «правилами записи» (recording rules).

- record: fabric:interface:in_bps
expr: 
    (
    sum by (fabric, role, hostname, name) (
        rate(interface_in_octets_total{role=~"leaf|spine"}[5m])
    ) * 8
    )
    * on (hostname, name) group_left (fabric, role)
    sot_interface_info{role=~"leaf|spine"}

В экосистеме Prometheus это известно как recording rules (правила записи).

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

6.2.3.4. Фильтрация#

Отбрасывайте мусор на раннем этапе. Не каждая строка лога стоит хранения. Не каждая метрика интерфейса важна (возможно, вас не интересуют loopback-интерфейсы). Чем раньше фильтруете - тем меньше тратите на хранение и обработку. Списки разрешённых (оставить только это) безопаснее списков запрещённых (отбросить то).

6.2.3.5. Выборка / Дросселирование#

Даже после фильтрации объём может быть слишком высок. Дросселируйте его. Выборка вероятностным методом («оставить 10% этих запросов»), фокус на топ-K метриках («хранить только 100 наиболее загруженных интерфейсов»), ограничение частоты по источнику («максимум 1000 метрик на устройство»). По мере устаревания данных в базе свёртывайте их (детализация 5 секунд становится 5-минутными средними) для экономии места.

Наконец, все эти процессоры могут запускаться на разных стадиях конвейера наблюдаемости в зависимости от варианта использования:

• Сборщик: лучше всего подходит для лёгкой ранней нормализации и фильтрации
• Выделенный процессор: необходим в масштабе для динамического обогащения и сложных трансформаций
• Слой персистентности: подходит для правил записи и долгосрочных свёрток (нормализация всегда должна происходить до этого)
• Слой оповещения: получает события из сохранённых данных и применяет бизнес-логику

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

6.2.4. Распределение#

Простые линейные конвейеры (сборщик - процессор - база данных) не масштабируются. Если база данных замедляется - сборщик накапливает очередь. Если нужно обновить процессор - останавливается сбор. Всё тесно связано и хрупко.

Вот где вступают брокеры сообщений.

Брокеры сообщений, такие как Apache Kafka или NATS, располагаются посередине. Производители (сборщики, устройства) публикуют в топики. Потребители (процессоры, базы данных, оповещение) получают в своём темпе. Полностью разделено.

Преимущества:

• Масштабирование: каждый компонент масштабируется независимо.
• Устойчивость: если потребитель медленный - данные накапливаются в очереди вместо потери.
• Гибкость: одни и те же данные питают несколько бэкендов без дублирования в источнике. Обновляйте или перезапускайте один компонент, не затрагивая другие.

Подробнее о паттернах масштабирования и надёжности - в Главе 11.

6.2.5. Персистентность#

После обработки данные должны где-то храниться. Уровень базы данных хранит все данные наблюдаемости. Он должен обрабатывать огромные объёмы, поддерживать быстрые запросы и поддерживать разумные затраты.

Хорошие базы данных для наблюдаемости разделяют общие черты:

• Ориентированность на время: данные по своей природе имеют временну́е метки. Базы данных оптимизированы для диапазонных запросов и вычислений в временных окнах.
• Высокая пропускная способность записи: постоянный приём метрик. Базы данных справляются с этим без замедления.
• Многомерность: метрики несут метки (устройство, интерфейс, местоположение). Эффективный запрос и агрегация по ним.
• Гибкие запросы: нужны выразительные языки (PromQL, LogQL) для исследования данных без предопределённых схем.
• Управление жизненным циклом: хранилище быстро растёт. Поддержка хранения, понижения дискретизации, удаления для контроля затрат.
• Гибкость схемы: новые метрики появляются постоянно. Базы данных справляются с эволюцией без дорогостоящих миграций.

Какие типы баз данных работают?

Ни одна база данных не обрабатывает все рабочие нагрузки наблюдаемости идеально, и тот, кто говорит вам обратное, что-то продаёт. Вот что реально работает:

1. Базы данных временных рядов (Time Series Database (TSDB)): с этого нужно начинать. Prometheus выиграл войну метрик. Его модель данных (метрики с метками) стала стандартом де-факто, а PromQL - языком запросов, который все знают. Используйте Prometheus при менее 100 миллионах активных рядов. Выше - смотрите на VictoriaMetrics (совместима с Prometheus, лучше масштабируется, использует меньше памяти). InfluxDB нормальна, но их лицензирование постоянно меняется. Избегайте специфичных для производителя решений, если уже не привязаны к их экосистеме.

2. Колоночные базы данных: ClickHouse здесь король. Абсурдно быстр для агрегации логов и анализа потоков. Если нужно запрашивать миллиарды строк для отчётности или исторического анализа - это ваш инструмент. InfluxDB v3 пытается конкурировать, но у ClickHouse годы закалки. Parquet-файлы работают для аналитических нагрузок, где не нужна запись в реальном времени (как делает Suzieq).

3. Базы данных полнотекстового поиска: Elasticsearch, если надо, но честно говоря, современные альтернативы, вроде Loki от Grafana, проще и дешевле в эксплуатации. Splunk отличен, если кто-то другой за него платит. Грязный секрет: большинство команд избыточно инвестируют в поиск по логам и недостаточно - в структурированное логирование, которое сделало бы поиск ненужным.

Моя рекомендация: начните с Prometheus (или аналога) для метрик, Loki (или аналога) для логов. Добавьте ClickHouse (или аналог), когда нужен серьёзный исторический анализ. Этот стек доведёт вас до огромного масштаба, прежде чем понадобится что-то сложнее.

Эта классификация не абсолютна; большинство инструментов имеют основную классификацию, но реализуют некоторые характеристики других (особенно временных рядов).

Два важных концепта при проектировании хранилища: кардинальность (сколько уникальных значений может принимать метка) и размерность (сколько меток имеет одна метрика). Метки с высокой кардинальностью, умноженные на много измерений = взрыв хранимых данных и медленные запросы. Это одна из крупнейших проблем наблюдаемости. Подробные соображения о масштабировании - в Главе 11.

После всего управления данными есть два финальных шага:

• Создание событий для использования другой автоматизацией или вмешательства людей: Оповещение
• Визуализация данных для предоставления информации для принятия решений: Визуализация

6.2.6. Оповещение#

Оповещения превращают данные в действия. Ваша цель: передавать их автоматизации. Уведомлять людей, когда автоматизация не справляется.

Оповещения проходят через стадии:

• Обнаружение: найти что-то не то в данных.
• Обработка: обогатить контекстом. Это критично? Незначительно? Ложная тревога? Корреляция связанных оповещений для снижения шума.
• Маршрутизация: отправка в оркестрацию (запуск рабочих процессов), командам (Slack) или управлению инцидентами (PagerDuty).
• Эскалация: если автоматизация не справляется - вступают люди.

flowchart LR
    A[Detection] --> B[Processor] --> C[Routing] --> D[Escalation]

Рисунок 5: Стадии оповещения.

Сложная часть - не настройка оповещений. Это предотвращение усталости от оповещений. Я видел NOC с 10 000 активных оповещений, где никто больше ни на одно не смотрит. В этот момент у вас нет мониторинга - у вас есть дорогостоящий шум.

Вот как это реально исправить:

1. Направляйте 95% оповещений в автоматизацию, а не людям. Если человек видит оповещение - это должно быть потому, что автоматизация попыталась и не смогла. Мигает интерфейс? Автоматизация проверяет, не плановое ли это обслуживание, перезапускает оптику, открывает тикет к поставщику. Человека будят только если автоматизация не может решить это.

2. Уберите статические пороги. Оповещения «CPU > 80%» бесполезны. 80% может быть нормой для этого устройства. Используйте динамические базовые линии: оповещать, когда что-то отклоняется от исторического паттерна, а не от произвольного числа.

3. Группируйте связанные оповещения. Когда умирает корневой коммутатор - вы получите 500 оповещений от нижестоящих устройств. Показывайте одно: «Корневой коммутатор недоступен, затронуто 500 устройств». Не 500 отдельных оповещений.

4. Требуйте инструкцию для каждого оповещения. Если не можете написать, что кто-то должен сделать при получении оповещения - удалите оповещение. Серьёзно. Если действие - «расследовать» - это не действие, это трата времени.

5. Измеряйте качество оповещений. Отслеживайте уровень ложных срабатываний. Любое оповещение с >10% ложных срабатываний исправляется или удаляется. Отслеживайте время до подтверждения. Если оповещения остаются неподтверждёнными часами - они недостаточно важны для существования.

Цель не «всесторонний мониторинг». Цель - «будить людей только для того, что люди должны исправить».

6.2.6.1. Роль ИИ и AIOps в наблюдаемости#

Отбросим шумиху: большинство «наблюдаемости на основе ИИ» - это просто обнаружение аномалий с маркетинговым бюджетом. Тем не менее здесь есть реальная ценность, если развернуть правильно.

Что реально работает:

• Обнаружение аномалий: МО действительно лучше статических порогов в изучении «нормы» для каждого устройства. CPU на 85% может быть нормой для устройства A, катастрофой для устройства B. МО разбирается в этом автоматически. Это теперь базовые требования, а не магия.

• Корреляция оповещений: когда одновременно ломается 50 вещей, МО может их сгруппировать и предположить «корневой коммутатор, вероятно, является первопричиной». Экономит часы поиска неисправностей. Но всё равно нужны люди для проверки, потому что МО ошибается в 20% случаев.

• Прогнозирование ёмкости: МО неплохо справляется с «по тенденциям, этот канал насытится через 6 недель». Лучше людей, смотрящих на графики. Всё равно требуется суждение человека о том, стоит ли беспокоиться.

Что переоценено:

• Автоматический анализ первопричин: каждый поставщик это обещает. Ни один не обеспечивает надёжно. Вы получите предложения, иногда хорошие, но «ИИ диагностировал и устранил проблему» - это на 95% маркетинг и на 5% отобранные примеры.

• Самовосстанавливающиеся сети: автоматизация может исправлять известные проблемы известными решениями. Это не ИИ, это хорошая инженерия. Настоящее «самовосстановление» для новых проблем пока не существует. Когда поставщики демонстрируют это - попросите показать случаи сбоев.

• «AIOps заменит ваш NOC»: нет. AIOps помогает вашему NOC быть более эффективным. Суждение человека, бизнес-контекст и способность обрабатывать граничные случаи? Это всё ещё люди.

Итог: используйте МО для обнаружения аномалий и ранжирования оповещений. Будьте скептичны ко всему остальному, пока не проверите на своей реальной сети, а не на демонстрации поставщика.

6.2.6.2. Интерфейс оповещение-к-действию#

Оповещение, которое читает человек - это уведомление. Оповещение, которое потребляет автоматизация - это контракт. Эти два потребителя имеют разные требования, и смешение их является одной из наиболее распространённых причин сбоев конвейеров оповещения на границе с Оркестратором.

Когда оповещение предназначено для автоматизации, его полезная нагрузка должна быть машинно-потребляемой без разбора. Это означает структурированные данные, а не читаемую человеком строку темы. Как минимум, полезная нагрузка оповещения, предназначенного для автоматизации, должна включать:

• Идентификатор устройства: каноническое обозначение, точно совпадающее с записью SoT (не имя хоста, которое может отличаться между DNS и CMDB)
• Класс оповещения: стабильный перечислимый тип, по которому Оркестратор может маршрутизировать (не свободный текст, меняющийся при редактировании правила оповещения)
• Серьёзность: определённое перечисление, а не числовое пороговое значение
• Временна́я метка: время события в UTC ISO 8601, а не время доставки уведомления
• Релевантный контекст: конкретная метрика или состояние, вызвавшее оповещение, в поле, которое Оркестратор может читать напрямую (например, "interface": "Ethernet0/1", а не встроенное в строку сообщения)
• Трассировка источника: ссылка или отсылка к сырому событию в системе Наблюдаемости, чтобы Оркестратор мог повторно запросить дополнительный контекст

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

Определяйте этот контракт до построения правил оповещения, а не после. Авторы правил оповещений, пишущие для читаемости человеком, создают сообщения, трудные для автоматизации. Авторы, пишущие для обеих аудиторий, создают сообщения, не обслуживающие ни одну из них хорошо. Самое чистое решение - два параллельных пути маршрутизации: один формат оповещения для людей (Slack, PagerDuty), один для автоматизации (очередь сообщений, webhook-конечная точка). Оба запускаются одним и тем же правилом обнаружения; разные шаблоны полезной нагрузки для разных потребителей.

6.2.7. Визуализация#

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

Финальный блок - уровень дашбордов/отчётов. Скажу прямо: большинство дашбордов ужасны. Они либо представляют тщеславные метрики, заставляющие руководителей чувствовать себя хорошо («аптайм 99.99%!»), либо являются потоком данных (50 графиков на экране, никто не знает, что они означают).

Вот как строить дашборды, которые реально помогают:

• Строить для принятия решений, а не для украшения. Каждый виджет должен отвечать на конкретный вопрос или запускать конкретное действие. Если кто-то смотрит на график и не знает, что с ним делать - удалите график.

• Показывать проблемы, а не просто данные. Сигналы зелёный/жёлтый/красный лучше сырых чисел. «Загрузка интерфейса: 45%» бесполезно. «Загрузка интерфейса: нормально» или «Загрузка интерфейса: ПРЕДУПРЕЖДЕНИЕ, тренд к насыщению» - это действенно.

• Иерархическая детализация лучше одного большого дашборда. Начните со сводки глобальной работоспособности («3 площадки имеют проблемы»). Нажмите площадку - увидите работоспособность устройств. Нажмите устройство - увидите интерфейсы. Пять сфокусированных дашбордов лучше одного перегруженного.

• Соответствовать аудитории. Персоналу NOC нужен операционный статус в реальном времени и детализация. Менеджерам нужны сводки трендов и бизнес-влияние. Инженерам нужен доступ к сырым данным и интерфейсам запросов. Один дашборд, пытающийся служить всем, не служит никому.

• Делать интерактивным или не делать вовсе. Статические дашборды быстро устаревают. Позвольте людям фильтровать, масштабировать, настраивать временные диапазоны. Поддерживайте расследование, а не просто показывайте красивые картинки.

И вот спорный вывод: у большинства команд слишком много дашбордов. Я видел организации с 200+ дашбордами, где каждый человек смотрит на 2 из них. Удаляйте дашборды, которые никто не использует. Если никто не смотрит на него 3 месяца - он не важен.

Граница визуализации и представления

Визуализация находится на архитектурной границе, которую стоит рассмотреть напрямую, а не оставлять сноской. Уровень Представления (Глава 8) отвечает за пользовательские интерфейсы: контроль доступа, порталы самообслуживания, интеграцию с ITSM и дизайн пользовательского опыта того, как люди запрашивают и потребляют информацию. Визуализация данных наблюдаемости принадлежит этой главе, потому что проектные решения полностью определяются данными: какие метрики доступны, как структурировано оповещение, какие пути детализации поддерживает уровень персистентности. Невозможно разработать эффективный дашборд наблюдаемости, не понимая стоящей за ним модели данных.

Различие, важное на практике: дашборды, построенные непосредственно на данных наблюдаемости для операционных решений (что происходит прямо сейчас, работает ли этот сервис) - это забота Наблюдаемости. То, как эти же дашборды предоставляются нетехническим пользователям, встраиваются в портал самообслуживания или интегрируются с рабочими процессами управления изменениями - это забота Представления. Глава 8 возвращается к этим инструментам с точки зрения доступа и рабочего процесса. Большинство инструментов визуализации (наиболее распространённый - Grafana) размывают эту границу, делая и то, и другое, из-за чего разделение кажется искусственным. Это не так. Задачи действительно разные, даже когда один инструмент обслуживает обе.

Основные правила:

• Ясность: легко понять. Каждый элемент имеет цель.
• Релевантность: показывать только данные, поддерживающие решения. Шум убивает понимание.
• Ориентированность на пользователя: создавать для своей аудитории. Персоналу NOC и менеджерам нужны разные представления.
• Интерактивность: позволять детализацию, масштабирование, настройку времени. Поддерживать расследование.
• Иерархичность: сначала общий обзор, потом детализация. Много сфокусированных дашбордов лучше одного перегруженного.

flowchart TD
    A[Global Overview] --> B[Site Summary] --> C[Device Summary] --> D[Device Detail] --> E[Interface Detail]

Рисунок 6: Иерархическая детализация.

В книге Modern Network Observability, глава 11 («Application of Your Observability Data»), можно найти значительно больше деталей по архитектуре дашбордов.

Помните, что этот блок очень связан с восприятием пользователей, поэтому не забывайте опрашивать их и вовлекать в процесс.

6.2.8. Наблюдаемость самой системы автоматизации#

Большинство команд строят наблюдаемость для сети. Почти никто не строит наблюдаемость для самой системы автоматизации. Это значительное слепое пятно: когда конвейер автоматизации ломается, сбой часто бывает незаметным. Никакое оповещение не срабатывает, потому что система, ответственная за генерацию оповещений, может быть именно той, что только что прекратила работу.

Плейбук, завершающийся со статусом 0 после развёртывания на ноль устройств, не генерирует ошибки. Экземпляр Telegraf, тихо прекращающий опрашивать вендор-специфичный протокол, не создаёт оповещения об отсутствующих данных, если специально не инструментировано для этого. Задание синхронизации SoT, завершившееся с ошибкой в 2 часа ночи и оставившее инвентарь устаревшим на 12 часов, приведёт к тому, что каждое последующее выполнение будет работать с устаревшими списками устройств, и ничто не просигнализирует об этом.

Что мониторить в платформе автоматизации

• Уровень исполнения (AWX, Ansible):

  • Доля успешных заданий во времени: медленно растущая доля сбоев - ранний признак деградации
  • Продолжительность выполнения: задание, обычно занимающее 4 минуты и занявшее 40, сигнализирует о проблеме с платформой, сетью или обоими
  • Задания, зависшие в состоянии ожидания или выполнения дольше ожидаемого окна
  • Частота откатов: растущая частота откатов обычно означает дефект в данных намерения или шаблонах
  • Количество достигнутых устройств на задание в сравнении с ожидаемым: развёртывание, затронувшее 10 устройств вместо 800, могло тихо завершиться неудачей при синхронизации инвентаря без ошибки

• Уровень Источника истины:

  • Время ответа API и частота ошибок: медленный API SoT будет останавливать каждое задание выполнения, запрашивающее его
  • Состояние заданий синхронизации на источник: время последней успешной синхронизации, количество последовательных сбоев
  • Полнота данных: сколько записей устройств отсутствуют обязательные поля, от которых зависит выполнение

• Уровень сбора:

  • Временна́я метка последнего успешного сбора на устройство: устройство, не опрошенное в трёх последовательных интервалах, фактически является слепым пятном мониторинга
  • Задержка сбора по всему парку: если средний возраст данных растёт - сборщик не успевает
  • Пропущенные циклы опроса по протоколу: сбои SNMP и потери подписок gNMI должны подсчитываться и оповещаться отдельно

Проблема тихого сбоя

Наиболее трудноуловимые сбои автоматизации - это задания, завершающиеся успешно, но не производящие значимых изменений. Плейбук, развёртывающийся на ноль устройств из-за сломанного фильтра инвентаря, завершится со статусом 0. Единственный способ поймать такой класс сбоев - инструментировать на уровне результата: «изменило ли ожидаемое количество устройств состояние?», а не «чисто ли завершился процесс задания?»

Это означает добавление метрик результата к заданиям выполнения: счётчик успешно настроенных устройств, измеритель устройств, потребовавших отката, и проверка того, что задание затронуло как минимум N устройств, прежде чем отметить его как успешное.

Архитектурная рекомендация

Мониторьте платформу автоматизации в отдельном, минимальном стеке наблюдаемости, не зависящем от основной системы наблюдаемости, которую он поддерживает. Если основной экземпляр Prometheus падает - оповещение для конвейера автоматизации не должно падать вместе с ним. Лёгкий вторичный стек (или облачный сервис оповещения), охватывающий только работоспособность основных компонентов автоматизации (AWX, Telegraf, API SoT, задания синхронизации), обеспечивает защитную сеть, которую основная система наблюдаемости не может обеспечить для себя.

Это напрямую связано с Главой 7 (Оркестрация): работоспособный Оркестратор должен сообщать о своём операционном состоянии как о первостепенной задаче. Если Оркестратор не может наблюдаться - нельзя наблюдать и координируемую им автоматизацию.

6.3. Пример реализации#

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

Это ни в коем случае не является рекомендацией инструмента, но поскольку он полностью построен на компонентах с открытым исходным кодом - вы можете попробовать.

6.3.1. Вариант использования: валидация после развёртывания и постоянный мониторинг сервиса кампуса#

Продолжаем с сетью кампуса из Главы 5. Новый VLAN-сервис был развёрнут блоком Исполнения на целевые коммутаторы в здании B. Теперь за дело берётся Наблюдаемость: сначала для проверки того, что развёртывание действительно прошло успешно с точки зрения сетевого состояния, затем для постоянного мониторинга работоспособности сервиса по всему кампусу.

Сценарий: после развёртывания нового VLAN-сервисного сегмента на ~800 кампусных коммутаторах Cisco, Arista и HPE операционная команда должна подтвердить, что сервис активен и согласован на всех предназначенных устройствах, обнаружить дрейф конфигурации, если коммутатор потеряет VLAN, и мониторить работоспособность трафика во времени - без ручных проверок на каждом устройстве.

Требования:

• Валидировать активность и согласованность членства в VLAN на всех целевых коммутаторах после развёртывания
• Оповещать о дрейфе конфигурации: VLAN отсутствует на коммутаторе, неожиданные изменения членства в транке
• Мониторить работоспособность трафика сервиса: уровни загрузки и частота ошибок на порт доступа
• Обнаруживать внезапные скачки трафика (>50% изменения), которые могут указывать на неправильно маршрутизированные потоки
• Поддерживать 30 дней данных при разрешении 30 секунд для соответствия требованиям и планирования ёмкости
• Интегрировать с Nautobot для инвентаря устройств и данных намерения VLAN
• Запускать оркестрационные рабочие процессы для автоматизированного исправления при обнаружении дрейфа

6.3.2. Архитектура решения#

Прежде чем начать анализ решения, важно оценить масштаб сценария. При ~800 кампусных коммутаторах × 48 портов × 8 метрик = примерно 307K активных временных рядов. Это хорошо вписывается в возможности одного узла Prometheus (комфортно до ~1M рядов), но уровень сборщиков требует нескольких экземпляров Telegraf для распределения нагрузки опроса по 800 устройствам с 30-секундными интервалами.

Обоснование выбора компонентов:

• Telegraf был выбран как сборщик за поддержку нескольких протоколов (SNMP для устаревших устройств HPE и более старых Cisco, gNMI для Arista и новых платформ Cisco), обширную экосистему плагинов и встроенные процессоры для нормализации данных. При 800 устройствах один экземпляр Telegraf был бы перегружен при 30-секундных интервалах опроса, поэтому развёртываются два или три экземпляра с координацией через Consul, определяющий, какие цели обслуживает каждый.
• Prometheus служит уровнем персистентности, оптимизированным для данных временных рядов с мощным языком запросов PromQL для сложных условий оповещения. При 32K рядов он работает в своей зоне комфорта, обеспечивая нативную интеграцию с Alertmanager.
• Grafana обеспечивает визуализацию с поддержкой нескольких источников данных, одновременно запрашивая как метрики Prometheus, так и метаданные Nautobot для создания контекстно-богатых дашбордов, адаптированных для разных аудиторий (NOC, планирование ёмкости, руководство).

Архитектура

На высоком уровне следующий рисунок отображает основные компоненты и роли:

flowchart TB
    subgraph Sources["Data Sources"]
        NB[Nautobot<br/>Source of Truth]
        SW[Network Devices<br/>SNMP/gNMI]
    end

    subgraph Collection["Collection Layer"]
        T[Telegraf<br/>Collectors]
        SD[Consul<br/>Service Discovery]
    end

    subgraph Storage["Storage"]
        P[Prometheus<br/>TSDB]
    end

    subgraph Alerting["Alerting"]
        AM[Alertmanager<br/>Routing]
    end

    subgraph Presentation["Visualization"]
        G[Grafana<br/>Dashboards]
    end

    subgraph Integration["External Systems"]
        ORCH[Orchestrator<br/>Automation]
        SLACK[Slack<br/>Notifications]
    end

    NB -->|Device Inventory| SD
    SD -->|Dynamic Targets| T
    SW -->|Metrics| T
    T -->|Expose HTTP| P
    P -->|Alert Rules| AM
    P <-->|Queries| G
    NB -->|Metadata| G
    AM -->|Webhook| ORCH
    AM -->|Alerts| SLACK

Рисунок 7: Пример архитектуры решения для наблюдаемости.

Эта упрощённая архитектура решения подробно рассматривается в книге Modern Network Observability. Если хотите практический подход с лабораторным сценарием для тестирования - попробуйте.

6.3.3. Поток реализации#

Интеграция инвентаря: Nautobot служит единым источником истины, определяя, какие устройства мониторить с профилями мониторинга и учётными данными SNMP. Лёгкий сервис синхронизации (например, Python-скрипт с использованием webhooks) непрерывно обновляет реестр сервисов Consul информацией об устройствах, обеспечивая динамическое обнаружение для сборщика.

Сбор данных: Telegraf использует Consul для обнаружения сервисов, автоматически опрашивая SNMP с устройств по мере их появления в Nautobot. Процессоры Telegraf нормализуют и обогащают данные (преобразуя коды статусов в метки, переименовывая поля в стандартные имена и добавляя контекстную информацию из Nautobot) и предоставляют метрики в формате Prometheus на HTTP-конечной точке.

Персистентность и анализ: Prometheus опрашивает конечные точки Telegraf с использованием обнаружения сервисов Consul, сохраняя метрики в своей базе данных временных рядов. Правила записи предварительно вычисляют проценты загрузки интерфейсов и скорости передачи для оптимизации производительности запросов.

Логика оповещений: правила оповещений в Prometheus определяют условия (например, загрузка интерфейса >80% в течение 5 минут, скачки трафика >50% прироста). При совпадении условий Alertmanager управляет маршрутизацией: критические оповещения с метками automation: enabled идут на webhook оркестратора, другие маршрутизируются в Slack или PagerDuty в зависимости от серьёзности.

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

Замкнутая автоматизация: когда срабатывают критические оповещения о насыщении, Alertmanager отправляет webhooks на платформу оркестрации, которая запускает автоматизированные рабочие процессы трафик-инжиниринга для перераспределения нагрузки по доступным путям. Этот компонент рассматривается в Главе 7.

6.3.4. Краткое изложение решения#

Операционные преимущества:

• Снижение ручных усилий мониторинга через интеграцию с SoT
• Проактивное обнаружение проблем с задержкой менее минуты
• Замкнутое исправление, снижающее MTTR с часов до минут
• Богатый контекст, объединяющий метрики с данными инвентаря

Соображения масштабируемости:

• Текущая архитектура обслуживает ~800 кампусных коммутаторов с использованием 2-3 распределённых экземпляров Telegraf за Consul; добавление зданий или устройств означает добавление экземпляров сборщиков, а не перепроектирование
• Ёмкости Prometheus достаточно при ~307K рядов с запасом для роста; один узел обрабатывает до ~1M рядов до необходимости федерации или распределённого бэкенда

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

6.4. Резюме#

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

Реализация этих целей требует семи взаимосвязанных архитектурных столпов и функциональных возможностей: интеграция с SoT для автоматического обнаружения инвентаря, многопротокольные сборщики, поддерживающие приём данных почти в реальном времени через потоковую телеметрию и современные протоколы, процессоры, нормализующие и обогащающие гетерогенные данные контекстными метаданными, распределённые системы для масштабируемого перемещения данных при высоких объёмах, специализированные базы данных (временных рядов, колоночные, полнотекстового поиска), оптимизированные для разных рабочих нагрузок наблюдаемости, интеллектуальное оповещение с обнаружением на основе ИИ/МО и маршрутизацией в оркестрацию или людям, и адаптированные визуализации, представляющие информацию на соответствующем уровне абстракции для разных аудиторий.

Реализация наблюдаемости требует архитектурных решений на раннем этапе проектирования. Организациям нужно выбирать между традиционными локальными платформами, облачными SaaS-решениями, предлагающими быстрое развёртывание и аналитику на основе ИИ, или составными стеками с открытым исходным кодом, обеспечивающими максимальную гибкость. Каждый подход включает компромиссы по стоимости, контролю, операционным накладным расходам и возможностям. Успех также зависит от понимания требований к обработке данных - от нормализации и обогащения до фильтрации и агрегации - и того, как развивающиеся возможности AIOps могут снизить усталость от оповещений и обеспечить прогностические операции.

Наблюдаемость - это не единый инструмент, а согласованный архитектурный паттерн. Успех зависит от рассмотрения её как системы: инвентарь определяет сбор, сбор обеспечивает обработку, обработка питает распределение, распределение связывается с персистентностью, персистентность информирует оповещение, а оповещение в конечном итоге управляет визуализацией и автоматическим ответом. Тщательно проектируя каждый компонент и их взаимодействие, организации могут строить системы наблюдаемости, масштабирующиеся вместе с сетями, интегрирующиеся с современными протоколами, такими как OpenTelemetry и gNMI, и трансформирующие операционную видимость в действенную аналитику, питающую замкнутую автоматизацию.

Ссылки и дополнительная литература#

• Modern Network Observability (David Flores, Christian Adell, Josh Vanderaa): практический подход с использованием инструментов с открытым исходным кодом, таких как Telegraf, Prometheus и Grafana

💬 Found something to improve? Send feedback for this chapter