Recentemente instalei o Zabbix no servidor da minha rede para monitorar algumas máquinas, inclusive ele próprio. Ontem passei o dia configurando os itens a serem monitorados das minhas máquinas e tudo estava funcionando perfeitamente bem, com todos os gráficos sendo gerados e todas as estatísticas computadas.

Hoje ao chegar na empresa, fui direto ver a tela de gráficos que configurei e qual não foi minha surpresa ao verificar que os gráficos estavam todos em branco. Como por padrão o zabbix exibe o gráfico com período de 1 hora, alterei para 24 horas e pude notar que a última atualização no gráfico ocorreu ontem por volta das 23hrs, no entanto as estatísticas continuavam sendo coletadas. Seria esse um erro no serviço zabbix? Felizmente não existe nenhum problema com o Zabbix pelo que pude verificar ao reinicia-lo, no entanto continuo sem geração dos gráficos.

Alterei o nível de debug no arquivo zabbix-server.conf para 4 na linha com o parâmetro DebugLevel e reiniciei novamente o serviço. Dessa forma consegui verificar no log do servidor o problema que estava acontecendo:

# tail -f /var/log/zabbix/zabbix_server.log
013359:20061124:105552 Query::insert into trends \\
(clock,itemid,num,value_min,value_avg,value_max) values \\
(1164369600,17543,1,1041.594705,1041.594705,1041.594705)
013359:20061124:105552 Query failed:The table 'trends' is full [1114]

Table is full? Como isso pode acontecer? Como utilizo o Mysql para o Zabbix imaginei logo que o banco devia ter crescido demasiadamente e dessa forma teria enchido a partição /var. Uma rápida consulta ao espaço livre em disco (df) me mostrou que ainda existe muito espaço livre na partição /var então isso não pode ser um problema de espaço em disco para o Mysql.

Verifiquei que a tabela trends só tem cerca de 1 milhão de registros, o que não é muito pois já tive tabelas em algumas base de dados com muito mais do que essa quantidade de registros.
Resolvi tentar executar a query direto no mysql para ver o que acontecia

# mysql -p
Enter password:
Database changed

mysql> use zabbix
mysql> insert into trends (clock,itemid,num,value_min,value_avg,value_max) \\
values (1164369600,17539,1,112.790411,112.790411,112.790411);
ERROR 1114: The table 'trends' is full

Procurar no google por “mysql error 1114 table is full” não me retornou resultados satisfatórios então resolvi pesquisar no mysql mesmo a raiz do problema.
Imaginei que deveria existir alguma variável limitando o tamanho da tabela ou algo parecido. Com o comando show variables é possível verificar as variáveis atuais do mysql.
Como não existia nenhuma variável que aparentemente estivesse limitando o tamanho das tabelas, resolvi verificar as variáveis pertinentes ao tipo de tabela innodb uma vez que esse é o tipo das tabelas usadas pelo zabbix.

A variável que me pareceu mais passível de estar limitando o tamanho das tabelas foi a “innodb_data_file_path” cujo valor estava definido como ibdata1:10M:autoextend:max:128M (provavelmente o padrão do mysql), no entanto o nome da variável não indicava exatamente limitação de tamanho da tabela, mas de qualquer forma era bom verificar.

Procurando no google por esse valor achei um blog onde o autor do post relatava o mesmo problema que o meu com o zabbix e tableas do tipo innodb e coincidentemente a mesma distribuição Linux estava sendo usada: Gentoo.
Pelo que entendi o problema realmente estava na definição do tamanho máximo definido pro arquivo InnoDB (ibdata1). O autor do post indica o endereço http://www.browardphp.com/mysql_manual_en/manual_InnoDB.html onde a configuração do InnoDB é explicada.

De acordo com as especificações do site, alterei o parâmetro innodb_data_file_path para ibdata1:10M:autoextend, reiniciei o mysql e o zabbix, e pronto, o zabbix voltou a gerar os gráficos novamente.

# vi /etc/my/mysql.cnf

innodb_data_file_path = ibdata1:10M:autoextend

# /etc/init.d/mysql restart
# /etc/init.d/zabbix-server restart

Não esqueça de alterar novamente o nível de debug no arquivo zabbix-server.conf

Referências

• The Geekery » Open Source
• MySQL Reference Manual for version 5.0.3-alpha – 15 The InnoDB Storage Engine

Tags: Gentoo,Linux,Mysql,Web-apps
Categories: Dicas
No Comments »

O AWStats é um excelente software para análise de logs e geração de estatísticas. Ele trabalha muito bem com os principais web servers (principalmente o Apache) e também pode ser usado para analisar logs de ftp, e deservidores de e-mail segundo informação dos desenvolvedores.

Na empresa onde trabalho, utilizamos o AWStats junto com outras soluções como extreme tracking e google analytics, porém acho o AWStats o mais objetivo de todos no sentido de apresentar as estatísticas coletadas do log.

Essa semana resolvi instalar o AWStats na minha conta da DreamHost, uma vez que eu não gostei muito do Analog que eles disponibilizam e além do mais eu já instalei o AWStats antes, então agora não devo encontrar dificuldades.

Para facillitar o processo, dei uma olhada no Wiki da DreamHost e achei um passo a passo de como instalar o AWStats.
O AWStats pode funcionar de 2 formas: com páginas estaticas ou através do cgi. Particularmente eu prefiro utilizar como CGI pois possibilita a atualização dos dados apartir do browser. No Wiki da DreamHost esse método é chamado de rápido (Quick).

Show me more… »

Tags: Linux,Web-apps
Categories: Artigos
428 Comments »

Após a implementação do segundo link de internet aqui da empresa (Roteando múltiplos links de internet) descobri que alguns sites não funcionavam direito.
Os problemas começaram a ocorrer principalmente nos Internet Banking devido a mudança do IP durante a sessão do sistema.

Como sou usuário do Bradesco comecei a testar o acesso e verifiquei que durante uma sessão de Internet Banking, aproximadamente 4 hosts diferentes do Bradesco são conectados.
Como os hosts são de redes diferentes, é bem possível que cada para cada host seja utilizado um gateway diferente e é ai que ocorre a alteração do IP do cliente.

Para contornar esse problema de forma fácil e rápida é possível marcar os pacotes no firewall que atenderem a uma certa condição, como por exemplo o endereço de destino.
Uma vez que os pacotes estejam marcados é possível definir a tabela de roteamento a ser utilizada por esses pacotes.

Após inúmeros testes e muito monitoramento com tcpdump, netstat e whois, descobri as 3 redes de IP do Bradesco que eu deveria forçar a utilização por 1 dos links. Inseri 3 regras no firewall para marcar os pacotes destinados a essas redes.

# iptables -A PREROUTING -t mangle -p tcp -m tcp -d 200.173.19.0/25 -j MARK --set-mark 0x1
# iptables -A PREROUTING -t mangle -p tcp -m tcp -d 200.246.210.0/23 -j MARK --set-mark 0x1
# iptables -A PREROUTING -t mangle -p tcp -m tcp -d 200.155.80.0/20 -j MARK --set-mark 0x1

Uma vez que os pacotes estejam marcados é possível definir a tabela de roteamento a ser utilizada. Para isso utilizamos novamente o iproute2:

# ip rule add prio 11 fwmark 0x1 table isp1
# ip route flush cache

O exemplo acima assume que o nome da tabela do link 1 é isp1. Para maiores informações sobre como criar/nomear tabelas de roteamento consulte o artigo Roteando múltiplos links de internet

Após mais um tempo alguns usuários detectaram outros sites com o mesmo problema e o que percebi é que em sua grande maioria os serviços em questão rodavam sobre conexões seguras (https). Sendo assim alterei a regra no firewall para trafegar todu que for destinado a porta 443 pela link 1.
A regra abaixo cuida do serviço:

# iptables -A PREROUTING  -t mangle -p tcp -m tcp --dport 443 -j MARK --set-mark 0x1
# ip route flush cache

É importante executar o comando ip route flush cache toda vez que for alterada alguma regra referente ao roteamento de pacotes.

Pronto, agora toda conexão https será direcionada para o primeiro link. Caso o link falhe é possível trocarmos a tabela de roteamento a ser utilizada:

# ip rule del prio 11 fwmark 0x1 table isp1
# ip rule add prio 11 fwmark 0x1 table isp2
# ip route flush cache

Usando o Nagios ou algum outro software de monitoramento (um simples shell script) é possível automatizar a detecção de problemas no link para alterar o link a ser utilizado por essas conexões, tornando assim o serviço praticamente ininterrupto.

Tags: Firewall,Linux,Network
Categories: Sem categoria
433 Comments »