Comments 7
Интересный пост, спасибо)
Текстовые логи это хорошо, но уже хочется чего-то интереснее - телеметрии с временем запросов, всякими метриками и correlation id. Скорее всего - через OpenTelemetry.
И там это всё уже есть, остаётся только настроить. OpenTelemetry Collector отдельным процессом или sidecar в kubernetes уже разгружает основное приложение, а сам коллектор при необходимости умеет писать WAL лог на диск или отправлять события в локальную кафку как ещё один слой перед отправкой в облако.
Заодно на коллекторе можно семплинг настроить - может быть, отправлять и хранить все сотни миллионов логов и не нужно. Я сейчас посмотрел - они в tail sampling умеют тоже, то есть можно решать, отправить лог или нет, после завершения всей операции. И, скажем, логи с ошибками отправлять все, а от успешных операций - агрессивно семплить.
Подушню: а вариант "писать меньше логов" вам не подошёл?
В нашем случае народ не очень сильно упарывается по детальным логам. Просто много компонентов и от этого много логов. А записывать в техдолг задачи типа "пройтись по коду и убрать лишние логи" - это уже перегиб)
А как насчёт задачи типа "пройтись по логам и выключить в конфиге неинтересные"?
Это можно и нужно, но, если прилетит нагрузка на приложение, которая чисто математически увеличит количество этих логов из-за увеличившегося числа запросов в секунду таким образом, что они станут копиться быстрее, чем отправляться в удалённый приёмник, то написанное актуально. В случае, когда на стороне удалённого приёмника возникнут непредвиденные задержки, то же самое.
Логирование с Serilog: как повысить отказоустойчивость и скорость