Diferenças
Aqui você vê as diferenças entre duas revisões dessa página.
| Ambos lados da revisão anterior Revisão anterior Próxima revisão | Revisão anterior | ||
| pres:gerti:servico_de_desenvolvimento_de_sistemas_de_informacao:projetos:observabilidade [03/06/2025 13:57] – mfaquino | pres:gerti:servico_de_desenvolvimento_de_sistemas_de_informacao:projetos:observabilidade [03/06/2025 14:34] (atual) – mfaquino | ||
|---|---|---|---|
| Linha 22: | Linha 22: | ||
| Caso alguma das partes importantes da aplicação não responda corretamente, | Caso alguma das partes importantes da aplicação não responda corretamente, | ||
| + | |||
| + | Uma vez configurada a rota **/ | ||
| + | |||
| + | Quando uma verificação de /health falhar, um alerta é enviado no Teams: \\ \\ {{https:// | ||
| + | |||
| + | ==== Logs ==== | ||
| + | |||
| + | Os logs das aplicações devem ser enviados para a stack ELK (Elasticsearch, | ||
| + | \\ | ||
| + | Uma vez que os logs estão sendo gerados, é necessário criar um agente no servidor que enviará os logs ao logstash para processamento e ingestão no elasticsearch. | ||
| + | |||
| + | Um exemplo dessa configuração em um sistema que usa docker é configurar o gelf no docker-compose: | ||
| + | < | ||
| + | |||
| + | logging: | ||
| + | | ||
| + | options: | ||
| + | gelf-address: | ||
| + | tag: " | ||
| + | |||
| + | </ | ||
| + | |||
| + | Para aplicações .NET podemos configurar o filebeat no IIS seguindo a documentação do elasticsearch [[https:// | ||
| + | |||
| + | **OBS: Os servidores IIS do TCE já estão configurados com o agente do filebeat, portanto basta salvar os logs da aplicação em um arquivo application.log para que os mesmos sejam enviados do IIS para o ELK** | ||
| + | |||
| + | O resultado são os logs enviados para o ELK e possíveis de visualização no Kibana: | ||
| + | |||
| + | [[https:// | ||
| + | |||
| + | {{https:// | ||
| + | |||
| + | **Métricas** | ||
| + | |||
| + | As métricas de código são geradas pelo Sonar, ele é responsável por analisar o código e gerar alertas de possíveis problemas e códigos que precisam de melhorias. | ||
| + | |||
| + | A adição do sonar no projeto é feita usando a pipelinde de CI/CD do gitlab e se necessário o docker. \\ \\ No projeto primeiro adicione a pipeline de CI/CD com o arquivo **.gitlab-ci.yml** | ||
| + | < | ||
| + | image: | ||
| + | name: docker/ | ||
| + | |||
| + | stages: | ||
| + | - sonar | ||
| + | - test | ||
| + | - deploy | ||
| + | |||
| + | tcego-iago: | ||
| + | image: sonarsource/ | ||
| + | stage: sonar | ||
| + | script: | ||
| + | - sonar-scanner -Dsonar.projectKey=TCE.Iago.AI -Dsonar.sources=source/ | ||
| + | only: | ||
| + | refs: | ||
| + | - main | ||
| + | - merge_requests | ||
| + | - develop | ||
| + | tags: | ||
| + | - docker-pipes-runner | ||
| + | |||
| + | </ | ||
| + | |||
| + | Usando a imagem do docker do sonar: **sonarsource/ | ||
| + | |||
| + | O seguintes parametros são necessários no sonar scanner: | ||
| + | |||
| + | * sonar.projectKey: | ||
| + | * sonar.sources: | ||
| + | * sonar.projectName: | ||
| + | * sonar.host.url: | ||
| + | * sonar.login: | ||
| + | |||
| + | Ao rodar a pipeline uma dashboard de métricas será gerada no sonar com o sonar.projectKey especificado: | ||
| + | |||
| + | [[http:// | ||
| + | |||
| + | {{https:// | ||