Информация о приложении не получает никаких данных

Question

Я пытаюсь установить соединение между используемым приложением .NET Core и Azure Application Insights. Само приложение представляет собой приложение API, в котором серверная часть разбита на несколько уровней обслуживания.

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

TelemetryClient telemetry = new TelemetryClient(TelemetryConfiguration.CreateDefault());
telemetry.InstrumentationKey = "<my instrumentation key>";
telemetry.TrackEvent("Hello event");
telemetry.TrackPageView("Hello event page view");
telemetry.TrackException(new Exception());
telemetry.TrackTrace("Hello trace message");

Я могу пройти вышеупомянутый код без каких-либо известных проблем (то есть без сбоев отладчика или без отображаемых ошибок). Однако, просматривая вкладку «Сеть» в Chrome Inspector, я вижу, что выполняется вызов моей функции API, но в Application Insights не было отправлено ни одного отслеживающего вызова. Согласно https://docs.microsoft.com/en-us/azure/azure-monitor/app/asp-net-troubleshoot-no-data, я должен видеть отправку данных на dc.services.visualstudio.com.

Может кто-нибудь пролить свет на то, как это работает, или я что-то упустил?

Answer 1

В сетевом базовом API рекомендуемый способ настройки параметров понимания вашего приложения - через метод AddApplicationInsightsTelemetry в коллекции служб, например,

// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{       
    services.AddApplicationInsightsTelemetry();
}

См. https://docs.microsoft.com/en-us/azure/azure-monitor/app/asp-net-core для дополнительных примеров,

Если вы посмотрите на то, что делает этот метод, он зарегистрирует ряд компонентов для вас в нижележащем контейнере, а это означает, что теперь вы можете получить доступ к объектам TelemetryClient и TelemetryConfiguration из экземпляров, созданных контейнером

Если вы хотитечтобы выполнить дополнительную настройку объекта TelemetryConfiguration, его можно добавить в метод Configure, например,

public void Configure(IApplicationBuilder app, IHostingEnvironment env, TelemetryConfiguration config)
{
    // do whatever you want to the config object here
}

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

public class MyLibraryClass
{
    TelemetryClient _telemetryClient

    public MyLibraryClass(TelemetryClient telemetryClient)
    {
        _telemetryClient = telemetryClient;     
    }   

    public void Foo()
    {
        _telemetryClient.TrackTrace("Foo");
    }
}

AI SDK будет буферизовать и пакетировать события телеметрии в инструментируемом процессе. Это означает, что каждое использование метода SDK, такого как TrackTrace, TrackEvent и т. Д., Не сразу приводит к HTTP-вызову конечной точки сбора. Данные передаются при заполнении буфера или прохождении интервала между буферами, в зависимости от того, что произойдет раньше,

При желании вы можете переопределить это поведение, передав флаг DeveloperMode в AddApplicationInsightsTelemetry, например,

services.AddApplicationInsightsTelemetry(new ApplicationInsightsServiceOptions() {DeveloperMode = true});

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

Answer 2

Разместить ответ на вопрос. Есть еще немного информации, которая, я думаю, не была бы уместна, например, что я использую Service Stack для .NET Core, поэтому я также публикую эту информацию здесь.

Способ ведения журнала в Service Stack - эточто он обычно определяется в файлах Program и Startup, а затем сохраняется в LogFactory. Service Stack заявляет, что в .NET Core они делегируют всю работу по ведению журнала встроенному классу NetCoreLogFactory, используемому в .NET Core. NetCoreLogFactory может использовать практически любой интерфейс ведения журнала, передавая ему ILoggerFactory, который определен в Program.cs. .

Код, который я использую для настройки интерфейса ведения журнала в Program.cs:

    public static IWebHost BuildWebHost(string[] args) =>
            WebHost.CreateDefaultBuilder(args)
            .ConfigureLogging(logging => {
                logging.ClearProviders();
                logging.SetMinimumLevel(LogLevel.Trace);
            })
            .UseNLog()
            .UseStartup<Startup>()
            .Build();

А в файле Startup.cs:

    public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
        {
            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }

            app.UseServiceStack(new AppHost
            {
                AppSettings = new NetCoreAppSettings(Configuration)
            });

            LogManager.LogFactory = new NetCoreLogFactory(loggerFactory, true);
        }

Уровни обслуживания могутзатем вызовите это определение, вызвав LogManager.GetLogger (GetType ()). Тогда возникает вопрос, как будет определяться LogFactory.

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

Теперь код работает, и я вижу данные, поступающие в Application Insights.