Есть ещё одна, на мой взгляд, хорошая практика из личного опыта: слать алерты от разных триггеров в разные чаты (например, в подгруппы в чате мониторинга), разделив их тегами. Я сетевик, поэтому расскажу со своей точки зрения. Типов алертов у сетевого оборудования выделено несколько:
1) Доступность. Сюда отправляются алерты про недоступность сетевых (и не только) железок по ICMP/SNMP.
2) Состояние. Сюда отправляются алерты про превышение нормы по температурным показателям, утилизации ЦП/ОЗУ, изменение состояния блоков питания, изменение состояния OSPF- и BGP-соседей у маршрутизаторов и прочее, не связанное с доступностью.
3) Сетевые интерфейсы. Сюда приходят алерты про падение интерфейсов, росте счётчика ошибок на них, затуханиях на оптических линках или повышенной утилизации в плане скорости. Эта подгруппа замьючена, так как триггеры там могут быть частыми. И в ней, в моём случае, полезно видеть и флапы. В то же время, позволяет увидеть, почему именно пришли алерты из других подгрупп (какие именно линки упали).
4) Аутентификация. Сюда сообщения пишутся уже не заббиксом (так сложилось). Фиксируются попытки входа в интерфейс управления: удачные (беззвучно) и неудачные (со звуком) на основании журналов сетевого оборудования и других систем.
Также, можно выведены в отдельные подгруппы, триггеры от ИБП и БРП, систем климатического контроля, серверов, гипервизоров и прочего.
В итоге чат с мониторингом один, но в него могут смотреть разные подразделения, отвечающие за разные вещи: инфраструктурщики замьютили для себя все чаты, связанные с состоянием сетевого железа, но всё равно могут увидеть, что их сервак перестал отвечать из-за того, что недоступен коммутатор. Мы же, в свою очередь, не слышим алертов о перезапуске серверов и виртуальных машин, но также, в случае чего, можем увидеть, что сайт недоступен именно из-за перезапуска сервера, а не из-за падения сетевой связности.
Оказывается, если в качестве Peer-Link'а для VPC на MES коммутаторах используется номер Port-channel больше 48, то может возникать проблема с изоляцией BUM трафика. Недокументированный баг или фича...
Эту проблему пофиксили в последнем релизе. Но боевые VPC-пары уже вряд ли кто-то будет перестраивать.
До 2022 года их точки доступа, которые WEP-2ac, стоили в районе 5к рублей. Тех же денег стоила латвийская cAP AC, которая в по производительности примерно той же паршивости. Цена-качество, получается, соблюдалось.
В 2023 cAP AC подорожала в 3 раза, а WEP-2ac на том же икскоме… до 70к :)
Регуляторика В и ВНЕ помещений различаются же. За незарегистрированный радиомост на улице вполне резонно предъявили. Если бы железки с обеих сторон стояли внутри помещения за стеклом - проблем с РЧЦ, вероятно, не возникло бы.
Внутри помещений разрешили 5.9-6.4 ГГц в конце 2022, если мне память не изменяет.
Большое спасибо за статью!
Есть ещё одна, на мой взгляд, хорошая практика из личного опыта: слать алерты от разных триггеров в разные чаты (например, в подгруппы в чате мониторинга), разделив их тегами. Я сетевик, поэтому расскажу со своей точки зрения. Типов алертов у сетевого оборудования выделено несколько:
1) Доступность. Сюда отправляются алерты про недоступность сетевых (и не только) железок по ICMP/SNMP.
2) Состояние. Сюда отправляются алерты про превышение нормы по температурным показателям, утилизации ЦП/ОЗУ, изменение состояния блоков питания, изменение состояния OSPF- и BGP-соседей у маршрутизаторов и прочее, не связанное с доступностью.
3) Сетевые интерфейсы. Сюда приходят алерты про падение интерфейсов, росте счётчика ошибок на них, затуханиях на оптических линках или повышенной утилизации в плане скорости. Эта подгруппа замьючена, так как триггеры там могут быть частыми. И в ней, в моём случае, полезно видеть и флапы. В то же время, позволяет увидеть, почему именно пришли алерты из других подгрупп (какие именно линки упали).
4) Аутентификация. Сюда сообщения пишутся уже не заббиксом (так сложилось). Фиксируются попытки входа в интерфейс управления: удачные (беззвучно) и неудачные (со звуком) на основании журналов сетевого оборудования и других систем.
Также, можно выведены в отдельные подгруппы, триггеры от ИБП и БРП, систем климатического контроля, серверов, гипервизоров и прочего.
В итоге чат с мониторингом один, но в него могут смотреть разные подразделения, отвечающие за разные вещи: инфраструктурщики замьютили для себя все чаты, связанные с состоянием сетевого железа, но всё равно могут увидеть, что их сервак перестал отвечать из-за того, что недоступен коммутатор. Мы же, в свою очередь, не слышим алертов о перезапуске серверов и виртуальных машин, но также, в случае чего, можем увидеть, что сайт недоступен именно из-за перезапуска сервера, а не из-за падения сетевой связности.
Эту проблему пофиксили в последнем релизе. Но боевые VPC-пары уже вряд ли кто-то будет перестраивать.
До 2022 года их точки доступа, которые WEP-2ac, стоили в районе 5к рублей. Тех же денег стоила латвийская cAP AC, которая в по производительности примерно той же паршивости. Цена-качество, получается, соблюдалось.
В 2023 cAP AC подорожала в 3 раза, а WEP-2ac на том же икскоме… до 70к :)
Регуляторика В и ВНЕ помещений различаются же. За незарегистрированный радиомост на улице вполне резонно предъявили. Если бы железки с обеих сторон стояли внутри помещения за стеклом - проблем с РЧЦ, вероятно, не возникло бы.
Внутри помещений разрешили 5.9-6.4 ГГц в конце 2022, если мне память не изменяет.