> ## Documentation Index
> Fetch the complete documentation index at: https://docs.appsignal.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Monitoramento de uptime
Com o monitoramento de uptime do AppSignal, você pode receber alertas quando sua aplicação estiver fora do ar.
Verificamos sua aplicação a partir de várias regiões pelo mundo, e avisaremos você quando sua aplicação não puder ser alcançada a partir de nenhuma dessas regiões. Também plotamos o desempenho do endpoint que você fornece a partir de diferentes regiões do mundo.
## Configuração
Para configurar uma nova verificação de monitor de uptime, clique no botão "Add uptime monitor" na página de [Monitoramento de Uptime](https://appsignal.com/redirect-to/app?to=uptime_monitors).
Forneça a URL completa (incluindo `http://` ou `https://`) da página que você gostaria de verificar. Nossos servidores farão uma requisição para essa URL a cada minuto a partir de várias regiões e reportarão se a requisição falhar ou se o código de status da resposta não estiver no intervalo `2xx`.
Para receber notificações quando sua aplicação estiver fora do ar, selecione um método de notificação. Para evitar receber alertas em pequenas instabilidades de rede, recomendamos definir um período de warm-up de alerta de pelo menos um minuto.
Você pode definir headers a serem enviados nas requisições que realizamos para a URL fornecida. Isso permite que você defina headers de autorização para permitir que as requisições passem.
## Como funciona
Pingamos suas aplicações a partir de workers do AWS Lambda que são executados a partir das seguintes regiões:
Faremos requisições à URL fornecida a partir das seguintes regiões:
* Ásia-Pacífico (Seul)
* Europa (Frankfurt)
* América do Norte (N. Virginia)
* América do Sul (São Paulo)
Há um timeout de 30 segundos para a conexão. Se seu servidor não responder dentro desse intervalo, consideramos a aplicação como fora do ar.
Note que se nossas requisições à sua aplicação estiverem falhando a partir de uma única região, isso não significa necessariamente que sua aplicação está fora do ar. Pode, em vez disso, indicar um problema de rede entre o AWS Lambda e seu endpoint.
### User Agent
As requisições do nosso monitoramento de uptime para sua aplicação definirão o header `User-Agent` da seguinte forma, onde `` é um número de versão como `1.0`:
```sh Shell theme={null}
AppSignalBot/ (+https://appsignal.com)
```
Isso permite detectar as requisições vindas do AppSignal.
### Allowlist de IPs
Executamos nossas verificações de uptime em um framework serverless e não temos controle sobre qual endereço IP será usado para fazer a requisição à sua aplicação. Portanto, não conseguimos fornecer uma lista de endereços IP para colocar em allowlist. A URL a ser monitorada deve estar acessível publicamente a partir da internet aberta.
## Métricas
Para cada verificação de monitor de uptime, criamos várias métricas que você pode usar para criar seus próprios [gráficos personalizados](/metrics/custom#graphing-custom-metrics) e definir seus próprios [gatilhos de detecção de anomalias](/anomaly-detection#creating-and-configuring-triggers).
Essas métricas serão marcadas pela **região** de onde a requisição foi feita, e pelo **nome** da verificação do monitor de uptime. As tags de região são `asia-pacific`, `europe`, `north-america` e `south-america`.
### Contagem de erros
A métrica `uptime_monitor_error_count` é um contador que, para um determinado minuto, será definido como zero se a requisição for bem-sucedida ou como um se a requisição falhar.
### Desempenho do endpoint
A métrica `uptime_monitor_duration` é um gauge que rastreia a duração da requisição para cada região. Isso permite que você veja se a latência para seus servidores está aumentando.
## Planos e Requisições
Se a aplicação que serve a URL usar uma integração do AppSignal, nosso monitor de uptime pode consumir muitas das requisições mensais do seu plano. Recomendamos configurar um endpoint dedicado de health-check e configurar o AppSignal para ignorar requisições a esse endpoint para que elas não contem no limite do seu plano.
### Exemplo
Aqui está um exemplo de endpoint de health-check em Ruby on Rails. Garantimos atingir todos os nossos serviços externos, como o banco de dados e o Redis, algo que pode não acontecer na página inicial, garantindo que todos os serviços estejam operacionais.
```ruby Ruby theme={null}
# routes.rb
resource :health_check, :only => :show
```
```ruby Ruby theme={null}
# health_checks_controller.rb
class HealthChecksController < ApplicationController
def show
# Check MongoDB
Account.mongo_client.command(:getLastError => 1)
# Check Redis
Redis.new.ping
head 200
rescue Mongo::Error, Redis::CannotConnectError
head 503
end
end
```
Em seguida, configuramos o AppSignal para ignorar requisições a esse endpoint usando [a opção de configuração `ignore_actions`](/ruby/configuration/options#option-ignore_actions):
```ruby Ruby theme={null}
Appsignal.configure do |config|
config.ignore_actions << "HealthChecksController#show"
end
```
```yaml YAML theme={null}
default: &defaults
ignore_actions:
- HealthChecksController#show
```