Архив метки: monitoring

Проверка состояния контейнера в Docker

Проверка состояния контейнераКаким-то непонятным образом я пропустил новость о том, что начиная с версии 1.12 Docker контейнерам можно навешивать проверку состояния. И речь тут идёт не о проверке, запущен ли ещё контейнер, а о том, делает ли он всё ещё то, ради чего создавался. Например, мы можем проверять, отзывается ли веб-сервер внутри контейнера на входящие запросы, вменяемое ли количество памяти он использует, встречаются ли в логах фразы вроде «epic fail!!!»… Много чего можно проверить, ведь проверка делается через запуск какого-нибудь стороннего скрипта или приложения, а её результат зависит от кода, с которым это приложение завершилось.

В обычном режиме контейнер, последние несколько проверок которого оказались «так себе», получит атрибут «unhealthy», в Docker events появится соответствующая запись (health_status), и на этом история закончится. Но если речь идёт о Swarm режиме, то проблемный контейнер без лишних разговоров усыпят и автоматически запустят новый. Вот так жестоко. Читать далее Проверка состояния контейнера в Docker

Проверка состояния сервисов в Consul

Consul logoВ прошлом посте мы создали небольшой Consul кластер с четырьмя сервисами в нём: двумя web сервисами и двумя db. Но так как мы не сказали Консулу, как мониторить их состояние, Консул-агенты абсолютно упустили из виду тот факт, что ни одного сервиса на самом деле не существует. Сегодня мы посмотрим, как это можно было бы исправить: как добавить проверки состояния сервисов, и как эти проверки влияют на способность сервисы обнаружить.

Читать далее Проверка состояния сервисов в Consul

Обрабатываем логи в Logstash

Logstash лого

Итак, с Elasticsearch, гибридом гугла и NoSQL базы данных, мы разобрались, самое время перейти к следующей букве ELK стэка от Elastic — Logstash.

Читать далее Обрабатываем логи в Logstash

Краткое введение в Elasticsearch

ElasticsearchНасколько замечательно Grafana, Graphite и Prometheus справляются с численными данными мониторинга, вроде загрузки процессора по времени, настолько же они бесполезны для работы с логами. А ведь с теми приходится работать даже чаще, чем с метриками.

Инструментов для работы с логами тоже навалом, но сегодня мы посмотрим в сторону ELK стека от Elastic. А именно: Elasticsearch, Logstash и Kibana — хранилище/поисковик, обработчик данных и тулза для их визуализации. А начнём, естественно, с первой буквы этого трёх-буквенного алфавита — «E».

Читать далее Краткое введение в Elasticsearch

Отслеживаем события приложения в Graphite

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

Предположим, наши метрики лежат в Graphite. Как бы мы хранили в нём еще и события?

Читать далее Отслеживаем события приложения в Graphite

Собираем метрики приложения с Prometheus

PrometheusЕсть два концептуально разных подхода к сбору метрик приложения. Есть PUSH подход, при котором хранилище тихо сидит где-нибудь и надеется, что случайный провайдер метрик в него что-нибудь да положит. Например, Graphite сам по себе не занимается сбором данных. Он ждёт, что их доставит прямо к порогу кто-нибудь вроде collectd.

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

Prometheus использует PULL подход. Читать далее Собираем метрики приложения с Prometheus

Визуализация данных мониторинга с Grafana

Хотя Graphite весьма неплохо рисует одиночные графики, с созданием дашбордов целиком он справляется так себе. Конечно, можно взять его Render URL API и сделать себе HTML-дашборд самостоятельно. С другой стороны, есть Grafana.

Дашборд в Grafana

Читать далее Визуализация данных мониторинга с Grafana

collectd: используем JavaScript для сбора метрик

Graphite-график, собранный из JavaScript-данных

Exec плагин

Среди всего разнообразия плагинов в collectd есть один особенный: если из-за какой-нибудь техногенной катастрофы у collectd останется только Exec, то им вполне можно заменить все остальные.

Как следует из названия, Exec запускает стороннее приложение или скрипт и интерпретирует её вывод в качестве данных для себя. Если быть точным, то он ищет строки вроде таких:

Что самое прекрасное, Exec абсолютно по барабану, на каком языке написан скормленный ему скрипт.  Хоть на JavaScript. В принципе, в некоторых сценариях использовать JavaScript было бы очень хорошей затеей. Например, когда приходится иметь дело с RESTful сервисом возвращающим JSON.

Но прежде чем мы попробуем скормить collectd данные из JavaScript приложения, стоит присмотреться поближе к формату PUTVAL-строк. Читать далее collectd: используем JavaScript для сбора метрик

Краткое введение в Graphite

Что такое Graphite

graphite-logo
Graphite
 — это приложение, которое здорово делает три вещи:

  1. принимает данные мониторинга от сторонних агентов,
  2. сохраняет их в базу, и
  3. показывает эти данные в виде графиков и дашбордов через веб-приложение

Читать далее Краткое введение в Graphite

Краткое введение в rrdtool

В прошлом посте я упомянул, что collectd по-умолчанию сохраняет собранные данные через rrdtool. На выходе получаются несколько .rrd файлов — по одному для каждой метрики — и их потом можно отрисовать при помощи той же rrdtool. RRD файлы не так часто вплывают в разговорах у кофеварки, да и сама rrdtool та еще tool, так что не сразу понятно, почему collectd использует именно её, а не какой-нибудь CSV.

Оказывается, причин хватает. Читать далее Краткое введение в rrdtool