Telliot: どこでもprintfの代わりに一貫性のあるロギングを使用してください。

作成日 2020年09月26日  ·  9コメント  ·  ソース: tellor-io/telliot

コードベースには多くの場所にprintfがあり、簡単に始めることができますが、ログを解析またはフィルタリングすると、後で監視とトレースで多くの問題が発生します。

ロガーはメインパッケージで初期化してから、すべてのパッケージコンストラクターに渡す必要があります。

これは非常に優れたログパッケージです
github.com/go-kit/kit/log

実装方法の例については、thanosまたはprometheusプロジェクトをご覧ください。

コメントアウトされたすべてのprintfは、デバッグログに置き換えることができるため、デバッグが有効になっている場合にのみ表示されます。
level.Debug(logger).Log("msg", "debug")

重要! プロジェクトのコーディングガイドラインを確認する
https://github.com/tellor-io/telliot/blob/master/docs/coding-style-guide.md

good first issue help wanted .high

全てのコメント9件

今日はこれを持っていきます!

更新:これは部分的に行われますが、printfとlogrusがある場所はまだほとんどありません。
TL-DRはどこでもgithub.com/go-kit/kit/logを使用する必要があります。 コンポーネントを初期化するときに引数として渡す必要があります。

問題のステータス:1。オープン2.開始3.送信済み4.完了


__この号には、Tellor-io基金の一部として0.1 ETH(114.26 USD @ $ 1142.63 / ETH)の資金が添付されています。__

@ krasi-georgievこれを引き受けたいのですが、Gitcoinに関する提案を読み、Telliotコードを読んだ後、コメントアウトされたすべてのfmt.Printfをlevel.Debug(logger).Log(.. .. 。)ユーザーの観点から何がより理にかなっているのかをそれぞれの状況で決定する必要があります。
開発者の観点から、出力が問題の検査に役立つはずであるが、ユーザーがコンソールへの出力を期待している状況では、ログデバッグを使用します。 たとえばのように
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())

私が間違っている場合は私を訂正してください。 ありがとう!

うん、とても本当! また、ログは起動時に1回発生するというルールもありますが、情報を提供することは問題ありませんが、非常に重要でない限り、ループ内で何度も発生する場合は、ノイズが多すぎるため、デバッグする必要があります。

@ krasi-georgievはい、ユーザーを圧倒しないのは理にかなっていますが、ツールを使用してログを分析したい状況では、分析に対するフィードバックはそれだけなので、動作の変更は混乱を招く可能性があると思いますが、とにかく適切なバランスが取れると思います。 ここでいくつかの変更を行います。このプロジェクトについて詳しく知ると、優れたユーザーエクスペリエンスに役立つものが見つかります。

これが行われると、同じPRに次のようなmakefileにリンティングを追加する必要があります。

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')

2つのetraラインは次のとおりです。

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

これにより、printステートメントがどこにも存在せず、 pkg/errorsがどこでも使用されるようになります。

問題のステータス:1。オープン2.開始3.送信済み4.完了


__作業が開始されました__。

これらのユーザーはそれぞれ、今から6か月後の265年までに作業を完了することができると主張しました。
以下の彼らの行動計画を確認してください:

1) g33kiddが作業の開始を申請しました_(ファンダーのみ:ワーカーの承認|ワーカーの拒否)_。

私はこれを突き刺します、それは面白いことのように思えました。
2) voanhcungが作業の開始を申請しました_(ファンダーのみ:ワーカーの承認|ワーカーの拒否)_。

わかりました[email protected]......................。
3) therocketcatは作業を開始することが承認されています。

私はあなたが言及したコードベースと前述のサンプルプロジェクトを見ました。

私が集めた例から、printfを使用する関数にコンストラクターがない場合、ロガーは関数自体に依存性注入されるべきであることがわかりました。 そうでない場合は、そこで説明をお願いします。

また、メインパッケージ(telliot / cmd / telliot / main.go)では、utilのSetupLogger関数を使用してセットアップされ、コンストラクターに渡されるか、関数に直接挿入されます(最初のパラメーターとして)。

また、コードベースを見ると、コメントアウトされたprintfsが見つからないので、一般的にprintfsを意味していると思いますか?

RocketCat#3507のタスクを誤解した場合は、これについてさらに話し合うために開いてください。
4) mendesfabioが作業の開始を申請しました_(資金提供のみ:労働者の拒否)_。

リポジトリを確認したところ、一部のprintfが置き換えられたようです(その方法を理解するのに役立ちました)。 printf-sを含むファイルがまだ10個あるので、これを変更します。
5) rodrigoadriandiazが作業の開始を申請しました_(資金提供のみ:労働者を拒否する)_。

私はこれを行うことができ、上記のロギングパッケージの実装のためにprintfへのすべての呼び出しを置き換え、明日これに取り組み始めることができます
6) raulcorreia7が作業の開始を申請しました_(ファンダーのみ:ワーカーの承認|ワーカーの拒否)_。

こんにちは、
これは簡単なことではありません、
DM私。
7) coder4520が作業の開始に適用されました_(ファンダーのみ:ワーカーの承認|ワーカーの拒否)_。

これは最初のプロジェクトとしては本当に良いと思います。
8) adiprerepaが作業の開始を申請しました_(ファンダーのみ:ワーカーの承認|ワーカーの拒否)_。

これは非常に簡単です。printfを見つけてロギングに置き換えてから、ダブルチェックするだけです。
9) xf3rnoが作業の開始を申請しました_(ファンダーのみ:ワーカーの承認|ワーカーの拒否)_。

要求されたタスクを実行します。 現在のすべてのログをGoogleのgolangロガーライブラリ(非常に軽量:https://github.com/google/logger)に置き換え、コンテキスト(デバッグ、警告など)に応じて各メッセージのスコープを設定します。

詳細については、Gitcoinの問題の詳細ページをご覧ください

問題のステータス:1。オープン2.開始3.送信済み4.完了


__0.1 ETH(167.47 USD @ $ 1674.72 / ETH)の作業は__によって提出されました:


このページは役に立ちましたか?
0 / 5 - 0 評価