syslogd: formato de arquivo de log (não formato de configuração)

1

Gostaria de analisar arquivos de log. O formato logfile do syslogd é o mesmo para todos os sistemas? No meu sistema (Debian Lenny), é:

Mar  7 04:22:40 my-host-name ...

(não estou muito interessado na ... parte)

Posso confiar nisso? E há talvez uma descrição mais ou menos oficial? A página de manual de syslogd descreve o formato de configuração, mas não o formato de arquivo de log.

Idealmente, a descrição daria aos campos nomes oficiais como (data, hora, host, entrada) ou (data e hora, nome do host, mensagem). Talvez além disso algumas expressões regulares. Gostaria de usar os nomes e expressões regulares no meu script, para evitar um desvio desnecessário do padrão e para garantir que o script seja executado em todos os lugares.

Obrigado

Chris

    
por Chris Lercher 22.03.2010 / 20:06

3 respostas

2

O RFC deve responder a esta pergunta. Para meu conhecimento: sim, esse é geralmente o caso.

    
por 22.03.2010 / 20:12
3

RFC 3164 que a Warner apontou para descrever o formato de rede para mensagens syslog UDP, você pode confiar que isso é o que acontece, mas o syslogd pode escrever algo um pouco diferente no disco quando ele registra suas mensagens.
Dito isso, normalmente você pode confiar nas entradas do syslog que se parecem com o que é descrito no RFC, aproximadamente da seguinte forma:

DATE HOSTNAME TAG: MESSAGE

Data está no formato Jan 1 00:00:01
Hostname geralmente é o nome abreviado do host, mas pode ser totalmente qualificado (especialmente se você estiver registrando uma mensagem de um host remoto)
Tag é de forma livre, mas por convenção não contém : . É geralmente no formato procname[PID] , e acredito que sempre seguido por um literal :
Mensagem é de forma livre

Se você precisa de uma garantia melhor de consistência em seu formato de log, vale a pena olhar para o syslog-NG - ele permitirá que você defina seus campos & insira marcadores para garantir que você possa analisar os arquivos resultantes. O syslog-NG também permite incluir metadados como o recurso + valores de prioridade da mensagem. O uso do syslog-NG reduz a definição de "todos os lugares" para "máquinas que executam o syslog-NG com uma configuração semelhante à sua".

    
por 22.03.2010 / 21:07
0

O diabo está no RFC que @warner vinculou:

4.1.3 MSG Parte de um pacote syslog

The MSG part will fill the remainder of the syslog packet. This will usually contain some additional information of the process that generated the message, and then the text of the message. There is no ending delimiter to this part. The MSG part of the syslog packet MUST contain visible (printing) characters. The code set traditionally and most often used has also been seven-bit ASCII in an eight-bit field like that used in the PRI and HEADER parts. In this code set, the only allowable characters are the ABNF VCHAR values (%d33-126) and spaces (SP value %d32). However, no indication of the code set used within the MSG is required, nor is it expected. Other code sets MAY be used as long as the characters used in the MSG are exclusively visible characters and spaces similar to those described above. The selection of a code set used in the MSG part SHOULD be made with thoughts of the intended receiver. A message containing characters in a code set that cannot be viewed or understood by a recipient will yield no information of value to an operator or administrator looking at it. The MSG part has two fields known as the TAG field and the CONTENT field. The value in the TAG field will be the name of the program or process that generated the message. The CONTENT contains the details of the message. This has traditionally been a freeform message that gives some detailed information of the event. The TAG is a string of ABNF alphanumeric characters that MUST NOT exceed 32 characters. Any non-alphanumeric character will terminate the TAG field and will be assumed to be the starting character of the CONTENT field. Most commonly, the first character of the CONTENT field that signifies the

Isso basicamente diz que o desenvolvedor pode colocar o que quiser no CONTENT, portanto, não há um padrão para o conteúdo real das mensagens, apenas para a organização das mensagens. Eu posso dizer que isso é uma falha, mas ainda não tenho certeza.

    
por 02.06.2016 / 18:04