Telliot: Используйте последовательное ведение журнала вместо printf везде.

Созданный на 26 сент. 2020  ·  9Комментарии  ·  Источник: tellor-io/telliot

Кодовая база имеет printf во многих местах, с чего легко начать, но при синтаксическом анализе или фильтрации журналов позже возникает множество проблем с мониторингом и трассировкой.

регистратор должен быть инициализирован в основном пакете, а затем передан всем конструкторам пакетов.

Это очень хороший пакет для ведения журнала
github.com/go-kit/kit/log

для примера как реализовать посмотрите проекты thanos или prometheus.

все закомментированные printf-s можно заменить журналами отладки, чтобы они отображались только при включенной отладке.
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. Готово


__Этот выпуск теперь имеет финансирование в размере 0,1 ETH (114,26 доллара США по 1142,63 доллара США за ETH) в рамках фонда Tellor-io .__

@ krasi-georgiev Я бы хотел заняться этим, но после прочтения ваших предложений по Gitcoin и чтения кода Telliot я бы сказал, что вместо того, чтобы менять все закомментированные fmt.Printf на level.Debug (logger) .Log (... .) мы должны решить для каждой ситуации то, что имеет больше смысла с точки зрения пользователя.
Я бы использовал отладку журнала, когда вывод должен быть полезен для проверки проблемы, больше с точки зрения разработчика, но ситуации, когда пользователь ожидает вывода на консоль, должны быть на уровне INFO. Как например
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())

Пожалуйста, поправьте меня, если я ошибаюсь. Спасибо!

да очень верно! Также еще одно правило состоит в том, что журнал создается один раз при запуске, это нормально, чтобы быть информацией, но если это происходит много раз в цикле, если это не очень важно, в большинстве случаев это слишком много шума, и его следует отлаживать.

@ krasi-georgiev Да, имеет смысл не перегружать пользователя, но я думаю, что в ситуациях, когда вы хотите анализировать журналы с помощью инструмента, изменение поведения может сбивать с толку, поскольку это единственная обратная связь, которая у вас есть для вашего анализа, но в любом случае я думаю, мы получим правильный баланс. Я собираюсь внести здесь некоторые изменения, и по мере того, как я узнаю больше об этом проекте, мы найдем то, что работает для хорошего взаимодействия с пользователем.

как только это будет сделано, также следует добавить в тот же PR еще немного линтинга в make-файл, например

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 строки этра:

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

Это приведет к тому, что нигде нет операторов печати, а также что pkg/errors везде используется

Статус проблемы: 1. Открыт 2. Начато 3. Отправлено 4. Готово


__Работа начата__.

Каждый из этих пользователей утверждал, что они могут завершить работу к 265 годам, 6 месяцам с этого момента.
Пожалуйста, ознакомьтесь с их планами действий ниже:

1) g33kidd подал заявку на начало работы _ (Только утвердить работника | отклонить работника ) _.

Я попробую это сделать, это показалось интересным занятием.
2) voanhcung подал заявку на начало работы _ (Только одобрить работника | отклонить работника ) _.

Хорошо, [email protected] .......................
3) therocketcat получил разрешение на начало работы.

Я просмотрел кодовую базу и ранее упомянутые вами примеры проектов.

Из примеров, которые я собрал, если функции, использующие printf, не имеют конструктора, тогда регистратор должен быть зависимостью, введенной в саму функцию. Если это не так, я хотел бы получить там разъяснения.

А в основном пакете (telliot / cmd / telliot / main.go) они будут настроены с помощью функции SetupLogger из утилиты и переданы либо конструктору, либо введены непосредственно в функцию (в качестве первого параметра).

Также, глядя на кодовую базу, я не могу найти никаких закомментированных printfs, поэтому я предполагаю, что вы имеете в виду printfs в целом?

Открыто для дальнейшего обсуждения, если я неправильно понял задачу RocketCat # 3507
4) Mendesfabio подала заявку на начало работы _ (Только одобрить работника | отклонить работника ) _.

Я только что проверил репо, и кажется, что некоторые printf-ы были заменены (и это помогло мне понять, как это сделать). У нас все еще есть 10 файлов с printf-s, и я это изменю.
5) Родригоадриандиаз подал заявку на начало работы _ (Только утвердить работника | отклонить работника ) _.

я мог бы сделать это, заменив все вызовы printf для реализации вышеупомянутого пакета журналирования, я мог бы начать работать над этим завтра
6) raulcorreia7 подал заявку на начало работы _ (Только одобрить работника | отклонить работника ) _.

Привет,
Это было бы ежу понятно,
Напишите мне.
7) coder4520 подал заявку на начало работы _ (Только одобрить работника | отклонить работника ) _.

Думаю, это будет действительно хороший первый проект для начала.
8) Adiprerepa подала заявку на начало работы _ (Только утвердить работника | отклонить работника ) _.

Это было бы очень просто - просто найдите и замените printf на logging, а затем дважды проверьте.
9) xf3rno подал заявку на начало работы _ (Только утвердить работника | отклонить работника ) _.

Я бы выполнил запрошенную задачу; замените все текущие журналы библиотекой golang logger (довольно легковесной: https://github.com/google/logger) и охватите каждое сообщение в зависимости от контекста (отладка, предупреждение и т. д.).

Узнайте больше на странице сведений о проблеме Gitcoin .

Статус проблемы: 1. Открыт 2. Запущен 3. Отправлен 4. Готово


__Работа на 0,1 ETH (167,47 долл. США по цене 1674,72 долл. США / ETH) была отправлена ​​__:


Была ли эта страница полезной?
0 / 5 - 0 рейтинги