![\"Mascote](\"\/wp-content\/uploads\/2026\/09\/go-uptime-monitoramento-v1.webp\")
<\/p>\n<\/p>\n
O Gatus<\/a> \u00e9 \u00f3timo para monitoramento como c\u00f3digo, mas deixa de fora duas coisas que muita equipe pede: cadastrar um monitor pela web sem editar o YAML, e publicar uma p\u00e1gina de status aberta enquanto o painel continua protegido. O Go Uptime<\/strong> nasceu para cobrir essas lacunas. \u00c9 um projeto derivado do Gatus, em um \u00fanico bin\u00e1rio Go, que mant\u00e9m a configura\u00e7\u00e3o em YAML e acrescenta administra\u00e7\u00e3o web, p\u00e1ginas de status p\u00fablicas, push compat\u00edvel com o Uptime Kuma, MySQL\/MariaDB, tela de login e backup. Neste guia, voc\u00ea vai ver o que muda em rela\u00e7\u00e3o ao Gatus, subir o Go Uptime com Docker ou systemd e configurar cada recurso novo.<\/p>\n <\/p>\n O Go Uptime<\/a> come\u00e7ou em 2026 como fork do Gatus<\/a>, de TwiN, a partir de um commit de 8 de setembro de 2026. Desde a A licen\u00e7a continua a mesma do original, Apache 2.0<\/strong>. O arquivo Tudo o que o Gatus faz continua l\u00e1: checagens HTTP, ICMP, TCP, DNS e outras, condi\u00e7\u00f5es sobre status, tempo de resposta, corpo e certificado, janelas de manuten\u00e7\u00e3o, su\u00edtes e mais de 40 provedores de alerta. Por cima disso, o projeto acrescenta:<\/p>\n Se voc\u00ea quer uma interface para tudo e n\u00e3o se importa com Node.js, o Uptime Kuma<\/a> continua sendo uma boa escolha. O Go Uptime fica no meio do caminho: YAML versionado no Git para o que \u00e9 est\u00e1vel, web para o que muda toda semana.<\/p>\n A imagem fica no Docker Hub<\/a>, para Abra Para manter o hist\u00f3rico e ligar a administra\u00e7\u00e3o, s\u00e3o necess\u00e1rios tr\u00eas blocos: um armazenamento SQL, um login e O comando imprime o hash bcrypt em base64 esperado em E o Antes de subir, valide a configura\u00e7\u00e3o. O A sa\u00edda esperada \u00e9 algo como:<\/p>\n Com Os exemplos do reposit\u00f3rio<\/a> sobem com a administra\u00e7\u00e3o ligada, usu\u00e1rio Com o login configurado, As abas Status pages<\/strong>, Push keys<\/strong> e Backup<\/strong> ficam na mesma tela. O backup baixa um JSON com endpoints, p\u00e1ginas de status e chaves de push. Esse arquivo inclui tokens, senhas e cabe\u00e7alhos; por isso existe a op\u00e7\u00e3o de cifrar com senha (AES-256-GCM). Na restaura\u00e7\u00e3o, a tela mostra uma pr\u00e9via do que vai mudar antes de aplicar.<\/p>\n Para cadastrar muitos hosts de uma vez, o reposit\u00f3rio traz o script Uma p\u00e1gina de status mostra s\u00f3 os grupos e endpoints escolhidos, sem login, enquanto o dashboard, a administra\u00e7\u00e3o e a API continuam protegidos. Cada endpoint aparece com o estado atual, as barras das \u00faltimas checagens e o uptime de 24 horas, 7 dias e 30 dias. Clicar no nome abre uma p\u00e1gina de detalhes com o gr\u00e1fico de tempo de resposta.<\/p>\n A chave de um endpoint \u00e9 Um detalhe de seguran\u00e7a que a documenta\u00e7\u00e3o deixa expl\u00edcito: o limite Nem tudo pode ser checado de fora. Um backup noturno, um job de cron ou um servi\u00e7o atr\u00e1s de firewall precisam avisar<\/em> que rodaram. No Go Uptime, isso \u00e9 um endpoint Push: ele n\u00e3o checa nada, apenas registra os avisos, e marca falha quando o intervalo de heartbeat<\/em> passa sem nenhum push.<\/p>\n No fim do script de backup, uma linha basta:<\/p>\n A resposta \u00e9 O formato \u00e9 o mesmo dos monitores Push do Uptime Kuma: um script que j\u00e1 faz push para o Kuma funciona trocando s\u00f3 o endere\u00e7o do servidor. Al\u00e9m do token por endpoint, a aba Push keys<\/strong> cria chaves globais<\/strong> ( Os provedores de alerta s\u00e3o os do Gatus: Slack, Telegram, Discord, Teams, Mattermost, PagerDuty, e-mail, webhooks personalizados e dezenas de outros. Um exemplo com Telegram, avisando tamb\u00e9m quando o servi\u00e7o volta:<\/p>\n O mesmo bloco SQLite atende bem uma inst\u00e2ncia \u00fanica. Quando o banco precisa ficar separado, o Go Uptime aceita O reposit\u00f3rio tem um exemplo completo em O Go Uptime \u00e9 um bin\u00e1rio est\u00e1tico, sem runtime nem bibliotecas. A instala\u00e7\u00e3o em Linux<\/a> coloca tudo em Bin\u00e1rio e configura\u00e7\u00e3o pertencem ao A unit vem endurecida: roda sem root, com O painel usa um fluxo de eventos em tempo real para atualizar as telas. Essa rota n\u00e3o pode ser bufferizada pelo proxy, e a conex\u00e3o fica aberta por minutos:<\/p>\n Vindo do Gatus original, o caminho \u00e9 trocar a imagem e reaproveitar o Vindo da s\u00e9rie Para monitorar o servidor por dentro (CPU, mem\u00f3ria, disco), o Go Uptime n\u00e3o substitui m\u00e9tricas: combine com Prometheus e Node Exporter<\/a>, que tamb\u00e9m pode coletar as m\u00e9tricas Se o seu time j\u00e1 gosta do Gatus e s\u00f3 sentia falta de uma p\u00e1gina de status p\u00fablica, de cadastrar um monitor sem abrir o servidor ou de acompanhar backups por push, o Go Uptime entrega isso sem trocar de ferramenta nem de configura\u00e7\u00e3o. O projeto \u00e9 novo, com releases frequentes: fixe a tag, rode Conoce Go Uptime, un derivado de Gatus en un \u00fanico binario Go, con administraci\u00f3n web, p\u00e1ginas de estado p\u00fablicas, push compatible con Uptime Kuma, MySQL\/MariaDB y backup. Instalaci\u00f3n con Docker y systemd.<\/p>","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[21,2,120,3],"tags":[156,467,58,31,126,203,465,123,464],"class_list":["post-1631","post","type-post","status-publish","format-standard","hentry","category-infra","category-linux","category-servidores","category-ubuntu","tag-docker","tag-gatus","tag-go","tag-golang","tag-monitoramento","tag-self-hosted","tag-status-page","tag-systemd","tag-uptime-kuma"],"_links":{"self":[{"href":"https:\/\/www.linuxpro.com.br\/es\/wp-json\/wp\/v2\/posts\/1631","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.linuxpro.com.br\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.linuxpro.com.br\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.linuxpro.com.br\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.linuxpro.com.br\/es\/wp-json\/wp\/v2\/comments?post=1631"}],"version-history":[{"count":1,"href":"https:\/\/www.linuxpro.com.br\/es\/wp-json\/wp\/v2\/posts\/1631\/revisions"}],"predecessor-version":[{"id":1633,"href":"https:\/\/www.linuxpro.com.br\/es\/wp-json\/wp\/v2\/posts\/1631\/revisions\/1633"}],"wp:attachment":[{"href":"https:\/\/www.linuxpro.com.br\/es\/wp-json\/wp\/v2\/media?parent=1631"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.linuxpro.com.br\/es\/wp-json\/wp\/v2\/categories?post=1631"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.linuxpro.com.br\/es\/wp-json\/wp\/v2\/tags?post=1631"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}De onde vem o Go Uptime<\/h2>\n
v6.0.0<\/code> ele segue caminho pr\u00f3prio: o servidor HTTP e a linha de comando foram reescritos. At\u00e9 a v6.3.0<\/code> o projeto era publicado como jniltinho\/gatus<\/code>. Na v7.0.0<\/code>, lan\u00e7ada em 21 de setembro de 2026, ganhou o nome atual e a imagem jniltinho\/go-uptime<\/code>.<\/p>\nNOTICE<\/code> registra a origem e a modifica\u00e7\u00e3o dos arquivos herdados. Na pr\u00e1tica, o que importa para quem j\u00e1 usa Gatus: um arquivo de configura\u00e7\u00e3o do Gatus funciona sem altera\u00e7\u00e3o<\/strong>. As condi\u00e7\u00f5es, os endpoints, os grupos e os provedores de alerta s\u00e3o os mesmos; os recursos novos entram como blocos opcionais.<\/p>\n![\"Dashboard](\"\/wp-content\/uploads\/2026\/09\/go-uptime-dashboard.webp\")
<\/p>\nO que o Go Uptime tem al\u00e9m do Gatus<\/h2>\n
\n
\/admin<\/code>: criar, editar, desativar e remover endpoints sem reiniciar o servi\u00e7o. No Gatus, endpoints s\u00f3 existem no arquivo de configura\u00e7\u00e3o (TwiN\/gatus#1345<\/a>).<\/li>\n\/status\/<slug><\/code>, abertas sem login, com o painel protegido. No Gatus, esse pedido foi fechado como not planned<\/em> (TwiN\/gatus#1311<\/a>).<\/li>\n\/api\/push\/<token><\/code>, com as mesmas URLs e respostas do Kuma.<\/li>\ncurl -u<\/code> continua funcionando.<\/li>\nconfig validate<\/code>, password hash<\/code>, version<\/code> e healthcheck<\/code>.<\/li>\nSuba com Docker em um minuto<\/h2>\n
amd64<\/code> e arm64<\/code>. N\u00e3o existe tag latest<\/code><\/strong>, de prop\u00f3sito: fixe a vers\u00e3o que voc\u00ea executa. Para uma primeira olhada, sem hist\u00f3rico persistente:<\/p>\nmkdir -p go-uptime\/config && cd go-uptime\ncurl -sL -o config\/config.yaml \\\n https:\/\/raw.githubusercontent.com\/jniltinho\/go-uptime\/main\/config.yaml\ndocker run -d --name go-uptime -p 127.0.0.1:8080:8080 \\\n -v \"$PWD\/config:\/config\" jniltinho\/go-uptime:v7.0.0<\/code><\/pre>\nhttp:\/\/127.0.0.1:8080<\/code>. O arquivo de exemplo j\u00e1 traz endpoints e as p\u00e1ginas \/status\/services<\/code> e \/status\/infrastructure<\/code>. Em poucos segundos, docker ps<\/code> mostra o cont\u00eainer como healthy<\/code>: a imagem n\u00e3o tem shell, e o HEALTHCHECK<\/code> usa o pr\u00f3prio subcomando go-uptime healthcheck<\/code>.<\/p>\nProdu\u00e7\u00e3o com Docker Compose, SQLite e login<\/h2>\n
admin.enabled<\/code>. Comece gerando o hash da senha do administrador:<\/p>\nprintf 'troque-esta-senha' | docker run --rm -i jniltinho\/go-uptime:v7.0.0 password hash<\/code><\/pre>\npassword-bcrypt-base64<\/code>. Rodado num terminal sem o printf<\/code>, ele pede a senha duas vezes sem ecoar. Crie ent\u00e3o config\/config.yaml<\/code>:<\/p>\nstorage:\n type: sqlite\n path: \/data\/data.db\n\nsecurity:\n basic:\n username: admin\n password-bcrypt-base64: \"COLE-AQUI-O-HASH\"\n\nadmin:\n enabled: true\n\nendpoints:\n - name: linuxpro\n group: sites\n url: \"https:\/\/www.linuxpro.com.br\"\n interval: 1m\n conditions:\n - \"[STATUS] == 200\"\n - \"[RESPONSE_TIME] < 1000\"\n - \"[CERTIFICATE_EXPIRATION] > 168h\"\n\n - name: dns-google\n group: infra\n url: \"8.8.8.8\"\n interval: 1m\n dns:\n query-name: \"linuxpro.com.br\"\n query-type: \"A\"\n conditions:\n - \"[DNS_RCODE] == NOERROR\"<\/code><\/pre>\ncompose.yaml<\/code>, com a porta publicada s\u00f3 em 127.0.0.1<\/code> para ficar atr\u00e1s de um proxy reverso:<\/p>\nservices:\n go-uptime:\n image: jniltinho\/go-uptime:v7.0.0\n restart: unless-stopped\n ports:\n - \"127.0.0.1:8080:8080\"\n volumes:\n - .\/config:\/config:ro\n - go-uptime-data:\/data\n\nvolumes:\n go-uptime-data:<\/code><\/pre>\nconfig validate<\/code> carrega o arquivo exatamente como o servidor faria, mas n\u00e3o abre banco nem faz requisi\u00e7\u00f5es, e sai com c\u00f3digo 1<\/code> se algo estiver errado. \u00c9 o comando certo para colocar num pipeline antes do deploy:<\/p>\ndocker run --rm -v \"$PWD\/config:\/config:ro\" jniltinho\/go-uptime:v7.0.0 config validate &&\ndocker compose up -d\ncurl -s http:\/\/127.0.0.1:8080\/health<\/code><\/pre>\nThe configuration is valid: 2 endpoints, 0 external endpoints, 0 suites\n{\"status\":\"UP\"}<\/code><\/pre>\nsecurity.basic<\/code> ativo, o painel e a API passam a exigir login. \/login<\/code> abre uma tela pr\u00f3pria, a sess\u00e3o fica no banco (s\u00f3 o hash SHA-256 do token \u00e9 gravado) e o cookie \u00e9 HttpOnly<\/code> e SameSite=Strict<\/code>. Scripts continuam usando curl -u admin:senha<\/code>. Mudan\u00e7as no arquivo n\u00e3o exigem restart: o Go Uptime recarrega a configura\u00e7\u00e3o sozinho em at\u00e9 30 segundos.<\/p>\nadmin<\/code> e senha go-uptime<\/code>. Essa senha \u00e9 p\u00fablica: os exemplos publicam a porta apenas em 127.0.0.1<\/code>, e voc\u00ea deve troc\u00e1-la antes de colocar um proxy na frente.<\/p>\nAdministra\u00e7\u00e3o pela web<\/h2>\n
\/admin<\/code> lista os endpoints do YAML (somente leitura, marcados como YAML<\/em>) e os cadastrados pela web (marcados como Web<\/em>, com editar, pausar e remover). Os endpoints da web ficam na tabela managed_endpoints<\/code> do banco e entram em vigor sem rein\u00edcio. O formul\u00e1rio tem modo visual e modo YAML, com bot\u00e3o de teste antes de salvar para endpoints ativos.<\/p>\n![\"Tela](\"\/wp-content\/uploads\/2026\/09\/go-uptime-admin-endpoints.webp\")
<\/p>\ndocs\/manager-go-uptime.py<\/code>, que usa a API da administra\u00e7\u00e3o para importar um CSV, renomear grupos, listar endpoints e exportar tokens de push.<\/p>\nP\u00e1ginas de status p\u00fablicas<\/h2>\n
status-pages:\n pages:\n - slug: publica\n title: \"Status LinuxPro\"\n description: \"Disponibilidade dos servi\u00e7os\"\n groups: [sites]\n featured: [sites_linuxpro]\n show-certificate-expiration: true<\/code><\/pre>\n<grupo>_<nome><\/code>, a mesma usada nos badges. featured<\/code> destaca at\u00e9 10 endpoints no topo, e show-certificate-expiration<\/code> exibe quantos dias faltam para o certificado TLS vencer. Outras op\u00e7\u00f5es \u00fateis: groups-collapsed<\/code> para p\u00e1ginas com centenas de servi\u00e7os e auth<\/code> para exigir usu\u00e1rio e senha s\u00f3 naquela p\u00e1gina. As p\u00e1ginas tamb\u00e9m podem ser criadas pela aba Status pages<\/strong> da administra\u00e7\u00e3o.<\/p>\n![\"P\u00e1gina](\"\/wp-content\/uploads\/2026\/09\/go-uptime-status-page.webp\")
<\/p>\nmaximum-endpoints-per-page<\/code> (400 por padr\u00e3o) \u00e9 regra de acesso, n\u00e3o s\u00f3 de exibi\u00e7\u00e3o. Um endpoint que fica al\u00e9m do corte responde 404 em detalhes, gr\u00e1fico e badges. Aumentar o limite, portanto, publica mais endpoints<\/strong>.<\/p>\n![\"Detalhes](\"\/wp-content\/uploads\/2026\/09\/go-uptime-endpoint-details.webp\")
<\/p>\nPush: backups e cron jobs que avisam quando rodam<\/h2>\n
external-endpoints:\n - name: backup-noturno\n group: jobs\n token: \"troque-por-um-token-longo-e-aleatorio\"\n heartbeat:\n interval: 25h<\/code><\/pre>\ncurl -fsS \"https:\/\/status.exemplo.com\/api\/push\/troque-por-um-token-longo-e-aleatorio?status=up&msg=backup%20ok&ping=\" >\/dev\/null<\/code><\/pre>\n{\"ok\":true}<\/code>; token desconhecido devolve 404 com {\"ok\":false,\"msg\":\"Monitor not found or not active.\"}<\/code>. O par\u00e2metro status<\/code> aceita up<\/code>, pending<\/code> (resultado amarelo, extens\u00e3o do Go Uptime) ou qualquer outro valor como falha; msg<\/code> aparece no painel e no alerta; ping<\/code> \u00e9 o tempo em milissegundos.<\/p>\n\/api\/push\/<chave>\/<grupo_nome><\/code>), guardadas como hash SHA-256 e revog\u00e1veis na hora. Endpoints ativos (HTTP, TCP etc.) tamb\u00e9m podem aceitar push, com push.enabled: true<\/code>, \u00fatil para receber alertas de um sistema externo.<\/p>\n![\"Aba](\"\/wp-content\/uploads\/2026\/09\/go-uptime-admin-push-keys.webp\")
<\/p>\nAlertas<\/h2>\n
alerting:\n telegram:\n token: \"TOKEN-DO-BOT\"\n id: \"ID-DO-CHAT\"\n\nendpoints:\n - name: linuxpro\n group: sites\n url: \"https:\/\/www.linuxpro.com.br\"\n interval: 1m\n conditions:\n - \"[STATUS] == 200\"\n alerts:\n - type: telegram\n send-on-resolved: true<\/code><\/pre>\nalerts<\/code> vale para endpoints Push: um backup que n\u00e3o reportou dentro do heartbeat dispara o alerta como qualquer outra falha.<\/p>\nMySQL, MariaDB ou PostgreSQL<\/h2>\n
postgres<\/code> e mysql<\/code>, este \u00faltimo compat\u00edvel com MySQL 8.4+ e MariaDB 10.11+. O storage.path<\/code> passa a ser o DSN:<\/p>\nstorage:\n type: mysql\n path: \"go_uptime:${MARIADB_PASSWORD}@tcp(mariadb:3306)\/go_uptime\"<\/code><\/pre>\n.examples\/docker-compose-mariadb-storage<\/code>, e a documenta\u00e7\u00e3o de armazenamento em MySQL<\/a> detalha usu\u00e1rio e permiss\u00f5es. O DSN segue o formato do driver go-sql-driver\/mysql<\/code>; par\u00e2metros como parseTime<\/code> e loc<\/code> s\u00e3o for\u00e7ados pelo pr\u00f3prio Go Uptime, e op\u00e7\u00f5es como tls=true<\/code> ou timeout=5s<\/code> podem ser acrescentadas.<\/p>\nSem Docker: bin\u00e1rio \u00fanico com systemd<\/h2>\n
\/opt\/go-uptime<\/code>, com um usu\u00e1rio pr\u00f3prio:<\/p>\nVERSION=7.0.0\nARCH=amd64 # ou arm64\n\nsudo useradd --system --home-dir \/opt\/go-uptime --shell \/usr\/sbin\/nologin go-uptime\nsudo install -d -o root -g go-uptime -m 0750 \/opt\/go-uptime \/opt\/go-uptime\/config\nsudo install -d -o go-uptime -g go-uptime -m 0750 \/opt\/go-uptime\/data\n\ncurl -fsSL -o \/tmp\/go-uptime.tar.gz \\\n \"https:\/\/github.com\/jniltinho\/go-uptime\/releases\/download\/v${VERSION}\/go-uptime_${VERSION}_linux_${ARCH}.tar.gz\"\nsudo tar xzf \/tmp\/go-uptime.tar.gz -C \/opt\/go-uptime go-uptime\nsudo chown root:go-uptime \/opt\/go-uptime\/go-uptime && sudo chmod 0750 \/opt\/go-uptime\/go-uptime\nsudo -u go-uptime \/opt\/go-uptime\/go-uptime version<\/code><\/pre>\nroot<\/code> e s\u00e3o apenas leg\u00edveis pelo grupo go-uptime<\/code>: o servi\u00e7o n\u00e3o consegue reescrever o pr\u00f3prio execut\u00e1vel nem o arquivo que guarda o hash da senha. Crie \/opt\/go-uptime\/config\/config.yaml<\/code> com web.address: 127.0.0.1<\/code>, web.port: 8080<\/code> e storage.path: \/opt\/go-uptime\/data\/data.db<\/code>, valide com config validate<\/code> e instale a unit publicada no reposit\u00f3rio:<\/p>\nsudo curl -fsSL -o \/etc\/systemd\/system\/go-uptime.service \\\n https:\/\/raw.githubusercontent.com\/jniltinho\/go-uptime\/v7.0.0\/docs\/systemd\/go-uptime.service\nsudo systemctl daemon-reload\nsudo systemctl enable --now go-uptime\ncurl -s http:\/\/127.0.0.1:8080\/health\njournalctl -u go-uptime -f<\/code><\/pre>\nProtectSystem=strict<\/code> e escrita liberada s\u00f3 em \/opt\/go-uptime\/data<\/code>, e valida a configura\u00e7\u00e3o no ExecStartPre<\/code>, o que impede um restart com YAML inv\u00e1lido de derrubar o processo que estava funcionando. A \u00fanica capability \u00e9 CAP_NET_RAW<\/code>, necess\u00e1ria para endpoints ICMP; se voc\u00ea n\u00e3o monitora por ping, pode remov\u00ea-la. Os logs v\u00e3o para o journal, e o n\u00edvel fica em GO_UPTIME_LOG_LEVEL<\/code>. Para entender melhor esse modelo de servi\u00e7o, veja nosso guia de comandos essenciais do systemd<\/a>.<\/p>\nAtr\u00e1s do Nginx<\/h2>\n
server {\n listen 443 ssl;\n server_name status.exemplo.com;\n # ssl_certificate ...;\n\n location \/ {\n proxy_pass http:\/\/127.0.0.1:8080;\n proxy_set_header Host $host;\n proxy_set_header X-Forwarded-Proto $scheme;\n proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;\n }\n\n location ~ ^\/api\/v1\/(endpoints|status-pages)\/.*\/events$ {\n proxy_pass http:\/\/127.0.0.1:8080;\n proxy_set_header Host $host;\n proxy_set_header X-Forwarded-Proto $scheme;\n proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;\n proxy_buffering off;\n proxy_read_timeout 7m;\n }\n}<\/code><\/pre>\nHost<\/code> e X-Forwarded-Proto<\/code> n\u00e3o s\u00e3o enfeite: a administra\u00e7\u00e3o usa esses cabe\u00e7alhos para aceitar altera\u00e7\u00f5es vindas do pr\u00f3prio endere\u00e7o e para marcar o cookie de sess\u00e3o como Secure<\/code>.<\/p>\nMigrando do Gatus<\/h2>\n
config.yaml<\/code>: ele \u00e9 aceito como est\u00e1, e os recursos novos s\u00e3o opcionais. Fa\u00e7a backup do banco antes e teste numa c\u00f3pia.<\/p>\njniltinho\/gatus<\/code> v6, o guia de migra\u00e7\u00e3o<\/a> \u00e9 ainda mais curto: no Docker, s\u00f3 o nome da imagem muda<\/strong>. O banco n\u00e3o precisa de migra\u00e7\u00e3o, as vari\u00e1veis GATUS_*<\/code> continuam aceitas como apelidos das novas GO_UPTIME_*<\/code>, e um backup feito na v6 restaura na v7. O que muda, se voc\u00ea depender disso:<\/p>\n\n
gatus_<\/code> para go_uptime_<\/code>; metrics-namespace: gatus<\/code> mant\u00e9m os nomes antigos;<\/li>\nUser-Agent<\/code> das checagens passa a ser go-uptime\/1.0<\/code>, o que importa se um firewall ou WAF libera por esse cabe\u00e7alho;<\/li>\ngo-uptime<\/code>, mas a imagem mant\u00e9m \/gatus<\/code> como link simb\u00f3lico durante a s\u00e9rie 7.x.<\/li>\n<\/ul>\ngo_uptime_*<\/code> que o Go Uptime exp\u00f5e em \/metrics<\/code> quando metrics: true<\/code> est\u00e1 na configura\u00e7\u00e3o.<\/p>\nVale a pena?<\/h2>\n
config validate<\/code> antes de cada deploy e acompanhe as releases<\/a> antes de atualizar. C\u00f3digo, documenta\u00e7\u00e3o e exemplos est\u00e3o no reposit\u00f3rio no GitHub<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"