infraestrutura como código
Monitoramento de uptime que você declara no Terraform
Provisione um monitor do mesmo jeito que provisiona o serviço que ele monitora. O provider do Uptimepage gerencia monitores, páginas de status, componentes e canais de notificação em HCL, então cada serviço novo já sai com monitoramento, em vez de um ticket para depois.
O monitoramento sai junto com o serviço
Declare o monitor ao lado do recurso que ele monitora, no mesmo repositório e no mesmo apply. Cada serviço novo ganha uma verificação desde o momento em que existe, em vez de um ticket para depois que alguém fecha três sprints mais tarde. E quando você sobe uma região nova, reproduz quarenta monitores com um único apply, em vez de passar quarenta tardes clicando.
Revise como qualquer outra mudança
Abra qualquer painel de monitoramento e conte as verificações que ninguém sabe explicar. A do intervalo de 47 segundos: por que 47? As duas que ainda apontam para uma máquina de staging desativada em março. Configuração criada no clique apodrece, porque o raciocínio vai embora com quem a fez. Num repositório, cada mudança é um pull request: “por que estamos reduzindo o intervalo da verificação de pagamentos?” é uma conversa melhor de ter na revisão do que num postmortem, e o git blame lembra a resposta depois que o autor segue em frente.
Um esquema que recusa o absurdo
O bloco check do provider é aninhado de propósito: você define o type como "http" e depois preenche um bloco http. Um recurso plano com url, port, host e cert_days todos no nível superior deixaria você escrever uma verificação TCP com um matcher de status HTTP e só avisaria na hora do apply. O formato aninhado torna impossível escrever esses estados inválidos. Um pouco mais verboso, e uma categoria inteira de erro desaparece. O tipo heartbeat é a exceção que vale conhecer: nada é enviado a ele, então a URL para a qual o seu cron job reporta não é um argumento que você define, mas um valor que você lê de volta, pelo data source uptimepage_heartbeat.
Depois que está em código, o código manda
Existe uma troca, e vale conhecê-la de antemão: depois que um monitor está no Terraform, o painel deixa de ser a fonte da verdade. Mude um intervalo à mão e o próximo plan propõe revertê-lo; rode terraform plan -refresh-only para ver o drift antes que ele pegue você de surpresa. E apagar o bloco do recurso apaga o monitor real, sem aviso. Trate uma verificação removida com a mesma desconfiança que uma tabela apagada, porque você não vai perceber até que quebre aquilo que você deixou de monitorar.
Trate o arquivo de estado como um segredo
Se uma verificação precisa de autenticação básica, essa senha chega ao provider pela sua configuração, e o estado do Terraform tem memória longa: qualquer coisa persistida ali pode ser lida por qualquer pessoa que consiga ler o backend. O provider marca a senha como sensível, o que a mantém fora da saída do plan, mas não fora do próprio arquivo de estado, então a proteção real é um backend de estado criptografado com acesso restrito. O Terraform 1.11 adicionou argumentos write-only, valores que nunca são persistidos, e eles são a resposta certa a longo prazo para as credenciais das verificações.
Tokens que fazem uma só coisa
Uma execução do Terraform não deveria carregar uma credencial que pode tudo. Os tokens têm escopo de um recurso e uma ação, são vinculados a uma organização e têm validade obrigatória, então o token no seu pipeline pode criar monitores sem também conseguir apagar a sua organização.
Declare um monitor no Terraform
terraform {
required_providers {
uptimepage = {
source = "uptimepage/uptimepage"
}
}
}
resource "uptimepage_target" "api" {
name = "api prod"
interval = 60
check = {
type = "http"
http = {
url = "https://example.com/healthz"
expected_status = {
kind = "exact"
exact = 200
}
}
}
}Perguntas frequentes
Qual provider eu uso?
O que posso declarar no Terraform?
Preciso do serviço hospedado?
Como o provider se autentica?
Visão geral
- Provider do Terraform uptimepage/uptimepage
- Recursos monitores, páginas, componentes, canais
- Tipos de verificação HTTP, TCP, ping, heartbeat, DNS, TLS, domínio, flow, manual
- Intervalo de verificação a partir de 60 s, mínimos maiores nas verificações de vencimento
- Autenticação tokens de API com escopo e validade
- Preço para começar grátis, sem cartão