Как осуществлять мониторинг приложений на основе Docker с использованием новой Relic

Вступление

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

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

Чтобы исправить это, New Relic взяла на себя задачу и сделала свои инструменты мониторинга на стороне сервера (Серверы и APM) поддержкой Docker. В июне 2015 года поддержка Docker стала доступна для всех клиентов New Relic.

В сообщении о поддержке Docker Эндрю Маршалл из New Relic пишет:

«Теперь вы можете перейти от приложения (которое действительно вас интересует) к отдельному контейнеру Docker, а затем к физическому серверу. Больше никаких слепых зон!»

Контролируя ваше приложение на основе Docker с помощью набора инструментов New Relic, вы теперь можете анализировать приложение в целом, а затем, когда вы найдете проблемы в вашем приложении, искать контейнеры, в которых возникают проблемы, и устранять проблемы внутри них.

Кроме того, отслеживая приложение на уровне Docker, вы получите ценную информацию о вашей настройке: используете ли вы свои контейнеры с умом, и работает ли распределение ресурсов между контейнерами так, как следует?

В этом уроке

В этом уроке я покажу вам, как начать мониторинг простого Docker-приложения с помощью инструментов New Relic.

Ты выучишь:

• как настроить мониторинг New Relic на веб-сервере, на котором запущен набор контейнеров Docker, для сбора информации об общей среде Docker
• как настроить мониторинг New Relic для PHP-приложения, работающего внутри одного или нескольких контейнеров Docker, для мониторинга состояния приложения, а также отдельного контейнера Docker

Чтобы добиться этого, мы создадим простой прототип для размещенного решения WordPress: три сайта WordPress, каждый из которых работает в контейнере Docker, и контейнер MySQL, совместно используемый между ними.

После установки мы включим мониторинг New Relic, пройдемся по представлениям инструментов мониторинга и изучим данные, которые вы найдете в них.

Требования

Хотя я надеюсь, что вы узнаете кое-что об использовании Docker, прочитав это руководство, оно не предназначено для того, чтобы быть руководством по Docker, а скорее по поводу использования инструментов мониторинга New Relic вместе с приложениями на основе Docker.

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

Настройте контейнеры Docker

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

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

Чтобы узнать больше о Docker, лучше всего начать с онлайн-документации инструмента. Это хорошо написано и будет вести вас за руку.

Тогда, когда вы почувствуете себя комфортно, попробовав Docker в действии, начнем с нашей настройки!

Что мы будем строить?

Прежде чем мы приступим к реализации нашей настройки Docker и New Relic, вот изображение, показывающее обзор базовой архитектуры, которую мы собираемся построить в этом руководстве:

Как я упоминал во введении, это упрощенный хостинговый сервис WordPress: в трех контейнерах (произвольное число) мы будем запускать установку WordPress в каждом. Все контейнеры WordPress связаны с контейнером под управлением MySQL. Все это будет выполняться на одном сервере, который в этом примере будет размещен в Amazon Web Services, но может быть любым сервером, на котором могут работать средства мониторинга Docker и New Relic.

Сервер и работающие в нем контейнеры будут отслеживаться с помощью инструментов New Relic APM (Application Performance Monitoring) и серверов .

Я разработал эту настройку в основном для демонстрационных целей, но она фактически смоделирована после того, что я создаю в своем собственном проекте: просто добавив инструмент администратора, правильную конфигурацию DNS и обратный прокси-сервер Nginx — все они работают по-своему Контейнеры Docker — установка может быть встроена в полнофункциональный сервис WordPress. Это, однако, выходит за рамки данного руководства, поэтому давайте вернемся к запуску некоторых контейнеров WordPress.

Шаг 1: Запустите новую машину EC2

Мне нравится использовать Amazon Web Services, когда мне нужен веб-сервер для подобных экспериментов: серверы дешевы в запуске, и вы платите только за время, которое используете (просто не забудьте остановить их, когда закончите!).

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

В этом случае вы можете пропустить этот шаг и перейти непосредственно к установке Docker на серверном компьютере ( шаг 2 ).

В моем предыдущем учебном пособии « Начало работы с мониторингом веб-приложения с помощью новых оповещений о реликвиях» я включил подробные пошаговые инструкции по запуску компьютера в облаке Amazon. Следуйте этим инструкциям, на шаге 1 руководства , но не устанавливайте PHP и не запускайте Apache, как сейчас, потому что Apache и PHP будут находиться внутри контейнеров Docker .

Если вы уже знакомы с AWS и хотите просто напомнить, какие параметры выбрать при запуске машины, этот краткий список проведет вас через весь процесс:

1. Войдите в консоль AWS , создав учетную запись, если у вас ее еще нет.
2. В главном меню выберите EC2 . Вы заметите, что Amazon недавно запустил новый сервис для запуска контейнеров Docker в облаке ( EC2 Container Service ), но на этот раз мы захотим сами управлять Docker.
3. Выберите Launch Instance, чтобы запустить новый компьютер. Выберите опцию « Быстрый старт» и выберите 64-битный сервер Amazon Linux по умолчанию. Для тестирования просто подойдет размер машины t2.micro .
4. На странице группы безопасности откройте порт HTTP и сделайте SSH доступным только с вашего IP, выбрав опцию My IP .
5. Нажмите кнопку « Обзор и запуск», чтобы запустить сервер. Когда вас попросят создать пару ключей, создайте ее (назовите ее, например, docker_test ) и загрузите ее.

Примерно через минуту вы заметите, что ваша машина работает.

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

Шаг 2: Установите Docker на сервере

Теперь, когда вы запустили сервер и подключились к нему через SSH, пришло время установить движок Docker.

Инструкции на этом шаге относятся к серверу Amazon Linux, который мы создали на шаге 1 . Если вы используете другую операционную систему, обратитесь к документации Docker за инструкциями по установке, специфичными для вашей среды.

Начните с установки пакета docker:

Опция -y заставляет yum автоматически отвечать да на любые вопросы об установке. Это делает вещи быстрее, но если вы хотите быть в безопасности, не стесняйтесь опускать это.

После установки пакета Docker запустите его как службу:

Теперь вы найдете Docker, работающий до конца этого сервера (или до тех пор, пока вы не остановите его самостоятельно).

Чтобы проверить установку, вы можете использовать команду docker ps которая выводит список запущенных контейнеров Docker:

На данный момент список еще пуст, так как мы еще не запустили никаких контейнеров:

Наконец, добавьте пользователя по умолчанию в группу Docker, чтобы вы могли управлять Docker без необходимости ставить префикс всех ваших команд Docker с помощью sudo . Это всего лишь четыре лишние буквы, но они имеют большое значение, когда вам приходится часто их писать!

Чтобы применить изменения к вашему соединению, закройте соединение ssh и подключитесь снова.

Теперь вы готовы запустить несколько контейнеров Docker.

Шаг 3: Запустите Docker Контейнеры

Если вы ищете WordPress и Docker (или MySQL и Docker), вы заметите, что есть много разных образов Docker на выбор. В вашем собственном приложении, это хорошая идея, чтобы просмотреть наиболее популярные из них и посмотреть, что работает лучше для вас, или если вы действительно должны написать его с нуля.

В этом уроке я решил использовать официальные изображения: образ MySQL, предоставленный MySQL, и официальный образ докера WordPress.

Сначала запустите контейнер, используя образ MySQL , mysql/mysql-server:5.5 .

Команда загружает пакет и его зависимости, а затем запускает контейнер MySQL с именем db . Имя важно, так как мы будем использовать его для связи наших контейнеров WordPress с базой данных.

Если хотите, используйте docker ps чтобы проверить, работает ли новый контейнер. Для получения дополнительной информации о запуске вы можете проверить файл журнала контейнера с помощью docker logs db . Вы должны увидеть что-то вроде этого как последние несколько строк вывода:

Затем запустите контейнер WordPress, используя образ WordPress Docker , wordpress:latest (используя latest тег, вы всегда получите самую последнюю версию на основе Apache).

В приведенной выше команде вы заметите, что мы связываем контейнер с изображением MySQL выше ( --link db:mysql ) и передаем имя базы данных для использования в качестве переменной среды ( -e WORDPRESS_DB_NAME="wordpress_1" ). Этот контейнер слушает стандартный HTTP-порт 80 .

Пароль базы данных пользователя root разделяется автоматически, когда мы связываем контейнер db .

Когда изображение загружено и контейнер запущен, перейдите по URL-адресу компьютера, чтобы убедиться, что контейнер работает должным образом. При работе с AWS используйте Public IP, начиная с шага 1 .

Завершите установку WordPress, если хотите — это займет всего минуту или две.

Вы запустили первый из трех контейнеров WordPress. Прежде чем добавить остальное, давайте настроим мониторинг New Relic для текущей настройки.

Установите новый сервер мониторинга Relic с поддержкой Docker

Поддержка Docker в новой Relic разделена на две части:

• В разделе « Серверы» вы найдете общую информацию о Docker: такие вещи, как количество контейнеров разных типов или количество ресурсов, которые они используют на каждом из ваших серверов.
• В части APM вы можете получить доступ к контейнерам Docker как к частям ваших веб-приложений, отслеживая их вместе, а также индивидуально на уровне приложений.

Давайте начнем с части серверов .

Шаг 1. Установите новый серверный монитор Relic

Поскольку New Relic работает как онлайн-сервис, для использования инструментов мониторинга New Relic вам сначала потребуется активная учетная запись New Relic. Вы можете начать с 14-дневной бесплатной пробной версии или использовать бесплатную версию — все функции, представленные в этом руководстве, доступны в бесплатной версии.

Если у вас еще нет учетной записи New Relic, начните с регистрации .

После регистрации выберите Серверы в верхнем меню, чтобы получить доступ к инструменту мониторинга сервера.

Если вы уже используете New Relic Servers, вы увидите список ваших серверов, отслеживаемых с помощью New Relic. Нажмите на кнопку « Добавить еще» для получения инструкций по установке.

Если вы только что зарегистрировались, вас отправят прямо на страницу « Начало работы с новыми серверами Relic» .

На этой странице вы найдете инструкции, относящиеся к различным средам. Выберите тот, который соответствует вашему серверу. Для установки Amazon Linux, использованной в этом руководстве, мы воспользуемся опцией Red Hat или CentOS .

Прокрутите вниз и завершите установку в соответствии с инструкциями, соответствующими среде вашего сервера.

В случае Amazon Linux начните с добавления репозитория New Relic yum. Обратите внимание, что это нужно сделать как root, поэтому мы будем использовать sudo .

Затем, с добавленным репозиторием yum, используйте его для установки пакета Server Monitor :

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

Для завершения установки настройте агент мониторинга и установите свой лицензионный ключ. Вы найдете версию команды с вашим лицензионным ключом на странице Начало работы с новыми серверами Relic . Не забудьте поставить перед командой префикс sudo.

Перед запуском демона мониторинга мы немного отклонимся от инструкций по настройке на странице «Новые серверы Relic» и сделаем несколько дополнительных настроек для мониторинга Docker.

Шаг 2. Примените конфигурацию, специфичную для Docker

Во-первых, чтобы позволить New Relic собирать данные о настройке Docker, добавьте newrelic пользователя в группу Docker на вашем сервере:

Затем перезапустите Docker.

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

После завершения перезагрузки все готово, и вы можете запустить демон мониторинга сервера.

Настройка демона сервера New Relic завершена. Запустите контейнеры Docker снова, и вы скоро увидите информацию о своем сервере на панели инструментов инструмента.

Давайте посмотрим на то, что вы можете найти там.

Что вы найдете внутри новых серверов Relic

Внутри New Relic, нажмите на пункт меню Servers, чтобы перезагрузить список серверов. Если все прошло хорошо, вы должны увидеть свой сервер в списке:

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

Первое, что вы увидите, это страница обзора.

обзор

На странице обзора все выглядит примерно так же, как на странице обзора New Relic Servers при мониторинге обычного сервера без Docker.

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

Если вы посмотрите на список процессов в правом нижнем углу, вы заметите, что Docker действительно работает на этом сервере:

Просмотр изображений Docker

Общий взгляд важен, когда мы думаем о здоровье сервера в целом, но сейчас нас действительно интересует то, что мы можем узнать о настройке Docker. Для этого наиболее интересной частью серверов является меню Docker .

Нажмите на пункт меню Docker слева.

Экран Docker показывает процент ресурсов сервера, используемых контейнерами Docker, сгруппированных по их изображениям.

В этом случае, например, вы увидите два изображения wordpress:latest и mysql/mysql-server:5.5 , которые мы использовали для запуска наших двух контейнеров на предыдущих шагах. На сервере нет большой активности, но мы видим, что WordPress использует больше ресурсов процессора, и оба используют примерно одинаковый объем памяти.

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

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

Например, если вы заметили, что MySQL использует много системной памяти и вычислительной мощности, возможно, стоит подумать о переносе его на свой выделенный сервер. Или, может быть, вы заметите, что на сервере работает больше контейнеров WordPress, чем на самом деле, и решите разделить их на два …

Пристальный взгляд на изображение одного докера

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

На экране отображается загрузка процессора и памяти из контейнеров с этим изображением, а также количество контейнеров с течением времени.

Чтобы увидеть, как добавление большего количества контейнеров влияет на представление, добавьте еще пару контейнеров WordPress. Мы будем использовать ту же команду docker run ранее, с небольшими изменениями:

• Новые контейнеры будут называться wordpress-2 и wordpress-3 соответственно.
• Новые контейнеры будут использовать базы данных wordpress_2 и wordpress_3 .
• Новые контейнеры будут прослушивать разные порты, 8000 и 8001 вместо 80 .

Вот две команды запуска с изменениями из списка выше:

В Amazon, чтобы сделать новые сайты WordPress доступными, вам все равно нужно отредактировать настройки группы безопасности своего экземпляра EC2, чтобы разрешить входящий трафик с портов 8000 и 8001 . Используйте опцию Custom TCP Rule и выберите Anywhere в качестве источника трафика.

Теперь посетите два новых сайта WordPress, нажав на некоторые из их пунктов меню.

Затем вернитесь на New Relic Servers, чтобы увидеть, как изменились данные на странице Docker .

Первое и наиболее заметное изменение — это количество запущенных контейнеров. Вместо одного теперь три:

Использование процессора и памяти все еще низкое, хотя использование памяти показывает рост:

Добавление поддержки нового Relic APM в ваши контейнеры Docker

До сих пор мы рассматривали контейнеры Docker извне, их использование ресурсов и то, как они выглядят, когда исследуются с сервера, на котором они работают.

Но даже несмотря на то, что это представление « Серверы» в Docker действительно предоставляет полезную общую информацию о вашем сервере и о том, что на нем работает, истинная сила New Relic заключается в его подходе «приложение в первую очередь»: отслеживая уровень приложения, вы можете получить более подробную информацию о том, что происходит на вашем сервере и что с этим делать.

Обычно при запуске PHP-кода непосредственно на вашем веб-сервере вы просто устанавливаете агент мониторинга APM. В качестве примера этого вы можете посмотреть прямо на сервере, на котором вы запускаете приложение (как мы делали в учебнике New Relic Alerts, который я упоминал ранее).

Теперь все немного по-другому: мы разделили архитектуру на отдельные части — «микро-сервисы» — каждый из которых работает в своих собственных контейнерах, и поэтому сам хост-сервер не работает под управлением Apache или PHP. Вот почему, если бы вы установили агент APM непосредственно на хост-сервер, вы бы не увидели никакой активности.

Мониторинг должен идти внутри контейнеров.

Шаг 1: Создайте свою собственную версию изображения WordPress

Одной из замечательных особенностей Docker является то, что он позволяет вам строить на основе существующих изображений, используя их в качестве основы и создавая их самостоятельно, без необходимости изменять исходное изображение или писать новое с нуля.

Мы изменим изображение WordPress, которое мы использовали ранее в этом уроке, включив в него мониторинг New Relic.

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

Начните с создания каталога для нового определения образа, например, в домашнем каталоге ec2-user .

Затем в этом каталоге добавьте новый текстовый файл с именем Dockerfile . Это файл, который будет содержать определение того, что входит в ваш образ Docker.

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

Теперь давайте пройдемся по файлу и посмотрим, что он делает.

Строка 1 : файл начинается с указания образа Docker, на котором должно быть построено наше изображение. Я выбрал конкретную версию изображения wordpress так что если мы через некоторое время создадим это изображение, оно не изменится между ними. 4.3.1-apache — последняя версия на момент написания.

Строки 3–5 . Включите скрипт для инициализации монитора New Relic. Сценарий будет запускаться при запуске контейнера, чтобы мы могли использовать его для определения имени приложения и лицензионного ключа отдельно для каждого контейнера.

Мы рассмотрим содержимое этого файла на следующем шаге.

Строки 7–8 : если вы внимательно посмотрите на код, определяющий базовый образ WordPress, вы заметите, что сценарий apache-entrypoint.sh , определенный для запуска в качестве своего ENTRYPOINT заканчивается строкой, которая выполняет команду, переданную в CMD опция (по умолчанию это apache2-foreground ).

Линия выглядит так:

Поскольку я не хотел заменять оригинальный сценарий «точки входа», но мне нужно было завершить его, вызвав новый скрипт run.sh который мы только что упомянули выше, я решил отредактировать файл ENTRYPOINT во время компиляции: команда sed (on line 8 ) заменяет строку exec сверху на команду exec которая вместо этого выполняет run.sh

Строки 10–11 : Это, вероятно, не то, что вам нужно в производственных условиях. Однако для тестирования очень удобно включить простой файл PHP, который мы можем использовать для проверки правильности настройки New Relic.

Не забудьте также создать файл с именем test.php со следующим содержимым:

Строки 13–20 . В этой части мы устанавливаем в образ пакет мониторинга New Relic.

Если вы посмотрите инструкции по установке на странице « Начало работы с новой реликвией» в New Relic (первую страницу, которую вы увидите при выборе опции APM после входа в систему), вы заметите, что команды в этих строках внимательно следят за установкой инструкции для среды Debian. Это потому, что образ WordPress по умолчанию основан на образе, который использует Debian.

Сначала скрипт устанавливает wget и использует его для загрузки ключа New Relic и добавления его в APT.

Затем скрипт добавляет репозиторий New Relic в APT.

И, наконец, в строках 19 и 20 он устанавливает пакет newrelic-php5 из этого хранилища.

Строки 22–25. Инструкции по установке New Relic на странице « Начало работы с New Relic» продолжаются после завершения установки и установки лицензионного ключа.

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

Чтобы подготовиться к этому, скрипт определяет три переменные среды:

• NR_INSTALL_SILENT : эта переменная, если она присутствует (и установлена ​​на любое значение), заставит сценарий установки New Relic пропустить все пользовательские запросы и использовать вместо них значения по умолчанию.
• NR_INSTALL_KEY : этот указывает лицензионный ключ. Поскольку мы не хотим жестко кодировать лицензионный ключ в определении изображения, сейчас он установлен на **ChangeMe** . Эта переменная также автоматически читается сценарием установки.
• NR_APP_NAME : я сам добавил эту переменную, которая будет использоваться в скрипте run.sh для редактирования конфигурации демона New Relic с использованием фактического имени приложения контейнера вместо значения по умолчанию ( "PHP Application" ).

Шаг 2. Создайте пользовательский сценарий запуска

Когда готов Dockerfile , нам все еще нужно реализовать скрипт запуска run.sh , упомянутый выше. Сценарий завершит настройку New Relic и только затем запустит сервер, теперь с включенным мониторингом New Relic.

Создайте файл и добавьте в него следующий код:

Теперь давайте пройдемся по коду построчно.

Строка 1 : укажите, что скрипт должен запускаться с интерпретатором bash.

Строка 2 : укажите, что скрипт должен завершиться в случае возникновения ошибки.

Строки 4–5 : Запустите установочный скрипт New Relic. Обратите внимание, что нам не нужно передавать какие-либо параметры, поскольку конфигурация выполняется с использованием переменных среды. NR_INSTALL_SILENT уже был указан в файле Docker, и NR_INSTALL_KEY следует передать с помощью команды docker run NR_INSTALL_KEY .

Строки 7–8 : поскольку в сценарии установки отсутствует переменная среды для указания имени приложения, нам придется редактировать конфигурацию вручную или фактически программно в этом сценарии.

В файле конфигурации имя приложения указывается как:

Команда sed в строке 8 ищет эту строку и заменяет ее версией, NR_APP_NAME имя, определенное в NR_APP_NAME .

Строка 10 : Наконец, чтобы завершить запуск, вызовите apache2-foreground для запуска Apache на переднем плане и продолжения работы контейнера. Как вы помните ранее, изначально это было сделано в конце сценария точки входа.

Теперь все компоненты для добавления образа WordPress с помощью мониторинга New Relic готовы. Теперь мы можем создать изображение и попробовать.

Шаг 3: скомпилируйте и запустите новый образ

В каталоге, куда вы поместили файлы, созданные в течение последних двух шагов, введите команду:

Это создаст новый образ с именем tutsplus/wordpress-newrelic с тегом 4.3.1-apache и добавит его в локальный репозиторий образов Docker.

Когда сборка завершится, пришло время посмотреть, все ли работает правильно.

Сначала остановите и удалите существующие контейнеры WordPress:

Затем запустите новые, начиная с одного и добавляя еще, как только вы проверите, что все работает нормально.

Команда в основном такая же, как мы видели ранее при запуске образа WordPress по умолчанию, со следующими изменениями:

-e NR_INSTALL_KEY="YOUR KEY HERE" : здесь вы указываете лицензионный ключ New Relic, который следует использовать в сценарии установки. Вы можете найти свои, перейдя на страницу APM « Начало работы с новой реликвией» и выбрав опцию PHP .

На этой странице, прямо перед инструкцией по установке, есть красная кнопка с надписью Reveal License Key . Нажмите на нее и замените YOUR KEY HERE показанным ключом.

-e NR_APP_NAME="wordpress-cloud" : эта часть команды устанавливает переменную среды, используемую для указания имени приложения. Это имя используется для группировки данных внутри APM.

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

Посмотрите документацию New Relic для более детального обсуждения имен ваших приложений .

tutsplus/wordpress-newrelic:4.3.1-apache : В конце команды вы заметите, что теперь мы используем вновь созданный образ вместо wordpress:latest .

После того, как вы запустите команду и ваш сервер запустится, посетите тестовую страницу WordPress, чтобы убедиться, что сервер работает и включена новая Relic. Вы также можете проверить значение newrelic.appname .

Затем вы можете снова перейти на главную страницу, чтобы увидеть, что WordPress работает нормально. Теперь у вас есть Docker-контейнер с WordPress и сообщающий о его состоянии в New Relic APM.

Добавьте оставшиеся два контейнера, wordpress-2 и wordpress-3 , а затем давайте посмотрим на данные, которые мы найдем в APM.

Что вы найдете в новом Relic APM

Теперь, когда вы настроили мониторинг для каждого из ваших контейнеров Docker, давайте посмотрим на информацию, которую мы можем найти о них в APM.

Поскольку мы добавили все три контейнера WordPress с одинаковыми именами, когда вы сейчас откроете страницу APM, вы найдете только одно приложение, wordpress-cloud . Когда вы поместите указатель мыши поверх названия приложения, вы увидите всплывающее окно с надписью «Приложение Php работает на 3 хостах (3 экземпляра)».

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

обзор

Первый вид, который вы увидите в APM — это Обзор . На этой странице показана сводная информация о производительности всех контейнеров в этом приложении: сколько времени в среднем занимают запросы к приложению, оценка Apdex приложения, его пропускная способность и список самых медленных транзакций приложения.

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

В более сложном, реальном приложении вы можете увидеть как несколько серверов, так и несколько контейнеров. Теперь вы найдете наши три контейнера WordPress. Поскольку мы не установили New Relic в образ базы данных, мы не можем увидеть его в этом списке.

Фильтрация данных по контейнеру

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

Однако, если вы хотите перейти к конкретному контейнеру, вы можете в любое время использовать раскрывающееся меню в верхней части экрана, чтобы выбрать тот, который вас интересует:

Если вы не уверены, что означают различные серверные коды в этом списке, вы можете использовать команду docker ps чтобы найти соответствие между этими идентификаторами Docker и вашими контейнерами.

Поиск и исправление ошибок PHP в Docker-контейнерах

APM полезен не только для отслеживания производительности вашего веб-приложения. Это также помогает заметить, когда что-то идет не так в вашем приложении, и найти проблемы.

Чтобы проверить это в среде, основанной на Docker, я создал простой плагин WordPress, намеренно поместив пару ошибок в код, и установил его в один из контейнеров. Затем, после просмотра сайта некоторое время, это то, что я увидел на странице ошибок в APM:

Глядя на картинку, вы быстро увидите, что уровень ошибок в вашем приложении растет.

Ниже графика вы найдете список последних ошибок: синтаксическая ошибка, которая произошла три раза, и деление на ноль, происходящее в разных местах кода. Обе проблемы должны быть рассмотрены, но сейчас давайте посмотрим на первый.

Нажав на сообщение об ошибке, вы попадете на страницу, на которой отображается дополнительная информация об ошибке:

Посмотрев на этот экран, вы увидите, что ошибка происходит в одном из контейнеров Docker, 402c389c0661 , который просто является идентификатором wordpress-3 , контейнера, в который я установил сломанный плагин.

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

Вывод

Теперь вы реализовали простую настройку веб-сервера на основе Docker и включили мониторинг New Relic на нем. Вы также видели, как вы можете использовать инструменты мониторинга, чтобы лучше видеть приложение, основанное на Docker.

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