Áú»¢¶Ä²©

2 Pr¨¦-requisitos

Hardware

²Ñ±ð³¾¨®°ù¾±²¹

Para instalar o Áú»¢¶Ä²© existem requisitos de mem¨®ria (128MB) e de armazenamento(256MB dispon¨ªveis em disco). Entretanto, a quantidade de mem¨®ria e de disco, obviamente, depender¨¢ da quantidade de hosts e de par?metros monitorados. Se voc¨º est¨¢ planejando manter um longo hist¨®rico dos par?metros monitorados voc¨º dever¨¢ pensar em, pelo menos, alguns gigas para ter espa?o dispon¨ªvel para uso do banco de dados.

Cada processo deamon do Áú»¢¶Ä²© Server ir¨¢ requerer diversas conex?es com o servidor de banco de dados. A quantidade de mem¨®ria alocada para cada conex?o depender¨¢ das configura??es da engine do SGBD.

Regra de ouro dos bancos de dados: quanto mais mem¨®ria RAM voc¨º possui, mais r¨¢pido ¨¦ o banco de dados (e mais r¨¢pido o Áú»¢¶Ä²© por consequ¨ºncia!)

CPU

O Áú»¢¶Ä²© Server e, especialmente, seu banco de dados pode exigir quantidade significativa de recursos da CPU dependendo da quantidade de par?metros monitorados e da engine do SGDB.

Outro hardware

Para a notifica??o por SMS nativa da solu??o ser¨¢ requerido tamb¨¦m uma porta de comunica??o serial e um modem GSM a ela conectado. Conex?es USB-to-serial tamb¨¦m dever?o funcionar.

Exemplos de configura??o de hardware

A tabela a seguir prov¨º diversos exemplos de configura??o de hardware:

Nome Plataforma CPU/²Ñ±ð³¾¨®°ù¾±²¹ SGDB Hosts Monitorados
Small CentOS Virtual Appliance MySQL InnoDB 100
Medium CentOS 2 CPU cores/2GB MySQL InnoDB 500
Large RedHat Enterprise Linux 4 CPU cores/8GB RAID10 MySQL InnoDB ou PostgreSQL >1000
Very large RedHat Enterprise Linux 8 CPU cores/16GB RAID10 r¨¢pido MySQL InnoDB ou PostgreSQL >10000

A apropriada depender¨¢ da quantidade de itens ativos e seu intervalo de coleta, o que varia muito de um ambiente para outro. ? altamente recomend¨¢vel separar o Banco de dados em um servidor em separado em instala??es maiores.

Plataformas Suportadas

Devido ¨¤ requisitos de seguran?a e natureza de miss?o cr¨ªtica dos servidores de monitoramento o UNIX ¨¦ o ¨²nico sistema operacional que pode entregar de forma consistente os requisitos de performance, toler?ncia a falha e resili¨ºncia. O Áú»¢¶Ä²© opera entre as ferramentas l¨ªderes de mercado.

O Áú»¢¶Ä²© ¨¦ testado nas seguintes plataformas:

  • Linux
  • IBM AIX
  • FreeBSD
  • NetBSD
  • OpenBSD
  • HP-UX
  • Mac OS X
  • Solaris
  • Windows: 2000, Server 2003, XP, Vista, Server 2008, 7, 8, Server 2012 (Apenas Áú»¢¶Ä²© Agent)

O Áú»¢¶Ä²© poder¨¢ rodar em v¨¢rias outras variantes do UNIX.

Software

O Áú»¢¶Ä²© ¨¦ constru¨ªdo em torno do servidor de p¨¢ginas Apache, SGDBs l¨ªderes de mercado e a linguagem de scripts PHP.

Banco de dados de monitora??o
Software Vers?o °ä´Ç³¾±ð²Ô³Ù¨¢°ù¾±´Ç²õ
MySQL 5.0.3 ou superior Se for o SGDB escolhido como backend database. A engine InnoDB ¨¦ requerida.
Oracle 10g ou superior Se for o SGDB escolhido como backend database.
PostgreSQL 8.1 ou superior Se for o SGDB escolhido como backend database
Entretanto ¨¦ sugerido o uso do PostgreSQL 8.3 ou posterior, com o suporte .
SQLite 3.3.5 ou superior Se for o SGDB escolhido como backend database.
IBM DB2 9.7 ou superior Se for o SGDB escolhido como backend database.

O uso do IBM DB2 ¨¦ experimental!

Enquatno o uso do SQLite3 com o Áú»¢¶Ä²© Proxy ¨¦ at¨¦ recomendado, o uso com o Áú»¢¶Ä²© Server n?o ¨¦ recomend¨¢vel. Desde o Áú»¢¶Ä²© 2.4.0, os requisitos de acessos simult?neos do Áú»¢¶Ä²© Server e da interface web podem levar ¨¤ corromper o banco de dados!

Interface Web

Para o funcionamento da interface web do Áú»¢¶Ä²© ser¨¢ necess¨¢rio:

Software Vers?o °ä´Ç³¾±ð²Ô³Ù¨¢°ù¾±´Ç²õ
Apache 1.3.12 ou superior
PHP 5.4.0 ou superior A vers?o 7 do PHP ainda n?o ¨¦ suportada.
Extens?es do PHP:
gd 2.0 ou superior A extens?o PHP GD precisa suportar imagens PNG (--with-png-dir), JPEG (--with-jpeg-dir) e FreeType 2 (--with-freetype-dir).
bcmath php-bcmath (--enable-bcmath)
ctype php-ctype (--enable-ctype)
libXML 2.6.15 ou superior php-xml ou php5-dom, se forem fornecidas de forma separada pela distribui??o escolhida.
xmlreader php-xmlreader, se for fornecido de forma separada pela distribui??o escolhida.
xmlwriter php-xmlwriter, se for fornecidp de forma separada pela distribui??o escolhida.
session php-session, se for fornecido de forma separada pela distribui??o escolhida.
sockets php-net-socket (--enable-sockets). Necess¨¢rio para o suporte a scripts de usu¨¢rio.
mbstring php-mbstring (--enable-mbstring)
gettext php-gettext (--with-gettext). Necess¨¢rio para o recurso de tradu??o.
ldap php-ldap. Necess¨¢rio somente se a autentica??o na interface web for atrav¨¦s do LDAP.
ibm_db2 Necess¨¢rio se a tecnologia de banco de dados escolhida para o reposit¨®rio da monitora??o for o IBM DB2.
mysqli Necess¨¢rio se a tecnologia de banco de dados escolhida para o reposit¨®rio da monitora??o for o MySQL.
oci8 Necess¨¢rio se a tecnologia de banco de dados escolhida para o reposit¨®rio da monitora??o for o Oracle.
pgsql Necess¨¢rio se a tecnologia de banco de dados escolhida para o reposit¨®rio da monitora??o for o PostgreSQL.
sqlite3 Necess¨¢rio se a tecnologia de banco de dados escolhida para o reposit¨®rio da monitora??o for o SQLite.

O Áú»¢¶Ä²© tamb¨¦m poder¨¢ funcionar em vers?es anteriores do Apache, MySQL, Oracle, e PostgreSQL.

Para outras fontes como a default DejaVu, a fun??o PHP poder¨¢ ser necess¨¢ria. Se estiver ausente, estas fontes poder?o n?o ser corretamente renderizadas no cabe?alho da vis?o geral da monitora??o (Monitora??o ¡ú Overview) e em outros locais. Esta fun??o s¨® est¨¢ dispon¨ªvel se o PHP for compilado com o suporte ao GD, o que n?o ¨¦ o caso para o Debian e outras distribui??es.

O suporte a Cookies e Java Script dever¨¢ estar habilitado.
?ltimas vers?es do Google Chrome, Mozilla Firefox, Microsoft Internet Explorer e Opera s?o suportadas. Outros navegadores (Apple Safari, Konqueror) tamb¨¦m poder?o funcionar.

Áú»¢¶Ä²© Server

Os requisitos obrigat¨®rios s?o sempre necess¨¢rios, os opcionais s?o necess¨¢rios quando utilizar alguma fun??o espec¨ªfica.

Requirement Description
OpenIPMI Necess¨¢rio para o suporte a IPMI.
libssh2 Necess¨¢rio para o suporte ao SSH, na vers?o 1.0 ou superior.
fping Necess¨¢rio para o suporte a itens de ping ICMP.
libcurl Necess¨¢rio para o suporte a verifica??o web, monitora??o de m¨¢quinas virtuais VMWare e SMTP autenticado. Para o SMTP autenticado ¨¦ necess¨¢rio no m¨ªnimo a vers?o 7.20.0.
libiksemel Necess¨¢rio para o suporte a envio de mensagens instant?neas / Jabber.
net-snmp Necess¨¢rio para o suporte ao SNMP.
Áú»¢¶Ä²© Java Gateway

Se voc¨º instalou atrav¨¦s do c¨®digo fonte, as depend¨ºncias necess¨¢rias foram atendidas durante a instala??o (pois elas s?o verificadas durante o processo de compila??o).

Se voc¨º instalou o Áú»¢¶Ä²© atrav¨¦s dos pacotes distribu¨ªdos, as depend¨ºncias foram resolvidas durante o processo de instala??o.

Em ambos os casos o software est¨¢ pronto para uso e n?o requer downloads adicionais.

Se, por qualquer motivo, voc¨º deseja fornecer as suas pr¨®prias vers?es destas depend¨ºncias (por exemplo, se voc¨º est¨¢ preparando um novo pacote para alguma distribui??o do Linux), a lista a seguir lista as bibliotecas e vers?es que j¨¢ testamos o funcionamento. ? poss¨ªvel que o Áú»¢¶Ä²© funcione tamb¨¦m com outras vers?es.

A tabela a seguir lista os arquivos JAR que s?o empacotados atualmente em conjunto com o Áú»¢¶Ä²© Java Gateway:

Biblioteca Licen?a Site °ä´Ç³¾±ð²Ô³Ù¨¢°ù¾±´Ç²õ
logback-core-0.9.27.jar EPL 1.0, LGPL 2.1 Testado com 0.9.27, 1.0.13, e 1.1.1.
logback-classic-0.9.27.jar EPL 1.0, LGPL 2.1 Testado com 0.9.27, 1.0.13, e 1.1.1.
slf4j-api-1.6.1.jar MIT License Testado com 1.6.1, 1.6.6, e 1.7.6.
android-json-4.3_r3.1.jar Licen?a Apache 2.0 Testado com 2.3.3_r1.1 e 4.3_r3.1. Veja src/zabbix_java/lib/README por instru??es sobre como criar um arquivo JAR.

O Áú»¢¶Ä²© Java Gateway ¨¦ compil¨¢vel e execut¨¢vel com o Java 1.6 ou superior. ? recomend¨¢vel que se forne?a uma vers?o pr¨¦-compilada do mesmo de modo a permitir que outras vers?es do Java tamb¨¦m possam ser utilizadas.

Tamanho do Banco de Dados

Os dados de configura??o do Áú»¢¶Ä²© requerem um tamanho praticamente fixo de espa?o em disco pois n?o crescem de forma significativa.

O tamanho do banco de dados do Áú»¢¶Ä²© depende, principalmente, do per¨ªodo de reten??o dos dados coletados (hist¨®rico e m¨¦dias). O primeiro ponto a se observar ¨¦:

  • A quantidade de novos valores processados por segundo (Values Per Second / VPS)

Esta ¨¦ a quantidade m¨¦dia de novos valores (chaves de itens coletadas) que o Áú»¢¶Ä²© Sever recebe a cada segundo. Por exemplo, se n¨®s temos 3000 itens para monitorar com um intervalo de coleta de 60 segundos, a quantidade de itens por segundo pode ser calculada conforme a seguir:

3000/60 = **50**.

Isso significa que 50 novos valores (50 novos registros) ser?o adicionados no banco de dados a cada segundo.

  • Configura??es do hist¨®rico no Housekeeper

O Áú»¢¶Ä²© guarda os valores por um per¨ªodo fixo de tempo, normalmente v¨¢rias semanas ou meses. Cada novo valor precisa de uma quantidade determinada de espa?o em disco para guardar o dado (seu valor) e os ¨ªndices associados ao registro.

Logo, se n¨®s queremos manter por 30 dias o hist¨®rico e recebemos 50 novos valores por segundo, podemos obter o total de valores atrav¨¦s de um simples c¨¢lculo (30*24*3600)* 50 = 129.600.000, ou cerca de 130M de valores.

Dependendo do SGBD utilizado, do tipo do valor (ponto flutuante, inteiro, caractere, log, etc), a quantidade necess¨¢ria de disco para armazenar um simples valor pode variar de 40 bytes para centenas de bytes. Normalmente ¨¦ algo em torno de 90 bytes por valor. Em nosso caso, isso quer dizer que os quase 130.000 valores ir?o precisar de cerca de 10.9GB de espa?o em disco (130M * 90 bytes = 10.9GB).

<?note>Observe que ¨¦ imposs¨ªvel prever o tamanho ocupado pelos campos do tipo texto ou log, mas estimamos algo em torno de 500 bytes por valor (m¨¦dia com grande margem de erro).</?note>?

  • Configura??es das m¨¦dias no Housekeeper

A cada hora o Áú»¢¶Ä²© guarda um kit de valores (max/min/avg/count) para cada item coletado que possua configura??o de m¨¦dias. Estes dados s?o salvos nas tabelas trends. Estes dados s?o utilizados para agilizar a constru??o de gr¨¢ficos em longos per¨ªodos. O intervalo das m¨¦dias n?o pode ser customizado.

Dependendo do tipo do SGDB cada registro de m¨¦dia consumir¨¢ cerca de 90 bytes.

Suponha que n¨®s precisemos guardar os dados de m¨¦dias por 5 anos. Os valores dos 3000 itens agora ir?o requerer 3000*24*365* 90 = 2.2GB por ano, ou 11GB para 5 anos.

  • Configura??es de eventos no Housekeeper

Cada evento no Áú»¢¶Ä²© requer aproximadamente 170 bytes de espa?o em disco. ? muito dif¨ªcil estimar a quantidade de eventos gerada pelo Áú»¢¶Ä²© Sever por dia. No pior cen¨¢rio n¨®s recomendamos assumir que o Áú»¢¶Ä²© gere um evento por segundo.

Isso significa que se n¨®s precisarmos manter 3 anos de eventos, isso ir¨¢ requerer 3*365*24*3600* 170 = 15GB .

A tabela a seguir cont¨ºm as f¨®rmulas utilizadas para calcular o espa?o em disco aproximado que ser¨¢ requerido pela solu??o Áú»¢¶Ä²©:

Par?metro F¨®rumla de c¨¢lculo de disco (em bytes)
Configura??o do Áú»¢¶Ä²© Tamanho fixo. Estimado em 10MB ou menos.
±á¾±²õ³Ù¨®°ù¾±³¦´Ç dias*(items/intervalo de coleta)*24*3600*bytes
items : quantidade de items
dias : quantidade em dias da reten??o do hist¨®rico
intervalo de atualiza??o: tempo m¨¦dio entre coletas do item
bytes : quantidade de bytes necess¨¢ria para guardar cada valor. Varia entre os SGDBs, mas normalmente ¨¦ de aproximadamente 90 bytes.

AQUI

²Ñ¨¦»å¾±²¹²õ dias*(items/3600)*24*3600*bytes
items : quantidade de items
dias : quantidade em dias da reten??o das m¨¦dias
bytes : quantidade de bytes necess¨¢ria para guardar cada valor. Varia entre os SGDBs, mas normalmente ¨¦ de 128 bytes.
Eventos dias*eventos*24*3600*bytes
eventos : quantidade de eventos por segundo. Um (1) evento por segundo no pior caso.
dias : quantidade em dias da reten??o de eventos
bytes : quantidade de bytes necess¨¢ria para guardar cada valor. Varia entre os SGDBs, mas normalmente ¨¦ de aproximadamente 170 bytes.

<?note>Os valores m¨¦dios (90 bytes para itens num¨¦ricos e 170 para eventos) foram obtidos atrav¨¦s de estat¨ªsticas em cen¨¢rios reais de ambientes monitorados pelo Áú»¢¶Ä²© utilizando como SGDB o MySQL.</?note>?

Ent?o, o total de espa?o em disco pode ser obtido atrav¨¦s da f¨®rmula a seguir:

Configura??o + ±á¾±²õ³Ù¨®°ù¾±³¦´Ç + ²Ñ¨¦»å¾±²¹²õ + Eventos

? claro que estes c¨¢lculos n?o pretendem obter o espa?o em disco utilizado logo ap¨®s o in¨ªcio da monitora??o e sim o m¨¢ximo de disco que o Banco ir¨¢ precisar consumir para guardar os dados do Áú»¢¶Ä²©.

Sincroniza??o de hora

? muito importante que voc¨º tenha um sistema preciso de sincronismo de hora entre todos os servidores monitorados, inclusive o Áú»¢¶Ä²©. O ¨¦ o deamon mais popular para sincronizar o hor¨¢rio de todo o ambiente.

Se os hor¨¢rios n?o estiverem sincronizados o Áú»¢¶Ä²© ir¨¢ converter as marcas de tempo de os dados recolhidos no servidor Áú»¢¶Ä²© utilizando timestamps do cliente / servidor depois de estabelecer a conex?o de dados e ajustar a data e hora do valor do item recebido pela diferen?a de tempo entre o cliente e o servidor. Para manter este processo mais simples e evitar poss¨ªveis complica??es a lat¨ºncia da conex?o ¨¦ ignorada. Os dados de lat¨ºncia da conex?o ser?o adicionados ¨¤s marcas de tempo de dados adquiridos a partir de conex?es ativas (agente ativo, Proxy ativa, o remetente) e subtra¨ªdo da data e hora dos dados obtidos atrav¨¦s de conex?es passivas (proxy passivo). Todas as demais verifica??es s?o feitas usando como refer¨ºncia o hor¨¢rio do servidor e, neste caso, n?o ocorrem ajustes.