Объедините все микросервисы AKS в единый Application Insights и сможете фильтровать по имени микросервиса - PullRequest
0 голосов
/ 03 февраля 2020

Я хотел бы знать, возможно ли иметь несколько Azure микро-сервисов Kubernetes, указывающих на одни и те же ресурсы Application Insights, и иметь возможность использовать журнальные запросы для разделения журналов по имени микро-сервисов.

На данный момент мне удалось создать ресурс Application Insights. Я также настроил микро-сервисы так, чтобы они указывали на этот ресурс Application Insights с помощью среды IDE Visual Studio 2017 (все это делается через GUI).

При этом все мои микро-сервисы теперь связаны с одним приложением. Insights. Я хотел бы иметь возможность отфильтровывать свои запросы журнала по микро-сервисам.

Причина этого в том, что компания, в которой я работаю, скоро может иметь много микро-сервисов и не хочет управлять ресурсами N Application Insights. , Вместо этого мы хотим, чтобы все было централизовано в одном и том же Application Insights (поэтому я не могу использовать оператор объединения, чтобы объединить несколько идей приложения, поскольку нам нужно только одно).

Я думал о добавлении настраиваемых полей в Application Insights, но не похоже, что это может помочь в моей ситуации. https://docs.microsoft.com/en-us/azure/azure-monitor/platform/custom-fields

Спасибо!

ОБНОВЛЕНИЕ: Пример кода: Telemetry Clas Program.cs: enter image description here Пользовательские измерения: enter image description here

После прочтения этого поста: Добавление пользовательского измерения для запроса телеметрии - Azure функции Я понял, что мне нужно вызвать TrackEvent () TrackTrace () и т. Д. c. чтобы увидеть новую запись пользовательских размеров. Однако мне нужно было добавить столбец Microservice к любому запросу / событию / трассировке, произведенному данным микросервисом.

Ответы [ 2 ]

1 голос
/ 05 февраля 2020

Мне удалось решить проблему, добавив несколько шагов к решению, которое дал мне Питер.

  1. Я создал собственный инициализатор телеметрии, который выглядит следующим образом:
 public class MicroserviceNameTelemetry : ITelemetryInitializer
    {
        private string microserviceName;
        public MicroserviceNameTelemetry(string microserviceName)
        {
            this.microserviceName = microserviceName;
        }
        public void Initialize(ITelemetry telemetry)
        {
            telemetry.Context.GlobalProperties["Microservice"] = microserviceName;
        }

    }

Затем мне пришлось перезаписать инициализатор телеметрии по умолчанию в Startup.cs (шаг, который я добавил):

public static IServiceCollection AddApplicationInsights(this IServiceCollection services, IConfiguration configuration)
{
            services.AddApplicationInsightsTelemetry(configuration);
            services.AddSingleton<ITelemetryInitializer, MicroserviceNameTelemetry>((serviceProvider) => {
                return new MicroserviceNameTelemetry(configuration.GetSection("Microservice").GetValue<string>("name"));
            });
            // Enable K8s telemetry initializer            
           services.AddApplicationInsightsKubernetesEnricher();

            return services;
}
1 голос
/ 03 февраля 2020

Причина этого заключается в том, что у компании, в которой я работаю, скоро может появиться много микро-сервисов, и они не захотят управлять ресурсами N приложения. Вместо этого мы хотим, чтобы все было централизовано в одной и той же Application Insights (поэтому я не могу использовать оператор объединения для объединения нескольких идей приложения, поскольку мы хотим иметь только одну)

Помните, что ценовая модель App Insights в основном на основе стоимости за ГБ данных. Первая пара ГБ в месяц бесплатно. Таким образом, ваше решение может быть не самым экономичным.

Я думал о добавлении настраиваемых полей в Application Insights, но, похоже, оно не поможет в моей ситуации. https://docs.microsoft.com/en-us/azure/azure-monitor/platform/custom-fields

Для App Insights вы можете использовать пользовательские свойства. Есть несколько способов установить их (используя код!). Один из них - установить их напрямую, как показано здесь :

using Microsoft.ApplicationInsights.DataContracts;

var gameTelemetry = new TelemetryClient();
gameTelemetry.Context.GlobalProperties["Game"] = currentGame.Name;
// Now all telemetry will automatically be sent with the context property:
gameTelemetry.TrackEvent("WinGame");

Имейте в виду, что этот метод добавит только свойства к телеметрии, созданной с использованием экземпляра TelemetryClient!

другой использует инициализатор телеметрии :

using System;
using Microsoft.ApplicationInsights.Channel;
using Microsoft.ApplicationInsights.DataContracts;
using Microsoft.ApplicationInsights.Extensibility;

namespace MvcWebRole.Telemetry
{
  /*
   * Custom TelemetryInitializer that overrides the default SDK
   * behavior of treating response codes >= 400 as failed requests
   *
   */
  public class MyTelemetryInitializer : ITelemetryInitializer
  {
    public void Initialize(ITelemetry telemetry)
    {
        var requestTelemetry = telemetry as RequestTelemetry;
        // Is this a TrackRequest() ?
        if (requestTelemetry == null) return;
        int code;
        bool parsed = Int32.TryParse(requestTelemetry.ResponseCode, out code);
        if (!parsed) return;
        if (code >= 400 && code < 500)
        {
            // If we set the Success property, the SDK won't change it:
            requestTelemetry.Success = true;

            // Allow us to filter these requests in the portal:
            requestTelemetry.Properties["Overridden400s"] = "true";
        }
        // else leave the SDK to set the Success property
    }
  }
}

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

Я хотел бы знать, возможно ли иметь несколько Azure микро сервисов Kubernetes, указывающих на одни и те же ресурсы Application Insights, и иметь возможность использовать запросы журнала для разделения журналы на имя микро-сервисов.

Теперь, возможно, что-то уже есть. Все телеметрии имеют такие свойства, как cloud_Rolename & cloud_RoleInstance:

requests
| project cloud_RoleInstance , cloud_RoleName 

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

Итак, для Например, это покажет запросы, разделенные на pod:

requests
| summarize count() by cloud_RoleName 

Если вы используете C#, вы также можете добавить этот пакет, созданный Microsoft, который будет прикреплять множество деталей AKS к телеметрия, такая как идентификатор модуля, метки модуля, имя набора реплик и т. д. c.

...