Skip to content
Marcio Trindade edited this page Feb 9, 2015 · 1 revision

Idéia principal

A idéia do endpoint JSON é fazer todos os testes do ponto de vista da aplicação, portanto ele deve prover os dados de todos os pontos que ele precisa acessar para funcionar corretamente. O endpoint irá validar partindo direto da app e poderemos adicionar checks adicionais, como por exemplo:

  • Disponibilidade de subsistema legado que não fará parte do SLA. Ou simplesmente um sistema que ainda não está lá.
  • Double check de uma dependência já presente no SLA, tipo um mongo DB, todavia este teste validará saindo da app, ou seja, passando pela comunicação entre as máquinas.

Em suma, aqui você diz se sua app pode ser considerada "up" se todos seus checks estiverem OK. É importante ressaltar que este endpoint deve responder em menos que 5 segundos, caso contrário o check irá considerar que sua app está indisponível. Portanto cuidado com a performance. Havendo integrações testadas que são naturalmente pesadas, pense em estratégias de caching de forma que o endpoint responda em menos que 5 segundos.

Se está pensando em utilizar esse padrão em uma aplicaçào Ruby, considere utilizar a gem Locaweb monitor

Implementação

Todo endpoint de moitoracao deve ser liberado para 127.0.0.1 e quando remoto via CAS O padrão do endpoint é um GET em http://meu_endereco/monitoring (por exemplo: https://feed-processor.systemintegration.locaweb.com.br/monitoring)

[
    {  
        saas-file-server: {
            status: "ok"
        }
    },
    {
        mongodb: {
            status: "ok"
        }
    },
    {
        suba: {
            status: "ok"
        }
    },
    {
        sapi: {
            status: "ok"
        }
    },
    {
        cas: {
            status: "ok"
        }
    },
    {
        redis: {
            status: "ok"
        }
    },
    {
        system2: {
            status: "ok"
        }
    },
    {
        system1: {
            status: "ok"
        }
    },
    {
        memcached: {
            status: "ok"
        }
    },
    {
        check_com_erro: {
            status: "error",
            message: ["Aqui fornecemos detalhes sobre a falha. Podemos indicar também como proceder para resolver"]
        }
    }
]

Monitoração funcional

"Gostaria que houvesse monitoração de outros recursos na minha app, como por exemplo, falhas em algum processo assíncrono. Como fazer?"

Para tal monitoração definimos uma verificação complementar. O objetivo é expor para operações e engenharia falha em processos que não indisponibilizam as apps, mas afetam diretamente os clientes. Exemplos são provisionamentos interrompidos ou incompletos, indisponibilidades momentâneas que demandam intervenção manual etc.

Expor e agir sobre estes casos permitirá um ciclo de evolução contínua sobre nossos sistemas (monitorar > alertar > contornar > PRB > resolução definitiva). Assim, saberemos dos problemas antes de nossos clientes e poderemos resolvê-los sem que eles percebam.

Aqui o tempo de verificação é maior que no cenário anterior (3 vezes ao dia) e o timeout para a resposta do endpoint é maior (60 segundos). Usar também a gem Locaweb monitor.

Implementação

Todo endpoint de moitoracao deve ser liberado para 127.0.0.1 e quando remoto via CAS O padrão do endpoint é um GET em *http://meu_endereco/monitoring/functional (por exemplo: https://resl-paas-provisioning.locaweb.com.br/monitoring/functional) Após isso é só passar nos métodos definidos pela Locaweb monitor que aquele trecho é um trecho funcional (marcando-os como true). Segue um exemplo

O formato de mensagem do JSON permanece o mesmo:

[
    {  
        funcional1: {
            status: "ok"
        }
    },
    {
        funcional2: {
            status: "error",
            message: ["Aqui fornecemos detalhes sobre a falha. Podemos indicar também como proceder para resolver"]

        }
    },
]
Clone this wiki locally