Problemas com logging

[Thiago Charchar]

Boa tarde galera!

Meu problema é o seguinte: Meu projeto utiliza como recurso de logging, o Apache Log4J 1.2.8. O projeto é grande e possui vários loggers e vários appenders,
entre os appenders existem alguns do tipo AsyncAppender, para log assíncrono. Temos um appender próprio que salva todos os events de transação
em um banco de dados de forma assíncrona, e é aí que está o problema, como a volumetria é alta, o banco está estourando. Quando o banco cai, o buffer
de log assíncrono acaba enchendo, e então as demais threads ficam em estado de espera e a aplicação trava. Gostaria de saber de vocês qual solução
vocês dariam para o problema em questão. Vale ressaltar que a aplicação ou conjunto de aplicações não pode travar em hipótese alguma por causa do
logging, e é preferível perder log do que ter todo um ambiente travado em produção.

Conto com a ajuda de vcs galera! obrigado a tds.


Thiago Charchar

[Felipe Gaucho]

pelo que entendi, você grava uma linha no banco para cada transacao, certo ?

Se apenas isso faz o banco "estourar", a dica é usar o mesmo mecanismo
de rolagem que o loggin tradicional usa..  ou seja, a cada n-linhas no
banco (ou dias, meses, trimestres, etc..) tu faz um backup da tabela
de logging (noutro banco, num arquivo, etc), e esvazia a tabela ...

se alguém precisar no futuro pesquisar algum registro mais antigo do
que os registros disponíveis no banco, tu precisa de um procedimento
para recuperar este registro do "arquivo morto" do log ...









2009/11/1 Thiago Charchar <thiagocharchar@...>:

> Boa tarde galera!
>
> Meu problema é o seguinte: Meu projeto utiliza como recurso de logging, o
> Apache Log4J 1.2.8. O projeto é grande e possui vários loggers e vários
> appenders,
> entre os appenders existem alguns do tipo AsyncAppender, para log
> assíncrono. Temos um appender próprio que salva todos os events de transação
> em um banco de dados de forma assíncrona, e é aí que está o problema, como a
> volumetria é alta, o banco está estourando. Quando o banco cai, o buffer
> de log assíncrono acaba enchendo, e então as demais threads ficam em estado
> de espera e a aplicação trava. Gostaria de saber de vocês qual solução
> vocês dariam para o problema em questão. Vale ressaltar que a aplicação ou
> conjunto de aplicações não pode travar em hipótese alguma por causa do
> logging, e é preferível perder log do que ter todo um ambiente travado em
> produção.
>
> Conto com a ajuda de vcs galera! obrigado a tds.
>
>
> Thiago Charchar
>

--
Looking for a client application for this service:
http://fgaucho.dyndns.org:8080/arena-http/wadl

---------------------------------------------------------------------
To unsubscribe, e-mail: enterprise-list-unsubscribe@...
For additional commands, e-mail: enterprise-list-help@...

[Thiago Charchar]

Valeu pelo feedback felipe!

Na verdade já existem algumas rotinas de expurgo. Como o volume de transações é
gigantesco, essas rotinas mantém esses logs por 48hrs, depois a tabela é zerada.
Tava pensando numa solução onde simplesmente não houvesse esse deadlock porque
uma das pontas parou, neste caso o banco de dados. Caso o banco parar, e o buffer
assíncrono encher, queria saber se existe algum recurso do log4j, seja via programação
ou arquivo de configuração que indique para não travar as demais threads, tipo...mandando
uma solicitação para o dispatcher thread esvaziar o buffer...sei la...preciso resolver isso!
Conto com a experiencia de vcs! :)

Thiago Charchar

2009/11/1 Felipe Gaúcho <fgaucho@...>

pelo que entendi, você grava uma linha no banco para cada transacao, certo ?

Se apenas isso faz o banco "estourar", a dica é usar o mesmo mecanismo
de rolagem que o loggin tradicional usa..  ou seja, a cada n-linhas no
banco (ou dias, meses, trimestres, etc..) tu faz um backup da tabela
de logging (noutro banco, num arquivo, etc), e esvazia a tabela ...

se alguém precisar no futuro pesquisar algum registro mais antigo do
que os registros disponíveis no banco, tu precisa de um procedimento
para recuperar este registro do "arquivo morto" do log ...









2009/11/1 Thiago Charchar <thiagocharchar@...>:

> Boa tarde galera!
>
> Meu problema é o seguinte: Meu projeto utiliza como recurso de logging, o
> Apache Log4J 1.2.8. O projeto é grande e possui vários loggers e vários
> appenders,
> entre os appenders existem alguns do tipo AsyncAppender, para log
> assíncrono. Temos um appender próprio que salva todos os events de transação
> em um banco de dados de forma assíncrona, e é aí que está o problema, como a
> volumetria é alta, o banco está estourando. Quando o banco cai, o buffer
> de log assíncrono acaba enchendo, e então as demais threads ficam em estado
> de espera e a aplicação trava. Gostaria de saber de vocês qual solução
> vocês dariam para o problema em questão. Vale ressaltar que a aplicação ou
> conjunto de aplicações não pode travar em hipótese alguma por causa do
> logging, e é preferível perder log do que ter todo um ambiente travado em
> produção.
>
> Conto com a ajuda de vcs galera! obrigado a tds.
>
>
> Thiago Charchar
>

--
Looking for a client application for this service:
http://fgaucho.dyndns.org:8080/arena-http/wadl

---------------------------------------------------------------------
To unsubscribe, e-mail: enterprise-list-unsubscribe@...
For additional commands, e-mail: enterprise-list-help@...

[Douglas Campos-3]

1) pq vc não usa algum esquema de syslog? as ferramentas de log *nix
são bem parrudas quando o problema eh volume grande... de repente,
redireciona o log pra um syslog em outra máquina, e consome essas
mensagens de log em outro lugar

2) Cara, pode até ser viagem de mais, mas já pensou em usar algum
banco de dados orientado a documentos pra isso, tipo o couchdb ou
mongodb? vc jamais teria os problemas de deadlock durante expurgo, já
que eh tudo imutavel por default. Já vi coisas desse tipo sendo usadas
em ruby/rails, mas seria trivial fazer em java :P

2009/11/1 Thiago Charchar <thiagocharchar@...>:

> Valeu pelo feedback felipe!
>
> Na verdade já existem algumas rotinas de expurgo. Como o volume de
> transações é
> gigantesco, essas rotinas mantém esses logs por 48hrs, depois a tabela é
> zerada.
> Tava pensando numa solução onde simplesmente não houvesse esse deadlock
> porque
> uma das pontas parou, neste caso o banco de dados. Caso o banco parar, e o
> buffer
> assíncrono encher, queria saber se existe algum recurso do log4j, seja via
> programação
> ou arquivo de configuração que indique para não travar as demais threads,
> tipo...mandando
> uma solicitação para o dispatcher thread esvaziar o buffer...sei
> la...preciso resolver isso!
> Conto com a experiencia de vcs! :)
>
> Thiago Charchar
>
> 2009/11/1 Felipe Gaúcho <fgaucho@...>
>>
>> pelo que entendi, você grava uma linha no banco para cada transacao, certo
>> ?
>>
>> Se apenas isso faz o banco "estourar", a dica é usar o mesmo mecanismo
>> de rolagem que o loggin tradicional usa..  ou seja, a cada n-linhas no
>> banco (ou dias, meses, trimestres, etc..) tu faz um backup da tabela
>> de logging (noutro banco, num arquivo, etc), e esvazia a tabela ...
>>
>> se alguém precisar no futuro pesquisar algum registro mais antigo do
>> que os registros disponíveis no banco, tu precisa de um procedimento
>> para recuperar este registro do "arquivo morto" do log ...
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 2009/11/1 Thiago Charchar <thiagocharchar@...>:
>> > Boa tarde galera!
>> >
>> > Meu problema é o seguinte: Meu projeto utiliza como recurso de logging,
>> > o
>> > Apache Log4J 1.2.8. O projeto é grande e possui vários loggers e vários
>> > appenders,
>> > entre os appenders existem alguns do tipo AsyncAppender, para log
>> > assíncrono. Temos um appender próprio que salva todos os events de
>> > transação
>> > em um banco de dados de forma assíncrona, e é aí que está o problema,
>> > como a
>> > volumetria é alta, o banco está estourando. Quando o banco cai, o buffer
>> > de log assíncrono acaba enchendo, e então as demais threads ficam em
>> > estado
>> > de espera e a aplicação trava. Gostaria de saber de vocês qual solução
>> > vocês dariam para o problema em questão. Vale ressaltar que a aplicação
>> > ou
>> > conjunto de aplicações não pode travar em hipótese alguma por causa do
>> > logging, e é preferível perder log do que ter todo um ambiente travado
>> > em
>> > produção.
>> >
>> > Conto com a ajuda de vcs galera! obrigado a tds.
>> >
>> >
>> > Thiago Charchar
>> >
>>
>>
>>
>> --
>> Looking for a client application for this service:
>> http://fgaucho.dyndns.org:8080/arena-http/wadl
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: enterprise-list-unsubscribe@...
>> For additional commands, e-mail: enterprise-list-help@...
>>
>
>

--
Douglas Campos (qmx)
[phone]

---------------------------------------------------------------------
To unsubscribe, e-mail: enterprise-list-unsubscribe@...
For additional commands, e-mail: enterprise-list-help@...