Closed pedrofgd closed 1 year ago
Esse diagrama estaria considerando que o Monitoramento é um outro servidor. É a ideia do semestre passado de ter rodar o InfluxDB + Kapacitor para cuidar do monitoramento e gerenciamento de alertas.
Essa estratégia envolve os pontos 12 e 14 do diagrama, sobre disparar alertas do monitoramento e guardar a lista ordenada de provedores na memória do Broker.
O que acham @ClaudioSiqueira @lucas-ye @An-225 ?
Cara talvez a gente não faça um servidor separado para o monitoramento e siga numa arquitetura monolítica mesmo... Ainda mais que pelo jeito a professor não entendeu que a gente tava querendo fazer aplicações separadas
processo 12 seria Diagrama de sequência para a validação da resposta do Provedor?
@lucas-ye sim, os detalhes estão nesse outro diagrama, só para não ficar muito extenso
Do antigo ponto 10 em diante, as ações representavam a ideia inicial de ter o ranqueamento dos provedores no subsistema de monitoramento (íamos usar o Kapacitor para disparar alertas sempre que um critério não fosse atingido). Com a estratégia atual do Ranqueador ficar no próprio ApiBroker, o Monitorador precisa apenas salvar o resultado no banco de dados para que o Ranqueador passa obter os dados mais atualizados quando receber uma requisição do cliente. Esses pontos foram removidos do diagrama.
Ajuste de nomenclatura: De "Monitoramento" para "Monitorador".
%%{init: {'theme': 'neutral'}}%%
sequenceDiagram
participant Cliente
participant Broker
participant Configuracoes
participant Monitorador
autonumber
Cliente->> Monitorador: Inicializa aplicação de monitoramento
Cliente->>Broker: "Preenche" arquivo de configuração
Cliente->>Broker: Inicializa o Broker
Broker->>Configuracoes: Obtém configurações do cliente
Configuracoes->>Broker: Configurações
Broker->>Broker: Valida configurações
alt Configurações inválidas
Broker->>Cliente: Erro
else Configurações válidas
loop Para cada provedor configurado
Broker->>Broker: Dispara health check para cada o provedor
Broker->> Monitorador: Envia o resultado da validação do health check
end
end
Remover ponto 9, já que essa é uma responsabilidade do health check #4:
%%{init: {'theme': 'neutral'}}%%
sequenceDiagram
participant Cliente
participant Broker
participant Configuracoes
participant Monitorador
autonumber
Cliente->> Monitorador: Inicializa aplicação de monitoramento
Cliente->>Broker: "Preenche" arquivo de configuração
Cliente->>Broker: Inicializa o Broker
Broker->>Configuracoes: Obtém configurações do cliente
Configuracoes->>Broker: Configurações
Broker->>Broker: Valida configurações
alt Configurações inválidas
Broker->>Cliente: Erro
else Configurações válidas
loop Para cada provedor configurado
Broker->>Broker: Dispara health check para cada o provedor
end
end
Atualização para alterar o cliente como ator e renomear o broker por inicializador
%%{init: {'theme': 'neutral'}}%%
sequenceDiagram
actor Cliente
participant Inicializador
participant Configuracoes
participant Monitorador
autonumber
Cliente->> Monitorador: Inicializa aplicação de monitoramento
Cliente->>Inicializador: "Preenche" arquivo de configuração
Cliente->>Inicializador: Inicializa o Broker
Inicializador->>Configuracoes: Obtém configurações do cliente
Configuracoes->>Inicializador: Configurações
Inicializador->>Inicializador: Valida configurações
alt Configurações inválidas
Inicializador->>Cliente: Erro
else Configurações válidas
loop Para cada provedor configurado
Inicializador->>Inicializador: Dispara health check para cada o provedor
end
end
Como já apresentamos essa versão para a professora ontem e como ela recomendou não incluir esse diagrama no projeto final (já que não é o foco do trabalho), vou fechar a issue. Vou manter o diagrama no repositório para ficar como histórico, até porque essa inicialização já está implementada
Versão inicial da sequência de ações que precisam acontecer assim que o Cliente roda o nosso projeto pela primeira vez (aprimorar após discussão):
Detalhes sobre o fluxo do health check em #4 Detalhes sobre o fluxo do Broker quando recebe uma requisição do Cliente em #3