Работали ли вы с системами логирования?

А, ну логирование, да? Ну, это ж святое, блядь. Без этого вообще нихуя не понятно, что у тебя там в проде творится. Как слепой котёнок.

Работал, конечно, с этим всем. Ну, стандартная история: сначала пишешь Console.WriteLine("Всё охуенно!"), а потом понимаешь, что нихуя не охуенно, и начинаешь искать, где же эта сука ошибка зарылась.

Чем обычно пользуюсь и как:

1. Библиотеки в .NET:

   • Serilog — это сейчас, блядь, вообще король. Все на него перешли. Удобный, структурированные логи пишет, и куда угодно их вывести можно — в консоль, в файл, в какую-нибудь облачную помойку.
   • NLog / log4net — старички, конечно, но ещё пыхтят. Мощные, но иногда такая конфигурация, что волосы дыбом встают. Как древние свитки, ёпта.
   • ILogger<T> — это типа официальная абстракция от Майкрософта. Под капотом у неё обычно Serilog или NLog сидит. Удобно, потому что от вендора не зависишь.

2. Вот тебе живой пример настройки Serilog, чтоб в консоль и в файл JSON лилось:

   // Program.cs (ASP.NET Core 6+)
   using Serilog;
   
   Log.Logger = new LoggerConfiguration()
       .MinimumLevel.Information()
       .MinimumLevel.Override("Microsoft", LogEventLevel.Warning) // А это чтобы убрать трепотню фреймворка, а то он спамит как сумасшедший
       .Enrich.FromLogContext() // Чтоб всякие TraceId цеплялись к логам
       .WriteTo.Console(new JsonFormatter()) // JSON'ом в консоль
       .WriteTo.File("logs/app-.json", rollingInterval: RollingInterval.Day) // И в файлик, который каждый день новый
       .CreateLogger();
   
   var builder = WebApplication.CreateBuilder(args);
   builder.Host.UseSerilog(); // Говорим хосту: "Друг, используй Serilog, забей на стандартный"

3. А вот самый важный пункт, блядь! Структурированное логирование. Запомни раз и навсегда: не пихай данные в строку, а то потом их нихуя не вытащить. Сравни:

   // Так делать — пиздец как не надо. Для анализа это просто кусок текста.
   _logger.LogInformation($"User {userId} ordered product {productId}");
   
   // А вот так — правильно, красиво, мать твою. Параметры именованные.
   _logger.LogInformation("User {UserId} ordered product {ProductId}", userId, productId);
   // На выходе будет чистая JSON'ка: {"@t":"...","@m":"User 123 ordered product 456","UserId":123,"ProductId":456}
   // Потом в том же Seq или Elastic'е ты по `UserId` отфильтруешь за секунду.

4. Ну и куда это всё слать? В консоль — это для дебага. В продакшене нужен централизованный сбор.

   • ELK/EFK Stack (Elasticsearch, Logstash/Fluentd, Kibana) — это, можно сказать, промышленный стандарт. Мощно, но и возни с ним овердохуища.
   • Seq — штука проще, для .NET-ников почти родная. Поднял докером и всё.

     .WriteTo.Seq("http://localhost:5341")

   • Application Insights — если вся твоя хуйня в Azure живёт, то очень удобно. Логи, метрики, трассировка — всё в одном месте.

     builder.Services.AddApplicationInsightsTelemetry();
     // И всё, логи с ILogger сами туда попрут.

На что ещё смотреть надо, чтоб не обосраться:

• Уровни (Debug, Info, Warning, Error) — не лей всё подряд в Information. Debug — для разработки, Warning — когда что-то подозрительное, но не критичное, Error — когда всё, пиздец, надо срочно смотреть.
• Контекст — обязательно пихай в логи CorrelationId, чтобы можно было все действия одного запроса собрать в кучу. Иначе будешь как дурак по миллиону строк ползать.
• Производительность — если у тебя уровень Debug выключен, а ты там целые объекты сериализуешь для лога, то ты конченый идиот. Всегда проверяй if (_logger.IsEnabled(LogLevel.Debug)).
• Данные — НИКОГДА, блядь, НИКОГДА не логируй пароли, токены, номера карт и прочую приватную хуйню. Тебя потом найдут и убьют.