KNOW INTUIT, Лекция, Регистриране
Формати на регистрационни файлове
Всеки лог файл има свой собствен формат. Помислете за формати на текстови регистрационни файлове.
Разширен W3C лог формат
W3C Extended Format е персонализиран ASCII формат, който ви позволява да посочите полетата, които се записват в дневника, като по този начин ограничава неговия размер. Microsoft използва няколко допълнителни полета във формат W3C. Нека разгледаме този формат по-подробно.
Разширени спецификации на регистрационния формат
Разширеният формат е предназначен да заобиколи ограниченията на общия формат и да въведе стандарт за регистриране, който е независим от операционната система или уеб сървъра. Разширеният формат използва обикновен ASCII текст. Всеки ред се нарича директива или запис.
Директиви за дневника. Директивите съдържат информация за лог файла и неговите свойства. Директивите се появяват в началото на дневника, предшествани от знак "#". Има общо седем директиви, но само две от тях са задължителни.
- Версия(Версия). Указва версията на регистрационния файл на W3C.
- Софтуер(Софтуер). Указва софтуерния пакет, с който е генериран регистрационният файл.
- Начална дата(Начална дата). Указва датата и часа, когато започва регистриране.
- Крайна дата(Крайна дата). Указва датата и часа на приключване на записването.
- Дата(Дата). Указва датата и часа, когато директивите са добавени в началото на дневника.
- Забележка(Коментари). Коментарите са въведени в дневника. Този запис се игнорира от анализаторите на софтуерни журнали.
- Полета(Полета). Указва полетата, използвани в дневника. Това е най-важната директива, тъй като съдържа подробна информация за това какчетене на данни от запис. Директивата Fields съдържа префикс, който дефинира асоциирането на данни с клиента и/или сървъра.
Записи в дневника. Записите в регистрационния файл улавят текущи потребителски събития или събития на процеси. Всеки запис включва префикс и поле. Префиксът се появява пред всяко поле и идентифицира клиента и/или сървъра, към който са свързани данните. Префиксите са описани по-долу.
° С | Клиент |
с | сървър |
r | Дистанционно |
cs | клиентски сървър |
sc | Сървър клиент |
ср | сървър-отдалечен сървър |
rs | отдалечен сървър сървър |
х | Приложение |
Забележка. Реализацията на разширения журнален формат не предвижда използването на префиксите sr, rs и x. Те са включени в списъка с цел пълнота.
Всеки запис в журнала се появява на отделен ред и е разделен с интервал. Това изключва използването на какъвто и да е знак (като запетая) за разделяне на записи. В крайна сметка разделителният знак може да бъде в самия запис, което ще отреже съдържанието на дневника, разположен след него. Ако в полето няма запис, тогава знакът "-" се използва за обозначаване на празен запис. По този начин всички записи в дневника съдържат еднакъв брой полета.
Таблица 11.2 изброява полетата, дефинирани за регистриране на W3C.
Тъй като форматът W3C може да се персонализира, към него могат да се добавят други полета. Внедряването на W3C журнали на Microsoft предоставя допълнителни полета (вижте Таблица 11.3).
потребителско име | Потребителското име за завършената транзакция. |
име на сайта | Номерът на интернет услугата и номерът на инстанцията, достъпни от клиента. |
име на компютър | Името на сървъра, на който е генериран записът. |
порт | Номер на пристанище. |
win32-състояние | Състояние по отношение на Windows. |
версия | Версията на протокола за тази транзакция. |
домакин | Съдържание на заглавката на възела. |
потребителски агент | Клиентски браузър. |
бисквитка | Съдържанието на изпратените или получени бисквитки. |
референт | Адресът на предишния сайт. |
Забележка. Някои потребители може да попитат защо се използва URI вместо URL. Отговорът на този въпрос е доста труден, тъй като има класически и модерни интерпретации на URI и URL адреси. Дори W3C и IETF са съгласни, че тези съкращения често са източник на объркване. Тъй като W3C използва URI, за целите на тази глава (и за по-голяма простота) ще интерпретираме URI като елемент, идентичен на URL.