[PROJETO] TRIGGERcmd - Service Status | https://dash.triggercmdstatus.com (PT-BR)

igorneth

TRIGGERcmd - Service Status — Monitoramento Global, Alta Disponibilidade e Confiabilidade

Olá, pessoal da comunidade TRIGGERcmd!

Gostaria de compartilhar com vocês um projeto que iniciei por gostar muito do trabalho que o Rus desenvolve e disponibiliza para todos nós desta comunidade.

Tomei a iniciativa e liberdade de registrar o domínio triggercmdstatus.com, com o objetivo de criar uma plataforma pública de monitoramento que nos permita acompanhar a disponibilidade de serviços essenciais, APIs utilizadas em nossas automações e outros componentes importantes para o funcionamento do ecossistema TRIGGERcmd.

A ideia é contribuir com a comunidade, oferecendo uma visão centralizada da disponibilidade desses serviços e ajudando a identificar possíveis instabilidades que possam afetar nossas automações, inclusive aquelas executadas por meio de assistentes de voz.

1. Domínio e Infraestrutura:

O domínio triggercmdstatus.com está vinculado à plataforma Cloudflare, com DNSSEC habilitado, acrescentando uma camada de proteção à resolução de nomes de domínio.

Para compor a infraestrutura, foram provisionados três servidores distribuídos em diferentes regiões geográficas:

Oracle Cloud — Instância 1: 1 GB de RAM e 1 OCPU.
Oracle Cloud — Instância 2: 1 GB de RAM e 1 OCPU.
KingHost — VPS: 4 GB de RAM e 2 vCPU.
Todas as Instâncias foram otimizadas o Kernel, Swap, Processadores e Memória RAM

Esses três servidores compõem uma arquitetura distribuída, concebida para proporcionar maior disponibilidade e redundância geográfica.

A proposta é reduzir a dependência de um único servidor ou localidade, permitindo que a infraestrutura de monitoramento tenha maior resiliência diante de eventuais falhas ou indisponibilidades regionais.

2. Objetivos do Projeto:

O projeto foi idealizado com os seguintes objetivos:

Monitorar a disponibilidade dos principais serviços globais utilizados pela comunidade.
Acompanhar as APIs que dão suporte às automações integradas à plataforma TRIGGERcmd.com.
Verificar a disponibilidade dos serviços de resolução DNS e conectividade de rede.
Utilizar sondas distribuídas para obter métricas de conectividade a partir de diferentes localidades.
Facilitar a identificação de possíveis falhas nos serviços monitorados.
Ajudar a diferenciar problemas nos serviços externos de possíveis instabilidades na conexão de internet residencial.
Disponibilizar um painel público, acessível de forma simples, sem depender de um computador específico.

É importante destacar que o monitoramento auxilia no diagnóstico, mas não determina sozinho a origem de uma falha. Os resultados devem ser interpretados em conjunto com as condições da rede local e os demais serviços envolvidos.

3. Plataformas e Tecnologias Utilizadas:

A infraestrutura utiliza Ubuntu 24.04.5 LTS como sistema operacional e Docker para executar os serviços em contêineres.

3.1. Uptime Kuma — Plataforma de Monitoramento (Open Source)

O Uptime Kuma é responsável pela apresentação do painel de status e pelo monitoramento dos serviços configurados.

Versão utilizada: 2.5.5
Projeto oficial: https://github.com/louislam/uptime-kuma
Créditos: Louis Lam e colaboradores do projeto.

A plataforma permite acompanhar o estado dos sensores, consultar informações de disponibilidade e visualizar possíveis interrupções nos serviços monitorados.

3.2. Cloudflare Tunnel — Acesso Seguro à Aplicação

O acesso público à aplicação é realizado por meio do Cloudflare Tunnel, executado em contêiner Docker.

Plataforma: Cloudflare One — Zero Trust
Painel: https://dash.cloudflare.com/one
Créditos: Cloudflare, Inc.

O túnel permite publicar a aplicação sem exigir a exposição direta de portas de entrada do servidor à internet, conforme a configuração adotada.

Também foram utilizadas funcionalidades da Cloudflare para aprimorar a entrega e a disponibilidade do painel:

Cache configurado para duas horas: destinado a reduzir solicitações repetidas à infraestrutura de origem e aliviar o consumo de recursos.
CDN da Cloudflare: utilizada para otimizar a entrega de conteúdo aos visitantes distribuídos geograficamente.
HTTPS com certificado digital SSL/TLS: para proteger a comunicação entre os visitantes e o endereço público.

As regras de cache são aplicadas considerando o comportamento dos recursos disponibilizados. Conteúdos dinâmicos e respostas de monitoramento precisam ser tratados adequadamente para evitar que informações desatualizadas sejam apresentadas como se fossem resultados atuais.

O objetivo é equilibrar desempenho, redução de carga e confiabilidade das informações exibidas.

3.3. Globalping — Monitoramento Distribuído

Também foi integrado o Globalping Probe, executado em contêiner Docker, para complementar o monitoramento com métricas de conectividade obtidas a partir de diferentes localidades.

Projeto e plataforma: https://globalping.io
Créditos: Globalping.io e seus colaboradores.

A utilização de uma sonda de monitoramento distribuído ajuda a ampliar a perspectiva sobre a disponibilidade dos serviços, permitindo observar condições que podem não ser perceptíveis a partir de uma única conexão residencial.

4. Organização dos Sensores:

Na primeira etapa do projeto, foram configurados 12 sensores, organizados em quatro grupos para facilitar a leitura do painel.

Grupo 1 — Server

Responsável pelo acompanhamento dos componentes da infraestrutura.

Uptime Kuma - Cluster: monitora a infraestrutura do cluster.
Cloudflare - Tunnel: acompanha a disponibilidade do túnel utilizado para acesso à aplicação.
Globalping - Probe: acompanha a disponibilidade da sonda utilizada nas métricas globais.

Grupo 2 — API

Responsável por acompanhar os serviços de API utilizados no ecossistema e em automações.

TRIGGERcmd.com API: monitora a disponibilidade da API do TRIGGERcmd.
MeuIP.com API: monitora a disponibilidade da API do MeuIP.com.
IPinfo.io API: monitora a disponibilidade da API do IPinfo.io.

Esses sensores ajudam a identificar indisponibilidades nos serviços consultados pelas automações e pelos scripts que dependem dessas APIs.

Grupo 3 — ICMP

Responsável pelos testes de conectividade ICMP com servidores DNS públicos.

Cloudflare - DNS: verifica a conectividade ICMP com o serviço DNS da Cloudflare.
Google - DNS: verifica a conectividade ICMP com o serviço DNS público do Google.

Esses testes fornecem informações sobre a conectividade com os destinos configurados. Uma eventual falha de resposta ICMP não significa necessariamente que o serviço DNS esteja indisponível, pois esse tipo de tráfego pode ser filtrado.

Grupo 4 — Resolution

Responsável pelos testes de resolução de nomes DNS.

Cloudflare - Resolution: monitora a resolução DNS utilizando a Cloudflare.
Google - Resolution: monitora a resolução DNS utilizando o Google.
TRIGGERcmd.com - Cloudflare: verifica a resolução do domínio TRIGGERcmd.com por meio da Cloudflare.
TRIGGERcmd.com - Google: verifica a resolução do domínio TRIGGERcmd.com por meio do Google.

Essa divisão permite observar tanto a disponibilidade dos resolvedores quanto a capacidade de resolver especificamente o domínio TRIGGERcmd.com.

A comparação entre os resultados pode ajudar a identificar problemas de resolução de nomes que, em determinadas circunstâncias, afetam o acesso aos serviços mesmo quando existe conectividade com a internet.

5. Acesso Público e Compatibilidade:

O painel está disponível publicamente no seguinte endereço:

https://dash.triggercmdstatus.com

A interface foi disponibilizada para utilização em diferentes dispositivos, incluindo:

Computadores e notebooks.
Celulares e tablets.
Smart TVs com navegador compatível.
Dispositivos IoT que disponham de navegador ou mecanismo compatível de acesso à página.

O painel é responsivo e pode ser consultado pela maioria dos navegadores modernos, adaptando sua apresentação ao tamanho da tela.

A intenção é permitir que qualquer integrante da comunidade possa consultar o estado dos serviços sem precisar instalar uma aplicação específica.

6. Por que esse monitoramento seria importante?

Quem utiliza o TRIGGERcmd em conjunto com Alexa, outros assistentes de voz, scripts e automações sabe que uma falha nem sempre está no computador ou no equipamento responsável por executar o comando.

Em determinadas situações, o problema pode estar relacionado a:

Indisponibilidade de uma API.
Problemas de resolução DNS.
Falhas de conectividade entre redes.
Instabilidades em serviços de terceiros.
Interrupções regionais ou problemas na infraestrutura de acesso.

Com um painel centralizado e sensores distribuídos, torna-se mais fácil reunir informações que auxiliem na investigação dessas ocorrências.

Por exemplo, se uma automação deixar de funcionar, a consulta ao painel poderá fornecer indícios sobre a disponibilidade dos serviços monitorados naquele momento. Isso não substitui os testes locais, mas oferece mais uma fonte de informação para o diagnóstico.

7. Considerações finais:

Este projeto nasceu da minha admiração pelo TRIGGERcmd e pelo trabalho que o @Russ todos os Desenvolvedores disponibilizam para toda a comunidade.

A proposta não é substituir ferramentas existentes, mas contribuir com um recurso complementar, público e acessível, que possa ser útil para todos nós.

A infraestrutura foi planejada com redundância geográfica, monitoramento de serviços, resolução DNS e recursos de distribuição de conteúdo, buscando oferecer uma experiência de consulta mais confiável.

Pretendo continuar aprimorando o projeto, adicionando novos sensores e aperfeiçoando os mecanismos de monitoramento conforme as necessidades identificadas.

Fiquem à vontade para acessar o painel:

https://dash.triggercmdstatus.com

Espero que esse recurso seja útil para a comunidade e ajude todos nós a compreender melhor a disponibilidade dos serviços envolvidos em nossas automações.

Um agradecimento especial ao @Russ e todos os Desenvolvedores, pelo desenvolvimento e pela manutenção do TRIGGERcmd, e a todos os desenvolvedores e colaboradores das ferramentas de código aberto e serviços utilizados neste projeto.

Obrigado a todos!

Autor: Igor Neth dos Santos
Alma Mater: UniCesumar - Superior de Tecnologia em Redes de Computadores (2015 - 2018)
Projeto: TRIGGERcmd - Service Status | https://dash.triggercmdstatus.com

LinkedIn:
https://www.linkedin.com/in/igorneth

Russ

Thanks @igorneth!