DotNet BR 🇧🇷

05 Aug 2023 01:19

[.NET + APIs + Backend|07/08| Online | Gratuito]
Acompanhe este evento ONLINE e GRATUITO no Canal .NET com novas dicas, truques e alternativas úteis para o desenvolvimento Back-End e de APIs REST com .NET 7, C#, ASPNET Core e Azure Functions. Ao longo da apresentação será coberto o uso de diferentes frameworks, serviços na nuvem, mensageria e boas práticas de forma a facilitar e tornar mais dinâmica a implementação de soluções baseadas na plataforma .NET no seu dia a dia.

Teremos também algumas novidades do .NET 8 e do C# 12 demonstradas na prática!

Quando: 07/08/2023 (segunda) a partir das 21:00 - horário de Brasília

Faça sua inscrição em:
https://bit.ly/live-backend-dotnet-jul-2023

DotNet BR 🇧🇷

04 Aug 2023 23:11

"...cada instância do serviço tem uma instância do redis...".

Se o cache não é compartilhado entre diversas instâncias, você está sendo bitributado.

está pagando o preço de um cache distribuído,

e pagando o preço de um cache em memória

ao mesmo tempo.

Sem ter o benefício de um cache distribuído.

DotNet BR 🇧🇷

04 Aug 2023 22:38

exatamente, tudo depende do tamanho e custo envolvido, aqui pra mim, não tenho $$ para monitoramentos ultra-mega-power, então, vai de healthcheck turbinado mesmo... rsrsrs.. mas, se crescer e usar outros métodos, só desabilitar o check (tudo habilitado com flags, então é simples de ligar/desligar)

DotNet BR 🇧🇷

04 Aug 2023 22:36

Acho que na questão de redução de custo possa valer a pena testar esse tipo de abordagem

DotNet BR 🇧🇷

04 Aug 2023 22:35

Pelo menos garante que não vai receber um ataque nesse endpoint

DotNet BR 🇧🇷

04 Aug 2023 22:33

Por isso o limitador

DotNet BR 🇧🇷

04 Aug 2023 22:32

Sua abordagem é interessante e funcional. Fiquei pensando se valeria a pena testar todos os serviços externos no Healthcheck

DotNet BR 🇧🇷

04 Aug 2023 22:28

é como falei, tudo depende, no seu caso vc já tem uma estrutura paralela para fazer essas verificações, o que é bem bacana.

DotNet BR 🇧🇷

04 Aug 2023 22:25

Não através da api em si.

DotNet BR 🇧🇷

04 Aug 2023 22:24

sim, mas ai é a questão do que vc precisa, se vc precisa saber apenas que a api responde, ou se ela está 100% funcional mesmo.

DotNet BR 🇧🇷

04 Aug 2023 22:20

Mas nunca tinha pensando em um healthcheck para todos os serviços

DotNet BR 🇧🇷

04 Aug 2023 22:09

Então, ai vem a grande resposta: "DEPENDE" rsrsrsrsrs... porque senão também vc consome todos os seus recursos só com health check rsrsrs... Aqui no meu caso, estou trabalhando com servidores postgres separados para cada serviço, então é uma boa sim, é uma dependência direta e reta. Vc vai precisar analisar sua arquitetura pra ver o que vale a pena, de repente, sei lá, vc usa só um DB central, então não vai precisar dos serviços checando, pq se cai o db cai todo mundo. Aqui por exemplo, não uso um REDIS central, eu uso uma instância ao lado de cada serviço e dependendo do caso, cada instância do serviço tem uma instância do redis, ai já vale muito a pena checar ele pelo healthcheck do serviço. ou seja, pra confirmar, tudo "depende"... rsrsrsrs

DotNet BR 🇧🇷

04 Aug 2023 21:43

Opa, vamos lá, eu faço o health para saber como está o serviço e as dependências dele, já vi muita gente fazer o health apenas no endpoint do serviço (normalmente um que sempre responde 200) e ai vc vai consumir o serviço e pronto, o DB está fora, devolve erro, quando vc verifica tb as dependências, vc evita esse tipo de problema, consegue mudar o status para "degradado" por exemplo, ao invés de totalmente fora do ar, coisas desse tipo. Também é útil quando se trabalha com muitos DBs (caso de microsserviço), vc até pode monitor SÓ os DBs, mas vai ter que ficar vendo qdo um DB cai, qual serviço que usa ele para tomar uma ação, quando vc monitora junto com o serviço, vc já tem o status de degradação de todos os serviços que usam aquele DB automaticamente. Não sei se fui claro ou enrolei demais, é que estou na correria e nem revisei o texto... kkkkk.. mas é a ideia geral, a princípio....

DotNet BR 🇧🇷

04 Aug 2023 21:07

@MarcosCostaDev vou deixar para o @aledevbr lhe responder, pq fiz esta poc com base no que ele relatou acima, mas eu mesmo nunca usei. Então não tenho autoridade para lhe dar uma reposta mais concreta, mas a galera aqui do grupo com certeza tem coisa rodando a muito tempo.

DotNet BR 🇧🇷

04 Aug 2023 20:49

So uma curiosidade, vocês quando usam healthcheck no banco de dados é somente para ver se ta retornando algo ou se tem alguma coisa bloqueando o banco? Melhor, isso realmente é efetivo em produção. gostaria de ouvir sobre a experiencia de vocês usando esse tipo de abordagem

DotNet BR 🇧🇷

04 Aug 2023 23:15

no caso é de um único serviço (que exige o redis para funcionar), mas ele é pouco usado, e então foi colocado uma instância do redis ao lado da instância dele (no mesmo composer, dentro do aws ECS), foi uma "gambiarra" para ele funcionar e não ter que pagar uma instância do serviço de redis para ele... 😁 (e não tem problema se cair e perder os dados, um caso bem atípico, até ser substituído)

DotNet BR 🇧🇷

04 Aug 2023 22:40

lembrando que aqui estou fazendo de forma genérica, é uma lib compartilhada entre os projetos/serviços, só subir e passar as configs para ela e pronto, começa a responder, o que deixa tudo mais simples de implementar, trabalho quase zero nos serviços

DotNet BR 🇧🇷

04 Aug 2023 22:36

A gente só estaria fazendo o trabalho de um monitor mesmo kkk

DotNet BR 🇧🇷

04 Aug 2023 22:35

sim, ai vc pode até criar um serviço "gateway" de checagens e liga seus monitores nele, e ele faz a checagem a cada minuto, por exemplo, independente de quantos monitores tem espetado nele

DotNet BR 🇧🇷

04 Aug 2023 22:34

Tipo, você configura que o endpoint do health check só pode ser acionado uma vez a cada 1 Minuto

DotNet BR 🇧🇷

04 Aug 2023 22:33

olha, dependendo do tempo entre as checagens, pode valer a pena sim, pois ai vc não agride o desempenho nem o n° de conexões

DotNet BR 🇧🇷

04 Aug 2023 22:29

aqui eu já tenho um problema com o budget, tenho que reduzir ao máximo, mas sem afetar o serviço nem os dados e nem a segurança (só dor de cabeça kkkkk)

DotNet BR 🇧🇷

04 Aug 2023 22:26

Receber uma notificação quando o serviço cair e etc

DotNet BR 🇧🇷

04 Aug 2023 22:25

Em geral, a gente tem como monitorar isso

DotNet BR 🇧🇷

04 Aug 2023 22:20

Em geral somente para a api mesmo

DotNet BR 🇧🇷

04 Aug 2023 22:18

Interessante. Costumo usar o redis somente na consulta ou como fallout de gravação. Exemplo, um objeto correto não gravou por falha no banco de dados, eu jogo esse objeto no redis e abro um background job pra salvar ele depois

DotNet BR 🇧🇷

04 Aug 2023 21:47

Na sua visão então faria sentido testar todos os serviços externo no endpoint de health check, correto? Só teria que ter um limitador de requisição por trás dele

DotNet BR 🇧🇷

04 Aug 2023 21:18

nessa linha de livro de linguagem , tem um autor chamado Mark Price que tem uma serie de c# que lanca uma edicao a cada versao.
Tem uma escrita boa e o autor costuma ter um canal direto caso voce encontre algum sobressalto

DotNet BR 🇧🇷

04 Aug 2023 21:06

Com certeza. Fez bem em ficar esperto antes da prod.

DotNet BR 🇧🇷

04 Aug 2023 19:26

mas fiquei preocupado, pq se deixa-se como estava, algumas horas/dias depois de iniciar o serviço em prod, ele estouraria e seria um perrengue achar o problema... rsrsrs...