| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
## Проблема
После аварийного завершения агента (SIGKILL) или длительной недоступности C++ клиент Unified Agent не восстанавливал соединение сам. Сессия оставалась в состоянии «активна», сообщения накапливались в буфере (inflight), при достижении лимита начинались потери (dropped messages), и доставка не возобновлялась даже после поднятия агента — требовался перезапуск приложения-клиента.
## Как исправлено
Добавлен механизм «страховки»: если у сессии есть не подтверждённые сообщения (inflight), но по активному gRPC-стриму долго нет никакой активности (ни read, ни write, ни finish), клиент принудительно отменяет текущий вызов и запускает обычный путь реконнекта (повторные попытки установки сессии). «Длительность молчания» задаётся новым параметром; по умолчанию механизм включён (30 с) — зависание сессии никому не нужно, отключить можно явно, выставив таймаут в 0.
{% cut "Технические детали" %}
**Корневая причина:** реконнект планировался только в `OnGrpcCallFinished`, то есть после завершения активного stream-вызова. При «зависшем» транспорте (transport stall после падения агента) gRPC мог не вызывать финальный callback, `ActiveGrpcCall` оставался занятым, и новый `MakeGrpcCall` не запускался.
**Изменения в коде:**
- В `TClientParameters` добавлен параметр `GrpcCallInactivityTimeout` (по умолчанию 30 с; 0 = отключено).
- В сессии заведён периодический watchdog-таймер; при срабатывании проверяется: есть ли активный `TGrpcCall`, есть ли inflight-сообщения и не было ли активности дольше заданного таймаута. При выполнении условий вызывается принудительное закрытие текущего call (`BeginClose(true)`), что приводит к `OnGrpcCallFinished` и планированию следующего `MakeGrpcCall` по `GrpcReconnectDelay`.
- Время последней активности обновляется при любом успешном событии стрима (Accept, Read, Write, Finish, а также при инициализации сессии и при ack).
**Тестирование:** добавлен интеграционный тест `TestReconnectAfterLongStall` (агент поднимается → сессия и первая доставка → убийство агента → отправка во время даунтайма → пауза → повторный запуск агента → проверка, что inflight обнуляется и сессия переинициализируется без рестарта приложения). Регрессии по существующим reconnect-тестам не наблюдаются.
{% endcut %}
commit_hash:f55efec2cff20fa975500e73d60ee57654abb2e0
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
# Улучшения библиотеки логирования и переход на троттлинг логов
## Описание
Этот PR содержит улучшения системы логирования unified\_agent с акцентом на предотвращение флуда логов и добавление метрик логирования.
## Основные изменения
### 1. Улучшения библиотеки логирования (`library/cpp/unified_agent_client/logger`)
- **Встроенный троттлинг логов**: Добавлена поддержка ограничения частоты логирования на уровне библиотеки
- Новые макросы `YLOG_*_T` с автоматическим троттлингом (20 логов на 10 секунд по умолчанию)
- Независимый троттлинг для каждой точки логирования (по `__FILE__:__LINE__`)
- Автоматический подсчет подавленных сообщений с выводом `[+N suppressed]`
- **Метрики логирования**: Добавлены счетчики для мониторинга активности логирования
- `RecordsReceived` - общее количество попыток логирования
- `RecordsDropped` - количество подавленных сообщений из-за троттлинга
- Счетчики передаются через `TLogger::TCounters` при создании логгера
- **Оптимизация производительности**:
- Использование `GetCycleCount()` для быстрого получения времени (вместо системных вызовов)
- Relaxed memory ordering для атомарных операций (достаточно для троттлинга)
- Минимальные накладные расходы при отключенном логировании
### 2. Переход всех логов агента на троттлинг
- **Унификация макросов**: Все макросы `YLOG_*` в `logbroker/unified_agent/common/util/logger.h` теперь используют троттлинг
- `YLOG_DEBUG`, `YLOG_INFO`, `YLOG_WARNING`, `YLOG_ERROR` и т.д. теперь автоматически применяют троттлинг
- Старые макросы `YLOG_*_F` теперь алиасы для новых троттлированных версий
- Обратная совместимость полностью сохранена
- **Обновление документации**: Файл `for_ai_cpp.md` обновлен с новыми рекомендациями по логированию
### 3. Интеграция метрик логирования в телеметрию
- **Новые счетчики в `TAgentLogCounters`**:
- `RecordsReceived` - rate метрика `agent.log.records_received`
- `RecordsDropped` - rate метрика `agent.log.records_dropped`
- **Экспорт метрик**: Метрики логирования автоматически собираются и отправляются в телеметрию агента
- **Рефакторинг конструктора `TAgent`**:
- Упрощена передача счетчиков через структуру `TAgent::TCounters`
- Счетчики логирования передаются в `TLogger` при инициализации
### 4. Тесты
- **Перенос тестов**: Тесты логирования перемещены из `logbroker/unified_agent/tests/gtests/logger_tests` в `library/cpp/unified_agent_client/ut`
- **Расширенное покрытие**:
- Тесты базового троттлинга
- Тесты счетчика подавленных сообщений
- Тесты независимого троттлинга для разных точек логирования
- Тесты форматирования сообщений
- Тесты счетчиков метрик
### 5. Исправления и улучшения
- **Удаление дублирования кода**: Логика троттлинга теперь находится только в `library/cpp/unified_agent_client/logger.cpp`
- **Упрощение API**: Удален отдельный файл `logbroker/unified_agent/common/util/logger.cpp`
- **Обновление импортов**: Все файлы обновлены для использования правильных заголовочных файлов
## Преимущества
1. **Защита от флуда логов**: Автоматическое ограничение частоты логирования предотвращает переполнение логов
2. **Наблюдаемость**: Метрики логирования позволяют отслеживать активность и проблемы с логированием
3. **Производительность**: Минимальные накладные расходы благодаря оптимизированной реализации
4. **Простота использования**: Троттлинг работает автоматически, не требует изменений в коде
5. **Обратная совместимость**: Все существующие макросы продолжают работать
## Тестирование
- ✅ Все unit-тесты логирования проходят
- ✅ Integration тесты обновлены (исключение нестабильной метрики `RecordsReceived` из сравнений)
- ✅ Проверена работа троттлинга в реальных условиях
commit_hash:75fc97a8576114446bfb9ec11efbb80df322e443
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
## Problem
Log spam with repeated ``'max inflight of [***] bytes reached, [***] bytes dropped'`` errors appearing multiple times within the same second, causing log flooding.
## Solution
Implemented one-second throttling mechanism for this specific error message to prevent log spam while maintaining accurate counter tracking.
## Testing
- Added `TestMaxInflightBytesThrottling` integration test
- Confirms throttling limits log entries to ≤3 for 50 rapid message drops (vs 50 without throttling)
- Ensures all dropped message counters remain accurate regardless of throttling
commit_hash:58f44ca8ce2b8b416586f8ca7a3d3ca971f1e9cb
|
| |
|
|
|
|
|
| |
fintech, games, geobase, infra, ipreg, juggler, kernel, keyboard, laas, library, logbroker, logos, mail
If you think that this pr has broken something for you, roll it back
commit_hash:df8e48b2a4ecbbc74a504aa3ff62ebb8f464218d
|
| |
|
|
| |
https://clubs.at.yandex-team.ru/arcadia/29404
|
| | |
|
| | |
|
| | |
|
| |
|
| |
Correct order of the GRPC_ENABLE_FORK_SUPPORT set
|
| |
|
