Проблема прерывания отправки метрик с помощью 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 STG. Наша реализация работала без сбоев примерно 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