Aqui são exemplos muito simples de como você pode implementar os dashboards. Não quis explorar muito aqui, mas é só para dar uma visão geral de como que você consegue colocar esses dashboards à disposição e trabalhar em cima deles. Aqui no início colocamos throughput como time series, mas se uma métrica não fizer sentido em formato temporal por exemplo número de requisições talvez não seja necessariamente relevante saber em relação ao tempo né então esse gráfico você poderia ajustar o formato dele você pode vir aqui editar em vez de time-serve você pode colocar um start por exemplo que você consegue visualizar melhor essas requisições tá bom vamos aplicar o que mais que dá para fazer no throughput na saturação aqui CPU também pode ser algo que você queira visualizar de outra forma, com Gaudi por exemplo. Se existe um interesse de você mensurar isso de forma cronológica, é interessante também, mas caso não tenha esse interesse você pode utilizar um gráfico mais simplificado. E aí, é claro, lembre-se que ao criar dashboards no Grafana ou qualquer outra ferramenta de dashboard, monitorar só a aplicação não é o suficiente. É interessante que você monitore o ecossistema em que a aplicação também está situada às vezes monitorar, por exemplo, saturação do ponto de vista da aplicação pode ser insuficiente, é interessante monitorar, por exemplo, saturação do lado da aplicação que suporta ali a sua aplicação, o serviço que suporta a sua aplicação, como o que suporta sua aplicação como docker por exemplo monitorar throughput do lado da aplicação pode ser insuficiente é interessante você monitorar seu pote do lado do gate e da peguei todo balanceador que tá à frente da sua aplicação tá então só só monitorar a aplicação é insuficiente, obviamente. E aí, tirando como uma lição, é aqui que a gente pode aprender dessas métricas. Se você observar aqui em latência, e eu vou atualizar aqui, vou pegar aqui, é uma resolução curta, não vou pegar muito grande, não. Vou pegar uma granularidade de 5 minutos aqui. Observe que a rota Get Or orders é a que se destaca. Todas as rotas estão respondendo em pouquíssimo tempo aqui. Se eu olhar aqui o Python, a aplicação em Python está chamando as requisições, fazendo requisição, mas as rotas de get, por id, post order, estão super rápidas. rotas de get por id post order estão super rápidas a rota de get é uma rota que traz todas as dados de uma vez e ela tá devorando ela tá levando mais tempo para retornar eu vou pausar o vídeo deixar por mais alguns minutos e ver como que esse valor vai se comportar se ele vai subir muito mais do que seria o ideal retomei aqui as métricas, fiz uma atualização na página aqui e observe que agora o tempo de resposta da rota de orders está beirando quase 9 segundos de resposta de latência, na média aqui. Isso é ruim, bastante ruim para a saúde da aplicação. Então, sempre que eu precisar consultar as rotas, a rota de ela vai levar em torno disso. Vamos fazer um teste aqui, né? Localhost oitenta e oitenta, orders. Que que será que tá acontecendo, né? Então, observe que realmente tá demorando um pouquinho para retornar a e a segunda as métricas aqui vale deve levar em torno de 19 segundos mais ou menos a realmente retornou o que que tá acontecendo aqui ó serve que eu comecei com a base praticamente zerada ali de dados e eu comecei a fazer o carregamento via script do Python e agora nós temos muitas orders aqui a quantidade de retorno que a API tá retornando por requisição de lista de todas as orders. Então isso é bem ruim, acho que a gente vai ter que implementar algum algum tipo de paginação de dados para que eu não retorne todos os dados de uma única vez. Então aqui é uma rota que vamos precisar ajustar e no ambiente produtivo é esse tipo de oportunidade que talvez você possa acabar capturando e identificando na aplicação. Havendo uma métrica que está muito além, você identificou que tem um desvio muito grande e mesmo que não muito grande mas você sabe que tem alguma coisa que não está muito funcionando muito corretamente por exemplo no início quando a gente começou a capturar as métricas de get orders ela já estava beirando 0.5 segundos a 1 segundo em comparação às demais rotas que levam em torno de 0.03 0.5 segundos a 1 segundo em comparação às demais rotas que levam então de 0,03 0,04 vai arredondando ou essa aqui de 0.18 realmente era uma rota que ia se destacar e é esse tipo de oportunidade que você pode acabar capturando no ambiente produtivo tá euplementei agora o mecanismo de paginação na rota de Get Orders. Aqui na rota de Get Orders eu estou esperando uma página, a página e o tamanho de cada página, a quantidade de itens por página, colocando até relativamente generoso aqui, mas nem se compara com a quantidade de itens que estava retornando antes. Eu basicamente configuro um pageable a partir de um page request, onde eu configuro, monto através, monto utilizando o page size e passo aqui no find all e aí eu segue aqui a vida a partir desse ponto. Se eu consultar agora, ele vai retornar muito mais rápido, observe que ele está retornando muito mais rápido, e eu posso também customizar aqui page, página 2, por exemplo, page 2, page 10, ah, não tem tantas assim. Page 7, tem page 7 também. Então, vamos dar um refresh aqui nas métricas e ver se vai melhorar um pouco. Observe que agora realmente melhorou muito. Melhorou bastante aqui. Agora é a rota de post orders, que tá com um número um pouquinho elevado. A gente resolveu essa, conseguiu tratar, mas a rota de post orders tá em torno de zero ponto trinta milis de zero ponto três segundos ah então se você tivesse que refatorar e olhar essas métricas aqui essa aqui seria por exemplo uma segunda forte candidata para olhar.