OPS Наблюдаемость сети: NTP, Syslog, SNMP, NetFlow

Сеть, которая молчит, — это сеть, которую нельзя чинить. Пока всё работает, наблюдаемость кажется роскошью; в ночь аварии она становится единственным, что отделяет «за 15 минут нашли причину» от «гадаем до утра». В этом модуле научим оборудование рассказывать о себе: единое время (NTP), события (Syslog), метрики (SNMP), кто-с-кем-и-сколько (NetFlow) — и куда всё это стекается. Это блок CCNA про management-плоскость и прямой мост в DevOps-наблюдаемость (Prometheus, Grafana, ELK).

Что узнаешь

Почему NTP — первый шаг наблюдаемости, и что такое stratum
Syslog: 8 уровней severity, facility, локальный буфер и отправка на сервер
SNMP: OID/MIB, get/walk, polling vs trap, версии v2c и v3
NetFlow/IPFIX: потоки по 5-tuple, top talkers, поиск аномалий и DDoS
Streaming telemetry — почему push вытесняет SNMP-polling (обзорно)
Куда всё стекается: коллекторы и дашборды (Zabbix, Grafana, ELK/Graylog)
Конфиги Cisco, мини-лаба на своём ПК и плейбук «разбор инцидента по логам»

Вспомни из прошлых модулей

Модуль 12: методичный поиск неисправности — «симптом → гипотеза → проверка». Наблюдаемость даёт данные для этих гипотез. Модуль 16: port-security и DAI шлют syslog/trap о нарушениях — сегодня узнаешь, куда они приходят. Модуль 4 (порты) и модуль 5 (маршрутизация) — NetFlow оперирует знакомым 5-tuple (IP, порты, протокол). Если что-то забылось — вернись, всё сойдётся здесь.

1. Заявка: «ночью моргнуло, а разобрать нечем»

Инцидент №8821 (постмортем)

«Ночью 3 минуты не работал сервис. Утром смотрим: на одном коммутаторе в логах 02:14, на роутере — 02:09, на сервере вообще UTC. Что за чем случилось — непонятно, логи не бьются по времени. И вообще неясно, что моргнуло: линк, маршрут, нагрузка? Настройте так, чтобы в следующий раз мы видели картину».

В этой заявке — вся суть модуля. Проблема даже не в том, что «нет данных», а в том, что данные несопоставимы: разное время, нет метрик, нет истории. Наблюдаемость — это не одна кнопка, а четыре слоя, и собирать их надо в правильном порядке. Начнём с фундамента — времени.

2. NTP — единое время, без которого всё врёт

Расследование инцидента — это корреляция событий по времени с десятков устройств. Если часы расходятся хоть на минуту, timestamp'ы врут, и сложить общую картину невозможно. Поэтому первый шаг наблюдаемости — NTP (Network Time Protocol): все устройства синхронизируют часы с единым источником.

Stratum — «расстояние» до эталонного источника. Stratum 0 — сами атомные/GPS часы; stratum 1 — сервер, подключённый к ним напрямую; stratum 2 — тот, кто синхронизируется от stratum 1, и так далее. Чем больше число, тем дальше от эталона.
В сети оператора обычно 2–3 своих NTP-сервера (stratum 2), от которых синхронизируется всё остальное; сами они смотрят на публичные stratum 1 (pool.ntp.org, ГЛОНАСС/GPS).

R(config)# ntp server 10.0.0.1 # источник времени R(config)# ntp server 10.0.0.2 prefer # предпочтительный R(config)# clock timezone MSK 3 R# show ntp status # synchronized, stratum N R# show ntp associations

Так на работе рушатся расследования

«Метрики врут / графики скачут в прошлое / логи не бьются» — первое, что проверяет опытный инженер, это show ntp status на всех участниках. Один несинхронизированный узел способен испортить весь постмортем. NTP — это не «мелочь под конец», а предусловие всего остального.

3. Syslog — поток событий и его уровни

Каждое значимое событие устройство пишет в syslog: линк упал, сосед OSPF пропал, сработал port-security, кто-то вошёл. У каждого сообщения есть severity — уровень важности от 0 до 7. Правило простое: чем меньше число, тем серьёзнее.

#	Уровень	Что значит
0	emergency	система непригодна — «всё горит»
1	alert	нужно немедленное вмешательство
2	critical	критическое состояние (сбой БП, перегрев)
3	error	ошибка (интерфейс лёг, сосед пропал)
4	warning	предупреждение (приближается порог)
5	notice	нормальное, но заметное событие
6	informational	информация (конфиг изменён)
7	debug	отладка — очень шумно

Устройство хранит немного логов локально (буфер в памяти) и — главное — шлёт их на удалённый syslog-сервер (rsyslog, Graylog, ELK). Локальный буфер теряется при перезагрузке; сервер хранит всё и позволяет искать по всей сети сразу. На сервер обычно шлют события до определённого порога (например, всё ≤ 6), а debug (7) держат локально, чтобы не топить коллектор шумом.

R(config)# logging host 10.0.0.53 # syslog-сервер R(config)# logging trap informational # слать на сервер уровни 0..6 R(config)# logging buffered 51200 debugging # локальный буфер (для debug) R(config)# service timestamps log datetime msec localtime # точное время в логах (нужен NTP!) R# show logging

4. SNMP — метрики: опрос и уведомления

SNMP (Simple Network Management Protocol) — стандарт «спросить у устройства его показатели»: загрузку CPU и памяти, счётчики и ошибки интерфейсов, температуру. Данные разложены по дереву MIB, где у каждого показателя свой числовой адрес — OID (например, ifInOctets — сколько байт пришло на интерфейс). Работает двумя способами:

Polling — система сама опрашивает (pull)

Коллектор (Zabbix, PRTG, SNMP exporter) каждые N секунд шлёт GET/WALK: «дай значение этого OID». Так строятся графики загрузки и трафика. Минус — узнаёшь о проблеме только на следующем опросе.

Trap — устройство само уведомляет (push)

Случилось событие (линк упал, порог превышен) — устройство немедленно шлёт TRAP коллектору, не дожидаясь опроса. Так узнают об авариях мгновенно. Polling + trap дополняют друг друга.

Версии SNMP различаются безопасностью — это важный вопрос:

Версия	Защита	Где
v1 / v2c	community-строка открытым текстом (по сути пароль в эфире)	устарело; только в изолированных сегментах
v3 ⭐	пользователи, аутентификация + шифрование (authPriv)	стандарт для управляющего трафика

# SNMPv2c (read-only) — простой пример; в проде предпочитают v3 R(config)# snmp-server community RO-secret RO R(config)# snmp-server host 10.0.0.53 version 2c RO-secret R(config)# snmp-server enable traps # включить отправку trap'ов

Частая ошибка джуна

Оставить SNMPv2c с community public/private на устройстве, доступном извне. Это открытая дверь: кто угодно прочитает всю топологию, а с RW — и перенастроит. Управляющий трафик — только v3 и только из доверенного management-сегмента (вспомни VRF управления из трека оператора).

5. NetFlow — кто, с кем и сколько

SNMP скажет «на интерфейсе 800 Мбит/с», но кто их генерирует — молчит. Это показывает NetFlow (и стандартизованный IPFIX, у других вендоров — sFlow/J-Flow). Устройство разбирает трафик на потоки (flow) по ключу — знакомому 5-tuple:

Flow = {src IP, dst IP, src port, dst port, протокол}. Все пакеты с одинаковым 5-tuple — это один поток; для него считаются байты, пакеты, время. Роутер шлёт сводки о потоках на коллектор.

Что это даёт на практике:

Top talkers — кто занимает канал: «весь аплинк выел бэкап с одного сервера».
Аномалии и DDoS — внезапно тысячи потоков с разных адресов на один порт.
Расследование — «с какого хоста шёл трафик на этот IP в 02:14» (когда есть NTP!).
Планирование ёмкости — реальные профили трафика, а не догадки.

R(config-if)# ip flow monitor MON input # Flexible NetFlow на интерфейсе R(config)# flow exporter EXP R(config-flow-exporter)# destination 10.0.0.53 # коллектор потоков R# show flow monitor MON cache # локально посмотреть топ-потоки

6. Streaming telemetry — куда всё идёт (обзорно)

SNMP-polling опрашивает раз в минуту-две — для современных сетей это редко и тяжело. Ему на смену идёт streaming telemetry: устройство само непрерывно «стримит» метрики (модель данных YANG, транспорт gNMI/gRPC) в реальном времени — push вместо pull, секунды вместо минут. Для CCNA достаточно знать: телеметрия — это push-модель, вытесняющая периодический SNMP-опрос там, где нужна высокая частота и масштаб.

7. Куда всё стекается: коллекторы и дашборды

Слой	Что собирает	Инструменты
Время	синхронизация	NTP-серверы (chrony), GPS/ГЛОНАСС
Логи	события (syslog)	rsyslog, Graylog, ELK (Elasticsearch+Kibana), Loki
Метрики	SNMP/telemetry	Zabbix, PRTG, Prometheus (+ snmp_exporter), Grafana
Потоки	NetFlow/IPFIX	nfdump, ntopng, Elastiflow, Kentik

Это ровно та же наблюдаемость, что в DevOps: логи + метрики + трейсы/потоки, сведённые в дашборды (Grafana). Сетевая часть — это Syslog/SNMP/NetFlow, а сверху — те же Prometheus и Grafana, что мониторят серверы и Kubernetes. Твоё сетевое прошлое здесь — не багаж, а фора: ты понимаешь, что именно меряешь.

8. Мини-лаба: наблюдаемость на своём ПК

# Единое время — тот самый NTP, только на твоём компьютере $ timedatectl # Linux: "System clock synchronized: yes", NTP service C:\> w32tm /query /status # Windows: Source, Stratum # Логи системы — твой локальный syslog $ journalctl -p err -n 30 # последние 30 сообщений уровня error и выше # обрати внимание: у каждой строки есть точное время — потому что часы синхронизированы

Что понять: journalctl -p err — это фильтр по severity, ровно как logging trap на роутере. А timedatectl показывает, синхронизировано ли время — без этого твои же логи было бы не сопоставить. Ты только что потрогал два из четырёх слоёв наблюдаемости.

9. Плейбук: разбор инцидента по данным

Сначала — доверяй ли времени

Проверь, что NTP синхронен на всех участниках (show ntp status). Иначе корреляция бессмысленна.

Что случилось — в логах

На syslog-сервере отфильтруй по времени инцидента и устройствам. Ищи error/ critical: «line protocol down», «OSPF neighbor down», «psecure-violation». Событие + точный timestamp = отправная точка.

Насколько сильно — в метриках

Графики SNMP за тот же интервал: скачок CPU, ошибки/дропы на интерфейсе, всплеск трафика. Метрика подтверждает или опровергает гипотезу из логов.

Кто виноват в трафике — в потоках

NetFlow за интервал: top talkers, аномальные потоки. «Канал забил бэкап» или «шёл флуд на порт 53» — видно только здесь.

Собери таймлайн

Сложи события по единому времени в одну ленту — вот и постмортем: что за чем, причина и следствие. Ровно то, чего не хватало в заявке из начала урока.

10. Частые ошибки и вопрос с собеседования

Грабли

1) Настроили логи/метрики, но не NTP → данные несопоставимы. 2) Шлют на сервер уровень debug со всей сети → коллектор захлёбывается, важное тонет в шуме. 3) SNMPv2c public наружу → утечка топологии. 4) Мониторят «доступность по ping», но не ошибки/ дропы интерфейсов → деградацию замечают последними.

Собеседование: «Ping до устройства идёт, метрики зелёные, а пользователи жалуются. Куда смотреть?»

Ping и «up» — грубые признаки. Смотри тонкие: счётчики ошибок/дропов на интерфейсах (SNMP), логи о флапах и ретрансмиссиях, NetFlow на предмет перегруза/аномалий. Деградация (потери, джиттер, микровсплески) не видна в «доступности», но видна в метриках и потоках.

11. Словарик модуля

Термин	По-английски	Смысл в одну строку
NTP	Network Time Protocol	синхронизация времени — фундамент корреляции
Stratum	stratum	«расстояние» до эталонных часов (0 — сам эталон)
Syslog	syslog	стандарт потока событий с уровнями severity 0–7
Severity	severity	важность лога: 0 emergency … 7 debug (меньше = серьёзнее)
SNMP	Simple Network Mgmt Protocol	опрос метрик устройства (get/walk) и trap-уведомления
OID / MIB	object identifier / MIB	адрес показателя и дерево показателей
Trap	SNMP trap	push-уведомление устройства о событии
NetFlow	NetFlow / IPFIX / sFlow	учёт потоков по 5-tuple: кто с кем и сколько
Flow	flow	набор пакетов с одинаковым 5-tuple
Telemetry	streaming telemetry	push-стрим метрик (gNMI/YANG) вместо polling

1. Графики Grafana по SNMP «прыгают в прошлое», часть точек с будущим временем. Инструмент виноват?

Почти наверняка нет — виноват рассинхрон часов. Если у устройства/коллектора время убежало, метки времени метрик врут, и график «скачет». Проверь NTP (show ntp status, timedatectl) на устройстве и на сервере мониторинга. Наблюдаемость всегда стоит на едином времени.

2. Коллектор syslog захлёбывается, диск забивается за часы. Что настроить?

Скорее всего на устройства выставлен слишком «болтливый» уровень (logging trap debugging) со всей сети. Поднять порог до informational/notice (слать 0–5/0–6), а debug держать локально в буфере и включать точечно при разборе. Плюс ротация/ретеншн на сервере.

3. Нужно узнать, какой хост залил аплинк в конкретную минуту прошлой ночи. Какой слой ответит?

NetFlow/IPFIX. SNMP покажет только суммарную загрузку интерфейса, а NetFlow разложит трафик на потоки по 5-tuple и покажет top talkers за интервал — конкретные src/dst и объём. И это работает только если время синхронно (NTP), иначе «ту самую минуту» не найти.

4. Почему polling и trap используют вместе, а не что-то одно?

Polling даёт непрерывную картину (графики трендов), но узнаёт о проблеме лишь на следующем опросе — задержка. Trap мгновенно сообщает о событии (линк упал), но не строит трендов и может потеряться (UDP). Вместе: trap — «сработало сейчас», polling — «как менялось во времени».

Наблюдаемость сети — четыре слоя на общем времени: NTP (без него всё врёт) → Syslog (что случилось) → SNMP/telemetry (насколько) → NetFlow (кто виноват в трафике). Собранные в коллекторы и дашборды, они превращают «ночью что-то моргнуло» в точный таймлайн причины. Это же — фундамент DevOps-наблюдаемости, куда ты придёшь дальше.

Мост к следующему модулю

Мы прошли провода, коммутацию, маршрутизацию, услуги, безопасность и наблюдаемость — всё по кабелю. Но половина устройств в современном офисе без кабеля вообще. Как работает Wi-Fi, почему он «то летает, то падает», что такое контроллер, каналы и роуминг — в следующем модуле про беспроводные сети.