Telliot: Verwenden Sie überall eine konsistente Protokollierung anstelle von printf.

Erstellt am 26. Sept. 2020  ·  9Kommentare  ·  Quelle: tellor-io/telliot

Die Codebasis hat an vielen Stellen printf, was für den Anfang einfach ist, aber beim Parsen oder Filtern von Protokollen führt dies später zu vielen Problemen bei der Überwachung und Verfolgung.

ein Logger sollte im Hauptpaket initialisiert und dann an alle Paketkonstruktoren übergeben werden.

Dies ist ein sehr gutes Logging-Paket
github.com/go-kit/kit/log

für ein beispiel zur umsetzung schauen sie sich die thanos- oder prometheus-projekte an.

alle auskommentierten printf-s können durch Debug-Logs ersetzt werden, so dass diese nur bei aktiviertem Debugging angezeigt werden.
level.Debug(logger).Log("msg", "debug")

Wichtig! Überprüfen Sie die Richtlinien zur Projektcodierung
https://github.com/tellor-io/telliot/blob/master/docs/coding-style-guide.md

good first issue help wanted .high

Alle 9 Kommentare

Das nehme ich heute!

Ein Update: das ist teilweise erledigt, aber es gibt noch wenige Stellen mit printf und logrus.
TL-DR muss überall github.com/go-kit/kit/log verwenden. Es muss beim Initialisieren der Komponenten als Argument übergeben werden.

Problemstatus: 1. Offen 2. Gestartet 3. Gesendet 4. Fertig


__Diese Ausgabe ist jetzt als Teil des Tellor-io-Fonds mit einer Finanzierung von 0,1 ETH (114,26 USD @ 1142,63/ETH) verbunden.__

@krasi-georgiev Ich würde das gerne übernehmen, aber nachdem ich Ihre Vorschläge zu Gitcoin gelesen und den Telliot-Code gelesen habe, würde ich sagen, dass anstatt alle auskommentierten fmt.Printf in level.Debug(logger).Log(... .) sollten wir in jeder Situation entscheiden, was aus Nutzersicht sinnvoller ist.
Ich würde Log-Debugging verwenden, wenn die Ausgabe für die Untersuchung eines Problems nützlich sein sollte, eher aus der Sicht des Entwicklers, aber Situationen, in denen der Benutzer eine Ausgabe an die Konsole erwartet, sollte INFO-Ebene sein. Wie zum Beispiel
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())

Bitte korrigieren Sie mich, wenn ich falsch liege. Vielen Dank!

ja sehr wahr! Eine weitere Regel ist, dass ein Protokoll beim Start einmal auftritt, es ist in Ordnung, Informationen zu sein, aber wenn es viele Male in einer Schleife passiert, es sei denn, es ist in den meisten Fällen extrem wichtig, ist dies in den meisten Fällen zu viel Rauschen und sollte debuggt werden.

@krasi-georgiev Ja, macht Sinn, um den Benutzer nicht zu überfordern, aber ich denke, in Situationen, in denen Sie die Protokolle mit einem Tool analysieren möchten, kann eine Verhaltensänderung verwirrend sein, da dies das einzige Feedback ist, das Sie für Ihre Analyse haben, aber trotzdem Wir werden die richtige Balance finden, denke ich. Ich werde hier einige Änderungen vornehmen und wenn ich mehr über dieses Projekt erfahre, werden wir herausfinden, was für eine gute Benutzererfahrung funktioniert.

Sobald dies erledigt ist, sollte das Makefile im selben PR noch etwas mehr Linting hinzufügen, wie

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

die 2 etra-Linien sind:

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

Dadurch wird erzwungen, dass es nirgendwo print-Anweisungen gibt und dass pkg/errors überall verwendet wird

Problemstatus: 1. Offen 2. Gestartet 3. Gesendet 4. Fertig


__Arbeit wurde begonnen__.

Diese Benutzer gaben jeweils an, dass sie die Arbeit in 265 Jahren, also in 6 Monaten, abschließen können.
Bitte überprüfen Sie ihre Aktionspläne unten:

1) g33kidd hat einen Antrag auf Aufnahme der Arbeit gestellt _(nur Arbeiter genehmigen | Arbeiter ablehnen )_.

Ich werde es versuchen, es schien eine interessante Sache zu sein.
2) voanhcung hat einen Antrag auf Aufnahme der Arbeit gestellt _(nur Arbeiter genehmigen | Arbeiter ablehnen )_.

Okay [email protected].....................
3) therocketcat wurde genehmigt, um mit der Arbeit zu beginnen.

Ich habe mir die Codebasis und die zuvor erwähnten Beispielprojekte angesehen, die Sie erwähnt haben.

Aus den Beispielen habe ich entnommen, dass, wenn die Funktionen, die printf verwenden, keinen Konstruktor haben, der Logger eine Abhängigkeit in die Funktion selbst injizieren sollte. Wenn dies nicht der Fall ist, möchte ich dort eine Klarstellung.

Und im Hauptpaket (telliot/cmd/telliot/main.go) werden sie mit der SetupLogger-Funktion von util eingerichtet und entweder an den Konstruktor übergeben oder direkt in die Funktion eingefügt (als erster Parameter).

Auch wenn ich mir die Codebasis anschaue, kann ich keine auskommentierten printfs finden, also gehe ich davon aus, dass du printfs im Allgemeinen meinst?

Offen, um dies weiter zu besprechen, wenn ich die Aufgabe RocketCat#3507 falsch verstanden habe
4) mendesfabio hat einen Antrag auf Arbeitsaufnahme gestellt _(nur Arbeiter genehmigen | Arbeiter ablehnen )_.

Ich habe gerade das Repo überprüft und es scheint, dass einige printf-s ersetzt wurden (und es hat mir geholfen, zu verstehen, wie es geht). Wir haben noch 10 Dateien mit printf-s und ich werde das ändern.
5) Rodrigoadriandiaz hat einen Antrag auf Aufnahme der Arbeit gestellt _(nur Arbeiter genehmigen | Arbeiter ablehnen )_.

Ich könnte dies tun und alle Aufrufe von printf für eine Implementierung des oben genannten Protokollierungspakets ersetzen, ich könnte morgen mit der Arbeit beginnen
6) raulcorreia7 hat einen Antrag auf Aufnahme der Arbeit gestellt _(nur Arbeiter genehmigen | Arbeiter ablehnen )_.

Hallo,
Das wäre ein Kinderspiel,
DM mich.
7) coder4520 hat die Aufnahme der Arbeit beantragt _(Nur Arbeiter genehmigen | Arbeiter ablehnen )_.

Ich denke, das wäre wirklich ein gutes erstes Projekt für den Anfang.
8) adiprerepa hat einen Antrag auf Aufnahme der Arbeit gestellt _(nur Arbeiter genehmigen | Arbeiter ablehnen )_.

Dies wäre sehr einfach - suchen Sie einfach printf und ersetzen Sie es, um es zu loggen und dann doppelt zu überprüfen.
9) xf3rno hat die Aufnahme der Arbeit beantragt _(nur Arbeiter genehmigen | Arbeiter ablehnen )_.

Ich würde die angeforderte Aufgabe ausführen; Ersetzen Sie die gesamte aktuelle Protokollierung durch die Golang-Logger-Bibliothek von Google (ziemlich leicht: https://github.com/google/logger) und bereichern Sie jede Nachricht je nach Kontext (Debug, Warnung usw.).

Weitere Informationen finden Sie

Problemstatus: 1. Offen 2. Gestartet 3. Gesendet 4. Fertig


__Arbeit für 0.1 ETH (167.47 USD @ $1674.72/ETH) wurde eingereicht von__:


War diese Seite hilfreich?
0 / 5 - 0 Bewertungen