Должен ли я использовать fmt в производственном коде?

Question

Я вижу много Go кода, который выглядит следующим образом:

func main() { 
    response, _, err := http.Get("http://golang.org/") 
    if err != nil { 
     fmt.Printf("%s", err) 
     os.Exit(1) 
    } 

    defer response.Body.Close() 
    contents, err := ioutil.ReadAll(response.Body) 
    if err != nil { 
     fmt.Printf("%s", err) 
     os.Exit(1) 
    } 

    fmt.Printf("%s\n", string(contents)) 
} 

Мои вопросы:

1. В производстве, я должен держать эти fmt.Printf заявления? Глупый вопрос, я уверен, но только проверка

2. Какие параметры ведения журнала вы рекомендуете для производственного кода, а также dev?

Answer 1

Мысленно допустимо использовать printf s в некоторой ситуации. В производственной среде лучше использовать разные стратегии ведения журнала.

Например, если ваше приложение является демонами, работающими в фоновом режиме, вы пропустите все свои fmt.Printf, если вы их не перетаскиваете в файл.

Хороший способ сделать looging - использовать поворот журнала (поскольку вы не хотите иметь невероятно большие файлы) вместо того, чтобы изобретать свой собственный логротат, вы можете использовать стандартные пакеты или внешние пакеты на основе ваших потребностей.

Golang предоставляет пакет logsyslog, который является оптимальным решением для простого ведения журнала, основанного на OS syslog.

Answer 2

fmt.Printf() подходит для того, чтобы начать наброски вашей программы, но вы, вероятно, должны либо удалить их, либо заменить на реальные записи ведения журнала.

Мне повезло со стандартом log и logrus, если мне нужно больше.

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

Answer 3

Я думаю, что лучший способ - подготовить свой код для легкого перехода из среды разработки в производственную среду, возможно, используя входной параметр при запуске приложения go.

Вы можете создать уровень variuos бревен:

«Всегда» бревном уровень

Этот уровень журнала всегда включен, дает важную информацию о состоянии приложения (при необходимости). Также сообщайте об авариях.

«тестирование» журнал Уровень

Этот журнал содержит полезную информацию, когда ваш код закончен, но у вас есть, чтобы проверить информацию больше не полезно, когда код на производстве

«Debug» log level

Этот уровень журнала содержит полезную информацию, когда вы находитесь в среде разработки, разрабатываете новые функции или оптимизируете уже существующий код

Лучший способ сделать это, на мой взгляд, с помощью chan s, которые позволяют вам создавать демон async и регистрировать везде, где вы хотите, что хотите.

Вы можете прочитать некоторую информацию о chan here.

Примером демона может быть:

func daemonLogging(importantMessage chan error, testingMessage chan error,debugMessage chan error){ 
    for{ 

     if globalDebugFlag == true{ 
      // Log debug message 
     } 

     if globalTestingMessage == true{ 
      // Log Testing message 
     } 

     // Log important message 
    } 
} 

Не забудьте вызвать эту функцию с go ключевого слова

Я думаю, что это не важно , что пакет, который вы используете (если у вас нет необходимости), но важно как Вы принимаете решение о регистрации ваших сообщений

Answer 4

Мое мнение, что для относительно простых «сервисно-подобных» soluti ons (долгосрочная программа, обслуживающая запросы пользователей), этот подход работает вполне нормально, если вы либо переключитесь на log.Fatal*(), который добавляет отметку времени для каждого вывода сообщения или запускает вашу службу под каким-либо разумным супервизором (systemd, daemon, , runit и т. д.), который пересылал бы то, что ваша программа выводит на приемник (ов) системного журнала.

Подход к регистрации также сильно зависит от характера программы. Скажем, для приложений с командной строкой, которые делают одноразовые действия (curl или wget - хороший пример такой программы — в духе вашего примера кода), вход в стандартный поток ошибок и выход - единственный нормальный режим работы , Ожидается, что демоны (службы) будут запускаться без присмотра, и, следовательно, вы должны убедиться, что они регистрируются и где-то хранятся, с отметкой времени.

Небольшое примечание: хорошая работа должна выводить сообщения об ошибках в стандартный поток ошибок, поэтому, если вы не хотите использовать log.Fatal*() для некоторого reaseon, по крайней мере, выполните fmt.Fprint*(os.Stderr, ...).