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!)
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.
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.
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.
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:
O Áú»¢¶Ä²© poder¨¢ rodar em v¨¢rias outras variantes do UNIX.
O Áú»¢¶Ä²© ¨¦ constru¨ªdo em torno do servidor de p¨¢ginas Apache, SGDBs l¨ªderes de mercado e a linguagem de scripts PHP.
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!
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.
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. |
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.
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 ¨¦:
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:
Isso significa que 50 novos valores (50 novos registros) ser?o adicionados no banco de dados a cada segundo.
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>?
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.
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 Áú»¢¶Ä²©.
? 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.