Primeiramente, obrigado pelo seu interesse em trabalhar na melhor plataforma de pagamentos do mundo! Abaixo você encontrará todas as informações necessárias para iniciar o seu teste.
- Crie um repositório na sua conta do GitHub sem citar nada relacionado ao PicPay;
- Faça seus commits no seu repositório;
- Solicite ao Recruter que está acompanhando o seu processo o username do Github do avaliador, assim você poderá dar permissão de leitura no código;
- Fique à vontade para perguntar qualquer dúvida aos recrutadores.
- Fique tranquilo, respire, assim como você, também já passamos por essa etapa. Boa sorte! :)
O desafio é criar uma API REST que será responsável por realizar as seguintes funcionalidades:
- Gestão de alertas;
- Gestão de incidentes; e
- Exposição de métricas e saúde da aplicação.
As funcionalidades estão explicadas em detalhes nos tópicos a seguir.
Sua aplicação deverá possuir alguns endpoints capazes de:
- Criar um Alerta
- Consultar uma lista de Alertas
- Habilitar ou Desabilitar um Alerta já criado
Como opcional você também pode ter a funcionalidade de:
- Consultar um alerta específico (opcional);
- Modificar o atributo de um alerta (opcional);
- Remover um alerta cadastrado (opcional).
Os alertas devem ser cadastrado em uma tabela do banco de dados MySQL e devem possuir a seguinte estrutura:
| Campo | Tipo | Descrição |
|---|---|---|
| alert_id | integer | Campo que indica o id do alerta. |
| app_name | string | Campo que indica o nome de uma aplicação a qual o alerta está relacionado |
| title | string | Campo que apresenta um título para o alerta |
| description | string | Campo que apresenta uma descrição do alerta (o que ele significa) |
| enabled | boolean | Campo que indica se o alerta encontra-se habilitado ou não |
| metric | string | Campo que indica o nome da métrica a ser monitorada |
| condition | char(2) | Campo que indica a condição de um alerta. (ex. Maior que >, Menor que <, igual á =, Maior Igual a >=, Menor Igual a <=) |
| threshold | integer | campo que indica o valor da métrica que acionará o alerta |
Observações Importantes
- Todos os campos da tabela de alerta são obrigatórios;
- Você pode ter N alertas para o mesmo app_name;
- O campo alert_id é unico e não pode ser repetido;
- O arquivo com os exemplos de alertas a serem cadastrados na API encontra-se neste repositório e possui o nome de
alerts-list.csv; - Deve-se subir a estrutura utilizando docker. Utilizar como exemplo o arquivo docker-compose.yml deste repositório;
- Ao executar o comando
docker-compose upo sistema deve-se configurar sozinho e rodar um container específico para cadastrar apenas uma vez os alertas; - A API deve gerar os logs no formato json_inline (onde cada linha representa um objeto JSON) e deverá ser gerado uma mensagem de log todas as vezes que os endpoints de gestão de alertas forem chamados.
Sua aplicação deverá:
- Possuir um endpoint para receber informações de métricas
O endpoint deve aceitar somente payload em json e deve receber os seguintes campos:
| Campo | Tipo | Descrição |
|---|---|---|
| metricName | string | Nome da métrica sendo informada |
| appName | string | Campo que indica o nome de uma aplicação a qual o alerta está relacionado |
| value | integer | Campo que indica o valor da métrica sendo reportada |
Exemplo de paylod recebido:
{"metricName":"throughput","appName":"ms-system-02","value":1651}- Validar as Informações recebidas com os alertas configurados
Aproveitando do endpoint definido na seção acima, a API deve ser capaz de comparar a metrica recebida, o appName recebido e o valor recebido pelo endpoint acima com os alertas ja configurados na API, respeitando a condição estipulada.
Exemplo, se você tiver um alerta onde:
metric = throughput
app_name = ms-system-02
condition = '>='
threshold = 1000 e você receber no endpoint de métricas recebidas o seguinte valor:
{"metricName":"throughput","appName":"ms-system-02","value":1651}Sua API deverá criar um registro na tabela de incidentes que possuí a seguinte estrutura (caso não atenda a condição ou o alerta esteja como desabilitado, deverá ignorar a criação do registro na tabela e informar nos logs):
| Campo | Tipo | Descrição |
|---|---|---|
| timestamp | integer | Campo que indica a data em que o incidente aconteceu |
| alert_id | string | Campo de ID que identifica o alerta cadastrado na tabela de alertas. |
Observações Importantes
- Todos os campos da tabela de incidentes são obrigatórios;
- Você deverá utilizar o script
metric-generator.shpara validar a sua implementação deste endpoint (lembre-se de alterar a variável ENDPOINT do script para o endereço correto da sua aplicação); - Você deverá pegar o script
metric-generator.she convertê-lo em um container adicionando sua execução dentro do arquivodocker-compose.yml; - A API deve gerar os logs no formato json_inline (onde cada linha representa um objeto JSON) e deverá ser gerado uma mensagem de log todas as vezes que este endpoint de recebimento de métricas for chamado.
Sua aplicação deverá:
- Possuir um endpoint chamado /health
Este endpoint deve retornar a saúde da sua aplicação, deve indicar se todas as dependencias do seu sistema estão ok.
-
Possuir um endpoint chamado /metrics
-
Este endpoint será o responsável por extenalizar as métricas da sua propria aplicação. Ele deverá retornar algumas informações da sua propria aplicação e ser representado de acordo com o formato que apresentaremos a seguir.
- Gerar uma métrica que traga a quantidade de registros da tabela de incidentes, agregado pelo nome da propria métrica (exemplo do formato)
# <metric_name> <metric>{alert_id=<value>} <count-da-quantidade-de-ocorrencias-na-tabela-incidentes>
(exemplo de retorno se chamarmos o endpoint /metrics)
# response_time response_time{alert_id=1} 10 response_time{alert_id=2} 0 response_time{alert_id=3} 3 # throughput throughput{alert_id=11} 0 throughput{alert_id=12} 5 throughput{alert_id=13} 3
- Gerar uma métrica que traga a quantidade de alertas habilitados e desabilitados (exemplo do formato)
# alerts-enabled alerts{enabled=<value>} <count-da-quantidade-de-alertas>
(exemplo de retorno se chamarmos o endpoint /metrics)
# alerts-enabled alerts{enabled=true} 10 alerts{enabled=false} 0- Gerar uma métrica que traga a quantidade de incidentes gerados agrupados por APP_NAME (exemplo do formato)
# app-name-incidents app-name-incidents-qtd{app_name=<value>, enabled=<value>} <count-da-quantidade-de-incidentes-gerados>
(exemplo de retorno se chamarmos o endpoint /metrics)
# app-name-incidents-qtd app-name-incidents-qtd{app_name="ms-system-01"} 10 app-name-incidents-qtd{app_name="ms-system-02"} 0 app-name-incidents-qtd{app_name="ms-system-03"} 50
-
Para finalizar, apresente uma solução para implementar esse API na nuvem.
- Apresentar quais serviços utilizaria
- Apresentar qual ou quais ferramentas de automação utilizaria
- Deve ser descrito no README
- Se preferir, pode criar um desenho da arquitetura para ajudar (opcional)
Sua aplicação deverá rodar utilizando docker. Utilize como referência o arquivo docker-compose.yml disponibilizado neste projeto.
Simplicidade na configuração e execução da sua aplicação, conforme exemplo:
git clone meu_repositorio.git
cd meu_repositorio
docker-compose up -dFique livre para sugerir outras abordagens :)
- Documentação (usar o próprio README.md do projeto);
- Código limpo e organizado;
- Aplicação funcionando e rodando;
- A Aplicação precisa estar rodando em docker;
- Logs da aplicação configurados em JSON;
- Ter sido implementado as 3 principais funcionalidades descritas acima:
- Gestão de alertas;
- Gestão de incidentes; e
- Exposição de métricas e saúde da aplicação.
- As linguagens e framework são livres, mas tenha em mente as premissas da solução.
- Respeitar as interfaces REST definidas;
- Apresentar solução de arquitetura para rodar o projeto em cloud native.
- Proposta de melhoria de solução;