Управление логированием¶

Общие сведения¶

Логирование (журналирование) пира и ордерера обеспечивается пакетом common/flogging. Этот пакет поддерживает:

Управление логированием, основанное на уровне важности (severity) сообщения
Управление логированием, основаное на логгере, генерирующем сообщение
Различные опции для форматирования, основывающиеся на важности сообщения

Все логи (журналы) направлены в поток stderr. Глобальное и зависящее от логгера управление логированием по важности предоставлено как пользователям, так и разработчикам. На текущий момент нет формальных правил, определяющих, какие типы информации соответствуют каким уровням логирования. При анализе сообщения об ошибке, разработчики часто хотят видеть все записи вплоть до уровня DEBUG.

В красиво отформатированном логе уровень обозначается цветом и четырехбуквенным кодом, «ERRO» для ERROR, «DEBU» для DEBUG и т.д. Логгер - это произвольное имя (строка) данная разработчикам для группировки сообщений. В отформатированном примере ниже, логгеры ledgermgmt, kvledger и peer генерируют сообщения.

2018-11-01 15:32:38.268 UTC [ledgermgmt] initialize -> INFO 002 Initializing ledger mgmt
2018-11-01 15:32:38.268 UTC [kvledger] NewProvider -> INFO 003 Initializing ledger provider
2018-11-01 15:32:38.342 UTC [kvledger] NewProvider -> INFO 004 ledger provider Initialized
2018-11-01 15:32:38.357 UTC [ledgermgmt] initialize -> INFO 005 ledger mgmt initialized
2018-11-01 15:32:38.357 UTC [peer] func1 -> INFO 006 Auto-detected peer address: 172.24.0.3:7051
2018-11-01 15:32:38.357 UTC [peer] func1 -> INFO 007 Returning peer0.org1.example.com:7051

Произвольное число логгеров может быть создано прямо в рантайме, нет какого-то общего списка логгеров и нет способа проверить существование определенного логгера.

Настройка логирования¶

Уровни логирования пира и ордерера настраиваются через спецификацию логирования, находящуюся в переменной окружения FABRIC_LOGGING_SPEC.

Полна структура этой спецификации выглядит так:

[<logger>[,<logger>...]=]<level>[:[<logger>[,<logger>...]=]<level>...]

Logging severity levels are specified using case-insensitive strings chosen from Уровни логирования указываются с помощью строк из следующего набора:

FATAL | PANIC | ERROR | WARNING | INFO | DEBUG

Уровень логирования без указаного перед ним списка логгеров будет установлен по умолчанию для всех сообщений. Для установки уровня по умолчанию для отдельного логгера или группы логгеров можно использовать такой синтаксис:

<logger>[,<logger>...]=<level>

Примеры спецификации:

info                                        - Установить по умолчанию уровень INFO
warning:msp,gossip=warning:chaincode=info   - По умолчанию - WARNING; Установить WARNING стандартным также для msp, gossip; Для chaincode - INFO
chaincode=info:msp,gossip=warning:warning   - То же самое, что предыдущая спецификация

Форматирование¶

Форматирование настраивается через переменную окружения FABRIC_LOGGING_FORMAT. Через нее вы можете указать строку форматирования, например такую (стандартную):

"%{color}%{time:2006-01-02 15:04:05.000 MST} [%{module}] %{shortfunc} -> %{level:.4s} %{id:03x}%{color:reset} %{message}"

Также можно указать значение json для вывода сообщений в формате json.

Чейнкод¶

Логирование чейнкода - обязаность разработчика.

Пользовательские чейнкоды также могут выводить в потоки stdout/stderr. Хотя полезно при разработке, при промышленной эксплуатации потоки обычно выключают, чтобы уменьшить вред, который может нанести сломанный или вредоносный код. Однако возможно включить вывод в эти потоки даже для контейнеров типа «netmode», управляемых пирами, для каждого пира в отдельности проставив опцию конфигурации CORE_VM_DOCKER_ATTACHSTDOUT=true.

После включения этой опции каждый чейнкод получит свой канал логирования по ключу своего conainer-id. Каждая строка вывода, записанного в stdout или stderr, будет включена в лог пира как отдельная запись. Не рекомендуется включать эту опцию при промышленном использовании.

Stdout и stderr, не пересылаемые в контейнер пира, могут быть просмотрены из контейнера чейнкода с использованием стандартных команд вашей платформы контейнерной виртуализации.

docker logs <chaincode_container_id>
kubectl logs -n <namespace> <pod_name>
oc logs -n <namespace> <pod_name>