Forwarded from Мониторим ИТ
Посмотрите на эту картинку. Да, это из известной сказки, в которой лживый мальчик кричал «Волки! Волки!» в то время, когда волки доедали каких-то других козлят. А когда волки пришли за его козлятами — никто не прибежал с вилами на помощь.
Если из мониторинга прилетают алерты без повода через какое-то время на них перестанут реагировать. Очень много таких ситуаций возникает когда нет ответственного за мониторинг и каждая группа администраторов добавляет туда свои метрики и алерты. Ниже несколько рекомендаций, чтобы не выпускать ситуацию из под контроля.
1️⃣ Выгружать отчёты по событиям/алертам. Выявлять повторяющиеся. В идеале каждое событие должно появляться из-за какого-то нового бага в коде или настройках.
2️⃣ События должны быть только по тому, что требует вмешательства. Если можно автоматизировать реакцию на событие — это нужно сделать как можно скорее и никого об этом не оповещать. Это касается повторяющихся событий, причину которых невозможно пофиксить.
3️⃣ В системах мониторинга или алертинга есть (или должен быть) такой Duration. Это позволит не реагировать на разовые всплески. Важно уточнить у администраторов информационных систем насколько долго эти системы могут работать в «красной зоне».
4️⃣ По каждому событию/алерту в системе мониторинга должна фиксироваться реакция ответственного сотрудника. Если на какие-то события реакции нет — нужно выяснить кто заказывал мониторинг. Может это уже никому не нужно.
5️⃣ Этот список не означает, что нужно собирать только минимальный набор ключевых метрик. Нужно собирать их как можно больше и различными технологиями (встривание в код, синтетические транзакции, анализ трафика и т.д.). Важно отключить генерацию событий и оповещения на то, на что некому реагировать.
6️⃣ Создавайте связанные триггеры. В системах Zabbix и Prometheus это можно делать. Не нужно плодить 100500 событий из-за отказавшего коммутатора на удалённой площадке.
7️⃣ Если есть мониторинг приложения, которое разрабатывается парнями через стенку, важно, чтобы они поучаствовали в определении метрик мониторинга, на которые должна реагировать эксплуатация (да они сами что-то могли записать в баг-репорт).
Хотел написать 10, но на 7 мысль дальше не идёт. Если хотите небольшое продолжение — я как-то писал на Медиуме о борьбе с событийной усталостью. Малую толику информации можно посмотреть там.
Если из мониторинга прилетают алерты без повода через какое-то время на них перестанут реагировать. Очень много таких ситуаций возникает когда нет ответственного за мониторинг и каждая группа администраторов добавляет туда свои метрики и алерты. Ниже несколько рекомендаций, чтобы не выпускать ситуацию из под контроля.
1️⃣ Выгружать отчёты по событиям/алертам. Выявлять повторяющиеся. В идеале каждое событие должно появляться из-за какого-то нового бага в коде или настройках.
2️⃣ События должны быть только по тому, что требует вмешательства. Если можно автоматизировать реакцию на событие — это нужно сделать как можно скорее и никого об этом не оповещать. Это касается повторяющихся событий, причину которых невозможно пофиксить.
3️⃣ В системах мониторинга или алертинга есть (или должен быть) такой Duration. Это позволит не реагировать на разовые всплески. Важно уточнить у администраторов информационных систем насколько долго эти системы могут работать в «красной зоне».
4️⃣ По каждому событию/алерту в системе мониторинга должна фиксироваться реакция ответственного сотрудника. Если на какие-то события реакции нет — нужно выяснить кто заказывал мониторинг. Может это уже никому не нужно.
5️⃣ Этот список не означает, что нужно собирать только минимальный набор ключевых метрик. Нужно собирать их как можно больше и различными технологиями (встривание в код, синтетические транзакции, анализ трафика и т.д.). Важно отключить генерацию событий и оповещения на то, на что некому реагировать.
6️⃣ Создавайте связанные триггеры. В системах Zabbix и Prometheus это можно делать. Не нужно плодить 100500 событий из-за отказавшего коммутатора на удалённой площадке.
7️⃣ Если есть мониторинг приложения, которое разрабатывается парнями через стенку, важно, чтобы они поучаствовали в определении метрик мониторинга, на которые должна реагировать эксплуатация (да они сами что-то могли записать в баг-репорт).
Хотел написать 10, но на 7 мысль дальше не идёт. Если хотите небольшое продолжение — я как-то писал на Медиуме о борьбе с событийной усталостью. Малую толику информации можно посмотреть там.
Forwarded from Мониторим ИТ
Подвезли стафф для линукс-администраторов. Ещё одна интересная статья от уже известного вам Антуана Солничкина, на которую стоит обратить внимание. Пишет про мониторинг MySQL при помощи специализированного экспортера для Prometheus и создании бизнес-дашборда в Grafana. Там есть список ключевых метрик и парав видосов с объяснениями.
Forwarded from linkmeup
Это всё что вам нужно знать о раздаче котят :)
https://habr.com/ru/post/487120/
https://habr.com/ru/post/487120/
Хабр
Как правильно раздавать котят
Раздача котят по DHCP Привязать к котёнку поводок Запустить котёнка в толпу Когда хозяин будет найден, он сам отвяжет котёнка от поводка. Раздача котят по HTTP...
Я давал ссылку на cheatsheet по регэкспам. А вот и ещё примеры с наглядными схемами работы
Telegram
Mikrotik Ninja
Классный cheat sheet по регулярным выражениям. Все подкреплено примерами с интерактивным выполнением
#regexp #cheatsheet https://medium.com/factory-mind/regex-tutorial-a-simple-cheatsheet-by-examples-649dc1c3f285
#regexp #cheatsheet https://medium.com/factory-mind/regex-tutorial-a-simple-cheatsheet-by-examples-649dc1c3f285
Forwarded from Записки админа
🔎 https://ihateregex.io/ - пачка примеров регэкспов, с объяснением того, как они работают. #линк #regexp
Никому не нужны твои знания всех ключей Ansible и годы поддержки MS SQL. Чтобы быть востребованным на рынке нужно уметь быстро учиться и видеть широкий горизонт перед собой. Нужно правильно строить процессы работы, а не заучивать команды.
Эти мысли в очередной раз пришли в голову во время курсов по DevOps и SRE.
Пост о том, как прошли курсы и что я узнал.
https://medium.com/@dbubnov/%D0%BC%D0%B8%D1%80%D1%83-%D0%BD%D1%83%D0%B6%D0%BD%D1%8B-%D0%B8%D0%BD%D0%B6%D0%B5%D0%BD%D0%B5%D1%80%D1%8B-cb2908c0952f
Эти мысли в очередной раз пришли в голову во время курсов по DevOps и SRE.
Пост о том, как прошли курсы и что я узнал.
https://medium.com/@dbubnov/%D0%BC%D0%B8%D1%80%D1%83-%D0%BD%D1%83%D0%B6%D0%BD%D1%8B-%D0%B8%D0%BD%D0%B6%D0%B5%D0%BD%D0%B5%D1%80%D1%8B-cb2908c0952f
Medium
Миру нужны инженеры!
Когда вы не интересуетесь окружающим миром, вам совершенно неизвестно чего вы не знаете(С) Не помню из какой книги
Forwarded from linkmeup
Давненько нас не обвиняли, что мы тут все помешанные на Wi-Fi.
Дельный набор советов по поиску проблем на основе понимания типа фреймов и что в них может пойти не так.
https://keepcalmandping.online/2020/02/07/troubleshooting-wlan-issues-with-802-11-frames-cwap9/
Дельный набор советов по поиску проблем на основе понимания типа фреймов и что в них может пойти не так.
https://keepcalmandping.online/2020/02/07/troubleshooting-wlan-issues-with-802-11-frames-cwap9/
Mikrotik Ninja via @like
В Mikrotik есть инструмент Sniffer (в меню Tools), который позволяет дампить весь трафик или отфильтрованный по каким-то условиям. Дамп можно открыть прямо в WinBox или скопировать на компьютер и наглядно посмотреть на него в Wireshark.
А в IP - Firewall - Mangle есть действие sniff-tzsp. Мало кто знает что оно делает. Этот экшн снифит трафик, специальным образом упаковывает его и отправляет по нужному адресу в сети. То есть этакий Sniffer, только с отправкой дампа на нужный узел (ага, Wireshark) в реальном времени.
Проблема в том, что распаковать этот tzsp непросто. Поэтому эта фича часто остается незамеченной. Здесь попытка написать распаковщик для этого протокола. Будем ждать от автора работающий бинарник.
Если вы знаете работающий распаковщик TZSP, то напишите о нем в комментариях.
🤩 - супер! Буду пользоваться
👽 - а че так можно было? До чего техика дошла!
🤢 - вряд ли кому-то пригодится
А в IP - Firewall - Mangle есть действие sniff-tzsp. Мало кто знает что оно делает. Этот экшн снифит трафик, специальным образом упаковывает его и отправляет по нужному адресу в сети. То есть этакий Sniffer, только с отправкой дампа на нужный узел (ага, Wireshark) в реальном времени.
Проблема в том, что распаковать этот tzsp непросто. Поэтому эта фича часто остается незамеченной. Здесь попытка написать распаковщик для этого протокола. Будем ждать от автора работающий бинарник.
Если вы знаете работающий распаковщик TZSP, то напишите о нем в комментариях.
🤩 - супер! Буду пользоваться
👽 - а че так можно было? До чего техика дошла!
🤢 - вряд ли кому-то пригодится
mikrotik.me
golang сниффер tzsp
Разбираемся как разобрать IP пакет, для каких либо нужд, делаем заготовку.
В личку добавляют, что сам tool - Sniffer умеет отправлять дамп на удаленный хост в реальном времени. Как правильно настроить Wireshark для приема этого дампа по ссылке
Спасибо, Макс
#wireshark #mikrotik #sniffer
Спасибо, Макс
#wireshark #mikrotik #sniffer
Отчет DORA State of DevOps за 2019 год перевели на великий и могучий.
Если ты не слышал про этот документ, то знай - это новейшие исследования и тренды в DevOps, которые однажды доберутся и до тебя, %username%
Если ты не слышал про этот документ, то знай - это новейшие исследования и тренды в DevOps, которые однажды доберутся и до тебя, %username%
Хабр
Отчет DORA State of DevOps 2019, теперь и на русском языке
Привет, Хабр! Я сделал перевод на русский язык отчёта DORA State of DevOps 2019. Предлагаю ознакомиться с отчетом, ведь это не только самое актуальное DevOps-исследование на данный момент, но и...
Forwarded from NetDevOps Space
Не питоном единым...
Так можно назвать статью, в которой Kelvin Tegelaar рассказывает об истории создания скрипта на Powershell для проверки скорости соединения. Он создал его по просьбе своего друга, которого попросил один из клиентов, который хотел иметь возможность запускать тесты скорости и заставлять систему RMM генерировать алерты каждый раз, когда падает скорость соединения.
Он создал скрипт на PowerShell, который использует утилиту CLI от speedtest.net
Прям как в "Доме, который построил Джек".
Что умеет делать скрипт:
1. Возвращает внешний и внутренний IP для используемого интерфейса.
2. Текущий провайдер.
3. Скорость загрузки и выгрузки.
4. Jitter, задержку и потери пакетов при соединении.
5. Сервер, который он использует
6. Фактический адрес speedtest.net для сравнения результатов.
Круто!-👍
Вон оно как!- 🤔
Я бы лучше сделал!-😏
Хотите поделиться своим мнением? Добро пожаловать в чат - https://t.me/automate_devnet
#powershell
Так можно назвать статью, в которой Kelvin Tegelaar рассказывает об истории создания скрипта на Powershell для проверки скорости соединения. Он создал его по просьбе своего друга, которого попросил один из клиентов, который хотел иметь возможность запускать тесты скорости и заставлять систему RMM генерировать алерты каждый раз, когда падает скорость соединения.
Он создал скрипт на PowerShell, который использует утилиту CLI от speedtest.net
Прям как в "Доме, который построил Джек".
Что умеет делать скрипт:
1. Возвращает внешний и внутренний IP для используемого интерфейса.
2. Текущий провайдер.
3. Скорость загрузки и выгрузки.
4. Jitter, задержку и потери пакетов при соединении.
5. Сервер, который он использует
6. Фактический адрес speedtest.net для сравнения результатов.
Круто!-👍
Вон оно как!- 🤔
Я бы лучше сделал!-😏
Хотите поделиться своим мнением? Добро пожаловать в чат - https://t.me/automate_devnet
#powershell
Cyberdrain
Monitoring with PowerShell: Monitoring internet speeds
This is meta description
Как трубят во всех каналах про сети, Mikrotik имплементирует VXLAN в 7 версии RouterOS. А это значит, что через пару лет Mikrotik можно будет увидеть в датацентрах.
Первая лаба с VXLAN уже описана в Интернетах - ученье свет!
#vxlan
Первая лаба с VXLAN уже описана в Интернетах - ученье свет!
#vxlan
StubArea51.net
MikroTik – RouterOSv7 first look – VxLAN
VxLAN support added in 7.0beta5 MikroTik announced VxLAN support on Valentine’s Day (Feb 14th) of 2020. This is a significant feature addition for RouterOSv7 as it will pave the way for a num…
https://snafucatchers.github.io - мета-анализ постмортемов из Etsy, IBM, и IEX
Советуют в чатике курсов
#postmortem
Советуют в чатике курсов
#postmortem
Поучительная история, подтверждающая мой недавний пост про инженеров. Иногда возникают такие проблемы, которые можно решить только обладая глубокими познаниями в широком стеке технологий
https://dou.ua/lenta/columns/story-of-new-years-eve-release/
#архитектор
https://dou.ua/lenta/columns/story-of-new-years-eve-release/
#архитектор
Интересная презентация о тестировании инфраструктурного кода. Кажется, 2019 год был годом тестов инфраструктуры. Об этом рассказывали на всех российских конференциях. Я тоже рассказывал
#ansible #molecule #tests
#ansible #molecule #tests
Хабр
Ansible playbooks — это код: проверяем, тестируем, непрерывно интегрируем. Иван Пономарёв
Предлагаю ознакомиться с расшифровкой доклада Ивана Пономарёва «Ansible playbooks — это код: проверяем, тестируем, непрерывно интегрируем». Рефакторинг кода может быть увлекательным, особенно если...
В нашем чате воюют с Windows 10 и SMB шарами. Вдруг кому-то из вас эта информация тоже поможет:
#windows #smb #samba
Свежеустановленая win 10 ltsc 1809 не видит самбу на линуксе? Не открывает ни по \\ip, ни в сетевом окружении не видно, хотя машины с win7 с ней успешно работают. В интернетах пишут про отключение SMB3 на винде. Оно помогает, да. Но отключает так же и SMB2, чего хотелось бы избежать.
Windows 10 по сравнению с предыдущими не хочет ходить на самбовые шары гостем. Лечится вот этим (https://www.nodeum.io/howto/guest-access-in-smb2-disabled-by-default-in-windows-10)#windows #smb #samba
Telegram
Sysadminka
Make Sysadmins Great Again!
Друзья, представляемся при входе.
О нас: проводим встречи sysadminka.timepad.ru, общаемся на тему IT систем в широком смысле. Правила: https://t.me/sysadminka/141069
Default city - Челябинск.
Offtop chat: https://t.me/+ghTI-B98
Друзья, представляемся при входе.
О нас: проводим встречи sysadminka.timepad.ru, общаемся на тему IT систем в широком смысле. Правила: https://t.me/sysadminka/141069
Default city - Челябинск.
Offtop chat: https://t.me/+ghTI-B98
В далеком 2011 Heroku сформировали набор принципов по построению веб приложений и сервисов. К своему стыду, я о нем узнал только сегодня. Посмотрите краткий обзор методологии The 12-Factor Applications
Pryazhnikov
Обзор методологии “The 12-Factor Applications”
Краткий конспект принципов из методологии “The 12-Factor Applications” от компании Heroku
Бэкап Шрёдингера - бэкап, состояние которого неизвестно до момента его восстановления
Отсюда. Заучить и повторять перед сном для успокоения нервной системы
#ops #lessons
Отсюда. Заучить и повторять перед сном для успокоения нервной системы
#ops #lessons
www.netmeister.org
(A few) Ops Lessons We All Learn The Hard Way
Ops is hard. What have learned so far?