Иженер систем мониторинга
Мы с Аней не тестировщики. Мы относимся к эволюционирующему классу IT-специалистов — системным администраторам или operations-инженерам. Но в нашей повседневной жизни мы тоже не обходимся без тестов. И сегодня мы хотим немного поговорить про Splunk. Точнее, вся наша статья будет именно про него.
Zabbix — замечательный продукт для администраторов крупных программно-аппаратных комплексов. Он настолько хорош, что может использоваться не только крупным бизнесом, но и средне-малым бизнесом, и даже в pet-проекте. В общем, у меня есть небольшой опыт работы с Zabbix'ом и я смело могу рекомендовать его к использованию.
Правда я не могу сказать, что понимаю "философию Zabbix'а". Несмотря на обширную подробную документацию на русском языке, мне было сложно погружаться в мир Zabbix'а — создавалось ощущение, что мы с разработчиками одни и те же вещи называем разными именами. Возможно потому, что Zabbix создавался админами для админов, а я всё-таки больше разработчик и пользователь.
Тем не менее, для запуска Zabbix'а и для мониторинга основных параметров компьютерных систем (процессор, память и т.п.) навыков обычного linux-пользователя хватает. Есть большое количество плагинов от сторонних разработчиков, расширяющих возможности Zabbix'а. Для моих нужд мне потребовалось настроить мониторинг Redis-сервера. Я немного покопался в коде имеющихся плагинов и на их примере выяснил, что архитектура Zabbix'а позволяет достаточно просто подключать к мониторингу любые параметры информационных систем, которые могут быть выражены в числовом виде.
Под катом — пример Zabbix-плагина с моим пояснением по терминологии Zabbix'а. Кому-то этот пример покажется наивным, ну а кому-то поможет проще освоиться с понятиями. В любом случае, Zabbix достаточно велик для того, чтобы ощупать его с разных сторон.
Счастливые люди успешнее на 50%. А значит они на 50% более продуктивные, если счастливы и находят смысл в своей работе. При этом они на 88% более лояльны, потому что понимают, что работают не зря, посвящая половину своего времени развитию этого бизнеса— доктор Корри Блок, эксперт по стратегии бизнеса в области оценки счастья.
Дзииииииинь! На часах 3 утра, вы смотрите чудесный сон, и вдруг — звонок. На этой неделе вы дежурите, и, видимо, что-то случилось. Автоматизированная система зовет разобраться, в чем дело. Это важный момент управления современными компьютерными системами, но давайте посмотрим, как сделать уведомления удобнее для людей.
Знакомьтесь с философией мониторинга, родившейся за несколько десятилетий моих дежурств в разных командах по мониторингу. На нее во многом повлияла настоящая библия от Роба Еващука My Philosophy on Alerting (Моя философия уведомлений), включенная в книгу по Google SRE, и книга Джона Олспо Considerations for Alert Design (Замечания по настройке оповещений).
Келли Данн, Ариджит Мукхерьи и Максим Петаццони — спасибо за помощь в редактировании поста.
Я решил придумать красивую аббревиатуру, как у метода USE Брендана Грегга или метода RED Тома Уилки. Я зову это метод CASE. Он описывает четыре момента, на которые нужно обратить внимание при работе с автоматическим мониторингом:
Решение поставленной перед разработчиком задачи бывает найти нелегко. Но как только оно получено, автору сразу хочется поделиться им со всем миром, ведь это так здорово — «отгружать» код. Неиспользуемая программа — это не что иное, как цифровой мусор. Чтобы не тратить время на никому не нужный софт, современные разработчики поставляют функциональность небольшими порциями, разбивая процесс на короткие итерации.
Такой способ создания программного обеспечения используется в процессах Непрерывной интеграции (Continuous Integration) и Непрерывного развертывания (Continuous Deployment), или CI/CD-цепочке. В этой статье мы пройдем по всем шагам настройки такой цепочки, используя для ее построения бесплатные облачные сервисы.
Про непрерывную интеграцию и её целебные свойства слышали, наверное, все — не буду повторять написанное в многочисленных вводных статьях и обзорах и рассказывать, что же такое непрерывная интеграция, и как именно она упрощает жизнь разработчикам, релиз-инженерам и менеджерам. Предполагается, что читатель и сам прекрасно понимает, что CI — вне зависимости от применяемых в проекте языков программирования — это стопроцентно правильный подход, но… Но вот до практического его внедрения руки в силу разных причин пока не дошли.
Данная статья — инструкция по прикручиванию базовой непрерывной интеграции (build-test-deploy) к гитхабовским C/C++ проектам с CMake сборкой — по непонятным причинам, на Хабре такого до сих пор не проскальзывало. Впрочем, если моё гугл-фу подвело меня, и таки проскальзывало — не беда. Лишний туториал, описывающий всё под несколько другим углом и предостерегающий от неповторимого набора набитых автором шишек, совершенно точно не повредит.
Code review — инженерная практика в терминах гибкой методологии разработки. Это анализ (инспекция) кода с целью выявления ошибок, недочетов, расхождения в стиле написания кода и понимания, решает ли код поставленную задачу.
Сегодня расскажу о том, как мы организовали процесс review для конфигурации мониторинга в Zabbix. Статья будет полезна тем, кто работает с системой мониторинга Zabbix, как в большой команде, так в одиночку, даже если у вас «десять хостов, что там ревьюить».
Всем привет! В своей прошлой статье я писал об организации модульной системы мониторинга для микросервисной архитектуры. Ничего не стоит на месте, наш проект постоянно растёт, и количество хранимых метрик — тоже. Как мы организовали переход с Graphite+Whisper на Graphite+ClickHouse в условиях высоких нагрузок, об ожиданиях от него и результатах миграции читайте под катом.
