Введение

Любому системному администратору постоянно приходится иметь дело с данными, представленными в форме временных рядов (time series): статистика скачивания файлов, статистика запросов к серверам, данные об использовании системных и аппаратных ресурсов виртуальными машинами…

Чтобы все это хранить и обрабатывать, нужен адекватный и производительный инструмент.

Моя прошлая статья была о выборе ламп освещения для жилой мастерской. В этот раз расскажу про реализацию домашней автоматизации в том же помещении. Мастерская отапливается двумя электрическими обогревателями. Хотелось удаленно их включать, чтобы не приезжать в холодное помещение. И еще хотелось поддерживать заданную температуру, до этого при изменении температуры на улице приходилось каждый раз крутить «термостаты» обогревателей. Ну и управление освещением, датчик открытия двери и т.д.

Удивительно, но об этой подающей большие надежды Time Series DB довольно мало статей на хабре, всего 10, причём она упоминается там вскользь. А ведь версия 0.9 вышла довольно давно, больше месяца назад и была весьма ожидаемой. Итак, что же нового?

Чтобы отслеживать состояние работающих приложений, необходимо проводить их постоянный мониторинг. А если приложения выполняются в таком хорошо масштабируемом окружении, как Docker Swarm, то потребуется также и хорошо масштабируемый инструмент мониторинга. В этой статье говорится о настройке именно такого инструмента.

В процессе работы мы установим агенты cAdvisor на каждой ноде для сбора метрик хоста и контейнеров. Метрики будут сохраняться в InfluxDB. Для построения графиков на основе этих метрик воспользуемся Grafana. Эти инструменты распространяются с открытым исходным кодом и могут быть развернуты в виде контейнеров.

Для построения кластера мы будем использовать Docker Swarm Mode и развернем необходимые сервисы в виде стека. Это позволит организовать динамическую систему мониторинга, которая способна автоматически начинать мониторинг новых нод по мере их добавления в рой (swarm). Файлы проекта можно найти здесь.

Очень долго хотел написать статью, но не хватало времени. Нигде (в том числе на Хабре) не нашёл такой простой альтернативы munin, как описанная в этой статье.

В своей практике я достаточно много времени посвящаю проектированию и администрированию облачных инфраструктур различного назначения. В основном это Apache CloudStack. Данная система обладает отличными возможностями, но в части мониторинга, функциональности явно недостаточно (читайте — отсутствует), особенно, если на мониторинг смотреть шире чем мониторинг индивидуального объекта наблюдения (сервер, виртуальная машина).

В целом, в связи с более широкими требованиями к систем визуального анализа информации и потребностями в части интеграции с источниками данных стали распространяться специализированные решения для ad-hoc анализа данных, такие как Kibana, Grafana и иные. Данные системы могут интегрироваться со специализированными хранилищами временных рядов данных, одним из которых является InfluxDB. Статья расскажет о готовом решении, распространяемом в виде образа Docker, использующем LibVirt API, Grafana и InfluxDB, предназначенном для сбора и анализа параметров исполняющихся VM для гипервизора KVM.

→ Вводная часть (со ссылками на все статьи)

Сложные системы (распределённые/крупные/со сложной логикой/сложной системой данных) – как живой организм: подвижный, изменчивый и самостоятельный. Всё это требует постоянного контроля со стороны разработчиков/администраторов/DevOps-инженеров.

К этому выводу я пришёл, когда система несколько раз «загибалась» в ходе её разработки, настройки сервера и эксплуатации. Это натолкнуло меня на мысль, что мониторинг должен осуществляться не только на этапе производственной эксплуатации, но и на этапе разработки.

Обо всём по порядку…

Если использовать БД временных рядов (timeseries db, wiki) как основное хранилище для сайта со статистикой, то вместо решения задачи можно получить много головной боли. Я работаю над проектом, где используется такая база, и иногда InfluxDB, о которой пойдет речь, преподносила вообще неожиданные сюрпризы.

Когда-нибудь думали о мониторинге качества воздуха в доме или за его пределами: там, где живёте и работаете? Этот проект, который мы окрестили balenaSense, представляет собой установку для снятия показаний температуры, влажности, барометрического давления и качества воздуха, а также панель мониторинга, к которой вы можете получить доступ из любого места, чтобы увидеть сводную статистику и отслеживать тенденции.

Всем привет! Уже на следующей неделе стартуют занятия в группе «Java QA Engineer». Этому и будет приурочена нынешняя публикация.

Обзор:

Ежедневное выполнение автоматизированных регрессионных тестов в рамках каждодневной сборки неизбежно на настоящий момент. Приятно находить и сообщать об ошибках, сразу после их нахождения. Одновременно с этим проблематично проводить сотни автоматизированных тестов и удаленное параллельное выполнение. Как только у вас появляется набор автоматизированных регрессионных тестов, вы можете разбить его на несколько наборов по бизнес-модулям и запускать их параллельно, как часть ежедневного автоматизированного регрессионного тестирования. Большинство таких тестовых наборов выполняются на удаленной виртуальной машине, а результаты теста становятся доступны только после его выполнения. В противном случае, вы можете заглянуть в консоль jenkins, чтобы увидеть логи процесса выполнения теста. Иногда это раздражает. Было бы здорово иметь приложение, которое выдавало бы информацию о прохождении теста во время выполнения их на удаленных виртуальных машинах.

За последние несколько лет базы данных временных рядов (Time-series databases) превратились из диковинной штуки (узкоспециализированно применяющейся либо в открытых системах мониторинга (и привязанной к конкретным решениям), либо в Big Data проектах) в «товар народного потребления». На территории РФ отдельное спасибо за это надо сказать Яндексу и ClickHouse’у. До этого момента, если вам было необходимо сохранить большое количество time-series данных, приходилось либо смириться с необходимостью поднять монструозный Hadoop-стэк и сопровождать его, либо общаться с протоколами, индивидуальными для каждый системы.

Может показаться, что в 2019-м году статья про то, какую TSDB стоит использовать, будет состоять лишь из одного предложения: «просто используйте ClickHouse». Но… есть нюансы.

Действительно, ClickHouse активно развивается, пользовательская база растет, а поддержка ведется очень активно, но не стали ли мы заложниками публичной успешности ClickHouse'а, которая затмила другие, возможно, более эффективные/надежные решения?

В начале прошлого года мы занялись переработкой нашей собственной системы мониторинга, в процессе которой встал вопрос о выборе подходящей базы для хранения данных. Об истории этого выбора я и хочу здесь рассказать.

У себя в компании я часто сталкиваюсь, что нужно поднять какой-то сервис, чтобы "общупать" его досконально. Хотя PCшники у нас довольно мощные, но большую часть ресурсов съедают PyCharm и Chrome, а на виртуалки с экспериментами очень часто остаётся совсем мало.

Поэтому мы завели у себя небольшую стойку с парой-тройкой серверов для экспериментов и локального Gitlab'а. Но что-то пошло не так и очень захотелось поиграться с чем-то новым.

Приглашаем инженеров неравнодушных к теме DevOps на очередной открытый
DINS DevOps EVENING, который пройдет в нашем офисе на Старо-Петергофском, 19.

Встреча посвящена вопросам мониторинга. Денис Кошечкин расскажет о внутренней системе обработки событий, её устройстве, сильных и слабых сторонах. В рамках совместного доклада Евгений Тетеньчук поделится различными тонкостями настройки и администрирования Influx из личного опыта, а Вячеслав Швецов расскажет об организации сбора требований, получения данных и налаживанию механизмов алертинга в компании.

Под катом — подробнее о докладах и спикерах, ссылка на регистрацию для участия во встрече, материалы с прошлой встречи.

Скорее всего, сегодня уже ни у кого не возникает вопрос, зачем нужно собирать метрики сервисов. Следующий логичный шаг – настроить алертинг на собираемые метрики, который будет оповещать о любых отклонениях в данных в удобные вам каналы (почту, Slack, Telegram). В сервисе онлайн-бронирования отелей Ostrovok.ru все метрики наших сервисов льются в InfluxDB и отображаются в Grafana, там же настроен базовый алертинг. Для задач типа «нужно посчитать что-то и сравнить с этим» мы используем Kapacitor.


Kapacitor – часть TICK-стека, который умеет обрабатывать метрики из InfluxDB. Он может соединить несколько измерений между собой (join), из полученных данных вычислить что-то полезное, записать результат обратно в InfluxDB, отправить алерт в Slack/Telegram/почту.

Весь стек имеет крутую и подробную документацию, но всегда найдутся полезные штуки, которые в явном виде в мануалах не указаны. В этой статье я решил собрать ряд таких полезных неочевидных советов (основный синтаксис TICKscipt описан здесь) и показать, как их можно применять, на примере решения одной из наших задачек.

Поехали!

Добрый день, дорогой читатель! Эта статья возникла благодаря попытке взглянуть на операционный мониторинг со стороны аналитики. Она будет вам полезна, если:

• что-то из следующего списка хорошо знакомо: Grafana, InfluxDB, Prometheus, Zabbix или другая система мониторинга с похожими идеями;
• вы не эксперт/профессионал/уверенный миддл в различных типах отображения временных рядов и матстатистике (в противном случае для вас, весьма вероятно, будет скучновато);
• есть желание взглянуть на некоторые аспекты «под микроскопом».

Если вы решили, что условия выше соблюдены, добро пожаловать под кат.

Всем привет!

Занимаюсь тестированием производительности. И очень люблю настраивать мониторинг и любоваться метриками в Grafana. А стандартом для хранения метрик в инструментах для подачи нагрузки является InfluxDB. В InfluxDB можно сохранять метрики из таких популярных инструментов, как:

• Apache.JMeter
• Gatling
• LoadRunner Enterprise
• Yandex.Tank

Работая с инструментами по тестированию производительности и их метриками, накопил подборку рецептов программирования для связки Grafana и InfluxDB. Предлагаю рассмотреть интересную задачу, которая возникает там, где есть метрика с двумя и более тегами. Думаю, это не редкость. И в общем случае задача звучит так: подсчёт суммарной метрики по группе, которая делится на подгруппы.

Очень часто за свой 15летний опыт работы разработчиком ПО и тимлидом я сталкиваюсь с одним и тем же. Программирование превращается в религию — редко кто пытается внедрять технологии на основе разумного выбора, аргументированно, с учетом ограничений, возможностей переносимости, оценки степени привязки к вендору, реальной цены, перспектив технологии и свободы лицензий. Разработчики ходят на конференции или читают посты — заводятся на хайповость, а их ИТ директоров и менеджеров кормят не только сказками о светлом аджайл будущем на мероприятиях различные визионеры, сейлы и консалтеры. И получается что технологии оказались в проекте не с учетом удобства разработки и внедрения, нефункциональных требований проекта, а потому что это хайпово и google у себя использует, amazon рекомендует(хотя их вакансии говорят что сами не часто используют) или принято высочайшее решение руководства компании внедрять «это».


Но особое веселье — это выбор базы данных. Чем больше объемы хранимой информации, сложнее структуры данных в проекте и их изменения/эволюция, выше требования ко времени отклика или производительности тем дороже стоит ошибка выбора в начале на поздних стадиях проекта.

Сделал dashboard Postgresql overview для postgres_exporter.

Чем отличается от других дашбородов postgres_exporter?

Я объединил все другие дашборды postgres_exporter в один.

Этот дашборд показывает общую информацию по кластеру.

Скриншоты и краткая инструкция по установке: postgresql, postgres_exporter, prometheus, grafana под катом.

Митап состоится 13 августа в 19:00.

Евгений Тетеньчук поделится опытом использования Influx. Поговорим о проблемах с Telegraf, Kapacitor и Continuous Queries. Кирилл Кузнецов из компании Злые Марсиане расскажет, как работает горизонтальное масштабирование приложений в Kubernetes.

Участие как всегда бесплатное, но нужно зарегистрироваться. Подробная программа — под катом.

У компаний, которым необходимо управлять данными и приложениями на более чем одном сервере, во главу угла поставлена инфраструктура.

Для каждой компании значимой частью рабочего процесса является мониторинг инфраструктурных узлов, особенно при отсутствии прямого доступа для решения возникающих проблем. Более того, интенсивное использование некоторых ресурсов может быть индикатором неисправностей и перегрузок инфраструктуры. Однако мониторинг может использоваться не только для профилактики, но и для оценки возможных последствий использования нового ПО в продакшне. Сейчас для отслеживания потребляемых ресурсов на рынке существует несколько готовых к использованию решений, но с ними, тем не менее, возникают две ключевые проблемы: дороговизна установки и настройки и связанные со сторонним ПО вопросы безопасности.