Histórico da Página

O dilema do troubleshooting em DevOps

Em técnicas práticas de DevOps utilizamos muitas , é comum utilizar uma variedade de ferramentas que conversam entre si, onde uma aciona outra para executar algum processo específico.se integram, permitindo que uma acione a outra para executar processos específicos de forma automatizada e contínua.

Para obtermos uma compreensão mais aprofundada desse conteúdo, vamos analisar o diagrama simplificado apresentado abaixoVejamos o diagrama simplificado abaixo para entendermos:

Image Modified

Cada ferramenta possui um registro (log contendo informações do ) que contém informações sobre o que acontece sob seu controle, porém ela não consegue . No entanto, essas ferramentas não são capazes de obter informações específicas de outas outras ferramentas.

Acontece a Da mesma coisa forma ocorre na execução dos testes do PROBAT, que somente conhece as só tem conhecimento das informações de execuções execução dos testes que ele disparoumesmo iniciou.

O que queremos mostrar destacar é que, em um ambiente automatizado, haverão muitas informações dos eventos, porém as informações ficam descentralizadas e portanto gera um trabalho muito grande para realizar o troubleshooting quando os testes não rodarem a contentohaverá uma grande quantidade de informações sobre os eventos, mas essas informações estarão descentralizadas. Isso pode gerar um trabalho significativo para realizar a resolução de problemas (troubleshooting) quando os testes não forem executados conforme o esperado.

Se o erro for somente estiver relacionado apenas a um teste específico, você poderá localizá-lo facilmente encontrará pelos resultados do PROBAT. No entanto, porém, e se o evento ocorrido for na ocorrer durante a execução do script ? ou em alguma outra ferramenta? Nesses casos, as informações descentralizadas podem dificultar a identificação e resolução do problema, tornando o processo de troubleshooting mais desafiador.

A Solução

Olhando para esse Diante desse "problema", o PROBAT passou a disponibilizar o recurso na apresenta uma solução ao disponibilizar um recurso no qual ferramentas externas podem enviar informações importantes para o PROBAT com usando o mesmo ID Customizado, dessa forma personalizado. Dessa forma, ao exportar os resultados dos testes, também serão considerados os dados de dos eventos externos também são considerados, proporcionando uma visão mais completa e integrada das informações, facilitando o processo de análise e troubleshooting.

Com essa a centralização de das informações, o trabalho para encontrar o que ocorreu fica facilitado de identificação do que ocorreu torna-se mais fácil, mesmo para pessoas menos experientes em ambientes complexos, pois uma vez que o PROBAT facilmente terá prontamente as informações de todas as ferramentas usadas utilizadas no processo automatizado.

A ideia proposta não é substituir as informações densas que existem detalhadas presentes em cada Loglog individual, mas sim centralizar os principais eventos para que o PROBAT possa sinalizar problemas ocorridos fora de sua própria execução, tornando o processo de troubleshooting mais assertivo e ágil. Essa abordagem permite que as equipes detectem e resolvam problemas de forma mais eficiente, melhorando a produtividade e a qualidade do desenvolvimento de software em um ambiente automatizado.

Como utilizar?

O PROBAT possui algumas 'Main Function', na qual permite que sejam executadas diretamente através do AppServer Command Line por qualquer processo de sua escolha. Aqui iremos utilizar como exemplo um Shell Script em Linux para orquestrar as tarefas de uma automação.

O script completo pode ser acessado por nosso projeto no GitHub que contém exemplos práticos de uso do PROBAT.
GitHub.com/TOTVS/tlpp-probat-samples/run/

Dessa forma, diretamente por um processo externo indicamos ao PROBAT quando o Script iniciou e encerrou sua execução, quando ocorreram eventos Positivos, de Erro ou somente Avisos, também podemos verificar se um Exit Code dentro do Script ocorreu sem erros e entregando ao PROBAT essa verificação.

Além dos estados acima, podemos informar qual é o Plano de Execução do processo, enviando ao PROBAT uma lista com os passos (Steps) e sua descrição. Com isso deveremos informar quando cada Step inicia e encerra, informando também se foi encerrado com sucesso ou erro.

Portanto, quando formos apurar os resultados no processo de exportação, o PROBAT irá considerar todos os dados recebidos da execução externa e anexar como fosse uma suite destacada, ou seja, se houver apenas um erro no script e não houver erro algum nos testes executados, ao mesclar as duas execuções o resultado final será negativo, justamente pelo erro ocorrido no evento do Script.

Importante: Para garantirmos que uma Execução real do PROBAT seja linkada com uma Execução Externa, devemos utilizar o recurso de Identificador Customizado e enviar o mesmo ID para todas as execuções do PROBAT, tanto as reais como a externa.

Funções

Abaixo seguem as funções disponíveis nesse recurso:

Início e Fim do Processo:

• tlpp.probat.over.startScript
• tlpp.probat.over.endScript

Asserts:

• tlpp.probat.over.assertOK
• tlpp.probat.over.assertError
• tlpp.probat.over.assertWarning
• tlpp.probat.over.assertExitCode

Plano de execução:

• tlpp.probat.over.setPlan
• tlpp.probat.over.startStep
• tlpp.probat.over.endStep
• tlpp.probat.over.setStep