Guia de configuração de monitoramento de banco de dados

Antes de começar

Verificações de Database não rodam a partir da rede pública distribuída de monitoramento da HostTracker como uma verificação Http ou Ping roda, então esse formulário não tem nenhuma seção de Localidades de Monitoramento. Em vez disso, toda verificação disca para o seu servidor a partir da própria infraestrutura de verificação privada da HostTracker, usando dois endereços de origem fixos: 4.207.101.172 e 20.107.152.200 (Norte da Europa). Antes de salvar o monitor, adicione os dois endereços à lista de permissões do firewall ou grupo de segurança do seu servidor de banco de dados, e certifique-se de que o servidor aceita conexões na porta dele a partir da internet pública, ou pelo menos a partir desses dois endereços. Se a porta não estiver acessível, toda verificação falha com um erro de conexão, independentemente de como o resto do monitor esteja configurado.

Configure a própria conta de monitoramento antes de começar: crie um usuário de banco de dados dedicado à verificação, conceda a ele só o que a verificação precisa (tipicamente só a capacidade de conectar, mais SELECT na tabela que a sua consulta toca), e evite reutilizar uma conta de aplicação ou de administrador. Se a consulta que você planeja rodar muda dados, dê a essa conta acesso de escrita só à tabela específica envolvida, nada mais amplo.

Banco de dados alvo

Três campos identificam a que a verificação se conecta, e ficam acima das seções recolhíveis já que são obrigatórios:

• Tipo de servidor - um menu suspenso dos provedores suportados: Microsoft SQL Server, Oracle, MySQL, PostgreSQL e Firebird.
• Servidor : Porta - o nome de host ou IP do servidor de banco de dados, e a porta dele. Mudar o tipo de servidor preenche automaticamente a porta padrão convencional daquele provedor (1433 para SQL Server, 1521 para Oracle, 3306 para MySQL, 5432 para PostgreSQL, 3050 para Firebird) - você só precisa substituí-la se o seu servidor escuta em outro lugar.
• Banco de dados (ou, para Oracle, Service e Nome da instância (SID) em vez disso) - o nome do banco de dados para conectar. Para Oracle você pode fornecer o nome do serviço, o SID, ou ambos, dependendo de como o seu listener está configurado.

Abaixo disso, um campo opcional de Nome permite rotular o monitor para alertas, relatórios e widgets - útil assim que você tiver mais de uma verificação de database e precisar diferenciá-las rapidamente.

Configurações Principais

Esse grupo guarda a agenda e as duas chaves de uso geral que todo tipo de verificação compartilha:

• Intervalo - com que frequência a verificação roda, oferecido de 10 minutos até 24 horas (10, 15, 30, 45 minutos, depois 1, 2, 4, 6, 12 e 24 horas), mais uma alternativa de agenda cron para horários menos regulares. Verificações de Database não oferecem os intervalos abaixo de 10 minutos que alguns outros tipos de verificação oferecem.
• Tags - rótulos de texto livre para agrupar e filtrar monitores em outros lugares do painel.
• Log Completo - salva todo resultado individual de verificação em vez de só resumos agrupados, útil quando você precisa ver os tempos de resposta ou valores exatos ao longo do tempo em vez de só o histórico de no-ar/fora-do-ar.
• Estatísticas Abertas - torna a página de estatísticas e log desse monitor compartilhável, inclusive com pessoas que não estão logadas.

Conexão

Com o alvo já definido acima, essa seção cobre como a verificação se autentica e como ela trata uma tentativa de conexão falhada:

• Nome de usuário do banco e Senha do usuário do banco - as credenciais da conta de monitoramento descrita acima. As duas são opcionais: deixe em branco se o seu banco de dados permite uma conexão de confiança ou anônima a partir de um endereço na lista de permissões, o que algumas configurações internas fazem.
• O próprio painel exibe os dois endereços de origem a partir dos quais as verificações são feitas (4.207.101.172, 20.107.152.200) com um lembrete para incluí-los na lista de permissões do firewall do seu banco de dados - essa é a mesma exigência coberta em Antes de começar, repetida aqui porque é exatamente onde as credenciais vivem.
• Tentar novamente em falha de conexão - uma chave, ativada por padrão, que tenta a conexão de novo uma vez antes de marcar a verificação como falhada. Só cobre a própria etapa de conexão, não a consulta.

Validação de Resposta

Essa é a decisão chave em uma verificação de Database: se você está testando que a conexão funciona, ou que uma consulta específica ainda se comporta como esperado.

• Consulta - deixe em branco e a verificação só testa a conexão: ela abre, e fecha, e isso é a verificação inteira. Preencha com qualquer SQL que a sua conta de monitoramento tem permissão para rodar - um SELECT, ou uma instrução que muda dados como UPDATE, DELETE ou INSERT - e a verificação a roda em toda consulta e pode julgar o resultado.
• Resultado da consulta (só mostrado assim que uma consulta é digitada) - escolha Valor escalar para ler o que está na primeira coluna da primeira linha devolvida (a escolha natural para um SELECT, ou para um UPDATE/INSERT que usa uma cláusula OUTPUT), ou Contagem de linhas para ler quantas linhas foram afetadas (a escolha natural para um UPDATE, DELETE ou INSERT simples sem conjunto de resultado próprio).
• Verificação do resultado - uma comparação para aplicar àquele valor: Sem verificação (a consulta só precisa rodar sem erro), Igual a, Diferente de, Maior que, Menor que, Dentro do intervalo, ou Fora do intervalo. As opções de maior/menor que e intervalo adicionam um ou dois campos numéricos, com uma chave de incluído/excluído em cada limite do intervalo.
• Tentar consulta novamente em erro - uma chave, ativada por padrão, que tenta a execução da consulta de novo uma vez se falhar, separada da tentativa no nível de conexão acima.

Escolha só conexão quando você só precisa saber que o banco de dados está acessível e aceitando conexões - isso pega indisponibilidades diretas. Escolha uma consulta com verificação de resultado quando a acessibilidade sozinha perderia o problema real: uma tabela que parou de receber linhas novas, uma contagem armazenada saindo de uma faixa normal, ou um dado específico que deveria sempre estar presente.

Inscrições de Alerta

Escolha quais contatos são avisados sobre esse monitor e para quais eventos - No Ar, Fora do Ar e Repetir (um lembrete repetido enquanto a verificação continua fora do ar). Uma única chave inscreve todo contato em No Ar/Fora do Ar de uma vez, ou você pode escolher contatos e eventos individuais na tabela abaixo dela.

Inscrições de Relatório

Separadamente dos alertas, escolha quem recebe relatórios periódicos de uptime e desempenho para esse monitor - Diário, Semanal ou Mensal - por e-mail.

Exemplo prático

Observando um banco de dados PostgreSQL de produção do qual uma aplicação depende: Tipo de servidor PostgreSQL, Servidor : Porta db.example.com:5432, Banco de dados myapp_prod. Uma conta dedicada somente leitura é digitada em Conexão, e os dois IPs de origem são adicionados ao grupo de segurança do banco de dados primeiro. O campo Consulta guarda SELECT COUNT(*) FROM orders WHERE created_at > now() - interval '1 hour', Resultado da consulta é Valor escalar, e Verificação do resultado é Maior que com um limite de 0 - se nenhum pedido foi registrado na última hora, algo upstream parou de escrever, e a verificação fica Fora do Ar mesmo com o banco de dados acessível. O Intervalo é 15 minutos, as duas chaves de Tentar novamente continuam ativadas para que uma falha passageira não dispare um alerta falso, os alertas vão para a inscrição No Ar/Fora do Ar da equipe inteira, e um relatório semanal vai para o dono da conta.

Solução de problemas

• Toda verificação falha com um erro de conexão. A causa mais comum é um firewall que não foi aberto para os dois endereços de origem da HostTracker - confirme que 4.207.101.172 e 20.107.152.200 estão na lista de permissões, e que a própria porta está aberta para eles.
• A conexão tem sucesso mas a autenticação falha. Verifique se o nome de usuário e a senha do banco estão corretos e se a conta tem permissão para conectar ao banco de dados nomeado, não só ao servidor.
• Uma consulta que funciona bem em uma ferramenta cliente não devolve nada aqui. Um UPDATE, DELETE ou INSERT simples sem cláusula OUTPUT não tem conjunto de resultado para ler como Valor escalar - mude o Resultado da consulta para Contagem de linhas, ou adicione uma cláusula OUTPUT se você precisa dos dados da linha de volta.
• A verificação do resultado nunca dispara. Confirme se a comparação e os campos numéricos batem com a faixa que você espera: um limite definido como excluído em vez de incluído é uma forma fácil de fazer um limite nunca disparar.
• Falhas únicas ocasionais que você suspeita serem passageiras. As duas chaves de tentar novamente estão ativadas por padrão e já tentam de novo uma vez antes de falhar a verificação - se as falhas ainda são frequentes, o problema é mais provavelmente uma questão real de conectividade ou consulta do que ruído.

Relacionados

• Monitoramento de consulta de banco de dados - a página de produto para esse tipo de verificação.
• Guia de monitoramento de CPU, RAM e disco - outra verificação que roda a partir da infraestrutura privada da HostTracker em vez da rede pública, útil junto com uma verificação de database no mesmo servidor.
• Guia de monitoramento SNMP - para ler valores diretamente de hardware de rede em vez de um banco de dados.
• Modo de asserções e regras de validação de resposta - a linguagem de regras de validação de resposta usada em outros lugares nos tipos de verificação da HostTracker.
• Todos os recursos de monitoramento da HostTracker - veja todo tipo de verificação lado a lado.
• 503 Service Unavailable - o status que um site devolve quando o banco de dados por trás dele para de responder.
• Todos os guias de monitoramento - o guia de configuração para todo outro tipo de verificação.