Telliot: Use registro consistente em vez de printf em todos os lugares.

Criado em 26 set. 2020  ·  9Comentários  ·  Fonte: tellor-io/telliot

A base de código tem printf em muitos lugares, o que é fácil de começar, mas ao analisar ou filtrar logs, ele traz muitos problemas posteriormente com monitoramento e rastreamento.

um logger deve ser inicializado no pacote principal e então passado para todos os construtores de pacotes.

Este é um pacote de registro muito bom
github.com/go-kit/kit/log

para um exemplo de como implementar veja os projetos thanos ou prometheus.

todos os printf-s comentados podem ser substituídos por logs de depuração para que sejam exibidos apenas quando a depuração estiver habilitada.
level.Debug(logger).Log("msg", "debug")

Importante! Verifique as diretrizes de codificação do projeto
https://github.com/tellor-io/telliot/blob/master/docs/coding-style-guide.md

good first issue help wanted .high

Todos 9 comentários

Vou levar este hoje!

Uma atualização: isso está parcialmente feito, mas ainda existem poucos lugares com printf e logrus.
TL-DR precisa usar github.com/go-kit/kit/log em qualquer lugar. Ele precisa ser passado como um argumento ao inicializar os componentes.

Status do problema: 1. Aberto 2. Iniciado 3. Enviado 4. Concluído


__Esta emissão agora tem um financiamento de 0,1 ETH (114,26 USD @ $ 1142,63 / ETH) anexado a ela como parte do fundo Tellor-io .__

@ krasi-georgiev Eu gostaria de abordar isso, mas depois de ler suas sugestões sobre Gitcoin e ler o código Telliot, eu diria que em vez de alterar todos os comentários de fmt.Printf para level.Debug (logger) .Log (... .) devemos decidir em cada situação o que faz mais sentido do ponto de vista do usuário.
Eu usaria o log debug quando a saída fosse útil para inspecionar um problema, mais do ponto de vista do desenvolvedor, mas as situações em que o usuário espera uma saída para o console devem ser de nível INFO. Como por exemplo
https://github.com/tellor-io/telliot/blob/master/pkg/ops/disputeOps.go#L249 -L255

    fmt.Printf("Dispute %s (%s):\n", dispute.DisputeId.String(), descString)
    fmt.Printf("    Accused Party: %s\n", reportedAddr.Hex())
    fmt.Printf("    Disputed by: %s\n", reportingMiner.Hex())
    fmt.Printf("    Created on:  %s\n", createdTime.Format("3:04 PM January 02, 2006 MST"))
    fmt.Printf("    Fee: %s TRB\n", util.FormatERC20Balance(uintVars[8]))
    fmt.Printf("    \n")
    fmt.Printf("    Value disputed for requestID %d:\n", dispute.RequestId.Uint64())

Por favor me corrija se eu estiver errado. Obrigado!

sim, é verdade! Outra regra também é que um log acontece uma vez na inicialização, não há problema em ser info, mas se acontecer muitas vezes em um loop, a menos que seja extremamente importante na maioria dos casos, isso é muito ruído e deve ser depurado.

@ krasi-georgiev Sim, faz sentido não sobrecarregar o usuário, mas acho que em situações em que você deseja analisar os registros com uma ferramenta, mudar o comportamento pode ser confuso, pois esse é o único feedback que você tem para a sua análise, mas de qualquer maneira vamos conseguir o equilíbrio certo, eu acho. Vou fazer algumas mudanças aqui e à medida que aprendo mais sobre este projeto, descobriremos o que funciona para uma boa experiência do usuário.

uma vez feito isso, também deve adicionar no mesmo PR um pouco mais de linting ao makefile, como

go-lint: check-git deps $(GOLANGCI_LINT) $(FAILLINT)
    $(call require_clean_work_tree,'detected not clean master before running lint, previous job changed something?')
    <strong i="6">@echo</strong> ">> verifying modules being imported"
    @$(FAILLINT) -paths "errors=github.com/pkg/errors" ./...
    @$(FAILLINT) -paths "fmt.{Print,Printf,Println,Sprint}" -ignore-tests ./...
    <strong i="7">@echo</strong> ">> linting all of the Go files GOGC=${GOGC}"
    @$(GOLANGCI_LINT) run
    <strong i="8">@echo</strong> ">> ensuring Copyright headers"
    <strong i="9">@go</strong> run ./scripts/copyright
    $(call require_clean_work_tree,'detected files without copyright, run make lint and commit changes')

as 2 linhas etra são:

    @$(FAILLINT) -paths "errors=github.com/pkg/errors" ./...
    @$(FAILLINT) -paths "fmt.{Print,Printf,Println,Sprint}" -ignore-tests ./...

Isso fará com que não haja instruções de impressão em qualquer lugar e também que pkg/errors seja usado em qualquer lugar

Status do problema: 1. Aberto 2. Iniciado 3. Enviado 4. Concluído


__Trabalho foi iniciado__.

Cada um desses usuários afirmou que pode concluir o trabalho em 265 anos, daqui a 6 meses.
Reveja os seus planos de ação abaixo:

1) g33kidd se inscreveu para iniciar o trabalho _ (apenas financiadores: aprovar trabalhador | rejeitar trabalhador ) _.

Vou tentar fazer isso, parecia uma coisa interessante a fazer.
2) voanhcung candidatou-se para iniciar o trabalho _ (apenas financiadores: aprovar trabalhador | rejeitar trabalhador ) _.

Ok [email protected] .......................
3) therocketcat foi aprovado para começar a trabalhar.

Eu olhei a base de código e os projetos de exemplo mencionados anteriormente que você mencionou.

A partir dos exemplos, concluí que, se as funções que usam printf não têm um construtor, o logger deve ser a dependência injetada na própria função. Se este não for o caso, gostaria de esclarecimentos.

E no pacote principal (telliot / cmd / telliot / main.go) eles serão configurados usando a função SetupLogger do util e passados ​​para o construtor ou injetados diretamente na função (como primeiro parâmetro).

Também olhando para a base de código, não consigo encontrar nenhum printfs comentado, então estou supondo que você quer dizer printfs em geral?

Abra para discutir isso melhor se eu entendi mal a tarefa RocketCat # 3507
4) mendesfabio candidatou-se para começar a trabalhar _ (apenas financiadores: aprovar trabalhador | rejeitar trabalhador ) _.

Acabei de verificar o repo e parece que alguns printf-s foram substituídos (e isso me ajudou a entender como fazer isso). Ainda temos 10 arquivos com printf-s e vou mudar isso.
5) rodrigoadriandiaz se candidatou para começar a trabalhar _ (apenas financiadores: aprovar trabalhador | rejeitar trabalhador ) _.

eu poderia fazer isso, substituindo todas as chamadas para printf por uma implementação do pacote de registro mencionado acima, poderia começar a trabalhar nisso amanhã
6) raulcorreia7 candidatou-se para começar a trabalhar _ (apenas financiadores: aprovar trabalhador | rejeitar trabalhador ) _.

Oi,
Isso seria um acéfalo,
DM mim.
7) coder4520 solicitou o início do trabalho _ (apenas financiadores: aprovar trabalhador | rejeitar trabalhador ) _.

Eu acho que este seria realmente um bom primeiro projeto para começar.
8) adiprerepa solicitou o início do trabalho _ (Financiadores apenas: aprovar trabalhador | rejeitar trabalhador ) _.

Isso seria muito fácil - basta localizar e substituir printf no registro e, em seguida, verificar novamente.
9) xf3rno solicitou o início do trabalho _ (apenas financiadores: aprovar trabalhador | rejeitar trabalhador ) _.

Eu realizaria a tarefa solicitada; substitua todo o registro atual pela biblioteca golang logger do Google (bastante leve: https://github.com/google/logger) e defina o escopo de cada mensagem de acordo com o contexto (depuração, aviso, etc.).

Saiba mais na página Detalhes do problema do Gitcoin .

Status do problema: 1. Aberto 2. Iniciado 3. Enviado 4. Concluído


__Trabalho para 0,1 ETH (167,47 USD @ $ 1674,72 / ETH) foi enviado por ___:


Esta página foi útil?
0 / 5 - 0 avaliações