Новость из категории: Интернет

Мониторинг сетевой инфраструктуры

Содержание:
1. Сообщения syslog и их анализ (Вы читаете данный раздел);
2. Сбор данных по протоколу SNMP;
3. Сбор данных по протоколу NetFlow;
4. Уведомления.
Мониторинг сетевой инфраструктуры

Сообщения syslog и их анализ. Журналы событий служат для мониторинга и анализа работы всех сетевых устройств, а так же фиксируют его состояние в любой промежуток времени. Любое действие, так или иначе связанное с сетевым оборудованием отражается в виде записей в журнале (логах). Уровни детализации таких записей различны и в зависимости от этого выделяют три уровня логирования. Для оборудования Cisco Systems предусмотрено восемь уровней: от уровня о (Emergencies — сообщения о неработоспособности системы) до уровня 7 (Debugging — отладочные сообщения).

Данное оборудование предоставляет следующие возможности по выводу сообщений: на консоль устройства (console logging), в локальный буфер устройства (buffer logging), в терминальную линию (monitor logging) и на внешний сетевой накопитель — выделенный сервер syslog. В роли последнего может выступать централизованная система мониторинга. Таким образом данное оборудование может оказаться неплохим подспорьем в поиске различных проблем сети. Именно поэтому так важно не только заказать сайт (http://i-to.me/) у опытных исполнителей, но и подыскать хостера, который использует качественное оборудование в своих сетях.

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

Мониторинг сетевой инфраструктуры

Первая особенность касается вывода на консоль или терминальную линию сообщений с высоким уровнем детализации, в частности уровня 7. Прежде всего речь идет о ситуации, когда инженер активирует дополнительную трассировку какого-либо сервиса командой debug. Поскольку сетевое устройство может генерировать слишком большое количество сообщений за единицу времени, все ресурсы процессора будут направлены на вывод этих сообщений на экран. В результате устройство может «зависнуть» и перестать выполнять свою главную функцию — маршрутизировать и коммутировать сетевой трафик. Таким образом, при необходимости просмотра сообщений высокого уровня детализации мы рекомендуем выводить их в локальный буфер.

Второй нюанс касается вывода сообщений в локальный буфер, который на сетевых устройствах Cisco выделяется из общего пула оперативной памяти. Если для буфера сообщений будет запрошен слишком большой объем памяти, это также может привести к «зависанию» устройства и неза-планированной перезагрузке.

Мониторинг сетевой инфраструктуры
Cisco ASA 5500-X

Отдельно стоит выделить настройку протоколирования на межсетевых экранах Cisco ASA. Распределение сообщений по уровням для многих случаев не является оптимальным. В частности, сообщения, связанные с работой списков доступа (ACL) или с правилами трансляции IP-адресов (NAT), могут соответствовать уровням 2-6. Например, если трафик подпадает под действие списка доступа, то в этом случае может генерироваться следующее сообщение:
Error Message % ASA-2-106006: Deny inbound UDP from outside_address/outside_ port to inside_address/inside_port on interface interface_name.

Таким образом, даже при работе устройства в нормальном режиме не исключено появление сообщений высокого уровня критичности. С учетом этого в операционной системе межсетевого экрана Cisco ASA предусмотрены широкие возможности по настройке и оптимизации протоколи-рования на устройстве. В частности, инженер может менять уровень любого сообщения, а также создавать списки системных сообщений, объединяя интересующие его события в группы. Например, для отладки и мониторинга работы сервиса VPN формируется список, в который будут попадать только те сообщения, которые связаны с работой данного сервиса, а на выделенный сервер Syslog будет передаваться настроенный список. Кроме того, устройство Cisco ASA может отправлять списки сообщений по электронной почте.

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

Системные сообщения незаменимы при расследовании непредсказуемых сетевых проблем. Вот простой пример. Сетевой администратор периодически получает от пользователей жалобы на то, что в течение рабочего дня три-четыре раза пропадает связь между центральным офисом и удаленным. Что делать в такой ситуации?

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

Таким образом, по записям в журнале мы смогли локализовать проблему и понять причину ее появления.

Помимо решения сетевых проблем, хотелось бы отметить еще одну область применения системных сообщений. Их можно использовать совместно со встроенным в операционную систему устройств Cisco редактором автоматических сценариев Cisco Embedded Event Manager (EEM). Данная функциональность позволяет создавать сценарии для автоматического изменения конфигураций устройств. Сообщение о событии может выступать триггером запуска сценария.

Рейтинг статьи

Оценка
0/5
голосов: 0
Ваша оценка статье по пятибальной шкале:
 
 
   

Поделиться

Похожие новости

Комментарии

^ Наверх