Статья на Habr про мониторинг и почему надо точно знать что мониторится и главное как это делается, самые основы. Метрология не зря наука.
Из самой распространённой практики - ни одно устройство не измеряет скорость, считается количество чего-то что было передано. А скорость это производная, которую считает мониторинг. Если это всё наложить на дискретную природу передачи в пакетных сетях, то получается что никаких непрерывных графиков битов в секунду вообще быть не может.

Отсюда растут многие недопонимания и появляется средняя температура по больнице. Если надо считать численные значения, например ошибки, то лучше их хранить численно, можно даже с накоплением, а не приводить к штукам в секунду. Иначе вас ожидают сюрпризы вроде 5 миллиошибок в секунду, что совершенно интуитивно непонятно и на самом деле означает, что у вас была одна ошибка за последний период опроса. Который тоже лучше явно указать, чтобы получить график ошибок в минуту или в 5 минут в нужном разрешении, точнее данных у вас всё равно нет.

Второй момент, пакетная нагрузка (скорость) не менее, даже более важна чем битовая. При длине пакета 64 байта обратный трафик из TCP ACK со "скоростью" 50Мбит/c будет иметь 100 000 пакетов в секунду, что более чем существенно. Типичная ситуация при постоянном скачивании большого объёма данных, например фильма, где как раз размер пакета будет максимальным. И это уже стоит обязательно учитывать проектируя в каком месте поставить офисную хранилку. От неё много битового трафика, в обратном направлении много пакетного. Много данных не бывает.

Менеджер или нет, вот в чём вопрос, который никак не может решиться в статье Silvia Bostros. Речь о должности, скорее роли Principal Engineer, для которой "главный инженер" не совсем адекватный перевод.
Должность стратегическая-техническая за рамками непосредственного управления людьми, как она позиционируется и в то же время управление ими. Хорошее описание пути развития технического специалиста обрастающего компетенциями и навыками которым уже не поместиться в более узкой и специализированной роли.

Несколько лет назад кабельные провайдеры посмеивались, что мол никогда радио не побьёт кабель по скорости и по надёжности. Но текущая действительность говорит о другом. Радио так и остаётся радио, но в дополнение к смарт устройствам с приемлемым размером экрана появились ресурсы где все действия можно совершать одним пальцем - проматывай, лайкай, репость. Вот такой современный интернет которому хватает радио, который не заставляет тебя вставать с удобного кресла чтобы в него погрузиться, а уж не дома вне конкуренции.
Прогнозы Cisco до 2022 года эту картину только подтверждают. Мало того, даже наша статистика Wi-Fi подключений (хотя казалось бы то же радио) в публичных местах говорит что пик пройден в 2017, а сейчас суммарное число  уникальных авторизаций медленно катится вниз, даже с учётом сезонности. Никому не хочется переключаться меняя контекст, потому что устраивает.

Один браузер, один веб сервер, один Интернет. Один на всех, наверное не очень это хорошо. Должно быть что-то в противовес. Я у себя lighttpd использую ;)

Power over Wi-Fi, несколько проектов которые возможно в будущем позволят черпать энергию "из воздуха" на расстояниях сопоставимых с расстоянием передачи данных. Не так глобально как у Теслы, но возможно пока. Интернет вещей конечно же является драйвером, главное не забыть оставить место для человека.

И я не знал, но подозревал что есть, вопрос в точном названии - numfmt знает что в килобайте 1024 байт:

$ numfmt --to=iec 1024
1.0K

и по "новому" может:

$ numfmt --to=iec-i 1024
1.0Ki

биты тоже:

$ numfmt --from=si 1K
1000

Хороший инструмент для вывода удобоваримой информации в скриптах, теперь можно опцию -h добавлять.

Тот момент, когда твой мониторинг – это современное искусство:

http://devopsart.tumblr.com

freeRouter - свободная opensource реализация маршрутизатора на Java с обширным набором возможностей. framerelay и vxlan как нечего делать. Попробовать в консоли можно подключившись telnet dl.nop.hu (у меня сильно тормозит). Можно скачать в виде готового образа для виртуалки или как jar.
Если не привязываться к вендору, а рассматривать только протоколы и принципы - отличный инструмент для понимания многих вещей, ради которых иной раз ничего кроме как физического устройства и не найдёшь.
Проект развивается постоянно начиная с 2009.

Vim или Emacs, сколько уже копий сломано. Казалось бы что ещё сказать, но нет, теперь у нас есть vim.dev и emacs.dev и не надо их встречать по одёжке (доменному имени). emacs.dev был зарегестрирован раньше на несколько часов.
Но это шутки. Без шуток про Vim можно найти полный, официальный, актуальный справочник online по этой ссылке vimhelp.org. Про Emacs не знаю, потому что я уже выбрал.

Сети крайне неустойчивые конструкции, просто потому что сложные. Интернет так вообще очень сложен. Неосторожное движение может привести к катастрофе, а уж если задастся целью что-то сделать. Банальная история - абонент положил провайдера (опять автоконфигурация, на этот раз wpad), провайдер обиделся, зря конечно. Абонент хоть и приносит деньги, но он с другой стороны - защищать его от Интернета надо не в меньшей степени чем защищать Интернет и свою сеть от абонента, а то и в большей.

Шикарная ссылка, которую прислал читатель канала. Вполне приличный и безопасный на вид пароль ji32k7au4a83 оказывается на поверку, если я правильно понял, транслитом с китайского по системе Чжуинь фухао, переводится как "my password", и встречается в различных утечках аж 141 раз.
https://gizmodo.com/why-ji32k7au4a83-is-a-remarkably-common-password-1833045282

И тут с подачи читателя, в кои-то веки пришла в голову идея. Наберем в https://haveibeenpwned.com/Passwords "мойпароль" в латинской раскладке — vjqgfhjkm, и получим 9635 использований в различных взломах. Неплохо, да.

Еще больше упростим задачу, и наберем слово "пароль" — gfhjkm.

Oh no — pwned!
This password has been seen 262,774 times before
This password has previously appeared in a data breach and should never be used. If you've ever used it anywhere before, change it!

ДВЕСТИ ШЕСТЬДЕСЯТ ДВЕ ТЫСЯЧИ СЕМЬСОТ СЕМЬДЕСЯТ ЧЕТЫРЕ ИСПОЛЬЗОВАНИЯ

ААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААААА

​Когда пытаются балансировать трафик на внешних каналах между AS обычно используют несколько первых шагов из алгоритма выбора лучшего пути BGP, при этом какие-то вопросы возникают только со входящим трафиком. С исходящим набор инструментов включает в том числе автоматическую балансировку по нескольким маршрутам bgp multipath и даже с учётом нагрузки bgp dmzlink-bw, не говоря уже обо всех возможностях просто маршрутизации, PBR, VRF. Полный контроль.

Со входящим трафиком используют community, сейчас это обычное дело у многих они определены и работают. Или AS_PATH препенды. Редко кто добирается до MED, вместо этого, как правило, идёт в ход артиллерия more specific префиксов. Меньше /24 в большом Интернет вряд ли заработает их и так уже скоро 60%, но метод действенный.

Однако алгоритм из 13 пунктов, а мы дальше 6 не двинулись. Есть одно шаманство куда можно атаковать - 10 пункт предписывает выбрать при прочих равных маршрут который уже является лучшим, получен первым. Это условие вносит некоторую неопределённость, чтобы убрать её есть команда bgp best path compare-routerid. Но она есть и это RFC5004 и её можно использовать. У Cisco включено по умолчанию, у Bird выключено.
Итак, нам надо поменять порядок маршрутов на удалённом узле, чтобы лучший маршрут через нужное нам направление был выбран. Убираем анонсы через какой-то свой аплинк или понижаем им приоритет добавив препенд. Тогда трафик из этого аплинка убежит, так как будет выбран другой лучший, а если всё вернуть как было трафик вернётся обратно, но не совсем весь. Ведь процесс на удалённых BGP маршрутизаторах, при прочих равных выберет маршрут который уже был лучшим, через другой наш аплинк. На этом можно сыграть, чтобы чуть-чуть добавить или убрать трафик.

Но предсказать такое поведение с точностью что сейчас мы перестроим X мегабит/c трафика нельзя, поэтому это злейшее шаманство. С большой вероятностью разницу не будет видно, как минимум алгоритм лучшего пути зависит от вендора и им можно управлять. Может будет видно сильнее ожидаемого, коррективу внесут повсеместные CDN с их умными балансировками. Эффект может быть отложенным, BGP в мировом масштабе вообще не сходится никогда.  Это может сработать один раз и не сработать другой. Причин не использовать гораздо больше чем использовать, если хочется строить стабильную и прогнозируемую сеть.

Интернет трафик в силу своей непредсказуемой природы в принципе сложно сбалансировать точно, плюс минус гигабит/c может изменится в течение одного часа. Но закономерности можно найти и они в первую очередь будут зависеть от источника внутри своей сети, на что мы всесильны влиять. Поэтому знать это и анализировать кто в сети пользуется и какими ресурсами, во сколько, как много, очень сильно помогает. Как минимум позволит отделить постоянную и периодические составляющие от неоднородностей, определить для чего нужны низкие задержки, а для чего нужна большая полоса. После этого как правило достаточно совершенно простых методов в рамках обычных механизмов маршрутизации, чтобы малыми усилиями (исходящим трафиком) изменить входящий, оставив всякие шаманства за бортом.

На картинке пример того как трафик убежал и не вернулся весь (телеграм немного поджал картинку, но я думаю эффект виден). Пример не искусственный, а следствие аварии. Весь период на графике 20 минут, но эффект сохранился и дальше если смотреть суточный график. Объём который не вернулся около гигабита/c, это единицы процентов от всего трафика.

​Коллега поделился ссылкой на скрипт который растит дерево, правда меленькое - бонсай https://gitlab.com/jallbrit/bonsai.sh. Автор очевидно может ставить галочку напротив пункта "Посадить дерево".

P.S. Когда-то давно, была похожая демка которая растила фрактальное дерево. Бесконечно можно за подобным наблюдать.

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

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

Базовывые настройки SNMP третьей версии у разных производителей, немного теории и примеры конфигураций.
Не могу сказать почему надо использовать v3, про авторизацию и шифрование все вроде знают, но всё равно не используют. Сдаётся мне что телеметрия будет скоро популярней чем SNMPv3 и вообще SNMP для целей мониторинга.

Картинка вообще хорошо отражает ситуацию с ICMP PMTUD, а не только то что происходит в списке рассылки Nanog. На который стоит подписаться потому что это, наверное, самое большое и активное комьюнити интернет-сетевиков, формально американских, но с глобальными вопросами.

Shodan как сервис:

pip install shodan
shodan init APIKEY
shodan alert create "Alert Name" IP list
shodan alert enable ALERTID type|any

Сообщения о найденных открытых службах приходят на почту или можно в консоли так же смотреть.
GitHub присутствует, там не только консольная утилита, а целый модуль для Python.

5 вещей которые делают IT современным, но я в два слова скажу облака в широком смысле и Sensu про который я впервые услышал. Буду смотреть что за зверь. Ruby меня настораживает (может и зря), но есть и Go вариант.