Проблема прерывания отправки метрик с помощью OpenTelemetry в .NET 6.0 ⇐ C#

[Anonymous]

Я разрабатываю веб-приложение на .NET 6.0 и использую OpenTelemetry для мониторинга показателей. Однако столкнулся с проблемой: в определенный момент приложение перестает отправлять метрики, и единственный способ восстановить работоспособность — перезапустить пул.

• Технические сведения:
  
  Платформа: .NET 6.0
• Язык: C#

[*]Библиотеки OpenTelemetry:

• OpenTelemetry 1.6.0
• OpenTelemetry.Exporter.OpenTelemetryProtocol 1.6.0

Конфигурация OpenTelemetry:
Я настроил OpenTelemetry в файле Program.cs следующим образом:

Код: Выделить всё

builder.Services.AddOpenTelemetry(builder.Configuration);

И у меня есть отдельный класс конфигурации MetricsConfigurator.
Вот фрагмент кода конфигурации OpenTelemetry:

Код: Выделить всё

private static readonly AsyncLocal CurrentCallConfiguration = new();

public static MeterProvider Configure(IConfiguration configuration, Assembly mainAssembly)
{
var appName = mainAssembly.GetName();
var resource = ResourceBuilder.CreateDefault()
.AddService(serviceName: appName.Name, serviceVersion: appName.Version!.ToString())
.AddAttributes(new KeyValuePair[]
{
new("server.name", Environment.MachineName),
new("process.id", Environment.ProcessId)
});

var exportInterval = TimeSpan.FromMilliseconds(configuration.GetValue("OpenTelemetry:ExportIntervalMilliseconds", 60000));

return Sdk.CreateMeterProviderBuilder()
.AddMeter("*")
.SetResourceBuilder(resource)
.AddView(instrument =>
{
var config = CurrentCallConfiguration.Value;
CurrentCallConfiguration.Value = null;
return config;
})
.AddOtlpExporter((eo, mo) =>
{
eo.Endpoint = new Uri("http://localhost:5110");
eo.Protocol = OtlpExportProtocol.Grpc;
mo.PeriodicExportingMetricReaderOptions = new PeriodicExportingMetricReaderOptions
{
ExportIntervalMilliseconds = (int)exportInterval.TotalMilliseconds
};
mo.TemporalityPreference = MetricReaderTemporalityPreference.Delta;
}).Build();
}

public static void AddOpenTelemetry(this IServiceCollection services, IConfiguration configuration)
{
var meterProvider = Configure(configuration, Assembly.GetCallingAssembly());
services.AddSingleton(meterProvider);
}

public static Meter UsingConfiguration(this Meter meter, MetricStreamConfiguration configuration)
{
CurrentCallConfiguration.Value = configuration;
return meter;
}

Попытки устранения неполадок:

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

Вопросы:

Вопросы:

Вопросы:

Strong>

• Кто-нибудь сталкивался с подобной проблемой и знает, как ее решить?
• Есть ли предложения о том, как мне можно ли дополнительно диагностировать и решить эту проблему?
• Любая помощь или предложение будем очень признательны.

Обновление от 04.10.2023
Проблема:
После развертывания регистрация телеметрии в обоих наших проектах работает только в течение ограниченного периода времени. Оба приложения используют .NET 6 и запускают OpenTelemetry с немного разными кодами. Предполагается, что сборщик мусора преждевременно освобождает экземпляр MeterProvider, воспринимая его как ненужный и нарушая ведение журнала телеметрии.
Попытка решения:
Попытка решения: Strong>
Я ввел статическое поле Provider для сохранения экземпляра MeterProvider и использовал GC.KeepAlive, чтобы предотвратить его преждевременный сбор GC.

Код: Выделить всё

private static MeterProvider Provider;

// Configuration logic...
Provider = Sdk.CreateMeterProviderBuilder()
// Configuration logic...
.Build();

// More configuration logic...
GC.KeepAlive(Provider);

Заменена предыдущая логика:

Код: Выделить всё

services.AddSingleton(meterProvider);

Ищу совета:[/b]
Хотя это решение, кажется, работает предварительно, я хочу понять, есть ли лучшие или оптимизированные способы гарантировать, что MeterProvider экземпляр не собирается преждевременно сборщиком мусора, или существуют альтернативные стратегии для защиты ведения журналов телеметрии без риска потенциального раздувания памяти в долго работающих приложениях.
Будем признательны за любые идеи или альтернативные решения. !
Обновление от 11.10.2023
Привет всем!
Спасибо за вашу постоянную поддержку и обсуждения по первоначальному запросу.
Я хотел бы обратить внимание на наше продолжающееся расследование проблем со связью gRPC, которые сохраняются даже после корректировки нашего класса конфигурации и развертывания решения на AWS. Среда СТГ. Наша реализация работала без сбоев примерно 3 часа, прежде чем начали появляться ошибки.
Обнаружена ошибка:

Код: Выделить всё

2023-10-10T07:38:24.9429543Z: Exporter failed to send data to collector to {0} endpoint... Grpc.Core.RpcException: Status(StatusCode="Unavailable", Detail="Error starting gRPC call. HttpRequestException: An error occurred while sending the request. IOException: The request was aborted. IOException: The response ended prematurely while waiting for the next frame from the server.", DebugException="System.Net.Http.HttpRequestException: An error occurred while sending the request.")

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

• Перезапустил пул соединений на двух веб-серверах в закрепленном сеансе последовательно, при этом метрики успешно отправляются после операции после каждого перезапуска.
• Проанализировали активные процессы связи со сборщиком, не заметив никаких процессов, связанных с нашим приложением перед пулом. перезапуски и появление процессов после перезапуска.
  Метрики точно фиксируются, но возникают трудности со связью со службой gRPC, особенно только тогда, когда приложение работает на платформе 6.0 во время процесса. на IIS и размещен на AWS.

Запрос информации:
Мы изучаем потенциальные версии, которые могут указывать на то, связана ли эта ошибка со стороной сборщика, и концентрируемся на исследовании IOException, когда ответ завершается преждевременно во время ожидания следующего кадра с сервера.
Эта интеграция идей и ошибок наших недавних усилий направлена ​​на предоставление комплексное представление о нашем пути и камнях преткновения, с которыми мы сталкиваемся.
Ваш опыт и предложения неоценимы, и мы ценим любой вклад, который может помочь в решении этих проблем. Давайте продолжим это содержательное обсуждение и вместе поработаем над решением проблемы.
Спасибо за ваше терпение, понимание и дух сотрудничества!
Ошибка регистрации OpenTelemetry: Исключение отмены задачи с Grpc.Core
Описание:
Я постоянно сталкивался с ошибкой при попытке записи журналы с помощью OpenTelemetry.
Ошибка предполагает, что при обращении через канал gRPC происходит отмена задачи. Вот сообщение об ошибке:

Код: Выделить всё

Failed to write logs to OpenTelemetry due to System.Threading.Tasks.TaskCanceledException: Reached deadline.
at Grpc.Core.Channel.d__16.MoveNext() in /path/obfuscated/Grpc.Core/Channel.cs:line 146
... [rest of the stack trace is similar to provided, but with paths obfuscated]
at Obfuscated.OpenTelemetryLogProvider.d__39.MoveNext() in /path/obfuscated/OpenTelemetryLogProvider.cs:line 250

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

Подробнее здесь: https://stackoverflow.com/questions/772 ... in-net-6-0