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

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

Что такое проверка состояния сервисов

Continue reading «Проверка состояния сервисов в CONSUL»

Поиск и регистрация сервисов с CONSUL

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

Самое очевидное решение — придумать какое-нибудь отдельное хранилище типа ключ-значение, в котором сервисы будут себя регистрировать при запуске: кто такой и куда слать запросы. Правда, сервисы иногда будут выключаться… Значит, перед выключением они должны себя «разрегистрировать». Continue reading «Поиск и регистрация сервисов с CONSUL»

Конфигурация сервисов с CONSUL KEY-VALUE STORE

Как люди обычно конфигурируют приложения? Некоторые, например, передают аргументы через командную строку. Ещё можно задать переменные окружения или просто указать на файл с настройками. Да чего уж там, пока никто не видит, опцию-другую можно и прямо в код прошить.

Но как быть с такой ситуацией. Есть у нас распределённое приложение: куча хостов, сервисы создаются, приходят в онлайн, уходят, и все с разными версиями и непонятными адресами. И вдруг нам нужно их всех переконфигурировать. Ничего такая задачка? С монолитным приложением можно было бы просто зайти на хост и поколдовать там. А как быть с распределённым? Continue reading «Конфигурация сервисов с CONSUL KEY-VALUE STORE»

Docker — измеряйте ресурсы, используемые контейнерами

В docker’е существует встроенная команда, позволяющая увидеть сколько CPU, памяти, сетевых операций ввода-вывода (network I/O) и блочных операций ввода-вывода (block I/O) используют запущенные контейнеры. Давайте разберемся!

Знать, сколько ресурсов используется тем или иным docker-контейнером очень полезно. Вооружившись этими знаниями, можно планировать апгрейд существующих и разворачивать дополнительные docker-хосты, соответствующие используемым ресурсам. В перспективе это знание позволяет сэкономить серьезные деньги на инфраструктуре. Continue reading «Docker — измеряйте ресурсы, используемые контейнерами»

Как хранить данные в DOCKER VOLUMES

Если полистать какой-нибудь Докер гайдлайн, то скорее всего в нём скажут, что контейнеры должны быть маленькими, с одним процессом, легко удаляемыми и так же легко заменяемыми на более новый. Прекрасная концепция. О чём в гайдлайнах пишут немного реже, так это что же делать с данными внутри таких контейнеров. Я же не могу легко удалить тот же mysql контейнер и заменить его на новый, но пустой внутри. Он ведь мне только ради данных и нужен был.

Но, оказывается, проблема вполне решаема. Docker volumes, которые существовали в Докере с момента сотворения мира, начиная с версии 1.8 получили обновлённый API, и теперь справляются с хранением данных не только технически, но и эстетически прекрасно. Continue reading «Как хранить данные в DOCKER VOLUMES»

KIBANA: окно в ELASTICSEARCH

Сегодня мы поговорим о последнем компоненте ELK стэка от Elastic — Kibana. Хотя Logstash отлично справляется обработкой логов и прочих потоков данных, а Elasticsearch поможет их сохранить, проиндексировать и запустить парочку поисковых запросов, ни у одного их них нету пользовательского интерфейса. А анализировать данные и искать закономерности из командной строки — удовольствие для любителей. Очень странных любителей…

И тут на помощь приходит Kibana. Continue reading «KIBANA: окно в ELASTICSEARCH»

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

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

Что такое Logstash

Logstash — это конвейер обработки данных, который получает сырые данные (например, логи) из одного или нескольких  источников, обрабатывает их и улучшает фильтрами, а затем отправляет результат одному или нескольким получателямElastic рекомендует в качестве получателя использовать Elasticsearch, но на самом деле можно использовать всё, что душе угодно: STDOUT, WebSocket, обычные сокеты, очереди сообщений — выбор огромный. Continue reading «Обрабатываем логи в LOGSTASH»

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

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

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

Что такое Elasticsearch

Continue reading «Краткое введение в ELASTICSEARCH»

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

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

Мониторинг серверов с COLLECTD

С распределёнными приложениями появляется проблема, которую обычно не приходится решать в монолитных: как узнать, что приложение работает нормально? Не в смысле выполняет бизнес задачи и радует сердца пользователей яркими иконками, а в принципе работает. Все ли ключевые сервисы запущены? Загрузка процессора и памяти в норме? Место на диске не закончилось? И так далее.
Continue reading «Мониторинг серверов с COLLECTD»