Arquivos de log do Cassandra
Introdução
Falamos neste artigo sobre nossos principais arquivos de configuração, dos parâmetros básicos que devemos alterar. Agora chegou a hora de olharmos nossos arquivos de log do Cassandra.
Todo mundo que administra uma ferramenta, seja um DB ou não, sabe que na hora do desespero tudo que você quer é uma explicação para o que está acontecendo e é o log que nos conta sobre o problema que estamos enfrentando. Eu costumo dizer que um DBA bom é aquele que consegue decifrar o log com fluência. Então vamos conversar um pouco sobre esses logs no Cassandra.
Como o Cassandra gera log?
O Cassandra usa uma funcionalidade chamada Simple Logging Facade for Java (SLF4J) para gerar seus logs. Uma parte curiosa aqui é que embora a gente veja no diretório de logs alguns logs do Garbage Collector, eles não são gerados exatamente pelo Cassandra.
O Cassandra gera apenas o system.log e o debug.log. Como você pode imaginar o debug.log é mais verboso (muito mais informações) enquanto o system.log se resume a logs mais relevantes. Por default todos os logs são gerados em /var/log/cassandra na instalação com pacotes, mas temos controle de alguns atributos.
logback.xml
Esse é o arquivo que controla o funcionamento dos logs: logback.xml. Por default ele fica no mesmo diretório dos outros arquivos de configuração, /etc/cassandra/conf. O arquivo em si é meio verboso, por ser um XML, mas vamos analisá-lo com calma.
<appender name="SYSTEMLOG" class="ch.qos.logback.core.rolling.RollingFileAppender">
<filter class="ch.qos.logback.classic.filter.ThresholdFilter">
<level>INFO</level>
</filter>
<file>${cassandra.logdir}/system.log</file>
<rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
<!-- rollover daily -->
<fileNamePattern>${cassandra.logdir}/system.log.%d{yyyy-MM-dd}.%i.zip</fileNamePattern>
<!-- each file should be at most 50MB, keep 7 days worth of history, but at most 5GB -->
<maxFileSize>50MB</maxFileSize>
<maxHistory>7</maxHistory>
<totalSizeCap>5GB</totalSizeCap>
</rollingPolicy>
<encoder>
<pattern>%-5level [%thread] %date{ISO8601} %F:%L - %msg%n</pattern>
</encoder>
</appender>
Este é nosso system.log, mas você verá configurações semelhantes para o debug.log. Aqui podemos ver que o log level (<level>INFO</level>), default, está em INFO, como várias outras tecnologias ele restringe ao necessário.
Já nosso arquivo está em: <file>${cassandra.logdir}/system.log</file>. Este é um truque legal, que demorei um tempinho para aprender, mas uma vez olhando o código do Cassandra vi que há referências a estes parâmetros ${cassandra.parametro} que, na verdade, são herdados do processo java em execução. Portanto, o ${cassandra.logdir} é o que aparece no processo do java rodando no Linux. Então quando você faz um ps -ef | grep java, você precisa procurar por uma opção “-Dcassandra.logdir=” para saber o destino dos logs. Por default, usando instalação através de pacotes, o destino será /var/log/cassandra.
A próxima opção controla o log rotation destes arquivos. Log rotate é uma coisa obrigatória para nossos servers. Ele fica responsável por remover arquivos de log antigos, compactar os mais recentes enquando o current continua sendo escrito normalmente. Há uma opção no linux para fazer esse log rotate, mas com o SLF4J vem com isso nativo. Você consegue controlar o tamanho máximo do arquivo corrente, antes de ser compactado, e o número de dias que quer reter os arquivos entre outras coisas.
GC Logs
Esta outra parte dos Logs é gerada pela JVM, não estando relacionado diretamente com o Cassandra, mas com a infraestrutura usada para manter o Cassandra rodando. Embora a forma como usamos o Cassandra possa influenciar a intensidade dos GCs, por exemplo, o log vem do Java e não do Cassandra. Novamente, conseguimos controlar alguns de seus atributos, principalmente relacionados a seu log rotate.
-XX:+UseGCLogFileRotation
-XX:NumberOfGCLogFiles=10
-XX:GCLogFileSize=10M
-Xloggc:/var/log/cassandra/gc.log
Esses logs normalmente necessitam de uma ferramenta especializada para análise, como GCeasy. Elas são capazes de gerar gráficos com as pausas e outras informações relevantes a respeito das thread pools.
Logs no dia a dia
Novamente, os logs são importantes para você saber o que está acontecendo com seu ambiente. Normalmente as falhas são registradas: nodes que caem, nodes que sobem, falta de espaço em disco para compactações e muitas outras coisas. Recorra aos logs sempre que aconceter algo significativo. E conheça seus logs para que seja útil quando você precisar.
No dia a dia administrando os ambientes Cassandra usamos bastantes ferramentas do Linux para alanisar estes logs, principalmente tail e grep. A opção tail -f permite que você acompanhe em tempo real os eventos que vão ocorrendo no log. E o grep permite você filtar por padrões desejados ou indesejado. Por exemplo, o grep -v permite que você excluir todas as linhas com valor INFO do output.
# para acompanhar o log em tempo real
tail -f /var/log/cassandra/system.log
# para acompanhar o log em tempo real filtrando apenas pelas linhas que possuem o termo ERR
tail -f /var/log/cassandra/system.log | grep ERR
# para acompanhar o log em tempo real excluindo as linhas que contenham o termo INFO
tail -f /var/log/cassandra/system.log | grep -v INFO
Conclusão
Falamos um pouquinho dos principais logs do Cassandra e como conseguimos ter algum controle sobre a forma como são gerados e armazenados. Dois pontos são importantes sobre os logs: o log rotate, já presente na configuração default e a forma como analisamos o log no dia a dia, que depende da nossa habilidade com o Linux. O fato é que são os logs que nos salvam quando algo estranho acontece. Espero que tenham gostado.
Você também pode gostar
Login com: Google