Организация Application Insights / Проверка работоспособности для услуг одного арендатора

Question

Я управляю продуктом, в котором мы настраиваем полную среду для каждого клиента. Продукт состоит из внешнего интерфейса Angular с бэкэндом API ASP.Net.Core и базой данных сервера SQL.

В результате получается архитектура, например,

https://customer1.product.com и https://customer1.product.com/api

https://customer2.product.com и https://customer1.product.com/api

и т. Д. ... Сайт для каждого клиента, но несколько сайтов клиентов совместно используют один и тот же сервер IIS.

Я пытался включить Application Insight хотя бы для API и включить проверку работоспособности.

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

Я хотел бы получить общее представление о сервере с суммированным общим количеством запросов по API и т. Д.

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

Тем не менее, для проверки работоспособности я могу добавить только 100 тестов ping к одному ресурсу. Я думал о создании независимой службы, которая, используя список сайтов, могла бы использовать новое ядро ​​.Net 2.2. Проверка работоспособности и проверка связи каждого сайта с внешнего сервера, а затем настройка этого параметра на .Net Core Health Check в качестве проверки связи на ресурсе Insight. (Использовал это как вдохновение: https://www.hanselman.com/blog/HowToSetUpASPNETCore22HealthChecksWithBeatPulsesAspNetCoreDiagnosticsHealthChecks.aspx). Но тогда я не получал бы пользу от региональных тестов Insights - так как все запросы приходили из моего API проверки работоспособности.

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

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

Я бы хотел

• Понимание на уровне сервера, например запросы, загрузка и т. д. для сайтов.
  • Но детализация до одного сайта также будет полезна для распределения нагрузки для клиентов
• Два теста ping на каждом сайте, Angular index.html и вызов API, который подключается к базе данных.
• Простая настройка, поэтому, когда мы получаем новых клиентов, часть мониторинга будет либо самоконфигурируемой, либо скриптовой. По крайней мере, нам не следует заходить на портал Azure Insights.

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

Также приветствуются предложения по другим продуктам, кроме Application Insights. Только что посчитал, что Insights хорошо подходит для API Asp.Net.Core. Уже используете Sentry для сбора отчетов об ошибках.

С наилучшими пожеланиями / Anders

Answer 1

Позвольте мне поделиться тем, что возможно, надеюсь, это поможет с решением.

Быстрое примечание - при необходимости можно написать все через ARM. Ресурсы Application Insights включены. Не должно беспокоиться о том, какое решение вы выберете в конце (хотя для разных решений может потребоваться больше сценариев).

Вариант 1. Каждый получает свой ресурс ИИ. Вся телеметрия (сервер, клиент, доступность) передается на нее.

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

Сказав это, на самом деле есть способ выполнять запросы ресурсов Application Insights в Application Insights Analytics. Трудно сделать такие запросы эффективными (поскольку им потенциально необходимо передавать данные по кластерам), поэтому вам нужно поиграть, чтобы понять, можете ли вы получить то, что вам нужно.

Вариант 2. Иметь один ресурс ИИ для всей телеметрии для всех клиентов. Клиент различается только по названию операции.

Легко сделать через запросы клиентов. Но сложнее провести расследование для конкретного клиента. Также существует ограничение в 100 веб-тестов на ресурс

Вариант 3. Иметь один ресурс AI для телеметрии сервер / клиент. Используйте RoleName, чтобы дифференцировать клиентов. Иметь ресурс AI / клиента для доступности.

Это позволяет получать как сводные данные по клиентам, так и данные, относящиеся к одному RoleName (клиенту).

Наличие - позволяет настроить необходимое количество тестов для каждого клиента. Индивидуальный отчет для каждого клиента. Распределенная трассировка должна продолжать работать (Application Insights может работать между ресурсами).

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

Надеюсь, это поможет!