Какие метрики стоит снимать с коммутаторов l3,l2?

Question

[alexxxhost]

Здравствуйте!
Только начинаю разбираться с zabbix'ом и в обще с мониторингом. Поэтому есть несколько вопросов.
1. Какие основные метрики стоит снимать?
2. Как стоит мониторить коммутаторы доступа, мониторить только магистральные порты? Или все?

Answer 1

[throughtheether]

1. Какие основные метрики стоит снимать?

Состояние самого коммутатора: утилизация CPU, памяти, показания датчиков температуры, обороты вентилятора, входное/выходное напряжение блока питания.
Состояние сетевой подсистемы: утилизация портов (bps, pps) с разделением по трафику (одноадресный, многоадресный, широковещательный), количество и тип ошибок/отброшенных фреймов, состояние интерфейсов (дуплекс, скорость).
Вообще говоря, я полагаю, что лучше иметь большое количество данных и при необходимости какие-то отбросить, чем иметь недостаточное количество данных и гадать, что происходит в сети. Поэтому рекомендую собирать все метрики, которые доступны.

2. Как стоит мониторить коммутаторы доступа, мониторить только магистральные порты? Или все?

См. предыдущий абзац, полагаю, лучше мониторить все интерфейсы. На главную страницу (dashboard), конечно, лучше выводить отобранные графики.

Comments

[alexxxhost]

Со все портов метрики снимать на вряд ли получиться, у нас 1200 портов. Дисковая подсистема не потянет.
1. Имеет ли смысл снимать метрики с коммутатора по cpu и памяти, если он не показывает какой процесс, что потребляет?(это l2)
2. С какой периодичностью снимать метрики с коммутаторов?

[throughtheether]

1. В вашем случае (на коммутаторе нет L3-функциональности, кроме управления), по всей видимости, можно обойтись без этого. Но имеет смысл, по возможности, мониторить размер таблицы MAC-адресов, на случай специфичных атак.
2. Зависит от требуемого времени реакции на инцидент. В системах, с которыми я работал, периодичность снятия показаний была не реже раза в пять минут. Но и снимать метрики чаще, чем коммутатор их обновляет, тоже не стоит (это не дает новой информации).

Со все портов метрики снимать на вряд ли получиться, у нас 1200 портов. Дисковая подсистема не потянет.

Не понял этого тезиса. Если у вас не хватает объема диска - храните подробную статистику в течение дней-недель и затем агрегируйте. Если не хватает производительности дисковой подсистемы - сохраняйте данные в оперативную память и в фоне записывайте на диск или воспользуйтесь специализированными (time-series data bases) базами данных.

Answer 2

[Disen]

Чем больше снимаете и мониторите, тем лучше. Однако, не переусердствуйте - исходите из возможностей железа. Скачайте MIB от производителей Вашего сетевого оборудования и по OID'ам создайте шаблон или используйте уже готовые шаблоны для zabbix (если имеются) и собирайте все метрики. Со временем поймете, что Вам надо, что - нет.
В анализе собираемой информации Вам помогут грамотно настроенные триггеры. С их помощью вполне возможно выявлять аномальную загрузку по сетевым интерфейсам, например.

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

Comments

[Thomas Andersen]

Вот за вебинары спс :D

Answer 3

[Армянское Радио]

Мониторить нужно все, метрики нужно писать и анализировать все. Любое отклонение от статистики пристально изучать.