Теория: Мониторинг и эксплуатация
Как узнают, что происходит в сети, и почему мониторинг врёт молча: опрос против ловушек, дерево SNMP и ограничение доступа, накопительные счётчики, централизованные журналы и уровни. Прочитайте материал, а затем пройдите тест — следующий пункт курса откроется после верных ответов.
Мониторинг ломается молча
У любой аварии в сети есть одно полезное свойство: она заметна. Не ходит трафик — приходят заявки, падает сервис — звонят.
У мониторинга этого свойства нет. Когда ломается он сам, ничего не происходит: графики ровные, оповещений нет, дежурный спокоен. Разницу между «в сети всё хорошо» и «мы перестали видеть сеть» по внешним признакам не отличить никак.
Отсюда главное правило эксплуатации, которое стоит усвоить раньше любых протоколов: тишина мониторинга — это не хорошая новость, а отсутствие новостей. Пустой график означает либо что ничего не происходило, либо что до устройства перестали доходить запросы. Это два совершенно разных состояния, и различать их надо специально.
Второй способ соврать — неполнота. Данные идут, графики рисуются, но нужного события в них нет: фильтр отсёк, уровень задран, нужная ветка не опрашивается. Такая ложь опаснее молчания: молчание хотя бы настораживает, а полный график успокаивает.
У мониторинга этого свойства нет. Когда ломается он сам, ничего не происходит: графики ровные, оповещений нет, дежурный спокоен. Разницу между «в сети всё хорошо» и «мы перестали видеть сеть» по внешним признакам не отличить никак.
Отсюда главное правило эксплуатации, которое стоит усвоить раньше любых протоколов: тишина мониторинга — это не хорошая новость, а отсутствие новостей. Пустой график означает либо что ничего не происходило, либо что до устройства перестали доходить запросы. Это два совершенно разных состояния, и различать их надо специально.
Второй способ соврать — неполнота. Данные идут, графики рисуются, но нужного события в них нет: фильтр отсёк, уровень задран, нужная ветка не опрашивается. Такая ложь опаснее молчания: молчание хотя бы настораживает, а полный график успокаивает.
Два способа узнать, что происходит
Опрос. Станция мониторинга раз в минуту-пять спрашивает устройство: как дела, сколько байт прошло, какие порты подняты. Просто, предсказуемо, легко считать графики. Но между двумя опросами устройство живёт само по себе: порт, упавший и поднявшийся за минуту, в опросе не появится вообще.
Ловушки. Устройство само отправляет сообщение, когда что-то случилось: порт погас, вентилятор встал, кто-то вошёл в конфигурацию. Событие не теряется и приходит сразу. Но ловушка отправляется по UDP и без подтверждения — потерялась значит потерялась, никто не переспросит.
Отсюда практика: берут оба. Опрос даёт состояние и историю, ловушки — события. И они ходят разными каналами (161 и 162 порты), так что ломаются независимо: опрос может работать, а ловушки нет, и наоборот. Проверять надо оба.
Ловушки. Устройство само отправляет сообщение, когда что-то случилось: порт погас, вентилятор встал, кто-то вошёл в конфигурацию. Событие не теряется и приходит сразу. Но ловушка отправляется по UDP и без подтверждения — потерялась значит потерялась, никто не переспросит.
Отсюда практика: берут оба. Опрос даёт состояние и историю, ловушки — события. И они ходят разными каналами (161 и 162 порты), так что ломаются независимо: опрос может работать, а ловушки нет, и наоборот. Проверять надо оба.
0:001:002:003:00
4:005:00
что в итоге знает станция мониторинга
Опрос и ловушки ходят разными каналами — 161-й и 162-й порты, —
поэтому и ломаются независимо: опрос может работать, а ловушки нет, и наоборот. Проверять
надо оба, причём каждый своим способом.
SNMP: дерево, имена и сообщества
Всё, что устройство готово рассказать о себе, разложено в дерево. Каждая веточка имеет номер, а полный путь от корня — это и есть OID, длинная строка вида
Запоминать такое невозможно, поэтому есть MIB — словарь, переводящий номера в человеческие имена. С ним тот же OID выглядит как
Полезно понимать деление дерева:
•
•
Доступ в старых версиях защищён строкой сообщества — по сути паролем, который ходит по сети открытым текстом. Обычно заводят одну строку только на чтение и ограничивают список адресов, которым разрешено спрашивать. Второе важнее первого: сообщество можно подсмотреть, а вот отвечать с устройства кому попало — не обязательно.
Отдельно ограничивают видимую часть дерева: незачем отдавать наружу список процессов и разделов диска, если мониторингу нужны интерфейсы.
.1.3.6.1.2.1.2.2.1.8.Запоминать такое невозможно, поэтому есть MIB — словарь, переводящий номера в человеческие имена. С ним тот же OID выглядит как
IF-MIB::ifOperStatus: состояние интерфейса.Полезно понимать деление дерева:
•
.1.3.6.1.2.1 — стандартная часть, одинаковая у всех вендоров: система, интерфейсы, IP, TCP;•
.1.3.6.1.4.1 — вендорская, у каждого своя: температура блоков, состояние вентиляторов, специфичные счётчики.Доступ в старых версиях защищён строкой сообщества — по сути паролем, который ходит по сети открытым текстом. Обычно заводят одну строку только на чтение и ограничивают список адресов, которым разрешено спрашивать. Второе важнее первого: сообщество можно подсмотреть, а вот отвечать с устройства кому попало — не обязательно.
Отдельно ограничивают видимую часть дерева: незачем отдавать наружу список процессов и разделов диска, если мониторингу нужны интерфейсы.
Версии и почему до сих пор живёт вторая
v1 — древняя, 32-битные счётчики, встречается только на очень старом железе.
v2c — та же модель безопасности (сообщество открытым текстом), но появились 64-битные счётчики и массовый запрос, забирающий целую таблицу за раз. Именно её вы увидите в девяти сетях из десяти.
v3 — нормальная аутентификация и шифрование, пользователи вместо сообществ.
Вопрос «почему все всё ещё на v2c, если есть v3» имеет скучный ответ: v3 сложнее в эксплуатации. Пользователи, ключи, согласование алгоритмов, разное поведение у вендоров — а выигрыш неочевиден для сети, где опрос идёт по выделенному сегменту управления.
Разумный минимум, если v3 не осилили: сообщество только на чтение, доступ только с адреса станции, управление вынесено в отдельную сеть.
v2c — та же модель безопасности (сообщество открытым текстом), но появились 64-битные счётчики и массовый запрос, забирающий целую таблицу за раз. Именно её вы увидите в девяти сетях из десяти.
v3 — нормальная аутентификация и шифрование, пользователи вместо сообществ.
Вопрос «почему все всё ещё на v2c, если есть v3» имеет скучный ответ: v3 сложнее в эксплуатации. Пользователи, ключи, согласование алгоритмов, разное поведение у вендоров — а выигрыш неочевиден для сети, где опрос идёт по выделенному сегменту управления.
Разумный минимум, если v3 не осилили: сообщество только на чтение, доступ только с адреса станции, управление вынесено в отдельную сеть.
Что снимают на практике
Список короче, чем кажется. Почти вся эксплуатация держится на нескольких показателях:
• Состояние интерфейса — поднят или нет. Причём состояний два: административное (не выключен ли руками) и рабочее (есть ли физическая связь). Расхождение между ними — сразу диагноз.
• Счётчики байт и пакетов — из них строятся графики загрузки.
• Счётчики ошибок и отброшенных пакетов — растут при проблемах с кабелем, дуплексом или перегрузкой.
• Загрузка процессора и памяти — из вендорской части дерева.
• Температура и питание — оттуда же.
Отдельная ловушка новичка: счётчики накопительные. Устройство отдаёт не «сейчас 200 мегабит», а «с момента включения прошло столько-то байт». Скорость станция считает сама: разница между двумя опросами, делённая на время между ними. Из этого следуют две вещи. Перезагрузка устройства обнуляет счётчик, и на графике появляется провал или всплеск. А 32-битный счётчик на гигабитном порту переполняется примерно за полминуты — если опрашивать раз в пять минут, показания будут случайными. Поэтому берут 64-битные.
• Состояние интерфейса — поднят или нет. Причём состояний два: административное (не выключен ли руками) и рабочее (есть ли физическая связь). Расхождение между ними — сразу диагноз.
• Счётчики байт и пакетов — из них строятся графики загрузки.
• Счётчики ошибок и отброшенных пакетов — растут при проблемах с кабелем, дуплексом или перегрузкой.
• Загрузка процессора и памяти — из вендорской части дерева.
• Температура и питание — оттуда же.
Отдельная ловушка новичка: счётчики накопительные. Устройство отдаёт не «сейчас 200 мегабит», а «с момента включения прошло столько-то байт». Скорость станция считает сама: разница между двумя опросами, делённая на время между ними. Из этого следуют две вещи. Перезагрузка устройства обнуляет счётчик, и на графике появляется провал или всплеск. А 32-битный счётчик на гигабитном порту переполняется примерно за полминуты — если опрашивать раз в пять минут, показания будут случайными. Поэтому берут 64-битные.
Журналы: уровни и куда их складывать
Второй источник правды — журнал. Он рассказывает то, чего не видно в счётчиках: кто вошёл в конфигурацию, почему упало соседство, какая именно ошибка случилась.
У каждого сообщения есть источник (какая подсистема) и уровень важности — от аварийного до отладочного, всего восемь ступеней. По ним и фильтруют: что писать локально, что отправлять на сервер, а что не писать вовсе.
Здесь же прячется вторая по частоте ошибка мониторинга: задранный уровень. Оставили только критическое — и обычные события, из которых складывается картина аварии, до сервера не доезжают. Журнал есть, он работает, в нём пусто.
Собирать журналы централизованно нужно по трём причинам:
• Устройство упало вместе со своим журналом — и самое интересное, последние секунды перед отказом, пропало.
• Авария редко на одном узле. Сопоставить время событий с пяти устройств можно только когда они в одном месте.
• Место. На сетевой железке журнал живёт в кольцевом буфере и затирается за часы.
Классический syslog ходит по UDP на порт 514 — без подтверждения доставки, как и ловушки. Где важна каждая строка, используют вариант поверх TCP.
У каждого сообщения есть источник (какая подсистема) и уровень важности — от аварийного до отладочного, всего восемь ступеней. По ним и фильтруют: что писать локально, что отправлять на сервер, а что не писать вовсе.
Здесь же прячется вторая по частоте ошибка мониторинга: задранный уровень. Оставили только критическое — и обычные события, из которых складывается картина аварии, до сервера не доезжают. Журнал есть, он работает, в нём пусто.
Собирать журналы централизованно нужно по трём причинам:
• Устройство упало вместе со своим журналом — и самое интересное, последние секунды перед отказом, пропало.
• Авария редко на одном узле. Сопоставить время событий с пяти устройств можно только когда они в одном месте.
• Место. На сетевой железке журнал живёт в кольцевом буфере и затирается за часы.
Классический syslog ходит по UDP на порт 514 — без подтверждения доставки, как и ловушки. Где важна каждая строка, используют вариант поверх TCP.
Что здесь ломается
Сменили сообщество на устройстве. Опрос молчит, графики встали, устройство живо. Отличить от настоящей аварии можно только проверкой вручную — и это ровно та ситуация, ради которой стоит помнить правило про тишину.
Приёмник слушает только localhost. Отправители настроены верно, журналы уходят и не приходят. Проверять надо обе стороны, а не только ту, где недавно что-то меняли.
Задран уровень важности. Канал работает, данные идут, нужного в них нет.
Не совпало время. Часы на устройствах разъехались, и события в общем журнале выстраиваются в бессмысленном порядке. Поэтому синхронизация времени — часть мониторинга, а не отдельная задача.
Ловушки настроены, приёмник не поднят. Устройство честно отправляет, ловить некому, UDP никому не жалуется.
Считают 32-битные счётчики на быстрых портах. Показания случайные, а выглядят правдоподобно.
Мониторинг видит только IPv4. Половина трафика dual-stack-сети не наблюдается вовсе.
Приёмник слушает только localhost. Отправители настроены верно, журналы уходят и не приходят. Проверять надо обе стороны, а не только ту, где недавно что-то меняли.
Задран уровень важности. Канал работает, данные идут, нужного в них нет.
Не совпало время. Часы на устройствах разъехались, и события в общем журнале выстраиваются в бессмысленном порядке. Поэтому синхронизация времени — часть мониторинга, а не отдельная задача.
Ловушки настроены, приёмник не поднят. Устройство честно отправляет, ловить некому, UDP никому не жалуется.
Считают 32-битные счётчики на быстрых портах. Показания случайные, а выглядят правдоподобно.
Мониторинг видит только IPv4. Половина трафика dual-stack-сети не наблюдается вовсе.
Как проверять
snmpwalk -v2c -c <сообщество> <адрес> <ветка> — обойти ветку дерева. Первое, чем проверяют, отвечает ли агент вообще: sysName.0 должен вернуть имя устройства. Timeout при живом пинге означает, что дело не в сети.snmpget — забрать одно конкретное значение, когда OID уже известен.И обязательно проверять с другого узла тоже: если ограничение по адресу настроено верно, оттуда должен быть Timeout. Правило доступа, которое никто не проверял, обычно оказывается не тем, что задумывали.
Журналы смотрят на приёмнике: есть ли файл от нужного устройства и — что важнее — насколько он свежий. Файл, в который последний раз писали час назад, означает, что пересылка встала, хотя формально «журналы собираются».
ss -lunp на приёмнике покажет, кто и на каком адресе слушает: привязка к локальной петле вместо всех адресов — типовая причина «ничего не приходит».Общий принцип разбора один: сначала убедиться, что канал наблюдения жив, и только потом верить тому, что он показывает.
Команды — шпаргалка
# агент на наблюдаемом устройстве (net-snmp): строки конфигурации
agentAddress udp:161 # протокол и порт, на котором слушать
rocommunity netlab-ro 192.168.99.10 # ro — только чтение. Дальше пароль-строка
# (community) и адрес, с которого
# разрешено спрашивать
view labview included .1.3.6.1.2.1.1 # имя набора, included — «включить эту
# ветку», дальше сам OID: описание системы
view labview included .1.3.6.1.2.1.2 # и ветка про интерфейсы
rocommunity netlab-ro 192.168.99.10 -V labview
# -V — ограничить доступ этим набором
trap2sink 192.168.99.10 netlab-trap # куда слать ловушки и с какой community
# опрос со станции
snmpwalk -v2c -c netlab-ro 192.168.99.1 sysName.0
# -v2c — версия протокола; -c — community;
# дальше адрес устройства и OID.
# walk обходит ветку целиком
snmpwalk -v2c -c netlab-ro 192.168.99.1 ifDescr # имена интерфейсов
snmpwalk -v2c -c netlab-ro 192.168.99.1 ifOperStatus # их состояние
snmpget -v2c -c netlab-ro 192.168.99.1 ifHCInOctets.2
# get берёт ровно один OID. Число после
# точки — номер интерфейса. HC значит
# 64-битный счётчик: обычный на гигабите
# переполняется за минуты
# приём ловушек
authCommunity log,execute,net netlab-trap # в snmptrapd.conf: что делать с ловушкой
# и от какой community принимать
snmptrapd -c snmptrapd.conf -Lf /var/log/traps.log
# -c — файл настроек; -Lf — писать журнал
# в указанный файл
# пересылка журналов (rsyslog, на устройстве)
*.* action(type="omfwd" target="192.168.99.10" port="514" protocol="udp")
# *.* — любой источник, любая важность;
# omfwd — модуль отправки по сети
# приём журналов и раскладка по устройствам (на станции)
module(load="imudp") # подключить приём по UDP
input(type="imudp" port="514") # слушать порт 514
template(name="RemoteFile" type="string" string="/var/log/remote/%HOSTNAME%.log")
# шаблон имени файла; %HOSTNAME%
# подставится из самого сообщения
*.* action(type="omfile" dynaFile="RemoteFile")
# omfile — писать в файл, dynaFile —
# имя берётся из шаблона, а не жёстко
# проверка
ss -lunp # -l слушающие, -u UDP, -n числами,
# -p чей процесс
ls -l /var/log/remote/ # -l — подробно, видно размер и время:
# есть ли файлы и насколько они свежиеКонтрольные вопросы
Дальше — лабораторная работа «Мониторинг: SNMP и журналы»
Для неё нужен аккаунт: стенд поднимается персонально под вас — свои роутеры, свои конфиги, никто в них не мешает. Регистрация — почта и пароль.
Теория прочитана. Дальше — руками.
Личный стенд из настоящих роутеров разворачивается за секунды. Платформа проверяет не ответы на тесты, а состояние вашей сети: поднялись ли соседства, сошлись ли маршруты, ходит ли ping. Рядом — AI-наставник, который видит ваши конфиги и ведёт к решению, не выдавая готовое.
Начать бесплатно →
бета открыта, доступ бесплатный