Golang의 글로벌 로깅에 대한 올바른 접근 방식

Golang의 글로벌 로깅에 대한 올바른 접근 방식

---

Go에서 애플리케이션 로깅의 패턴은 무엇입니까? 예를 들어 5 개의 고 루틴을 기록해야한다면 ...

• 싱글을 log.Logger만들고 전달 하시겠습니까?
• 그것에 대한 포인터를 전달 log.Logger하시겠습니까?
• 각 고 루틴 또는 함수가 로거를 만들어야합니까?
• 로거를 전역 변수로 만들어야합니까?

---

• 단일 로그를 만들고 로거를 전달 하시겠습니까?

가능합니다. log.Logger는 여러 goroutines에서 동시에 사용할 수 있습니다.

• 해당 로그에 대한 포인터를 전달합니다.

log.New*Logger 는 일반적으로 객체를 포인터로 전달해야 함을 나타내는를 반환합니다 . 값으로 전달하면 구조체의 복사본 (즉, Logger의 복사본)이 생성되고 여러 고 루틴이 동일한 io.Writer에 동시에 쓸 수 있습니다 . 작성자의 구현에 따라 심각한 문제가 될 수 있습니다.

• 각 고 루틴 또는 함수가 로거를 만들어야합니까?

각 기능 또는 고 루틴에 대해 별도의 로거를 만들지 않습니다. 고 루틴 (및 기능)은 별도의 로거의 유지 보수를 정당화하지 않는 매우 가벼운 작업에 사용됩니다. 프로젝트의 더 큰 구성 요소마다 로거를 만드는 것이 좋습니다. 예를 들어 프로젝트에서 메일을 보내기 위해 SMTP 서비스를 사용하는 경우 메일 서비스에 대해 별도의 로거를 만드는 것이 좋은 생각처럼 들리므로 출력을 별도로 필터링하고 끌 수 있습니다.

• 로거를 전역 변수로 만들어야합니까?

패키지에 따라 다릅니다. 이전 메일 서비스 예에서 서비스의 각 인스턴스에 대해 하나의 로거를 사용하는 것이 좋습니다. 그래야 사용자가 Gmail 메일 서비스를 사용하는 동안 오류를 로컬 MTA를 사용하는 동안 발생한 오류 (예 : sendmail ).

---

간단한 경우에는 로그 패키지에 정의 된 전역 로거가 log.Logger있습니다. 이 글로벌 로거는를 통해 구성 할 수 있습니다 log.SetFlags.

이후 하나는 바로 최상위 같은 로그 패키지의 기능을 호출 할 수 있습니다 log.Printf및 log.Fatalf그 글로벌 인스턴스를 사용합니다.

---

이것은 간단한 로거입니다

package customlogger

import (
    "log"
    "os"
    "sync"
)

type logger struct {
    filename string
    *log.Logger
}

var logger *logger
var once sync.Once

// start loggeando
func GetInstance() *logger {
    once.Do(func() {
        logger = createLogger("mylogger.log")
    })
    return logger
}

func createLogger(fname string) *logger {
    file, _ := os.OpenFile(fname, os.O_RDWR|os.O_CREATE|os.O_TRUNC, 0777)

    return &logger{
        filename: fname,
        Logger:   log.New(file, "My app Name ", log.Lshortfile),
    }
}

이런 식으로 사용할 수 있습니다

package main

import (
    "customlogger"
    "fmt"
    "net/http"
)

func main() {
    logger := customlogger.GetInstance()
    logger.Println("Starting")

    http.HandleFunc("/", sroot)
    http.ListenAndServe(":8080", nil)
}

func sroot(w http.ResponseWriter, r *http.Request) {
    logger := customlogger.GetInstance()

    fmt.Fprintf(w, "welcome")
    logger.Println("Starting")
}

---

이 질문이 조금 오래 logger.go되었다는 것을 알고 있지만 저처럼 프로젝트가 네 번째 옵션에 투표하는 여러 개의 작은 파일로 구성되어 있다면 패키지 메인의 일부인을 만들었습니다 . 이 go 파일은 로거를 생성하고 파일에 할당하고 나머지 main에 제공합니다. 참고 오류 로그를 닫는 우아한 방법을 찾지 못했습니다 ...

package main

import (
    "fmt"
    "log"
    "os"
)

var errorlog *os.File
var logger *log.Logger

func init() {
    errorlog, err := os.OpenFile(logfile,  os.O_RDWR|os.O_CREATE|os.O_APPEND, 0666)
    if err != nil {
        fmt.Printf("error opening file: %v", err)
        os.Exit(1)
    }

    logger = log.New(errorlog, "applog: ", log.Lshortfile|log.LstdFlags)
}

---

This is an older question, but I would like to suggest the use of http://github.com/romana/rlog (which we developed). It is configured through environment variables, the logger object is created and initialized when rlog is imported. Therefore, no need to pass around a logger.

rlog has quite a few features:

• Fully configurable date/time stamps
• Simultaneous output to stderr or stdout as well as file.
• Standard log levels (Debug, Info, etc.) as well as freely-configurable multi-level logging.
• On demand logging of caller info (file, line number, function).
• Ability to set different log levels for different source files.

It is very small, has no external dependencies, except the standard Golang library and is actively being developed. Examples are provided in the repo.

---

I found the default log package (https://golang.org/pkg/log/) somewhat limiting. For example, no support for info vs. debug logs.
After some poking around, settled on using https://github.com/golang/glog . This seems to be a port of https://github.com/google/glog and gives decent flexibility in logging. For example when running an application locally you may want DEBUG level log but might want to run only in INFO/ERROR level in production. The list of full features/guide is, here https://google-glog.googlecode.com/svn/trunk/doc/glog.html (Its for the c++ module, but for the most part translates to the golang port)

참고URL : https://stackoverflow.com/questions/18361750/correct-approach-to-global-logging-in-golang