Anpac.ru

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

Акцент выполнен на пользовательских метриках, а не системных. Что будем мониторить? Метрики из нескольких десятков сервисов, написанных на языке, который сохраняет jvm (java, scala). Цель: создать инструмент, позволяющий подвергать анализу в живую то, что происходит в дополнениях, не роясь в больших логах на нескольких серверах.

Во всем мире jvm есть прекрасная библиотека для сбора метрик. Лучше, я пока ничего не видел. Ок, создавать метрики мы обучились.

Как их подвергать анализу и визуализировать? Несовременный подход требовать какую-то точную метрику через jmx или создавать их плагином jmx в какой-то zabbix для нас не подходит, поскольку мы не знаем какая метрика (какое ее значение mean, max, percentile) может потребоваться, за какой этап, с какой группировкой.

После начала сервиса, все значения метрик будут раз в 10 сек идти в influxdb. Скорости одной базы данных (single server deployment) хватит чтобы принимать десятки тысяч значений метрик раз в 10 сек. А можно без проблем перейти и в режим кластера.

Несколько слов про модель хранения. Приходит эра микросервисов и дележ 1 сервис — 1 физ.сервер почти не встречается.

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

Любая метрика имеет имя (seriesName), сервер (host), имя сервиса (app). В моем случае есть еще machine id, а это специфика моего приложения. Такая организация весьма понадобится, когда мы начнем строить дашборды.

Когда все настроено и данные пишутся в influxdb можно переходить к созданию дашбордов. С моей точки зрения, имеет резон сделать несколько template variables и применять их как условия для фильтров. Давайте сделаем дашборд, где будет можно посмотреть среднее значение для любой метрики типа Meter.