Мониторинг и логирование C++ приложений: от хаоса к порядку

Ваше C++ приложение — чёрный ящик? Пора это исправить!

Представьте ситуацию: вы запустили высоконагруженный C++ сервис, всё работает отлично. Проходит неделя, другая — и вдруг пользователи жалуются на тормоза. Вы лезете в код, ставите std::cout в критических местах, перекомпилируете, перезапускаете... Знакомо? Если да — эта статья для вас.

В мире продакшена C++ мониторинг и логирование — это не роскошь, а необходимость. Без них вы слепы, как крот в тёмной комнате. Но хорошая новость в том, что современный C++ (особенно начиная с C++17) предоставляет все инструменты для создания прозрачной, наблюдаемой системы.

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

Почему просто std::cout — это боль?

Многие начинающие C++ разработчики пишут так:

std::cout << "Ошибка: файл не найден" << std::endl;

На первый взгляд — нормально. Но давайте подумаем о проблемах:

• Нет уровней важности. Вы не отличите debug-сообщение от критической ошибки.
• Нет временных меток. Когда это произошло? Вчера? Секунду назад?
• Нет контекста. Какой поток? Какой запрос? Какие данные?
• Блокирующий вывод. std::endl сбрасывает буфер, что убивает производительность в высоконагруженных системах.
• Нет ротации. Файл лога будет расти бесконечно, пока не займёт весь диск.

Короче говоря, std::cout годится только для игрушечных проектов. Для серьёзного C++ продакшена нужен серьёзный подход к логированию C++ приложений.

Spdlog: ваш новый лучший друг

Библиотека spdlog — это золотой стандарт логирования в современном C++. Она быстрая (одна из самых быстрых), header-only (не нужно собирать), и невероятно гибкая. Давайте посмотрим, как настроить её правильно.

Установка и базовая настройка

Spdlog можно подключить через CMake FetchContent или просто скопировать заголовки. Вот минимальная настройка для продакшена:

#include <spdlog/spdlog.h>
#include <spdlog/sinks/rotating_file_sink.h>
#include <spdlog/sinks/stdout_color_sinks.h>
#include <memory>

void setup_logging() {
    // Создаём консольный логгер с цветным выводом
    auto console_sink = std::make_shared<spdlog::sinks::stdout_color_sink_mt>();
    
    // Создаём файловый логгер с ротацией: 5 файлов по 10 МБ
    auto file_sink = std::make_shared<spdlog::sinks::rotating_file_sink_mt>(
        "logs/myapp.log",  // путь к файлу
        10 * 1024 * 1024,   // максимальный размер файла: 10 MB
        5                   // количество файлов для ротации
    );

    // Объединяем в многопоточный логгер
    auto logger = std::make_shared<spdlog::logger>(
        "main_logger",
        spdlog::sinks_init_list{console_sink, file_sink}
    );

    // Устанавливаем формат: [время] [уровень] [имя_логгера] сообщение
    logger->set_pattern("[%Y-%m-%d %H:%M:%S.%e] [%^%l%$] [%n] %v");
    
    // Устанавливаем глобальный уровень логирования (можно менять runtime)
    logger->set_level(spdlog::level::info);
    
    // Регистрируем как глобальный логгер
    spdlog::set_default_logger(logger);
}

int main() {
    setup_logging();
    
    spdlog::info("Приложение запущено. Версия: {}", APP_VERSION);
    spdlog::warn("Конфигурация не найдена, используем значения по умолчанию");
    
    try {
        // какой-то код
        throw std::runtime_error("Ошибка подключения к БД");
    } catch (const std::exception& e) {
        spdlog::error("Критическая ошибка: {}", e.what());
        spdlog::flush();  // принудительно сбрасываем лог перед аварийным выходом
        return 1;
    }
    
    return 0;
}

Обратите внимание: мы используем rotating_file_sink_mt (многопоточная версия). Это значит, что логгер потокобезопасен — можно смело вызывать spdlog::info() из разных потоков без блокировок.

Уровни логирования: когда что использовать

Spdlog поддерживает стандартные уровни. Вот практическое руководство:

• trace — для супер-детальной отладки. Включайте только при расследовании инцидентов.
• debug — для разработчика. Вход в функции, значения переменных.
• info — для администратора. Запуск/остановка сервиса, успешные операции.
• warn — что-то пошло не так, но система выжила. Нехватка памяти, повторные попытки.
• error — операция не удалась. Ошибка БД, таймаут сети.
• critical — приложение в опасности. Потеря данных, аварийное завершение.

Совет: в продакшене обычно ставят info, а trace и debug включают только при необходимости через конфигурационный файл.

Мониторинг C++ приложений: смотрим под капот

Логирование — это история о прошлом. Мониторинг — это взгляд в настоящее. Что нам нужно знать о работающем приложении?

• Сколько памяти оно потребляет?
• Какова загрузка CPU?
• Сколько запросов в секунду?
• Какое время ответа?
• Не растёт ли количество ошибок?

Ответы на эти вопросы дают метрики. И лучший способ их собирать — использовать клиентскую библиотеку Prometheus для C++.

Prometheus-cpp: метрики для продакшена

Установите prometheus-cpp через vcpkg или соберите из исходников. Вот как добавить базовые метрики в ваше приложение:

#include <prometheus/exposer.h>
#include <prometheus/counter.h>
#include <prometheus/histogram.h>
#include <prometheus/registry.h>
#include <