Как се пише дневника ()

[Системна информация] [съобщение] [контекст]

когато:

инфо система. маркирано време, процес номер, номер на потока и друга служебна информация
съобщение. текстови съобщения
контекст. всякаква допълнителна информация, контекста може да бъде обща за съобщения в рамките на това, което тази операция.

За да се свържете двойката искане \ отговор често се използва HTTP хедър X-Искане-ID. Такава глава може да генерира клиент, или може да бъде генериран от страна на сървъра. Добавете ги в контекста на всеки ред в дневника, ще бъде в състояние да намери леко движение на ръката, всички съобщения, които са настъпили при изпълнение на конкретна заявка. И в случай на разпределени системи, заглавието може да се предава по веригата на мрежови повиквания.
Но с един контекст, искането е проблем с различни ORM, HTTP клиенти или други услуги \ библиотеки, които живеят живота си. И още добре, ако те предоставят възможността да замени стандартния си дървар най-малко в световен мащаб, но за определяне на контекста за дървар, като част от искането често не е реалистично. Този проблем касае най-вече за многонишковите обработка, когато даден процес обслужва редица искания. Но например в Rails freymvorke има много тясна интеграция между всички компоненти и запитвания ActiveRecord може да се запише в дневника заедно с глобалния контекст на искането за текущата мрежа. И по някакъв език Go сеч библиотеки ви позволяват динамично да се създаде нов дървар обект с правилния контекст, тя изглежда така:

reqLog: = log.WithField ( "requestID", requestID)

След това, копие от дървар може да се прехвърля като зависимост в други проекти. Но липсата на стандартизиран интерфейс сеч (като в определен район-3 в PHP) провокира създателите библиотеки твърдо кодиране malosovmestimymi дървар изпълнение. Ето защо, ако напишете своя библиотека да отида и да го има сеч компонент, не забравяйте да предостави интерфейс за потребителя да замени дървар.

Свързани статии