1. Тема дня

Log levels, rate limit, event ring buffer, breadcrumbs, fault snapshot, binary events, UART/MQTT/CAN telemetry, CLI diag/events/health. Главная мысль: логирование само может стать причиной задержек, переполнений и watchdog reset.

2. Зачем это нужно в проектах

Нужно понимать: на какой AT-команде умер EC25, почему был reconnect MQTT, есть ли queue drops, дрожит ли вход светофора, есть ли I2C timeout, UART overrun, CAN bus-off, какая задача не сделала progress перед reset.

3. Теория

Слои диагностики:

text 
1. Counters - быстро и дёшево.
2. Event ring buffer - последние события.
3. Text logs - для человека.
4. Fault snapshot - перед reset/fatal fault.
5. Core dump - post-mortem задач/стеков/регистров.

Уровни:

text 
ERROR - невосстановленная ошибка, data loss, reset.
WARN - recovered fault/degraded mode.
INFO - boot, connected, OTA start, mode change.
DEBUG - state machine internals.
VERBOSE - byte dumps/raw samples.

Fast path не печатает текст. Он обновляет counters и event ring. Rate limit:

c 
typedef struct {
    int64_t last_us;
    uint32_t suppressed;
} log_rl_t;
static bool log_rate_allow(log_rl_t *rl, int64_t now_us, int64_t period_us)
{
    if ((now_us - rl->last_us) >= period_us) {
        rl->last_us = now_us;
        return true;
    }
    rl->suppressed++;
    return false;
}

Event ring:

c 
typedef struct {
    int64_t ts_us;
    uint16_t module;
    uint16_t event;
    uint32_t a, b, c;
} diag_event_t;

Сетевые логи не отправляются из места ошибки. Модуль пишет event/counter, logger_task best-effort отправляет, DEBUG/INFO drop первыми при перегрузке. CLI diag должен показывать heap, stack watermark, queue fill/drops, DMA overrun, reconnect count, last reset reason.

4. Типичные ошибки

  1. Логировать в fast path.
  2. Логировать ошибку без счётчика и контекста.
  3. Не иметь rate limit.
  4. Отправлять логи через сломанный канал.
  5. Считать DEBUG harmless.
  6. Дампить большие буферы без лимита.
  7. Не сохранять breadcrumbs перед watchdog reset.

5. Практическое задание

Создай LOGGING_DIAGNOSTICS_POLICY.md:

markdown 
# Logging and diagnostics policy
Main rule:
Logs are not part of fast path timing.
Rules:
1. Fast path updates counters/events, not text logs.
2. Every repeated error has counter and rate limit.
3. ERROR/WARN logs include context.
4. DEBUG/VERBOSE are disabled in production by default.
5. Hex dumps are length-limited and debug-only.
6. Network log transport must not block critical tasks.
7. Last diagnostic events are stored in ring buffer.
8. Fault snapshot is saved before intentional reset.
9. CLI exposes counters, queues, health, events and reset reason.

Enums:

c 
typedef enum {
    DIAG_MOD_SYSTEM = 1,
    DIAG_MOD_INPUT,
    DIAG_MOD_PHASE,
    DIAG_MOD_MODEM,
    DIAG_MOD_MQTT,
    DIAG_MOD_I2C,
    DIAG_MOD_UART,
    DIAG_MOD_CAN,
    DIAG_MOD_LOGGER,
} diag_module_t;

6. Что почитать или попробовать дальше

ESP-IDF Logging Library, ESP-IDF Core Dump/Fatal Errors, ESP-IDF Heap Debugging, ST AN4989 SWV/ITM/SWO.

Ошибка возникает в input fast path. Что делать первым?

Задание

UART работает на 115200 baud, 8N1. Logger производит 400 строк/с по 40 байт, включая перевод строки. Игнорируя прочие накладные расходы, хватает ли линии? Какую bounded overload policy выбрать?

Критерии самопроверки: Покажите 10 bits/byte, 11520 и 16000 bytes/s; предложите bounded очередь и учёт dropped logs.

Показать ответ автора

8N1 требует 10 bits/byte: 115200/10=11520 bytes/s. Logger требует 400×40=16000 bytes/s, поэтому нет: очередь будет расти без ограничения. Введите bounded queue, rate limit, агрегированные counters и drop/accounting DEBUG/INFO; важные fault events сохраняйте по отдельной ограниченной policy.