Збирання логів: Seq та Application Insights

1. Вступ

Перш ніж переходити до практики, розберімося, навіщо взагалі потрібні зовнішні системи для збирання логів. Уявіть, що ваш застосунок розгорнуто не на домашньому ПК, а у продакшні: сотні серверів, мікросервіси, безліч користувачів; хтось скаржиться: «застосунок гальмує». Знайти потрібну подію в такому потоці логів — як шукати голку в копиці сіна. Без централізованого збирання логів налагоджувати й супроводжувати такі застосунки практично неможливо. Саме тут на сцену виходять Seq та Application Insights.

Seq: приємний UI, швидкий пошук, реальний час

Seq — це система централізованого збирання та аналізу структурованих логів, орієнтована на .NET і Serilog. Це не просто сервіс для вивантаження лог-файлів, а потужний інструмент: у реальному часі ви бачите потоки логів, фільтруєте їх, шукаєте за властивостями, налаштовуєте алерти. Seq можна розгорнути локально або в хмарі.

Чому обирають Seq?

• Орієнтований на .NET і Serilog, працює одразу після встановлення.
• Дуже швидкий пошук і фільтрування за будь-якими властивостями подій.
• Простий і зручний веб-інтерфейс.
• Можна розгорнути локально без зайвих клопотів, навіть на ноутбуці.

Як виглядає проста архітектурна схема?

+--------------+        +-------------+         +-------------+
| .NET-додаток | --(лог)| Serilog     | --(http)|     Seq     |
+--------------+        +-------------+         +-------------+
                                    |            ^ 
                                    |            | 
             (пошук, фільтри,        <----[Web UI] 
              алерти, інтеграції)

Застосунок записує структуровані логи через Serilog, Serilog надсилає їх до Seq. У веб-інтерфейсі Seq ви робите все, що душі завгодно.

2. Інтеграція Serilog із Seq

Встановлення Seq

Seq можна швидко спробувати локально, навіть для домашніх експериментів. Наприклад, якщо ви використовуєте Windows, завантажте Seq з офіційного сайту.

1. Завантажте Seq і встановіть.
2. Після встановлення відкрийте веб-інтерфейс (зазвичай http://localhost:5341).
3. Готово! Тепер лишилося налаштувати надсилання логів до Seq.

Інтеграція Serilog із Seq

Встановлення NuGet-пакета:

dotnet add package Serilog.Sinks.Seq

Приклад налаштування логування в Program.cs:

using Serilog;

public class Program
{
    public static void Main(string[] args)
    {
        // Налаштування Serilog для виводу логів у Seq
        Log.Logger = new LoggerConfiguration()
            .MinimumLevel.Information()
            .WriteTo.Console()
            .WriteTo.Seq("http://localhost:5341") // URL вашого Seq-сервера
            .CreateLogger();

        Log.Information("Застосунок стартує");
        // ... Інший код застосунку ...

        Log.CloseAndFlush();
    }
}

Якщо все налаштовано правильно, ваші логи із застосунку почнуть надходити до Seq.

Приклад структурованої події

Log.Information("Користувач {User} увійшов у систему о {Time}", userName, DateTime.UtcNow);

У Seq тепер можна шукати всі входи конкретного користувача:

User == 'vasya'

Фільтрація та пошук

Seq уміє фільтрувати події за будь-яким полем і значенням. Наприклад, хочете переглянути всі помилки за сьогодні? Просто задайте фільтр:

@Level = 'Error' and @Timestamp > today()

Можна поєднувати умови — це справді зручно!

Алерти та інтеграції

Seq уміє створювати алерти: якщо, наприклад, кількість помилок перевищує поріг, ви отримаєте лист, спрацює webhook або навіть можна надіслати повідомлення до Slack.

Які ще можливості є?

• Інтеграція з системами CI/CD, щоб автоматично збирати логи тестів.
• Можливість власних дашбордів (за додаткову плату).
• Плагіни для аналізу логів, автоматизації дій (наприклад, автоматичне створення багів під час падіння).
• Інтеграція з Grafana/Prometheus через плагіни.

Типові помилки під час налаштування Seq

Одна з частих проблем — забувають правильно вказати URL сервера Seq у Serilog, або сервер Seq прослуховує інший порт.

Ще одна проблема — не відкривають порт для вхідних з’єднань, якщо Seq працює в Docker або на сервері. Варто перевірити доступність порту із застосунку до Seq.

3. Application Insights: телеметрія для .NET, хмара і магія

Application Insights (або «App Insights») — хмарна платформа моніторингу та аналізу застосунків від Microsoft Azure. Це не лише збирання логів, а й автоматичне виявлення аномалій, аналітика використання, моніторинг залежностей, запитів, зовнішніх API — і, звісно, візуалізація в реальному часі. Azure Application Insights — стандарт у світі enterprise .NET.

У чому плюси Application Insights?

• Не потребує встановлення окремого сервера: усе в хмарі.
• Глибока інтеграція з .NET, ASP.NET, Azure, Visual Studio.
• Автоматично збирає не лише ваші логи, а й метрики, помилки, запити, SQL-запити.
• Можливість будувати дашборди, моніторити SLA, шукати аномалії, аналізувати розподілені трасування (distributed tracing).

Як працює Application Insights?

+--------------+        +-------------------+         +---------------------+
| .NET-додаток | --(SDK)| AppInsights SDK   | --(https)| Azure Application   |
+--------------+        +-------------------+         | Insights (хмара)   |
                                                       +---------------------+
                          ^         |
                        (W3C Trace   +----> Аналітика, пошук, панелі
                         Context)

Застосунок із під’єднаним SDK надсилає телеметрію в хмару Azure, а ви аналізуєте й візуалізуєте її через веб-інтерфейс порталу Azure.

Інтеграція Application Insights із .NET‑застосунком

Варіант 1: Швидко й просто

Якщо у вас ASP.NET Core-застосунок, усе дуже просто:

dotnet add package Microsoft.ApplicationInsights.AspNetCore

У Program.cs:

builder.Services.AddApplicationInsightsTelemetry("<ваш_ключ_інструменту>");

А якщо у вас консольний або десктопний застосунок:

dotnet add package Microsoft.ApplicationInsights

Ініціалізація:

using Microsoft.ApplicationInsights;
using Microsoft.ApplicationInsights.Extensibility;

var telemetryConfig = TelemetryConfiguration.CreateDefault();
telemetryConfig.InstrumentationKey = "<ваш_ключ_інструменту>";
var telemetryClient = new TelemetryClient(telemetryConfig);

telemetryClient.TrackTrace("Привіт від Application Insights!");
telemetryClient.TrackException(new Exception("Ой, сталася помилка!"));

Ключ інструменту потрібно отримати у порталі Azure після створення ресурсу Application Insights.

Як надіслати структуровані дані?

Можете додати властивості до кожного запису trace:

telemetryClient.TrackTrace("Користувач увійшов у систему", 
    new Dictionary<string, string> { ["User"] = userName }
);

Приклад: логування дій користувача

Припустімо, ви хочете логувати вхід користувача:

var props = new Dictionary<string, string>
{
    { "User", userName },
    { "Time", DateTime.UtcNow.ToString("o") }
};
telemetryClient.TrackEvent("UserLogin", props);

Тепер не лише сама подія, а й усі властивості видно в порталі.

4. Корисні нюанси

Що ви бачите в Application Insights?

• Огляд за застосунками: входи, помилки, залежності (наприклад, SQL-запити).
• Пошук за логами: будь-які події, фільтрування за властивостями.
• Візуалізація: графіки, дашборди.
• Трасування: можна бачити ланцюжок викликів і скільки часу тривала кожна операція.
• Алерти: налаштування алертів за будь-якими умовами.

Коротко про структуру Application Insights

Приклад: пошук помилки в Application Insights

У порталі Azure можна побудувати простий запит (Kusto Query Language — KQL):

exceptions
| where timestamp > ago(1d)
| where outerMessage contains "Timeout"
| project timestamp, operation_Name, user_Id, outerMessage

Це покаже всі тайм-аути за останню добу, з деталями.

Обмеження/нюанси Application Insights

• Для використання потрібен обліковий запис Azure. Є безкоштовний рівень, але з лімітами.
• Іноді затримка між надсиланням логів і їх появою в UI — до кількох хвилин.
• Для «дуже приватних» проєктів — це хмара, а не локальна інсталяція.
• Якщо надмірно використовувати trace‑повідомлення — можна швидко вичерпати денний ліміт.

5. Порівняння Seq та Application Insights

Застосування знань на практиці

Знання про Seq та Application Insights стануть у пригоді вам не лише у продакшні, а й на етапах розробки, тестування (наприклад, для аналізу поведінки автотестів), під час роботи з мікросервісами, коли хочеться бачити картину цілком. На співбесідах часто запитують «Як би ви організували збирання логів, щоб швидко знаходити проблеми у продакшні?» — тепер у вас є що відповісти!

Більше того, багато сучасних компаній використовують такі системи для побудови цілих ланцюжків DevOps-інструментів: Continuous Delivery, автоматичне створення багів за алертами тощо. Система збирання логів — це не просто «куди потрапляє рядок Console.WriteLine», а справжня «чорна скринька» і монітор вашого застосунку.