Marcador de separação formal de eventos syslog?

7

Eu tenho procurado RFC5424 para encontrar o marcador formalmente especificado que terminará com um evento syslog.

Infelizmente, não consegui encontrá-lo. Então, se eu quisesse implementar algum pequeno servidor syslog que reage em certas mensagens, qual é o marcador que termina uma mensagem (sim, geralmente um evento é uma única linha, mas eu simplesmente não consegui encontrá-lo na especificação)

Esclarecimento :

Eu chamo de evento porque associo uma mensagem a uma única linha. Um evento poderia ser algo como

Type: foo
Source: webservers

enquanto uma mensagem para mim é esta:

Type: foo Source: webservers

link define:

SYSLOG-MSG      = HEADER SP STRUCTURED-DATA [SP MSG]

nem STRUCTURED-DATA nem MSG informam como esses campos terminam. Especialmente MSG é definido como MSG-ANY / MSG-UTF8 , que se expande virtualmente para qualquer coisa. Não há nada que diga que uma nova linha marca o fim (ou um 8 ou um a para esse assunto). Dadas as mensagens de exemplo (seção 6.5):

Esta é uma mensagem válida, ou 2 mensagens válidas, dependendo de você dizer que um elemento HEADER nunca deve ocorrer em nenhum elemento MSG :

espaço em branco literal

<34>1 2003-10-11T22:14:15.003Z mymachine.example.com su - ID47 - <34>1 2003-10-11T22:14:15.003Z mymachine.example.com su - ID47
                                                                |
                                                               is this an end marker?

\t significa uma guia

<34>1 2003-10-11T22:14:15.003Z mymachine.example.com su - ID47 -\t<34>1 2003-10-11T22:14:15.003Z mymachine.example.com su - ID47
                                                                |
                                                               is this an end marker?

\n significa uma nova linha

<34>1 2003-10-11T22:14:15.003Z mymachine.example.com su - ID47 -\n<34>1 2003-10-11T22:14:15.003Z mymachine.example.com su - ID47
                                                                |
                                                               is this an end marker?

Ou eu estou interpretando mal o RFC ou simplesmente não há qualquer menção. Os tamanhos especificados no RFC dizem apenas qual o tamanho mínimo esperado para trabalhar com ...

RESPOSTA? : Aparentemente eu estava lendo o RFC errado. É preciso ir as RFCs de transporte específicas e manter esse link diz tudo para o transporte UDP.

@joechip: Como os seus comentários e respostas levam eu realmente li um pouco mais nos RFCs de transporte Eu ficarei feliz em aceitar sua resposta se você atualizar um pouco nessa direção:)

    
por serverhorror 18.06.2011 / 23:47

2 respostas

2

Bem, o que você quer dizer com "evento syslog"? No caso de você se referir a mensagens syslog, o RFC5424 define inequivocamente a sintaxe da mensagem syslog em sua seção 6, como ela deve ser transmitida de um aplicativo syslog para outro.

Caso você esteja se referindo a como eles são armazenados nos arquivos de log pelo aplicativo syslog de recebimento, as implementações típicas do syslog simplesmente separam um registro do outro com novas linhas, e isso geralmente não é um comportamento configurável. Além disso, o campo de texto de um registro syslog também pode incluir novas linhas e isso complica a tarefa de analisar o arquivo de log corretamente. Ele geralmente pode ser analisado, no entanto, porque cada registro syslog começa com a sequência usual de data, hora, host e tag, enquanto novas linhas dentro de um registro syslog normalmente não seriam seguidas por um texto semelhante àquele.

Acho que a capacidade de alterar o separador de registro armazenado do syslog seria um recurso útil, mas qualquer ocorrência de tal separador dentro do próprio registro deve ser evitada para que isso seja útil. Adicionando tanta estrutura a um arquivo de texto simples é obrigado a ser um compromisso. Se você se importa muito com esse problema, talvez seja melhor dar suporte à gravação em arquivos de log em algum formato binário bem definido (por exemplo, o sqlite pode ser útil aqui).

Editar: Um exame mais cuidadoso da seção 6 do RFC5424 mostra que uma mensagem do syslog pode ter duas formas:

HEADER SP STRUCTURED-DATA

ou

HEADER SP STRUCTURED-DATA SP MSG

Ao expandir a especificação ABNF, podemos ver facilmente que o primeiro formulário termina em "-" ou "]". Pode haver outros "-" e "]" caracteres antes deste caractere final, portanto, não pode ser usado como terminador de mensagem syslog.

A segunda finalização do formulário depende de como o MSG termina. O MSG pode ser uma string UTF-8 (conforme especificado no RFC 3629, que não contém terminação de string) ou um fluxo de octetos arbitrários que termina em qualquer valor. Evidentemente, não há tal símbolo de terminação especificado para este formulário.

Mas o fato é que não há necessidade de um terminador de mensagem do syslog, não importa de que forma ele esteja, porque o comprimento da mensagem é comunicado fora da banda pela camada de transporte. Quando o pacote UDP é enviado pelo aplicativo, a mensagem do syslog já deve estar preparada de acordo com a especificação e armazenada em um buffer. Esse buffer é passado pelo aplicativo para uma função ou método para enviá-lo e a quantidade de bytes para enviar também é passada. Por exemplo, em C, temos:

ssize_t sendto(int sockfd, const void *buf, size_t len, int flags,
               const struct sockaddr *dest_addr, socklen_t addrlen);

Neste exemplo, len é a quantidade de bytes que deve ser retirada do buffer buf e enviada para o host remoto.

Da mesma forma, no servidor syslog outra função ou método é chamado, como este:

ssize_t recvfrom(int sockfd, void *buf, size_t len, int flags,
                 struct sockaddr *src_addr, socklen_t *addrlen);

Esta função retorna o comprimento em bytes da carga útil UDP recebida no buffer buf . Se o aplicativo tentar ler mais do que esse comprimento retornado, ele receberá lixo (ou uma falha de segmentação). Para evitar a leitura acima desse limite, é comum colocar um valor NULL na posição buf [siz] logo após a chamada siz = recvfrom (...) . Dessa forma, qualquer chamada de função posterior que use buf como uma string funcionará corretamente. Essa terminação nula só se aplica a strings, é claro, e não a fluxos de octetos. E esse valor nulo é, como eu disse, geralmente não transmitido pela rede, mas apenas adicionado pelo aplicativo de recepção.

No caso do servidor syslog como um aplicativo de recebimento, a maioria dos servidores syslog pode adicionar essa terminação nula para sua manipulação interna da cadeia de caracteres recebida (se a tratarem como uma cadeia de caracteres), mas em qualquer caso valor é deixado de fora quando a string é anexada ao arquivo de log para não atrapalhar o processamento de texto do arquivo de log como um todo.

    
por 30.06.2011 / 00:38
0

Na seção 6.1, eles definem um tamanho de mensagem. Eu imaginaria que quando você obtivesse a mensagem completa, você teria o cabeçalho e os dados e somaria esse tamanho.

Além disso, não vejo facilidade para várias mensagens. Então eu acho que cada mensagem é um evento. Não há rastreamento de várias mensagens de qualquer tipo e nenhuma codificação especificada para mensagens de início, meio e fim. O Syslog rastreia mensagens registradas, mas não possui um conceito de evento de nível superior.

    
por 29.06.2011 / 23:36