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

Question

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

Уточнение проблемы: Как часть инструментария / конфигурации New Relic, я установил "имя_приложения", используя имя службы. (Это стандартная конфигурация для New Relic.)

Сделав это, я могу зайти в New Relic и посмотреть, что работает микро-сервис, выбрав его (по app_name) из списка приложений. Я вижу обзор, карту сервиса, транзакции, базу данных... Все эти страницы хорошо сфокусированы на моем сервисе и выделяют метрики, представляющие интерес для меня как владельца / разработчика сервиса.

Однако у моего менеджера есть команда людей, каждый из которых владеет / разрабатывает услуги. Мой менеджер хотел бы, чтобы все эти службы использовали одно и то же "имя_приложения", чтобы он мог перейти в New Relic и посмотреть обзор, карту сервисов, транзакции... все они прекрасно отображают интересующие метрики для всех сервисов, за которые он отвечает,

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

Я бы хотел, чтобы оба потребителя данных New Relic получили то, что они хотят.

Это должна быть общая потребность, которая имеет общее решение.

Что я пробовал / узнал: несколько "app_name": я узнал, что могу предоставить до трех значений "app_name" для каждой службы / приложения. Я пробовал это, и, кажется, работает просто отлично. Предоставляя как уникальное имя, так и общее имя, оба этих имени приложения доступны в списке выбора "приложения". Кажется, это делает то, что нам нужно, но из документации следует, что это предназначено для поддержки приложений, работающих в разных средах. Похоже, что это также "подобный взлому" подход, поскольку он ограничен тремя значениями, и можно представить, что нужно больше способов агрегировать данные. Если это рекомендуемый / распространенный подход, я согласен с ним.

Подход категории / метки: я также экспериментировал с добавлением метки для приложения (метка представляет собой пару ключ / значение, заданную в конфигурации New Relic). Казалось бы, это более общий подход, который будет масштабироваться по мере необходимости. Тем не менее, это не решает проблему. Это просто позволяет фильтровать список приложений / услуг по категориям. Категории не доступны как способы агрегирования метрик.

Инсайты / Инфраструктура: Есть новые функции Relic, которые я пока не понимаю. Наша учетная запись не имеет доступа к этим функциям, поэтому, если они верны, мне нужно предложить улучшить нашу учетную запись.

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

Если кто-нибудь знает, как правильно решить эту проблему, я был бы очень признателен за ваши отзывы.

Answer 1

New Relic разработан так, чтобы работать так, как вы изначально его использовали: одно приложение в реальном мире - это одно приложение в New Relic. Каждый сервис или микросервис должен сообщать в New Relic как отдельное приложение в APM. В противном случае вы загрязняете данные, которые вы получаете.

Рассмотрим сценарий, в котором одно приложение является общедоступным ("foo"), а другое - только внутренним ("bar"). Если они оба отправляют отчеты в New Relic, используя только одно имя приложения ("foobar"), вы можете открыть "foobar" в APM и увидеть, что он имеет умеренную пропускную способность, но хорошее время отклика. На самом деле общение с публикой может быть затруднено запросами или может работать очень плохо, но поскольку у вас внутренний сайт с низким трафиком, который очень быстро реагирует на каждый запрос, ваша средняя пропускная способность и среднее время отклика в "foobar" выглядят хорошо,

Если ваш менеджер должен иметь возможность просматривать данные приложения, он должен использовать New Relic Insights. Вы можете запросить данные в нескольких приложениях, например:

SELECT * FROM Transaction WHERE appName = 'foo' OR appName = 'bar'

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