Помните те времена, когда для анализа проблемы приходилось подключаться к серверу, искать нужный лог-файл среди десятков других и вручную фильтровать тысячи строк в поисках ошибки? К счастью, эти дни остались позади. Централизованное логирование становится не просто удобством, а необходимостью. Когда приложение масштабируется и распределяется по множеству серверов и контейнеров традиционный подход с записью логов в файлы превращается в кошмар. Как быстро найти причину ошибки, если она могла произойти на любом из десятков микросервисов? Как связать цепочку событий, которые происходили в разных частях системы? Как обнаружить аномалии в работе приложения до того, как они повлияют на пользователей? Для решения этих проблем сформировался мощный стек технологий, который мы рассмотрим в этой статье. Он включает в себя три ключевых компонента:
Serilog – библиотека логирования для .NET, которая позволяет структурировать логи и направлять их в различные хранилища,
ElasticSearch – распределённая поисковая система, способная эффективно хранить и индексировать огромные объёмы данных,
Kibana – визуальный интерфейс для ElasticSearch, превращающий сухие данные в наглядные графики и дашборды.
Этот стек, часто называемый "ELK" (заменяя Logstash на Serilog для .NET приложений), стал стандартом де-факто для многих компаний. В сравнении с альтернативами, такими как Graylog или стек на базе Fluentd, ELK выигрывает своей гибкостью, производительностью и огромным сообществом пользователей. В то время как Graylog предлагает более простую настройку и может быть удобнее для небольших проектов, он уступает в гибкости ElasticSearch при работе с большими объёмами данных. Fluentd c другой стороны отлично справляется со сбором логов из различных источников, но требует дополнительных компонентов для хранения и визуализации.
Основы логирования в ASP.NET Core
ASP.NET Core предлагает встроенную систему логирования, которая работает "из коробки" и не требует подключения сторонних библиотек. Эта система построена на основе абстракции Microsoft.Extensions.Logging, которая предоставляет унифицированный интерфейс для различных провайдеров логирования.
Встроенная система логирования и её ограничения
По умолчанию ASP.NET Core приложение уже настроено для вывода логов в консоль и отладочное окно. Это происходит благодаря вызову метода CreateDefaultBuilder() при создании хоста приложения:
| C# | 1
2
3
4
5
6
| public static IHostBuilder CreateHostBuilder(string[] args) =>
Host.CreateDefaultBuilder(args)
.ConfigureWebHostDefaults(webBuilder =>
{
webBuilder.UseStartup<Startup>();
}); |
|
Console — вывод в терминал,
Debug — вывод в отладочное окно IDE,
EventSource — для трассировки событий,
EventLog — для Windows Event Log (только на Windows).
Однако встроенная система имеет ряд существенных ограничений:
1. Ограниченная поддержка структурированныхлогов — встроенные провайдеры обрабатывают строки сообщений, а не структурированные данные.
2. Сложное расширение — добавление новых "приёмников" логов требует написания своих провайдеров.
3. Отсутствие готовых решений для сложных сценариев — нет встроенной поддержки ротации файлов, буферизации, обогащения контекстом.
4. Низкая производительность — стандартные провайдеры не оптимизированы для высоконагруженных систем.
В результате при разработке серьёзных приложений приходится либо писать расширения для стандартной системы, либо обращаться к сторонним библиотекам.
Почему стоит выбрать Serilog
Serilog — одна из наиболее мощных и популярных библиотек логирования для .NET. Она решает практически все проблемы стандартного логирования и предлагает ряд существенных преимуществ:
1. Нативная поддержка структурированных логов — вы можете логировать объекты и структуры данных, а не только строки.
2. Множество готовых "приёмников" (sinks) — от простых файлов до сложных систем вроде ElasticSearch.
3. Высокая производительность — оптимизированная архитектура с минимальными накладными расходами.
4. Богатая экосистема расширений — для любой задачи найдётся готовое решение.
5. Простая интеграция с ASP.NET Core — благодаря пакету Serilog.AspNetCore.
Уровни логирования и их правильное использование в бизнес-контексте
В Serilog, как и в стандартной системе логирования ASP.NET Core, используется 6 основных уровней логирования:
Verbose (Trace) — самые детальные сообщения, обычно используются только при отладке,
Debug — диагностическая информация, полезная разработчикам,
Information — нормальные события работы приложения,
Warning — потенциальные проблемы не прерывающие работу приложения,
Error — ошибки и исключения, которые влияют на функциональность, но не останавливают приложение,
Fatal (Critical) — критические ошибки, требующие немедленного вмешательства.
Правильное использование уровней — это не просто технический вопрос, а важный аспект бизнес-контекста приложения. Рассмотрим несколько примеров:
Information следует использовать для бизнес-событий, которые должны быть видны в операционном мониторинге: "Заказ #12345 создан", "Платеж на сумму 1000₽ обработан".
Warning подходит для нештатных, но не критичных ситуаций: "Сервис доставки не ответил, используем резервный", "Попытка входа с необычного IP-адреса".
Error должен фиксировать ситуации, когда бизнес-функциональность нарушена: "Не удалось списать средства с карты", "Невозможно сформировать отчёт".
Исключения и логирование: стратегии перехвата и документирования ошибок
При работе с исключениями и их логированием стоит придерживаться нескольких правил:
1. Логировать исключения там, где они обрабатываются — это предотвращает дублирование записей.
2. Включать полный стек вызовов и контекст — это критично для отладки.
| C# | 1
2
3
4
5
6
7
8
9
10
| try
{
// Код, который может вызвать исключение
_paymentService.ProcessPayment(orderId, amount);
}
catch (Exception ex)
{
_logger.LogError(ex, "Ошибка при обработке платежа для заказа {OrderId} на сумму {Amount}", orderId, amount);
// Обработка исключения
} |
|
Конфигурация через appsettings.json vs программная конфигурация
Существует два основных подхода к конфигурации Serilog: через файл appsettings.json и программный путь. Оба имеют свои преимущества.
Конфигурация через appsettings.json:
| JSON | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| {
"Serilog": {
"MinimumLevel": {
"Default": "Information",
"Override": {
"Microsoft": "Warning",
"System": "Warning"
}
},
"WriteTo": [
{ "Name": "Console" },
{
"Name": "File",
"Args": {
"path": "logs/app.log",
"rollingInterval": "Day"
}
}
]
}
} |
|
| C# | 1
2
3
4
5
6
7
| Log.Logger = new LoggerConfiguration()
.MinimumLevel.Information()
.MinimumLevel.Override("Microsoft", LogEventLevel.Warning)
.MinimumLevel.Override("System", LogEventLevel.Warning)
.WriteTo.Console()
.WriteTo.File("logs/app.log", rollingInterval: RollingInterval.Day)
.CreateLogger(); |
|
- Изменения не требуют перекомпиляции.
- Удобно менять настройки между окружениями.
- Централизованное хранение всех настроек приложения.
Преимущества программной конфигурации:- Полный контроль над порядком инициализации.
- Возможность динамически изменять настройки.
- Удобство использования переменных окружения и других источников конфигурации.
Наилучшим подходом обычно является комбинирование обоих методов - базовая инициализация программным путём с подгрузкой детальной конфигурации из appsettings.json:
| C# | 1
2
3
4
5
6
7
8
| var configuration = new ConfigurationBuilder()
.AddJsonFile("appsettings.json")
.Build();
Log.Logger = new LoggerConfiguration()
.ReadFrom.Configuration(configuration)
.Enrich.FromLogContext()
.CreateLogger(); |
|
Разница между ASP.NET Core 2, ASP.NET Core MVC, ASP.NET MVC 5 и ASP.NET WEBAPI 2
Здравствуйте. Я в бекенд разработке полный ноль. В чем разница между вышеперечисленными... ASP.NET Core. Старт - что нужно знать, чтобы стать ASP.NET Core разработчиком?
Попалось хор краткое обзорное видео 2016 года с таким названием - Что нужно знать, чтобы стать... Какая разница между ASP .Net Core и ASP .Net Core MVC?
Какая разница между ASP .Net Core и ASP .Net Core MVC? Или я может что-то не так понял? И... ASP.NET MVC 4,ASP.NET MVC 4.5 и ASP.NET MVC 5 большая ли разница между ними?
Начал во всю осваивать технологию,теперь хочу с книжкой посидеть и вдумчиво перебрать всё то что...
Настройка Serilog в ASP.NET Core
Теорию мы разобрали, пора переходить к практике. Начнём с установки всех необходимых компонентов и настройки базовой конфигурации Serilog в ASP.NET Core приложении.
Установка пакетов и базовая конфигурация
Для начала работы с Serilog необходимо установить несколько NuGet пакетов. Минимальный набор выглядит так:
| Bash | 1
2
3
| dotnet add package Serilog.AspNetCore
dotnet add package Serilog.Sinks.Console
dotnet add package Serilog.Sinks.File |
|
| Bash | 1
2
| dotnet add package Serilog.Sinks.Elasticsearch
dotnet add package Serilog.Enrichers.Environment |
|
Program.cs. Важно сделать это как можно раньше, чтобы иметь возможность логировать даже ошибки инициализации приложения:
| C# | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
| public class Program
{
public static void Main(string[] args)
{
// Настраиваем логирование перед запуском приложения
var configuration = new ConfigurationBuilder()
.AddJsonFile("appsettings.json")
.Build();
Log.Logger = new LoggerConfiguration()
.ReadFrom.Configuration(configuration)
.Enrich.FromLogContext()
.Enrich.WithMachineName()
.WriteTo.Console()
.CreateLogger();
try
{
Log.Information("Запуск приложения...");
CreateHostBuilder(args).Build().Run();
}
catch (Exception ex)
{
Log.Fatal(ex, "Приложение остановлено из-за исключения");
}
finally
{
Log.CloseAndFlush();
}
}
public static IHostBuilder CreateHostBuilder(string[] args) =>
Host.CreateDefaultBuilder(args)
.UseSerilog() // Используем Serilog вместо стандартного логгера
.ConfigureWebHostDefaults(webBuilder =>
{
webBuilder.UseStartup<Startup>();
});
} |
|
appsettings.json может выглядеть так:
| JSON | 1
2
3
4
5
6
7
8
9
10
11
| {
"Serilog": {
"MinimumLevel": {
"Default": "Information",
"Override": {
"Microsoft": "Warning",
"System": "Warning"
}
}
}
} |
|
ILogger<T> в любой контроллер или сервис и начать логирование.
Примеры структурированного логирования
Одно из главных преимуществ Serilog — поддержка структурированного логирования. Вместо конкатенации строк или использования string.Format(), Serilog позволяет передавать структурированные данные, которые потом можно фильтровать и анализировать:
| C# | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| public class OrdersController : ControllerBase
{
private readonly ILogger<OrdersController> _logger;
public OrdersController(ILogger<OrdersController> logger)
{
_logger = logger;
}
[HttpPost]
public IActionResult CreateOrder([FromBody] Order order)
{
_logger.LogInformation("Создание заказа {OrderId} для клиента {CustomerId} на сумму {Amount}",
order.Id, order.CustomerId, order.TotalAmount);
// Логика обработки заказа...
return Ok(new { order.Id });
}
} |
|
OrderId, CustomerId и Amount будут сохранены как отдельные поля в структурированном логе, а не просто как часть текстового сообщения. Это позволит позже легко найти все заказы определённого клиента или все заказы выше определённой суммы.
Для сложных объектов можно использовать деструктурирование:
| C# | 1
| _logger.LogInformation("Обработка платежа {@Payment}", payment); |
|
@ перед именем параметра указывает Serilog, что нужно сериализовать весь объект payment, а не просто вызвать его метод ToString().
Создание кастомных форматтеров для логов в Serilog
Хотя стандартные форматтеры Serilog достаточно гибкие, иногда возникает необходимость создать собственный форматтер, например, для интеграции с существующей инфраструктурой логирования или для соответствия корпоративным стандартам.
Вот пример создания простого кастомного форматера, который добавляет префикс с окружением (dev, staging, prod) к каждому сообщению:
| C# | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| public class EnvironmentPrefixFormatter : ITextFormatter
{
private readonly string _environmentName;
private readonly ITextFormatter _innerFormatter;
public EnvironmentPrefixFormatter(string environmentName, ITextFormatter innerFormatter)
{
_environmentName = environmentName ?? "unknown";
_innerFormatter = innerFormatter ?? throw new ArgumentNullException(nameof(innerFormatter));
}
public void Format(LogEvent logEvent, TextWriter output)
{
output.Write($"[{_environmentName}] ");
_innerFormatter.Format(logEvent, output);
}
} |
|
| C# | 1
2
3
4
5
6
7
8
| var formatter = new EnvironmentPrefixFormatter(
Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT"),
new JsonFormatter()
);
Log.Logger = new LoggerConfiguration()
.WriteTo.Console(formatter: formatter)
.CreateLogger(); |
|
Конвейеры обработки логов (Pipeline) в Serilog
Одной из мощных возможностей Serilog является построение конвейеров обработки логов. Это позволяет фильтровать, трансформировать и маршрутизировать сообщения по различным правилам. например, можно настроить отправку только критических ошибок на email, при этом сохраняя все логи в ElasticSearch:
| C# | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| Log.Logger = new LoggerConfiguration()
.MinimumLevel.Debug()
.WriteTo.Logger(lc => lc
.Filter.ByIncludingOnly(e => e.Level == LogEventLevel.Error || e.Level == LogEventLevel.Fatal)
.WriteTo.Email(new EmailConnectionInfo
{
FromEmail = "app@example.com",
ToEmail = "admin@example.com",
MailServer = "smtp.example.com"
}))
.WriteTo.Elasticsearch(new ElasticsearchSinkOptions(new Uri("http://localhost:9200"))
{
AutoRegisterTemplate = true,
IndexFormat = "app-logs-{0:yyyy.MM}"
})
.CreateLogger(); |
|
| C# | 1
2
3
4
5
6
7
8
9
10
| Log.Logger = new LoggerConfiguration()
.WriteTo.BufferingSink(sink:
new ElasticsearchSink(new ElasticsearchSinkOptions(new Uri("http://localhost:9200"))
{
AutoRegisterTemplate = true,
IndexFormat = "app-logs-{0:yyyy.MM}"
}),
bufferSize: 100,
period: TimeSpan.FromSeconds(2))
.CreateLogger(); |
|
Обогащение логов контекстной информацией
Enrichers — еще одна мощная возможность Serilog. Они позволяют автоматически добавлять контекстную информацию к каждому сообщению лога. Serilog поставляется с несколькими встроенными энричерами, но также легко создать свои. Вот некоторые из стандартных обогатителей:
| C# | 1
2
3
4
5
6
7
| Log.Logger = new LoggerConfiguration()
.Enrich.WithMachineName() // Добавляет имя машины
.Enrich.WithEnvironmentName() // Добавляет имя окружения
.Enrich.WithThreadId() // Добавляет ID потока
.Enrich.WithProcessId() // Добавляет ID процесса
.Enrich.FromLogContext() // Позволяет добавлять динамический контекст
.CreateLogger(); |
|
FromLogContext(), который позволяет динамически добавлять информацию в контекст логирования, например, идентификатор текущего пользователя или трассировочный ID запроса:
| C# | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| public async Task<IActionResult> GetOrderDetails(int orderId)
{
// Добавляем orderId в контекст логирования
using (LogContext.PushProperty("OrderId", orderId))
{
_logger.LogInformation("Запрос деталей заказа");
var order = await _orderService.GetOrderAsync(orderId);
if (order == null)
{
_logger.LogWarning("Заказ не найден");
return NotFound();
}
_logger.LogInformation("Детали заказа получены успешно");
return Ok(order);
}
} |
|
OrderId с соответствующим значением, что значительно упрощает трассировку действий, связанных с конкретным заказом. Создание собственного обогатителя тоже не представляет сложности. Например, если нужно добавлять к каждому логу версию приложения:
| C# | 1
2
3
4
5
6
7
8
9
| public class VersionEnricher : ILogEventEnricher
{
public void Enrich(LogEvent logEvent, ILogEventPropertyFactory propertyFactory)
{
var version = Assembly.GetExecutingAssembly().GetName().Version.ToString();
var property = propertyFactory.CreateProperty("AppVersion", version);
logEvent.AddPropertyIfAbsent(property);
}
} |
|
| C# | 1
2
3
| Log.Logger = new LoggerConfiguration()
.Enrich.With<VersionEnricher>()
.CreateLogger(); |
|
Использование паттерна Sink Selector для разделения потоков логов
Иногда требуется более сложная логика маршрутизации логов, чем просто фильтрация по уровню. Паттерн Sink Selector позволяет динамически определять, в какие "приёмники" отправлять конкретное сообщение. Реализация выглядит примерно так:
| C# | 1
2
3
4
5
6
7
8
9
10
| Log.Logger = new LoggerConfiguration()
.WriteTo.Conditional(
e => e.Properties.ContainsKey("PaymentOperation") &&
e.Properties["PaymentOperation"].ToString() == "\"CreditCardPayment\"",
config => config.File("logs/payments.json"))
.WriteTo.Conditional(
e => e.Properties.ContainsKey("SecurityEvent"),
config => config.File("logs/security.json"))
.WriteTo.Elasticsearch(...) // Все логи идут в ElasticSearch
.CreateLogger(); |
|
Тактики сохранения контекста запроса между различными компонентами приложения
В сложных приложениях важно иметь возможность проследить путь запроса через различные компоненты. Для этого применяются различные тактики сохранения контекста.
Использование HttpContext для передачи контекста:
Middleware для сохранения контекста:
| C# | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
| public class RequestContextMiddleware
{
private readonly RequestDelegate _next;
public RequestContextMiddleware(RequestDelegate next)
{
_next = next;
}
public async Task InvokeAsync(HttpContext context)
{
var correlationId = context.Request.Headers["X-Correlation-Id"].FirstOrDefault() ??
Guid.NewGuid().ToString();
using (LogContext.PushProperty("CorrelationId", correlationId))
{
context.Items["CorrelationId"] = correlationId;
context.Response.Headers.Add("X-Correlation-Id", correlationId);
await _next(context);
}
}
} |
|
| C# | 1
| app.UseMiddleware<RequestContextMiddleware>(); |
|
Интеграция с ElasticSearch
Настроив Serilog в нашем ASP.NET Core приложении, мы готовы сделать следующий шаг — отправить наши структурированные логи в ElasticSearch.
Подключение Serilog к ElasticSearch
Для начала нам необходимо установить соответствующий Sink для Serilog:
| Bash | 1
| dotnet add package Serilog.Sinks.Elasticsearch |
|
| JSON | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
| {
"Serilog": {
"MinimumLevel": {
"Default": "Information",
"Override": {
"Microsoft": "Warning",
"System": "Warning"
}
},
"WriteTo": [
{
"Name": "Elasticsearch",
"Args": {
"nodeUris": "http://localhost:9200",
"indexFormat": "app-logs-{0:yyyy.MM}",
"autoRegisterTemplate": true,
"numberOfShards": 2,
"numberOfReplicas": 1
}
}
]
},
"ElasticConfiguration": {
"Uri": "http://localhost:9200"
}
} |
|
| C# | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| var environment = Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT");
var configuration = new ConfigurationBuilder()
.AddJsonFile("appsettings.json")
.AddJsonFile($"appsettings.{environment}.json", optional: true)
.Build();
Log.Logger = new LoggerConfiguration()
.Enrich.FromLogContext()
.Enrich.WithMachineName()
.WriteTo.Console()
.WriteTo.Elasticsearch(
new ElasticsearchSinkOptions(new Uri(configuration["ElasticConfiguration:Uri"]))
{
AutoRegisterTemplate = true,
IndexFormat = $"{Assembly.GetExecutingAssembly().GetName().Name.ToLower().Replace(".", "-")}-{environment?.ToLower().Replace(".", "-")}-{DateTime.UtcNow:yyyy.MM}",
NumberOfShards = 2,
NumberOfReplicas = 1
})
.ReadFrom.Configuration(configuration)
.CreateLogger(); |
|
AutoRegisterTemplate = true — Serilog автоматически создаст шаблон индекса в ElasticSearch,
IndexFormat — определяет формат имени индекса, включая имя приложения, окружение и временной штамп,
NumberOfShards — количество первичных шардов (влияет на распределение данных),
NumberOfReplicas — количество реплик каждого шарда (влияет на отказоустойчивость).
Настройка маппинга индексов
ElasticSearch использует маппинг для определения того, как документы и их поля хранятся и индексируются. Хотя Serilog с опцией AutoRegisterTemplate создаёт базовый шаблон, в сложных случаях может понадобиться кастомный маппинг. Создадим свой шаблон индекса:
| C# | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
| var template = new
{
index_patterns = new[] { "app-logs-*" },
settings = new
{
number_of_shards = 2,
number_of_replicas = 1,
analysis = new
{
analyzer = new
{
custom_analyzer = new
{
type = "custom",
tokenizer = "standard",
filter = new[] { "lowercase" }
}
}
}
},
mappings = new
{
properties = new
{
TimeStamp = new { type = "date" },
Level = new { type = "keyword" },
Message = new { type = "text", analyzer = "custom_analyzer" },
Exception = new { type = "text" },
CorrelationId = new { type = "keyword" },
UserId = new { type = "keyword" },
OrderId = new { type = "keyword" }
}
}
};
var templateString = JsonConvert.SerializeObject(template);
var elkOptions = new ElasticsearchSinkOptions(new Uri(configuration["ElasticConfiguration:Uri"]))
{
AutoRegisterTemplate = false,
OverwriteTemplate = true,
RegisterTemplateFailure = RegisterTemplateRecovery.FailSink,
IndexFormat = "app-logs-{0:yyyy.MM}",
TemplateName = "app-logs-template",
CustomFormatter = new EsJsonFormatter(),
CustomTemplateRegistration = async (client, templateName, templateMatchString) =>
{
await client.LowLevel.IndicesPutTemplateForAllAsync<StringResponse>(
templateName,
templateString
);
}
};
Log.Logger = new LoggerConfiguration()
.WriteTo.Elasticsearch(elkOptions)
.CreateLogger(); |
|
Шаблонизация индексов для анализа логов по средам развертывания
Правильное именование индексов значительно упрощает работу с логами. Хорошей практикой является включение в имя индекса
1. Названия приложения.
2. Окружения (dev, staging, prod).
3. Временного периода (обычно год.месяц).
| C# | 1
2
| // В строковом формате
var indexFormat = $"app-{appName}-{environment}-{DateTime.UtcNow:yyyy.MM}"; |
|
| C# | 1
| var indexFormat = $"app-{serviceName}-{environment}-{DateTime.UtcNow:yyyy.MM}"; |
|
Стратегии шардирования для высоконагруженных систем
Шардирование — это способ разделения индекса на несколько частей (шардов), которые могут распределяться по нескольким узлам кластера. Правильная стратегия шардирования напрямую влияет на производительность ElasticSearch.
Существует несколько ключевых аспектов, которые следует учитывать:
1. Размер шарда — оптимальный размер шарда находится в диапазоне 20-40 ГБ. Слишком маленькие шарды увеличивают накладные расходы, слишком большие — замедляют операции.
2. Количество шардов — зависит от объёма данных и количества узлов. Формула для предварительного расчёта:
Количество шардов = (суточный объём логов * срок хранения) / целевой размер шарда
3. Количество реплик — для критически важных данных рекомендуется иметь хотя бы одну реплику (значение 1). Это означает, что каждый шард будет иметь одну копию на другом узле.
Для высоконагруженных систем обычно используют следующую конфигурацию:
| C# | 1
2
3
4
5
6
7
8
| var elkOptions = new ElasticsearchSinkOptions(new Uri(elasticUri))
{
IndexFormat = $"logs-{DateTime.UtcNow:yyyy.MM.dd}",
NumberOfShards = 4,
NumberOfReplicas = 1,
BufferLogShippingInterval = TimeSpan.FromSeconds(5), // Буферизация для снижения нагрузки
BatchPostingLimit = 1000 // Количество событий в одном запросе
}; |
|
| C# | 1
| IndexFormat = $"logs-{DateTime.UtcNow:yyyy.MM.dd.HH}" |
|
Управление жизненным циклом индексов и политики ротации
С течением времени объём логов может стать огромным. Для эффективного управления жизненным циклом индексов в ElasticSearch используется Index Lifecycle Management (ILM). ILM автоматизирует процесс управления индексами по мере их старения. Типичный жизненный цикл включает в себя следующие фазы:
1. Hot — индекс активно пишется и запрашивается,
2. Warm — индекс больше не обновляется, но всё ещё часто запрашивается,
3. Cold — индекс редко запрашивается,
4. Delete — индекс больше не нужен и может быть удалён.
Настройка ILM с помощью Elasticsearch.NET клиента:
| C# | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
| var client = new ElasticClient(new ConnectionSettings(new Uri(elasticUri)));
var policyResponse = client.IndexLifecycleManagement.PutLifecycle(new PutLifecycleRequest("logs-policy")
{
Policy = new Policy
{
Phases = new Phases
{
Hot = new HotPhase
{
Actions = new HotPhaseActions
{
Rollover = new RolloverLifecycleAction
{
MaxAge = "1d",
MaxSize = "50gb"
}
}
},
Warm = new WarmPhase
{
MinimumAge = "2d",
Actions = new WarmPhaseActions
{
ForceMerge = new ForceMergeLifecycleAction
{
MaxNumberOfSegments = 1
},
Shrink = new ShrinkLifecycleAction
{
NumberOfShards = 1
},
Allocate = new AllocateLifecycleAction
{
RequireAttribute = new Dictionary<string, string>
{
{ "data", "warm" }
}
}
}
},
Cold = new ColdPhase
{
MinimumAge = "30d",
Actions = new ColdPhaseActions
{
Freeze = new FreezeLifecycleAction()
}
},
Delete = new DeletePhase
{
MinimumAge = "90d",
Actions = new DeletePhaseActions
{
Delete = new DeleteLifecycleAction()
}
}
}
}
}); |
|
- Перемещать индексы в "тёплое" хранилище после 2 дней.
- Перемещать их в "холодное" хранилище после 30 дней.
- Удалять после 90 дней.
Такой подход обеспечивает баланс между доступностью данных и стоимостью хранения.
Для небольших проектов можно использовать более простое решение — Curator, который позволяет настраивать политики через YAML-файлы и запускать их по расписанию.
Оптимизация производительности при работе с большими объемами логов
При масштабировании системы логирования производительность становится критическим фактором. Рассмотрим несколько ключевых стратегий оптимизации:
1. Буферизация и пакетная отправка — отправка логов пакетами существенно сокращает сетевой трафик:
| C# | 1
2
3
4
5
6
7
| var sinkOptions = new ElasticsearchSinkOptions(new Uri(elasticUri))
{
BatchPostingLimit = 500, // Количество событий в одном пакете
Period = TimeSpan.FromSeconds(2), // Максимальная задержка отправки
EmitEventFailure = EmitEventFailureHandling.WriteToSelfLog,
FailureCallback = e => Console.Error.WriteLine($"Ошибка отправки: {e.MessageTemplate}")
}; |
|
| C# | 1
2
3
4
| var connectionSettings = new ConnectionSettings(new Uri(elasticUri))
.RequestTimeout(TimeSpan.FromSeconds(5))
.MaximumRetries(3)
.RetryOnHttpError(false); |
|
| C# | 1
2
3
4
| Log.Logger = new LoggerConfiguration()
.Filter.ByExcluding(e => e.MessageTemplate.Text.Contains("health check"))
.WriteTo.Elasticsearch(sinkOptions)
.CreateLogger(); |
|
Визуализация логов в Kibana
После настройки Serilog и ElasticSearch нужно сделать следующий важный шаг — визуализировать собранные данные. Kibana предоставляет мощный интерфейс для взаимодействия с логами, превращая сухие записи в наглядные графики и информативные дашборды.
Создание дашбордов
Прежде чем создавать первый дашборд нужно убедиться, что Kibana "видит" индексы с логами. Перейдите в раздел "Stack Management" > "Index Patterns" и создайте новый шаблон индекса, соответствующий формату ваших логов (например, "app-logs-*"). Для создания дашборда:
1. Перейдите в раздел "Dashboard" и нажмите "Create dashboard".
2. Добавьте визуализации нажав "Add".
3. Создайте новую визуализацию или выберите из существующих.
Типичный дашборд для мониторинга веб-приложения может включать:- Счётчик общего количества запросов с разбивкой по статусам HTTP.
- График распределения ошибок по времени.
- Круговую диаграмму распределения запросов по контроллерам.
- Таблицу последних ошибок с возможностью быстрого перехода к деталям.
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
| // Пример запроса для визуализации распределения HTTP-статусов
{
"aggs": {
"statuses": {
"terms": {
"field": "StatusCode",
"size": 10
}
}
},
"query": {
"bool": {
"must": [
{
"match": {
"Properties.SourceContext": "YourApp.Controllers"
}
}
],
"filter": [
{
"range": {
"@timestamp": {
"gte": "now-24h",
"lte": "now"
}
}
}
]
}
}
} |
|
Настройка поиска и фильтрации
Kibana предлагает два языка для поиска: KQL (Kibana Query Language) и Lucene. KQL имеет более простой синтаксис и рекомендуется для большинства случаев. Несколько примеров запросов:
1. Поиск по конкретному сообщению:
| C# | 1
| message:"Ошибка при обработке платежа" |
|
| C# | 1
| level:"Error" OR level:"Fatal" |
|
| C# | 1
| level:"Error" AND Properties.OrderId:"12345" |
|
| C# | 1
| message:/Платеж \d+ отклонен/ |
|
1. Настройте запрос и фильтры.
2. Нажмите "Save" в верхнем меню.
3. Присвойте запросу понятное имя.
4. При необходимости можно закрепить запрос на панели быстрого доступа.
Расширенная фильтрация возможна с использованием скриптованных полей. Например, можно создать поле, вычисляющее длительность запроса:
1. Перейдите в "Stack Management" > "Index Patterns",
2. Выберите ваш шаблон индекса,
3. Перейдите на вкладку "Scripted fields",
4. Добавьте новое поле:
doc['ResponseTimeMs'].value > 1000 ? 'slow' : 'normal'
После создания такого поля можно фильтровать "медленные" запросы:
| C# | 1
| responseCategory:"slow" |
|
Создание шаблонов визуализации для типовых проблем приложения
Для эффективного мониторинга полезно создать набор специализированных визуализаций под конкретные сценарии проблем.
Мониторинг ошибок аутентификации
| JavaScript | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| {
"query": {
"bool": {
"must": [
{
"match_phrase": {
"message": "Failed authentication attempt"
}
}
]
}
},
"aggs": {
"by_ip": {
"terms": {
"field": "Properties.ClientIP",
"size": 10
}
}
}
} |
|
Отслеживание проблем производительности
Для контроля производительности полезна тепловая карта (heatmap), показывающая распределение времени отклика по времени суток:
1. Создайте визуализацию типа "Heat Map".
2. Выберите в качестве Y-оси date_histogram по полю @timestamp с интервалом 1 час.
3. Для X-оси установите range по полю Properties.ResponseTimeMs с интервалами [0-100, 100-500, 500-1000, 1000-5000, 5000+].
Такая карта наглядно покажет, когда приложение начинает "тормозить", что может указывать на проблемы с масштабированием или планировыми задачами.
Техники корреляции логов между различными сервисами
В микросервисной архитектуре ключевая сложность — связать события, которые происходили в разных сервисах, но относятся к одному бизнес-процессу. Здесь на помощь приходит трассировка запросов (request tracing).
В Kibana можно создать визуализацию типа "Vega", чтобы построить диаграмму последовательности запросов:
| JSON | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
| {
"data": {
"url": {
"index": "app-logs-*",
"body": {
"query": {
"bool": {
"must": [
{
"match": {
"Properties.CorrelationId": "{{CorrelationId}}"
}
}
]
}
},
"sort": [
{
"@timestamp": {
"order": "asc"
}
}
],
"size": 1000
}
}
},
"mark": "line",
"encoding": {
"x": {"field": "@timestamp", "type": "temporal"},
"y": {"field": "Properties.ServiceName", "type": "nominal"},
"color": {"field": "level", "type": "nominal"}
}
} |
|
CorrelationId по всем сервисам. Дополнив её интерактивными элементами, можно обеспечить удобную навигацию по цепочке событий.
Построение алертов на основе анализа логов
Kibana предлагает функциональность Alerting для автоматического оповещения о проблемах. Настроим алерт на рост числа ошибок:
1. Перейдите в раздел "Stack Management" > "Rules and Connectors".
2. Создайте новый коннектор (например, Webhook или Email).
3. Создайте правило типа "Threshold".
4. Настройте условие срабатывания (например, более 5 ошибок в минуту):
| C# | 1
| WHEN count() OF documents WHERE level:"Error" OVER all documents IN LAST 1m IS ABOVE 5 |
|
Для более гибкой настройки можно использовать скрипты. Например, алерт на рост процента ошибок относительно общего числа запросов:
| C# | 1
| WHEN some_script() FROM "app-logs-*" OVER all documents IN LAST 15m |
|
| C# | 1
| params.error_count / params.total_count > 0.05 |
|
error_count и total_count вычисляются с помощью агрегаций.
Применение машинного обучения для выявления аномалий
Модуль Machine Learning в Kibana позволяет настроить автоматическое выявление аномалий в логах без явного определения правил:
1. Перейдите в раздел "Machine Learning" > "Anomaly Detection",
2. Создайте новую задачу,
3. Выберите индекс с логами,
4. Настройте параметры анализа (например, анализ числа ошибок по времени суток),
5. Запустите анализ.
Kibana ML будет анализировать шаблоны в данных и определять отклонения от обычного поведения. Это особенно полезно для выявления:- Необычного количества ошибок в нетипичное время.
- Аномального времени ответа на запросы.
- Появления неизвестных типов ошибок.
- Необычных паттернов использования API.
Для более прицельного анализа можно использовать функционал "Outlier Detection", который выявляет нетипичные комбинации свойств в логах, что может указывать на попытки взлома или необычное поведение пользователей.
Docker-композиция для локальной разработки
Один из наиболее эффективных способов быстро развернуть инфраструктуру логирования — использование Docker. Docker позволяет запустить ElasticSearch и Kibana в изолированных контейнерах, что решает проблемы с зависимостями и упрощает настройку среды разработки.
Пример docker-compose файла
Создадим базовый docker-compose.yml файл для запуска ElasticSearch и Kibana:
| YAML | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
| version: '3.4'
services:
elasticsearch:
container_name: elasticsearch
image: docker.elastic.co/elasticsearch/elasticsearch:7.16.2
ports:
- 9200:9200
- 9300:9300
volumes:
- elasticsearch-data:/usr/share/elasticsearch/data
environment:
- xpack.monitoring.enabled=true
- xpack.watcher.enabled=false
- "ES_JAVA_OPTS=-Xms512m -Xmx512m"
- discovery.type=single-node
networks:
- elastic
kibana:
container_name: kibana
image: docker.elastic.co/kibana/kibana:7.16.2
ports:
- 5601:5601
depends_on:
- elasticsearch
environment:
- ELASTICSEARCH_URL=http://elasticsearch:9200
networks:
- elastic
networks:
elastic:
driver: bridge
volumes:
elasticsearch-data: |
|
- Мы используем одну версию для ElasticSearch и Kibana (7.16.2), чтобы избежать проблем совместимости.
- Параметр
discovery.type=single-node отключает кластеризацию для локальной разработки.
ES_JAVA_OPTS ограничивает потребление памяти, чтобы не перегружать машину разработчика.- Мы используем именованный том
elasticsearch-data для сохранения данных между запусками.
- Контейнеры подключены к одной сети
elastic для взаимной коммуникации.
Запустить ELK-стек теперь можно одной командой:
После запуска ElasticSearch будет доступен по адресу http://localhost:9200, а Kibana — по адресу http://localhost:5601.
Особенности настройки сети и портов для ELK-стека
При работе с Docker-контейнерами важно понимать несколько нюансов настройки сети:
1. Внутренняя сеть контейнеров
В примере выше мы создали выделенную сеть elastic. Внутри этой сети контейнеры могут обращаться друг к другу по именам (elasticsearch, kibana), а не по IP-адресам. Это упрощает конфигурацию, поскольку IP-адреса могут меняться при перезапуске.
2. Проброс портов
Строки вида 9200:9200 означают проброс портов из контейнера на хост-машину. Первое число — порт на хост-машине, второе — порт внутри контейнера. Если у вас эти порты уже заняты другими приложениями, можно использовать другие:
| YAML | 1
2
| ports:
- 9201:9200 # ElasticSearch будет доступен на localhost:9201 |
|
По умолчанию ElasticSearch в Docker не имеет аутентификации. Для реальных проектов следует включить X-Pack Security:
| YAML | 1
2
3
4
| environment:
- xpack.security.enabled=true
- ELASTIC_PASSWORD=changeme
- bootstrap.memory_lock=true |
|
| YAML | 1
2
3
4
| environment:
- ELASTICSEARCH_URL=http://elasticsearch:9200
- ELASTICSEARCH_USERNAME=elastic
- ELASTICSEARCH_PASSWORD=changeme |
|
Расширенная конфигурация для продуктивной разработки
Для более удобной разработки можно дополнить базовую конфигурацию несколькими компонентами:
| YAML | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
| services:
# Базовые сервисы ElasticSearch и Kibana...
logstash:
container_name: logstash
image: docker.elastic.co/logstash/logstash:7.16.2
ports:
- 5044:5044
- 9600:9600
volumes:
- ./logstash/pipeline:/usr/share/logstash/pipeline
environment:
- xpack.monitoring.enabled=true
networks:
- elastic
depends_on:
- elasticsearch
apm-server:
container_name: apm-server
image: docker.elastic.co/apm/apm-server:7.16.2
ports:
- 8200:8200
environment:
- output.elasticsearch.hosts=["elasticsearch:9200"]
networks:
- elastic
depends_on:
- elasticsearch
- kibana |
|
Профиль разработки с минимальными требованиями
Если вы работаете на машине с ограниченными ресурсами, можно создать облегченную конфигурацию:
| YAML | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| services:
elasticsearch:
image: docker.elastic.co/elasticsearch/elasticsearch:7.16.2
environment:
- "ES_JAVA_OPTS=-Xms256m -Xmx256m"
- discovery.type=single-node
- xpack.ml.enabled=false
- xpack.monitoring.enabled=false
- xpack.security.enabled=false
- xpack.watcher.enabled=false
- bootstrap.memory_lock=false
# Остальная конфигурация...
kibana:
image: docker.elastic.co/kibana/kibana:7.16.2
environment:
- ELASTICSEARCH_URL=http://elasticsearch:9200
- SERVER_BASEPATH=/kibana
- SERVER_MAXPAYLOADBYTES=1048576
# Остальная конфигурация... |
|
Заключение и лучшие практики
Главные выводы и рекомендации
На основе рассмотренного материала можно сформулировать несколько ключевых рекомендаций:
1. Начинайте с правильной структуры логов. Структурированное логирование с Serilog даёт огромное преимущество при последующем анализе. Используйте именованные параметры вместо строковой конкатенации и применяйте контекстное обогащение.
2. Разделяйте инструментальные и бизнес-логи. Логи инфраструктуры и фреймворка (ASP.NET Core, Entity Framework) следует отделять от бизнес-событий приложения. Для этого можно использовать разные уровни логирования или даже разные индексы
3. Тщательно выбирайте что логировать. Излишнее логирование создаёт "шум", затрудняет анализ и увеличивает расходы на хранение. Не логируйте личные или чувствительные данные из соображений безопасности и соответствия законодательству.
4. Применяйте механизм корреляции запросов. Использование CorrelationId позволяет связать разрозненные события в единую цепочку, что критически важно для отладки распределённых систем.
5. Настраивайте уровни логирования по окружениям. В продакшн-среде обычно достаточно уровня Information для бизнес-событий и Warning для системных сообщений, в то время как в среде разработки можно использовать более подробные уровни.
Оптимизация производительности
Логирование не должно становиться узким местом приложения:
1. Используйте буферизацию. Настройте Serilog на пакетную отправку логов для снижения нагрузки на сеть и ElasticSearch.
2. Применяйте асинхронное логирование. В высоконагруженных системах критично, чтобы логирование не блокировало основной поток выполнения.
3. Регулярно пересматривайте политики хранения. Старые логи занимают ценное дисковое пространство и замедляют поиск. Используйте ILM в ElasticSearch для автоматического управления жизненным циклом данных.
4. Оптимизируйте индексы. Правильная стратегия шардирования и настройка маппинга полей могут значительно ускорить поиск по логам.
Типичные ошибки и их предотвращение
Опыт внедрения ELK-стека в различных проектах выявил ряд типичных проблем:
1. Переполнение диска логами. Всегда настраивайте ротацию и контролируйте объем генерируемых данных.
2. Хрупкость конфигурации Serilog. Ошибки в настройке могут привести к потере логов или даже падению приложения. Обязательно включайте обработку исключений при инициализации логирования.
3. "Дребезг" логов. Избегайте многократного логирования одних и тех же событий в цикле или в часто вызываемых методах.
4. Недостаточная контекстная информация. Лог без контекста малополезен. Включайте в сообщения идентификаторы пользователей, запросов, транзакций.
5. Игнорирование предупреждений ElasticSearch. Проблемы с индексами или шаблонами могут постепенно накапливаться и приводить к неожиданному отказу системы.
Масштабирование системы логирования
Для крупных проектов или растущих стартапов важно заранее предусмотреть масштабирование:
1. Кластеризация ElasticSearch. Настройте кластер с несколькими узлами для обеспечения отказоустойчивости и распределения нагрузки.
2. Введение очереди сообщений. Для особо высоких нагрузок полезно использовать промежуточную очередь сообщений (Kafka, RabbitMQ) между приложением и ElasticSearch.
3. Распределение по темам. Разделяйте логи по смысловым категориям и направляйте их в специализированные индексы.
4. Резервное копирование критичных логов. Помимо ElasticSearch, дублируйте важные логи в долговременное хранилище.
Перспективные направления
Технологии логирования продолжают развиваться, и стоит обратить внимание на следующие тенденции:
1. Трассировка распределённых систем с использованием OpenTelemetry и Jaeger.
2. Автоматический анализ аномалий на основе машинного обучения.
3. Интеграция системы логирования с CI/CD пайплайнами для автоматической корреляции сбоев с изменениями в коде.
4. Observability как целостный подход, объединяющий логи, метрики и трассировку.
Грамотно настроенная система логирования с использованием Serilog, ElasticSearch и Kibana — это не просто техническая необходимость, а конкурентное преимущество, позволяющее быстрее выявлять и устранять проблемы, а значит, обеспечивать более высокое качество продукта и лучший пользовательский опыт.
Кастомное логирование в ASP.NET Core
Захотел сделать логирование в MongoDB. Воспользовался след. гайдом.
При отладке или хостинге в... Логирование запросов к БД на Asp.Net Core 3.1
На Asp.Net Core 2.1 в файле Startup настраивал логирование запросов EF в консоль:
public void... ASP.NET Core: разный формат даты контроллера ASP.NET и AngularJS
Собственно, проблему пока еще не разруливал, но уже погуглил. Разный формат даты который использует... ASP.NET MVC или ASP.NET Core
Добрый вечер, подскажите что лучшие изучать ASP.NET MVC или ASP.NET Core ? Как я понимаю ASP.NET... Что выбрать ASP.NET или ASP.NET Core ?
Добрый день форумчане, хотелось бы услышать ваше мнение, какой из перечисленных фреймворков лучше... ASP.NET Core или ASP.NET MVC
Здравствуйте
После изучение основ c# я решил выбрать направление веб разработки. Подскажите какие... Стоит ли учить asp.net, если скоро станет asp.net core?
Всем привет
Если я правильно понимаю, лучше учить Core ? ASP.NET или ASP.NET Core
Добрый вечер, подскажите новичку в чем разница между asp.net и asp.net core, нужно ли знать оба... Почему скрипт из ASP.NET MVC 5 не работает в ASP.NET Core?
В представлении в версии ASP.NET MVC 5 был скрипт:
@model RallyeAnmeldung.Cars
... Serilog как работать не со статическим объектом
Здравствуйте. Я начинающий в программировании.
Пытаюсь использовать Serilog в своей программе.
... Serilog. Как логировать , используя внедрение зависимостей
Всем добрый день!
Цель: записывать логи в файл формата {"имя контроллера"-"дата"}.
То есть на... Serilog.FluentDestructuring
При работе с Serilog настройка деструктуризации для сложных объектов с использованием стандартных...
|
