Мониторинг и логирование в Rust: от хаоса к порядку

Ваш код работает. Но что происходит на самом деле?

Вы написали крутой сервис на Rust. Компилятор счастлив, тесты зелёные, скорость зашкаливает. Вы запускаете его на сервере, и... тишина. Как понять, что происходит внутри? Не упал ли он? Не утекает ли память? Не тормозит ли обработка запросов?

Без мониторинга и логирования ваш код — это чёрный ящик. В мире Rust, где каждый байт на счету, а производительность критична, умение заглянуть внутрь процесса становится суперсилой. В этой статье мы разберём, как превратить ваше Rust-приложение из немого исполнителя в разговорчивого помощника, который сам расскажет о своих проблемах.

Почему Rust требует особого подхода к observability?

В отличие от языков с рантаймом (Java, Python, Go), Rust не даёт вам готовых инструментов "из коробки". Нет встроенного профайлера или агента метрик. Но есть и плюсы: вы контролируете всё. Система типов и владения позволяет создавать невероятно эффективные инструменты мониторинга без оверхеда. Главное — правильно выбрать библиотеки и архитектуру.

Современный стек observability в Rust строится на трёх китах:

• Логирование (Logging) — структурированные записи о событиях
• Метрики (Metrics) — числовые показатели (счётчики, гистограммы)
• Трейсинг (Tracing) — цепочки вызовов в распределённых системах

И всё это должно работать с минимальным влиянием на производительность. Давайте посмотрим, как это реализовать на практике.

1. Логирование: от println! к структурированным данным

Начнём с базы. Забудьте про println! в продакшене. Вместо этого используйте крейт log — стандартный фасад для логирования в экосистеме Rust. Он не привязан к конкретному бэкенду, что даёт гибкость.

Подключаем log и env_logger

// Cargo.toml
[dependencies]
log = "0.4"
env_logger = "0.11"

Простой пример использования:

use log::{info, warn, error};

fn main() {
    env_logger::init();
    
    info!("Сервис запущен на порту {}", 8080);
    warn!("Память превышает 80%");
    error!("Ошибка подключения к БД: {}", "timeout");
}

Управляйте уровнем логирования через переменную окружения RUST_LOG:

RUST_LOG=info cargo run
RUST_LOG=warn,my_crate=debug cargo run  # Для конкретного крейта

Но это только начало. Для продакшена нужно структурированное логирование (JSON). Используйте log4rs или slog для продвинутого форматирования.

2. Tracing: логирование на стероидах

Крейт tracing — это эволюция log. Он добавляет концепцию спанов (span) — именованных временных интервалов, которые можно вкладывать друг в друга. Это идеально для отслеживания цепочек вызовов.

Установка tracing

[dependencies]
tracing = "0.1"
tracing-subscriber = "0.3"

Пример с использованием макросов:

use tracing::{info, instrument, span, Level};
use tracing_subscriber;

#[instrument]  // Автоматически создаёт span для функции
fn process_request(user_id: u64) {
    // Вложенный span
    let validation_span = span!(Level::INFO, "validation", user_id);
    let _guard = validation_span.enter();
    
    // Какое-то действие
    std::thread::sleep(std::time::Duration::from_millis(10));
    
    info!("Валидация пройдена");
    
    // Выход из span автоматически при падении _guard
}

fn main() {
    tracing_subscriber::fmt()
        .with_target(true)
        .init();
    
    process_request(42);
}

Вывод будет содержать структурированную информацию о времени выполнения каждого span и вложенности. Это бесценно для дебага latency-проблем.

3. Метрики: считаем всё

Логи — это хорошо, но чтобы увидеть тренды, нужны метрики. Популярный выбор в Rust — metrics крейт с экспортом в Prometheus.

Настройка Prometheus экспортера

[dependencies]
metrics = "0.23"
metrics-exporter-prometheus = "0.15"
actix-web = "4"  # Для HTTP сервера метрик

Создаём счётчики и гистограммы:

use metrics::{counter, histogram, gauge};
use metrics_exporter_prometheus::PrometheusBuilder;
use std::time::Instant;

fn main() {
    // Настраиваем экспорт метрик на /metrics
    let builder = PrometheusBuilder::new();
    builder
        .listen_address("0.0.0.0:9000".parse().unwrap())
        .install()
        .expect("Не удалось установить экспортёр метрик");
    
    // Симуляция работы
    for _ in 0..10 {
        let start = Instant::now();
        
        // Инкрементируем счётчик
        counter!("requests_total", 1);
        
        // Записываем значение в гистограмму
        let duration = start.elapsed().as_secs_f64();
        histogram!("request_duration_seconds", duration);
        
        // Обновляем gauge
        gauge!("memory_usage_mb", 128.0);
        
        std::thread::sleep(std::time::Duration::from_millis(100));
    }
    
    // Бесконечный цикл, чтобы сервер метрик работал
    loop {
        std::thread::sleep(std::time::Duration::from_secs(10));
    }
}

Теперь откройте http://localhost:9000/metrics — Prometheus с радостью соберёт эти данные.

4. OpenTelemetry: универсальный мост

Если ваша инфраструктура использует OpenTelemetry (а это современный стандарт), Rust вас не подведёт. Крейт opentelemetry позволяет отправлять трейсы и метрики в любой бэкенд (Jaeger, Zipkin, Grafana Tempo).

Пример интеграции с tracing

[dependencies]
opentelemetry = { version = "0.25", features = ["rt-tokio"] }
opentelemetry-otlp = "0.17"
tracing-opentelemetry = "0.28"
tokio = { version = "1", features = ["full"] }

use opentelemetry::global;
use opentelemetry_otlp::WithExportConfig;
use tracing_subscriber::prelude::*;
use std::time::Duration;

#[tokio::main]
async fn main() {
    // Настройка OTLP экспортера (отправляем на localhost:4317)
    let tracer = opentelemetry_otlp::new_pipeline()
        .tracing()
        .with_exporter(
            opentelemetry_otlp::new_exporter()
                .tonic()
                .with_endpoint("http://localhost:4317")
                .with_timeout(Duration::from_secs(3))
        )
        .install_batch(opentelemetry::runtime::Tokio)
        .expect("Не удалось установ