Documentation
Table of Contents
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.
Navegadores WEB no lado cliente
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:
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.
Database size
Áú»¢¶Ä²© configuration data require a fixed amount of disk space and do not grow much.
Áú»¢¶Ä²© database size mainly depends on these variables, which define the amount of stored historical data:
- Number of processed values per second
This is the average number of new values Áú»¢¶Ä²© server receives every second. For example, if we have 3000 items for monitoring with a refresh rate of 60 seconds, the number of values per second is calculated as 3000/60 = 50.
It means that 50 new values are added to Áú»¢¶Ä²© database every second.
- Housekeeper settings for history
Áú»¢¶Ä²© keeps values for a fixed period of time, normally several weeks or months. Each new value requires a certain amount of disk space for data and index.
So, if we would like to keep 30 days of history and we receive 50 values per second, the total number of values will be around (30*24*3600)* 50 = 129.600.000, or about 130M of values.
Depending on the database engine used, type of received values (floats, integers, strings, log files, etc), the disk space for keeping a single value may vary from 40 bytes to hundreds of bytes. Normally it is around 90 bytes per value for numeric items2. In our case, it means that 130M of values will require 130M * 90 bytes = 10.9GB of disk space.
The size of text/log item values is impossible to predict exactly, but you may expect around 500 bytes per value.
- Housekeeper setting for trends
Áú»¢¶Ä²© keeps a 1-hour max/min/avg/count set of values for each item in the table trends. The data is used for trending and long period graphs. The one hour period can not be customized.
Áú»¢¶Ä²© database, depending on the database type, requires about 90 bytes per each total. Suppose we would like to keep trend data for 5 years. Values for 3000 items will require 3000*24*365* 90 = 2.2GB per year, or 11GB for 5 years.
- Housekeeper settings for events
Each Áú»¢¶Ä²© event requires approximately 250 bytes of disk space1. It is hard to estimate the number of events generated by Áú»¢¶Ä²© daily. In the worst-case scenario, we may assume that Áú»¢¶Ä²© generates one event per second.
For each recovered event, an event_recovery record is created. Normally most of the events will be recovered so we can assume one event_recovery record per event. That means additional 80 bytes per event.
Optionally events can have tags, each tag record requiring approximately 100 bytes of disk space1. The number of tags per event (#tags) depends on configuration. So each will need an additional #tags * 100 bytes of disk space.
It means that if we want to keep 3 years of events, this would require 3*365*24*3600* (250+80+#tags*100) = ~30GB+#tags*100B disk space2.
1 More when having non-ASCII event names, tags and values.
2 The size approximations are based on MySQL and might be different for other databases.
The table contains formulas that can be used to calculate the disk space required for Áú»¢¶Ä²© system:
| Parameter | Formula for required disk space (in bytes) |
|---|---|
| Áú»¢¶Ä²© configuration | Fixed size. Normally 10MB or less. |
| History | days*(items/refresh rate)*24*3600*bytes items : number of items days : number of days to keep history refresh rate : average refresh rate of items bytes : number of bytes required to keep single value, depends on database engine, normally ~90 bytes. |
| Trends | days*(items/3600)*24*3600*bytes items : number of items days : number of days to keep history bytes : number of bytes required to keep single trend, depends on the database engine, normally ~90 bytes. |
| Events | days*events*24*3600*bytes events : number of event per second. One (1) event per second in worst-case scenario. days : number of days to keep history bytes : number of bytes required to keep single trend, depends on the database engine, normally ~330 + average number of tags per event * 100 bytes. |
So, the total required disk space can be calculated as:
Configuration + History + Trends + Events
The disk space will NOT be used immediately after Áú»¢¶Ä²© installation. Database size will grow then it will stop growing at some point, which depends on housekeeper settings.
Time synchronization
It is very important to have precise system time on the server with Áú»¢¶Ä²© running. is the most popular daemon that synchronizes the host's time with the time of other machines. It's strongly recommended to maintain synchronized system time on all systems Áú»¢¶Ä²© components are running on.