×

Мониторинг серверов и сервисов с TICK Stack

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

Обзор будет полезен системным администраторам, специалистам DevOps, клиентам, которые сотрудничают с IT-сервисами и разработчикам.

TICK Stack — бесплатный комплекс программ, простой в использовании и гибкий в настройке, с механизмом агрегации и удобными кастомизируемыми функциями выбора.

Существуют и платные решения для таких задач, например DataDoghq. Но так как требования к IT-отделу обычно ограничены стандартными задачами, нам не нужны дорогостоящие программы с широким функционалом, и TICK идеально подходит под наши требования.

Структура TICK Stack

Это ядро ​​с открытым исходным кодом или стек TICK, состоящий из четырех модулей: Telegraf, InfluxDB, Chronograf и Kapacitor.

Рассмотрим каждый компонент отдельно.

Telegraf

Telegraf — управляемый плагином сервер для сбора показателей и отчетности. Telegraf интегрируется с разнообразными метриками, событиями и логами, обращаясь непосредственно к контейнерам и системам, в которых он работает, достает метрики из сторонних API или даже прослушивает показатели через сервисы ConsumerD и Kafka. Он также имеет выходные плагины для отправки показателей во множество других хранилищ данных, служб и query-сообщений, включая InfluxDB, Graphite, OpenTSDB, Datadog, Librato, Kafka, MQTT, NSQ.

InfluxDB

InfluxDB — Time Series Database, построенная с нуля, для обработки высоких нагрузок на запись и запрос. InfluxDB — это специализированное высокопроизводительное хранилище данных, написанное специально для временных данных (мониторинг DevOps, метрики приложений, данные датчика IoT и аналитика в реальном времени). Оно позволяет сохранять пространство на своем компьютере, настраивая InfluxDB для хранения данных в течение определенного периода времени и по его истечению — автоматического удаления любых нежелательных данных из системы. InfluxDB использует язык запросов, подобный SQL, для взаимодействия с данными.

Chronograf

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

Kapacitor

Kapacitor — собственный механизм обработки данных. Он может обрабатывать как потоковые, так и пакетные данные от InfluxDB. Kapacitor позволяет подключать собственную пользовательскую логику или пользовательские функции для обработки предупреждений с динамическими порогами, сопоставления показателей для шаблонов, вычисления статистических аномалий и выполнения определенных действий на основе этих предупреждений, таких как динамическая перебалансировка нагрузки. Kapacitor интегрируется с HipChat, OpsGenie, Alerta, Sensu, PagerDuty, Slack и т. д.

Как это работает

Это Dashboard. Он показывает статус уведомлений, используя таймлайн. Таким образом, пользователь может видеть, когда и какие события произошли в системе.

С помощью инструмента мы можем проверить: CPU, RAM, место на жестком диске, интенсивность сетевого трафика, количество соединений с веб-сервером, запросы на сайты, MS SQL запросы, количество операций записи и чтения, RabbitMQ.

Если вам нужна дополнительная функциональность, можно обновить инструмент плагинами из list of opportunities.

Системные характеристики сервера

Этот борд показывает использование CPU, использование диска, Lead, Memory Gigabytes Used, Network Mb и т. д.

Борд мониторинга Linux, показывающий состояние соединения, свободное пространство в оперативной памяти трех серверов и количество активных подключений к веб-серверу. Последнее не является стандартной настройкой, но мы хотим отслеживать, сколько запросов приходит на сайт. И можем проверить это таким способом.

Хронограф позволяет сделать выборку из базы данных, создавая уникальные борды под потребности команды или клиента. Приведу еще несколько примеров.

Выше приведены диаграммы двух серверов Windows: процессор и оперативная память. Это три графика с тремя параметрами для двух серверов (шесть параметров), которые одновременно демонстрируются на экране.

Зависимости и прогнозирование

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

Например, можно создать график событий за определенный период, чтобы проанализировать, что произошло в течение дня, недели, месяца.

Простая и настраиваемая система оповещений

TICK позволяет настроить уведомления через удобные каналы, которые будут отвечать задачам конкретной системы мониторинга и поддержки. Оповещения могут быть направлены в Slack, Page Duty, Telegram и так далее.

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

Можно автоматизировать устранение некоторых сбоев (например, переполнение буфера оперативной памяти, очистка кеша веб-сервера и т. д.) через скрипты оповещений.

Так выглядит классификация алертов для оповещений с настраиваемой системой приоритетов (низкий и высокий приоритет алерта).

Как работает приоритетность алертов

Предупреждение появляется в специальном канале в Slack. Это очень удобно. Не нужно открывать дополнительное приложение или браузер. Slack широко используется.

Проверка статуса оповещения позволяет быстро генерировать сообщение с информацией, где и что исправить. Это упрощает командную работу.

Приоритизация алертов позволяет фильтровать несрочные оповещения для нерабочих часов. Но сверх важные алерты, несвоевременная реакция на которые подвергает риску инфраструктуру или репутацию компании, система (по желанию юзера) может отправлять в нерабочее время. Таким образом, вы быстро реагируйте на угрозу даже в 2 часа ночи, если Галактика в опасности.

Кто может использовать TICK

TICK ​​- полезный технический стек для таких специалистов:

Разработчики

Большое количество плагинов, таких как: MySQL,MS SQL. Elastic Search, RabbitMQ и другие, — могут помочь разработчикам отслеживать узкие области использования программного обеспечения и повышать эффективность работы.

Администраторы

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

Клиенты

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

Заключение

Система позволяет контролировать большой парк серверов. Метод развертывания довольно прост и может быть автоматизирован с помощью Ansible или другого агрегатора. Функция выбора показателей позволяет создавать информативные графики, быстро анализировать их и прогнозировать риски.


Эту статью вы также можете прочитать на английском языке.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Схожі статті




42 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Ок, вставлю свої 5 копійок.

1. В TICK входить InfluxDB, інших варіантів немає. Висока доступність в InfluxDB коштує грошей і здається пристойних. Але знову ж, це серверний софт, це не ліцензія на Windows XP.
2. Якщо потрібний rollup/retention/storage aggregation/downsampling — то він тут дуже дивний. Типу є через Continuous Queries (чи Kapacitor), але налаштовується досить проблемно www.slideshare.net/...​luxdata/downsampling-data. Основний недолік, що для кожного точності необхідна окрема measurement база. Тобто зобразити це все на одному графіку не можливо...і це, чорт забирай, костиль. Окрім цього багато хто скаржиться на те, що це все повільно працює. github.com/...​data/influxdb/issues/7198
3. Також здається лімітовані вбудовані логічні функції. В порівнянні з Graphite. Але ось це якраз відносно.

Якщо це не критично — то мабуть можна юзати. Інакше я б дивився в сторону класичного python/go Graphite (якщо невисокі навантаження), Graphite з альтернативними storage-engine (Cassandra, ClickHouse). Як би його не ганьбили, але це чудовий продукт. Також звісно man statsd.

Також здається лімітовані вбудовані логічні функції. В порівнянні з Graphite. Але ось це якраз відносно.

попробовал строить дашборды в InfluxDB+Grafana:
— по сравнению с Graphite+Grafana, любые вычисления с метриками — просто какой-то адъ и содомия
— построение дашбордов в Graphite+Grafana уже не кажется ресурсоемким и неудобным

Еще стоит добавить что у chronograf c визуализацией все заметно хуже чем у графаны, зато отличный Data Explorer — иструмент по выборке данных из инфлюкса, для дебага например.
Я бы советовал если уж ставить TICK stack то сбоку добавлять еще графану красиво визуализирующую метрики из инфлюкса.
И касательно построения правил алертинга — проще сразу делать все через TICKscript, визуальный конструктор умеет не все из того что можно сделать через скрипты и на поздних этапах скорее мешает чем помогает :)

посмотрел этот TICK Stack, с информационной безопасностью там просто никак — обращения к InfluxDB с агентов из-под административной учетки этой базы, логин/пароль которой лежит на клиентах в открытом виде в текстовом файле

А в чем преимущества этого стека в сравнении с Prometheus+Grafana+Alertmanager?

В пропрієтарних опціях для HA і скалабіліті, там нижче вже відповіли ))) Тоді як в прометеус це є з коробки ємніп.

а Prometheus має сенс, коли немає мікросервісів, кубеса та взагалі контейнерів?
Federation в Prometheus це ж не HA, а scalability?
там відразу є якийсь базовий моніторинг через node_exporter, чи потрібно кожний параметр додавати окремо?
P.S. шукаю срібну кулю, яка гарантовано вб’е zabbix

PRTG 8-)
Я не жартую. Там справді гарний продукт

🤣🤣🤣🤣🤣😂😂😂😁😁😁😁😁

но что интересно, хоть и полностью проприетарное решение, но под Grafana есть соответствующий официальный плагин
мне, чтобы в Grafana вывести данные с lpar2rrd/stor2rrd, пришлось между ними еще Graphite вставлять

> P.S. шукаю срібну кулю, яка гарантовано вб’е zabbix
Prometheus чудовий варіант, раджу. Можете ще поглянути в сторону Sensu.

Та взагалі все краще за Zabbix, навіть мабуть Nagios.

> а Prometheus має сенс, коли немає мікросервісів, кубеса та взагалі контейнерів?

Prometheus популярний в K8s бо чудово інтегрується з ним (надає дані в форматі Prometheus) і все разом розвивається. Я результат з ним легко почати працювати.

Пользовался обоими, преимущества все спорные а отличия имхо в подходе — samples/aggregated data (prometheus) против raw data (TICK) а также pull (prometheus) vs push (TICK) — второе интуитивней понятно простому админу и не вызывает внутреннего отторжения — запросы на таких данных интуитивней и понятней результат — в язык запросов прометеуса нужно вникать с бутылкой а результат иногда будет не тот что ожидался опять же из за особенности данных и операций над ними. В общем порог вхождения несопоставим. У прометеуса круче коммунити зато и отзывчивей, это в некоторой степени нивелирует новичку вхождение. За заббикс в некоторых чатах вообще банят так что промолчу) а вот ELK для метрик тоже очень удобно но тупо дорого и тормознуто — скорости отрисовки дашбордиков в графане за месячный период несопоставимы нет (или не было недавно) возможности даунсэмплинга ну индекс со всеми оптимизациями для метрик все равно будет занимать на порядок больше — в общем будете платить за ELK больше чем за енв который вы им мониторите. Есть конечно соображение что ELK у вас будет все равно для логов — поэтому на старте проекта можно только им вполне обойтись ну скажем год — два но потом все равно придете к отдельной TSDB для метрик. Сори за многа букв, все чисто мое имхо.

Пользовался обоими

так и который из двух в итоге? или что-то третье?

Сори, не знаю)
Нужно смотреть от проекта, сроков, пожеланий и тп наверное.

интересовало — что в итоге реально у себя используется?
у автора TICK Stack
а у всех остальных?

TICK заменил ELK+metricbeat на старом проекте — работало без замечаний
Prometheus на новом — работает тоже :)

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

У меня противоположный опыт — в influxdb ради псевдо-SQL совместимости придумали очень неудобный синтаксис, после перехода на prometheus время, потраченное на крафтанье очередного запроса, сократилось раза в 3

В тому, що Prometheus — це pull-модель, TICK — це push. Це досить різні речі. Мені наприклад більше подобається push моніторингові системи, але думки різняться.

Prometheus — це чудовий продукт, але це більше моніторингова система з можливістю малювання графіків. Коли ж TICK/Graphite — це відображення графічних даних з можливостями моніторингу. Це все відносно звісно.

Окрім цього Prometheus не призначений для дійсно довгого зберігання метрик (я маю на увазі 1-2-3 роки), rollup/retention/storage aggregation/downsampling відсутній і не планується. Висока доступність досить сумнівна, у випадку Prometheus — це просто декілька серверів котрі довблять сервери і отримують ті ж дані, і це не дуже елегантно, як на мене.

Власне це різні продукти, спробуйте.

В Influx можна інгестити ще й аплікейшен метрики і потім по ним собі графічки будувати.

А взагалі, тема Prometheus не розкрита.

TICK Stack — бесплатный комплекс программ, простой в использовании и гибкий в настройке, с механизмом агрегации и удобными кастомизируемыми функциями выбора.
Существуют и платные решения для таких задач, например DataDoghq.

а еще существует оригинальный InfluxEnterprise, бесплатной версией которого и является TICK Stack,
но уже лишенный:
High Availability (Clustering)
Scalability (Clustering)
и т.д.

а ведь данные фичи очень не помешали бы...
никто опенсорсных решений с подобным функционалом не встречал? :-)

У Яндекса есть аналогичная по функциям база с этими фичами. ClickHouse вроде..

PS: m.habr.com/...​company/smi2/blog/317682

ну это ж только сама база, а не система мониторинга

Выгружать тем же телеграфом туда не сложно, для визуализации подключить графану. Остается только вопрос алертов.

я смотрю, даже плагин для этого какой-то есть github.com/...​elegraf-clickhouse-plugin
но все равно напоминает про — еще полторы тысячи вёдер и золотой ключик у нас ©
хотелось бы уже готовое, проверенное решение

Готовое будет стоить денег. По этому варианта всегда два, или собрать самому, или купить тот же TICK. Не зря говорят, что свободный софт отнимает свободное время.

Купить. кстати можно и datadog. Он очень не плох.

в FOS все же приветствуется другой подход в отношении денег
когда сам продукт распространяется — бесплатно
а вот поддержка — уже за деньги

Да ве теории такое тоже очень возможно. Говорят, что у кого то даже получается) На деле же обычно всегда выгодней иметь раздельные редакции, типа CE и EE. Первые для энтузиастов и пиара, вторые для тех кому нужна поддержка и стабильность.

Да ве теории такое тоже очень возможно. Говорят, что у кого то даже получается)

ну да, никому не известный RedHat и прочие

Ну тот же rhel не такой то уж доступный и свободный. Просто так взять и пользоваться им получая все обновления не выйдет. Кто то его вообще использует без платной поддержки?

Ну ще є ж ELK stack, де є clustering безплатно з коробки

насколько я понимаю, он все же для других целей

В ELK є окремі сервіси (MetricBeat) та плагіни Logstash для моніторингу. Плюс для візуалізації можна використовувати Grafana замість Kibana. Ну і є Filebeat, який вичитує файли, що дозволяє парсити метрики прямо з логів.

Спасибо, интересно про новые инструменты мониторинга !
Но, на основании моего сисадминского опыта, могу сказать, что все это делается Zabbix и де-факто у него практически те же функции. Про девопс и все такое — не знаю, но вот мониторинг оборудования — забка один к одному.

думаю, на больших инсталляциях у них будут кардинально разные потребности в ресурсах/итоговой производительности,
обусловленные использованием принципиально разных баз под хранение данных (не в пользу Zabbix)
не работал с TICK Stack, но у Zabbix на мой взгляд — странная идеология отображения графиков (например, free memory вместо привычного total и used), отсутствие адекватного мониторинга агентом «из коробки» нагрузки на дисковую подсистему, убогие дашборды, а в его плагине к Grafana зачем-то обрезаны многие математические функции, привычные для Grafana
в общем Zabbix вообще не торт

думаю, на больших инсталляциях у них будут кардинально разные потребности в ресурсах/итоговой производительности,
обусловленные использованием принципиально разных баз под хранение данных (не в пользу Zabbix)

Именно же ! Забка хороша для среднего массива данных — где-то до 100 единиц оборудования, не более — а далее начинаются уже затыки и сложности. Да. туда уже нужно что-то платное, да и кгм..если у тебя много точек снятия данных — ты готов платить за хорошее ПО.

хехе, расскажите это админам ланета, где около 100к хостов мониторится заббиксом =)

Всякому городу нрав и права, всяка імієть свій ум голова ©

и какое железо под это используется?
сколько метрик с каждого хоста? с каким интервалом? это все ж нужно перемножать на кол-во хостов
MySQL/MariaDB потребуют прилично больше ресурсов на таких объемах, в отличие от любой Time Series Database, которые еще между собой на порядок по эффективности могут отличаться

Плюс tick в том что он поднимается за вечер любым Линукс юзером.

Підписатись на коментарі