Распространять данные сложно

Распределенные системы сложны, потому что они приносят компромисс повышенной сложности развертывания в обмен на линейную горизонтальную масштабируемость. При исчерпании ресурсов физических серверов позиция «просто добавьте больше узлов» обычно избавляет вас от неприятностей. Если бы мы говорили о системе без сохранения состояния, которая фокусируется только на вычислениях, нам нужно было бы только отслеживать использование ресурсов - соответственно масштабировать и прекращать работу.

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

Масштабирование распределенной системы

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

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

В этом посте будет рассмотрено, как можно легко настроить стек мониторинга для Apache Pinot, который поможет вам устранять неполадки, когда ваша система недостаточно подготовлена ​​или данные распределяются неравномерно. Обычно расследование начинается с:

Высокий уровень использования ресурсов на всех узлах (как в системе, так и в JVM) или это всего лишь несколько узлов?

Когда все ваши серверы работают в горячем режиме и система работает с ожидаемой пропускной способностью для данного масштаба, ответ будет «просто добавь больше узлов». Если это не так, это обычно означает, что пришло время закатать рукава, окунуться и исследовать, какие шаблоны использования приводят к тому, что некоторые конкретные узлы системы становятся не полностью загруженными.

Подготовка стека наблюдаемости для Apache Pinot

Прохождение такого дерева решений подчеркивает, что нам нужны метрики уровня системных ресурсов, а также метрики уровня данных от Apache Pinot. Без них обоих вы будете только догадываться о том, что не так с системой. Существует множество решений и технологий, которые помогут вам с показателями системных ресурсов. Что касается показателей уровня данных, здесь нет темной магии. Любые метрики, которые могут быть привязаны к конкретным наборам данных, должны быть отправлены исходной системой, которую вы отслеживаете. Удобно, что Apache Pinot генерирует обширный набор метрик данных, которые доступны через JMX. Если ваша метрическая система может использовать JMX, вы сможете без проблем выполнить интеграцию.

Облегчение жизни с Прометеем

Команда Apache Pinot из коробки получила поддержку Prometheus, повсеместного облачного инструментария для мониторинга метрик. Не заставляя вас использовать определенную инфраструктуру мониторинга, вы можете выбрать опции для активации экспортера Prometheus JMX, который упакован в образ Docker Apache Pinot. Образ также поставляется с предварительно настроенной конфигурацией экспортера.

Просто добавьте эти аргументы JVM в переменные среды JAVA_OPTS ваших контейнеров Apache Pinot, и Prometheus сможет очистить ваши экземпляры:

-javaagent:jmx_prometheus_javaagent-0.12.0.jar=8888:exporter-config.yml

Не используете Docker?

Нет проблем, просто принесите свой собственный Prometheus JMX Exporter и свою собственную конфигурацию экспортера jmx. Просто убедитесь, что вы настроили переменную среды JAVA_OPTS с правильными путями для этих двух файлов.

Подготовим демонстрационную среду

Чтобы продемонстрировать интеграцию Apache Pinot с Prometheus, я подготовил образец репозитория, содержащий развертывание docker-compose, предварительно настроенное с помощью Pinot, Prometheus, Grafana и простое приложение Smoke Test, которое передает события в Pinot. через Кафку. Prometheus поддерживает более десятка механизмов обнаружения, таких как Consul и Kubernetes. Для простоты в следующем примере будут показаны статические конфигурации, относящиеся к нашим компонентам Pinot, настроенным вручную в файле prometheus.yml. Ищите справочную документацию Apache Pinot для руководства по Обнаружению метрик в Kubernetes.

Предпосылки

  • мерзавец
  • докер
  • докер-сочинять
  • Java 8 или новее

Скачать исходный код

$ git clone https://github.com/daniellavoie/monitoring-apache-pinot

Взглянем на манифест развертывания

Примечательные конфигурации манифеста docker-compose - это переменная среды JAVA_OPTS для всех компонентов pinot и подключение тома к конфигурации очистки prometheus.

Запустить демонстрационную среду

$ cd  monitoring-apache-pinot && git checkout blog && ./run.sh

Доступ к панели управления Pinot

Откройте браузер и перейдите по адресу http: // localhost: 9000 /. Вы сможете просмотреть статус кластера Пино. Подождите, пока вы не подтвердите, что брокер, контроллер и сервер имеют статус Живой.

Консоль запросов (http: // localhost: 9000 / # / query) также поможет вам подтвердить, что некоторые данные эффективно записываются в Pinot через встроенное приложение Smoke Test и Kafka.

Доступ к панели управления Grafana

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

Образец проекта удобно упакован с автоматически настраиваемым источником данных Prometheus и панелью управления Grafana для Pinot. Используя учетные данные `admin / password`, войдите в эту панель управления через http: // localhost: 3000 / d / a2HnNdCWk / pinot? OrgId = 1 & refresh = 5m .

Хорошо, на что я сейчас смотрю?

Одна интересная особенность метрик, генерируемых Apache Pinot, заключается в том, что они в основном родственны вашим таблицам. Создайте новую таблицу, и Grafana начнет динамически отображать ряд данных для таблиц, поскольку они автоматически обнаруживаются Prometheus через JMX Exporter. Хотя этот пример панели мониторинга может быть неполным, это прекрасный холст, который можно настроить в соответствии с вашими потребностями и выделить важные метрики, связанные с шаблоном использования, который вы создаете с помощью Apache Pinot.

Демонстрация некоторых показателей

Задержка запроса таблицы

Вероятно, самая очевидная метрика, за которой нужно следить. Задержка запроса таблицы дает прямой ответ на общую реактивность системы. Скорость выполнения запроса всегда зависит от ожиданий, размера инфраструктуры и объема набора данных. Любая таблица, превышающая пороговое значение, которое считается разумным, должна инициировать расследование со стороны SRE.

Таблица запросов QPS

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

Что будет дальше?

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

А пока мы приглашаем вас присоединиться к нашему Сообществу Slack Apache Pinot, чтобы поделиться своим собственным опытом мониторинга распределенных систем. Кроме того, не пропустите отличный блог Чинмей Зоман о Достижение 99-го процентиля SLA с задержкой с использованием Apache Pinot.