Почему бизнес теряет деньги на сетевых сбоях, и как NPM помогает это предотвратить?
На связи Станислав Грибанов, руководитель продуктового направления компании «Гарда». В предыдущем посте мы обсуждали, почему классический мониторинг часто оказывается «слеп» к проблемам бизнес-приложений, и разбирали базовые принципы работы NPM (Network Performance Monitoring). Сегодня углубимся в архитектуру отказов, методы анализа трафика и поговорим о том, как своевременная диагностика сетевых взаимодействий влияет на финансовую устойчивость компании.
Точки отказа: где теряются деньги?
Изнутри даже простые сервисы представляют собой обширную распределенную инфраструктуру. При этом системы мониторинга и оркестрации, призванные гарантировать стабильность, не всегда могут своевременно и точно обнаружить источник проблемы.
Отчасти причина такой «слепоты» кроется в том, что работа современного бизнес-приложения опирается на несколько уровней (аппаратный уровень, уровень ОС, уровень приложения, сетевой уровень), на каждом из которых потенциально может возникнуть точка отказа.
Первые три уровня обычно успешно закрывают агентские решения. С сетевым уровнем дела обстоят иначе: агент на сервере не всегда видит, что происходит между узлами.
Помимо технологических сложностей, есть и управленческая проблема. Часто за бесперебойную работу каждого уровня отвечают разные подразделения. Когда сервис падает, команда проверяет только свой участок. Это затягивает устранение инцидента и анализ, необходимый для поиска первопричин. Возникает эффект «футбола».
NPM как инструмент превентивной защиты
Сбои, задержки, атаки и мисконфигурации сетевого оборудования могут приводить не просто к снижению производительности, а к полной остановке бизнес-приложений. Для компаний это означает прямые убытки и репутационный ущерб.
Для решения таких задач применяются решения класса NPM. Они анализируют сетевой трафик (его копии или сетевую телеметрию NetFlow), а также данные syslog и SNMP. На их основе система подсчитывает метрики и строит интерактивные виджеты, визуализируя потенциально проблемные узлы сети. Например, можно вывести топ приложений по объему трафика, хостов по повторным передачами или хостов с наибольшим временем установки соединения и др.
На этом этапе возникает закономерный вопрос: какой источник данных лучше — сетевой трафик или телеметрия? Однозначного ответа здесь нет. Выбор зависит от особенностей инфраструктуры. Так, сетевой трафик предоставляет больше возможностей для извлечения разнообразных сетевых метрик. Однако его намного сложнее обрабатывать, а в некоторых случаях, таких как огромные объёмы данных (ЦОД) или распределённые децентрализованные сети с большим количеством сетевого оборудования с возможностью выхода в интернет, это становится либо вовсе невозможным, либо требует очень больших ресурсов. И тут на помощь приходит NetFlow или его аналоги.
Фактически сетевая телеметрия позволяет анализировать заголовки сессий сетевого трафика, предоставляя специалистам различные возможности для мониторинга производительности сети. В частности, мы можем контролировать объем трафика, его скорость, загрузку интерфейса, привязку объема или скорости трафика к приложениям. Кроме того, за счёт анализа сырого трафика все описанные кейсы можно дополнительно обогащать такими сетевыми метриками, как время установки соединения, задержка ответа сети или приложения и другими.
Благодаря машинному обучению NPM позволяют увидеть аномальные выбросы, которые сигнализируют о проблемах в сети. Например, большое количество сессий или, наоборот, провал в их количестве.
Вместо вывода
Решения класса NPM формирует единую картину производительности, позволяя видеть проблемы еще до того, как они повлияют на бизнес. Причем неважно, что вы выберете в качестве источника (полный трафик или Flow-данные), система подскажет, где именно искать причину сбоя.
Мы обязательно продолжим исследовать тему NPM в нашем блоге на Хабре. А пока мы структурировали всю информацию по NPM на нашем сайте.
