Наблюдаемость позволяет нам понять систему снаружи, позволяя нам задавать вопросы об этой системе, не зная ее внутреннего устройства. Более того, это позволяет нам легко устранять и решать новые проблемы (т. е. «неизвестные неизвестные») и помогает нам ответить на вопрос: «Почему это происходит?»
Чтобы иметь возможность задавать такие вопросы системе, приложение должно быть правильно оснащено. То есть код приложения должен выдавать такие сигналы , как трассировки , метрики и логи . Приложение правильно оснащено, когда разработчикам не нужно добавлять дополнительные инструменты для устранения проблемы, поскольку у них есть вся необходимая информация.
Журналирование обеспечивает наглядное представление поведения работающего приложения. Журнал – это поток агрегированных, упорядоченных по времени событий, собранных из потоков вывода всех запущенных процессов и вспомогательных сервисов. Журнал в своём сыром виде обычно представлен текстовым форматом с одним событием на строчку (хотя трассировки исключений могут занимать несколько строк). Журнал не имеет фиксированного начала и конца, поток сообщений непрерывен, пока работает приложение.
Приложение двенадцати факторов никогда не занимается маршрутизацией и хранением своего потока вывода. Приложение не должно записывать журнал в файл и управлять файлами журналов. Вместо этого каждый выполняющийся процесс записывает свой поток событий без буферизации в стандартный вывод stdout. При рабочем развёртывании поток вывода каждого процесса будет захвачен средой выполнения, собран вместе со всеми другими потоками вывода приложения и перенаправлен к одному или нескольким конечным пунктам назначения для просмотра и долгосрочной архивации. Эти конечные пункты архивации не являются видимыми для приложения и настраиваемыми приложением, вместо этого они полностью управляются средой выполнения.
Нет определенного стандарта RFC, который бы описывал уровни логирования. Но часто используют 6 уровней, и их можно причислить к общепринятым стандартам, так же они описаны в стандарты https://opentelemetry.io/docs/specs/otel/logs/data-model/#field-severitynumber
В общем, уровни(severity) логирования включают:
| SeverityNumber | Name | Meaning |
|---|---|---|
| 1-4 | TRACE | A fine-grained debugging event. Typically disabled in default configurations. |
| 5-8 | DEBUG | A debugging event. |
| 9-12 | INFO | An informational event. Indicates that an event happened. |
| 13-16 | WARN | A warning event. Not an error but is likely more important than an informational event. |
| 17-20 | ERROR | An error event. Something went wrong. |
| 21-24 | FATAL | A fatal error such as application or system crash. |
Property
плоский список свойств, обязательно динамической длины
Enrich, Scope
logger.LogDebug($"PersonId={personId} params={params} process");
// Code to process item...
logger.LogDebug($"PersonId={personId} result={result}");