Шесть миллиардов запросов в месяц. Это число кажется вам большим? Это число представляет собой общее количество запросов, сделанных за месяц на очень популярном веб-сайте, известном каждому разработчику: StackOverflow.
Два сервера HAProxy и девять веб-серверов являются строительными блоками StackOverflow, реализующими хорошо известную и надежную архитектуру, известную как кластеры серверов высокой доступности.
В более мелких масштабах такие архитектуры внедряются многими компаниями, чтобы гарантировать доступность услуги даже в случае аппаратных дефектов. Но в случае выключения сервера, как можно получить эффективное уведомление, чтобы быстро предпринять действия по возврату сервера?
Сегодня мы собираемся создать полную панель управления Grafana для мониторинга кластера серверов с помощью InfluxDB и Telegraf.
I - О кластерах высокой доступности
Прежде чем приступить к разработке нашей информационной панели, давайте вкратце поговорим о кластерах высокой доступности, о том, для чего они используются и почему мы заботимся о их мониторинге (если вы эксперт в архитектуре предприятий, Вы можете пропустить эту часть)
Кластер высокой доступности - это группа серверов, спроектированных и собранных таким образом, чтобы обеспечить постоянную доступность и избыточность предоставляемых услуг.
Допустим, вы создаете простое веб-приложение. При запуске вы получаете трафик в тысячу просмотров страниц в день, нагрузку, с которой любой достойный HTTP-сервер может справиться без каких-либо проблем. Внезапно ваш трафик резко возрастает и достигает миллиона просмотров страниц в день. В этом случае ваш основной HTTP-сервер не может справиться с нагрузкой в одиночку и требует дополнительных ресурсов.
Решением этой проблемы может быть реализация архитектуры кластера высокой доступности.
Когда HTTP-запрос получен, балансировщик нагрузки проксирует (то есть перенаправляет) запрос на соответствующий узел, чтобы гарантировать, что нагрузка равномерно распределяется между кластером. Балансировщики нагрузки используют разные методы, чтобы решить, на какой узел отправлять, но в нашем случае мы будем использовать невзвешенную конфигурацию Round Robin: запрос будет отправлен на первый сервер, затем на второй и скоро. При выборе узла никаких предпочтений делать не будет.
Теперь, когда мы определили все технические термины, мы можем приступить к внедрению нашей системы мониторинга.
II - Выбор правильного стека
В этом проекте я буду использовать машину Xubuntu 18.04 со стандартным ядром.
Чтобы отслеживать наш кластер серверов, нам нужно выбрать правильные инструменты. Для визуализации в реальном времени мы будем использовать Grafana v6.1.1.
Для мониторинга я выбрал InfluxDB 1.7 в качестве источника данных для Grafana, поскольку он представляет собой надежный источник данных для Grafana. Чтобы получить метрики для InfluxDB, я выбрал Telegraf - агент, управляемый сервером плагинов, созданный InfluxData. В этом руководстве не рассматривается установка представленных ранее инструментов, поскольку соответствующая документация объясняет это достаточно хорошо.
Примечание: убедитесь, что вы используете те же версии, что и в этом руководстве. Такие инструменты подвержены частым изменениям и могут повлиять на достоверность этой статьи.
III - Настройка простого кластера высокой доступности
Чтобы контролировать наш кластер высокой доступности, мы собираемся создать его простую версию, используя NGINX v1.14.0 и 3-узловые экземпляры HTTP-сервера. Как показано на диаграмме выше, NGINX будет настроен как балансировщик нагрузки, проксирующий запросы к нашим экземплярам Node.
Если в вашей инфраструктуре уже есть кластер высокой доступности, пропустите эту часть.
a - Установка NGINX в качестве балансировщика нагрузки
NGINX настроен для работы на порту 80, с использованием конфигурации по умолчанию и проксирования запросов к службам, расположенным на портах 5000, 5001 и 5002.
Обратите внимание на часть конфигурации сервера / nginx_status. Важно не пропустить его, поскольку он будет использоваться Telegraf для получения метрик NGINX позже.
б - Установка простых экземпляров Node HTTP.
В этой части я использовал очень простой экземпляр Node HTTP, используя библиотеки http и httpdispatcher, изначально предоставленные Node.
Этот сервер не предоставляет никаких специальных возможностей, но он будет использоваться в качестве базового веб-сервера для NGINX для прокси-запросов к.
Чтобы запустить три экземпляра этих веб-серверов, я использую pm2: утилиту диспетчера процессов для экземпляров узлов в системах Linux.
Теперь, когда NGINX настроен и готов, давайте запустим наши три экземпляра, выполнив:
Проделав это с двумя другими экземплярами серверов Node, мы получили кластер из трех узлов Node, готовый к работе.
IV - Настройка Telegraf для мониторинга
Теперь, когда наш кластер высокой доступности построен и запущен, нам нужно настроить Telegraf для привязки к различным компонентам нашей архитектуры.
Telegraf будет отслеживать наш кластер с помощью двух разных плагинов:
- Подключаемый модуль NGINX: используется для получения показателей для серверов NGINX, таких как количество запросов, а также ожидающих / активных или обработанных запросы на нашем сервере балансировки нагрузки.
- HTTP_Response: используется для периодического получения времени ответа каждого узла, а также кода HTTP, связанного с запросом. Этот плагин будет очень полезен для отслеживания пиков на наших узлах, а также сбоев узлов, которые могут произойти.
Перед запуском убедитесь, что telegraf запущен, с помощью следующей команды: sudo systemctl status telegraf. Если ваш сервис отмечен как Active, вы готовы к работе!
Перейдите в расположение Telegraf по умолчанию для конфигурации (/etc/telegraf), отредактируйте файл telegraf.conf и добавьте в него следующие конфигурации вывода.
Когда вы закончите изменять конфигурацию Telegraf, обязательно перезапустите службу, чтобы изменения были учтены. (sudo systemctl restart telegraf).
После запуска Telegraf он должен начать периодически отправлять метрики в InfluxDB (работающий на порту 8086) в базе данных telegraf, создавая метрику, называемую именем плагина, который ее запускает. (так что либо nginx, либо http_response).
Если такие базы данных и измерения не созданы на вашем экземпляре InfluxDB, убедитесь, что у вас нет проблем с настройкой и что служба telegraf правильно работает на машине.
Теперь, когда наши различные инструменты запущены, давайте взглянем на нашу окончательную архитектуру, прежде чем переходить к Grafana.
V - Настройка Grafana - Наконец-то!
Теперь, когда на вашем компьютере все настроено, пришло время поиграть с Grafana и создать самую крутой приборной панели для мониторинга нашей инфраструктуры.
Учитывая представленную выше панель инструментов, у вас есть три варианта визуализации:
- Диаграмма доступности: показывает соединения между узлами, их текущее состояние и время ответа.
- Датчики, показывающие время отклика, или сообщение об ошибке - служба не работает.
- График времени ответа каждого узла и настраиваемое предупреждение в случае сбоя службы.
Вы можете перейти к частям, которые, по вашему мнению, имеют отношение к вашей собственной панели инструментов.
0 - Необходимые шаги
У вас должна быть полностью пустая панель инструментов, если вы найдете кнопку Create Dashboard в левом меню Grafana.
а - Диаграмма доступности
Этот вариант визуализации показывает связь между различными частями нашей архитектуры, а также цветные узлы для представления состояний каждого отдельного узла.
Немного настройки, поскольку плагин схемы изначально не доступен в Grafana, но его не должно быть слишком сложно установить.
В командной строке запустите sudo grafana-cli plugins install jdbranham-diagram-panel и перезапустите Grafana. Теперь, когда вы успешно установили плагин, он должен быть доступен на панели визуализации Grafana.
Панель диаграммы использует синтаксис Mermaid, который мы собираемся использовать для изображения нашей архитектуры. Для удобства я собрал конфигурацию на единой картинке.
Синтаксис русалки для этого плагина должен быть настроен, как описано ниже.
Важное примечание: есть небольшой параметр, который вам нужно настроить в Grafana, чтобы получить желаемый результат. По умолчанию, если вы определяете запрос как представленный выше, Grafana примет последнее значение относительно временного интервала окна. Это проблема, потому что если вы установите для своей панели управления Grafana
Last 15 minutesс параметромRefresh every five seconds, вы получите уведомление о том, что ваша служба не работает, через 15 минут.
Чтобы противостоять этому, вам нужно найти эту строку в своей конфигурации:
Таким образом, вы получите предупреждение только через 20 секунд после того, как служба отключится.
И мы закончили с диаграммой доступности! Давайте посмотрим на диаграмму, если мы остановим одну из служб до pm2 stop server
Как раз то, что мы ожидали! К сожалению, на панели диаграмм нет системы предупреждений, но мы сможем отправлять предупреждения через панель графиков.
б - Панель манометров
Эта панель датчиков - новая панель, доступная в Grafana v6.0, и настроена следующим образом:
Панель датчика привязана к полю response_time, и пороговые значения настроены для уведомления, когда определенному узлу требуется слишком много времени для ответа. Предупреждения пока не настраиваются на панели приборов.
c - Панель графика
Панель графиков показывает время отклика и очень похожа по сравнению с панелью датчиков, показанной выше. Основное отличие панели шкалы состоит в том, что она предоставляет конфигурации предупреждений, когда определенное значение недоступно.
Все виджеты, представленные выше, можно настроить в соответствии с вашими потребностями, и они должны быть такими! Их конфигурация описывает очень частный случай кластера высокой доступности, но они могут отличаться, если вы используете HAProxy или другой метод балансировки нагрузки.
VI - Заключение
Необходимость мониторинга в 2019 году определенно является тенденцией, которую больше не может игнорировать ни один инженер. Растет потребность в решениях для мониторинга, а также в инструментах, объединяющих агентов мониторинга, инструменты визуализации и инструменты постанализа.
Для DevOps появятся несколько отличных инструментов: InfluxDB уже переходит на версию 2.0 с языком Flux, и все выглядит многообещающе.
Тем не менее, InfluxData - не единственный поставщик баз данных временных рядов на рынке: Amazon определенно хочет свою долю и анонсировала Amazon Timestream во время re: Invent 2018. Были представлены некоторые функции, но он может представлять собой очень надежную альтернативу InfluxCloud.
Время покажет!
Я надеюсь, что вы прекрасно провели время, читая и создавая эту панель мониторинга кластера вместе со мной: если вы хотите, чтобы в будущем были затронуты определенные темы, не стесняйтесь замечать меня об этом.
До скорого.
Любезно,
Антуан Сольничкин.
