Heim  >  Artikel  >  Backend-Entwicklung  >  Ermitteln Sie mithilfe der Uber/Zap-Protokollierung in der gRPC-Middleware die tatsächliche Fehlerquelle in Go

Ermitteln Sie mithilfe der Uber/Zap-Protokollierung in der gRPC-Middleware die tatsächliche Fehlerquelle in Go

王林
王林nach vorne
2024-02-09 13:18:08419Durchsuche

使用 gRPC 中间件中的 Uber/Zap 日志记录获取 Go 中的实际错误源

PHP-Editor Zimo stellt in diesem Artikel vor, wie man die Uber/Zap-Protokollierung verwendet, um die tatsächliche Fehlerquelle in der Go-Sprache zu ermitteln, wenn gRPC-Middleware verwendet wird. Durch den Einsatz dieser Middleware können wir Fehler im Code besser verstehen und verfolgen und so Probleme schneller lokalisieren und lösen. In diesem Artikel erfahren Sie, wie Sie die Uber/Zap-Protokollierung konfigurieren und verwenden und wie Sie Fehlerinformationen in gRPC-Anfragen und -Antworten erfassen und protokollieren. Durch die Beherrschung dieser Techniken können wir unsere Debugging- und Fehlerbehandlungsfähigkeiten in gRPC-Anwendungen verbessern.

Frageninhalt

Ich verwende das Paket uber/zap für die Protokollierung. In meinem Design protokolliere ich alle Fehler in der Middleware des grpc-Pakets. Ich möchte protokollieren, von welcher Datei und Zeilennummer der Fehler stammt. Derzeit kann ich jedoch nur den Dateinamen und die Zeilennummer der aktuellen Middleware abrufen. Gibt es eine Möglichkeit, die tatsächliche Fehlerquelle herauszufinden?

func RegisterLogger(c config.Config) *zap.SugaredLogger {

    var logger *zap.Logger
    var err error
    if c.IsDebug {
        logger, err = zap.NewDevelopment()
    } else {
        logger, err = zap.NewProduction()
    }

    if err != nil {
        panic(err)
    }
    defer logger.Sync()

    return logger.Sugar()
}



func (s *ProviderServer) Pay(ctx context.Context, in *payment.PayRequest) (string, error) {
    resp, err := ctx.Value(in.Provider).(provider.IPayment).Exec(ctx, in)

    if err != nil {
            pc, file, line, ok := runtime.Caller(2)
            if ok {
                file = filepath.Base(file)
                nowTime := time.Now().Format("2006/01/02 15:04:05")
                funcName := runtime.FuncForPC(pc).Name()
                funcName = filepath.Ext(funcName)
                funcName = strings.TrimPrefix(funcName, ".")
                s.log.Info("Times:", i, " nowTime:", nowTime, " file:", file, " line:", line, " funcName:", funcName, " err:", err)
            }
        
//Log the error information, including which file the error comes from.

        return resp.Result, err
    } else {
        s.log.Info("resp:", resp)
    }

}

Workaround

In der aktuellen Implementierung versuchen Sie, die Datei- und Zeilennummer zu protokollieren, in der der Fehler aufgetreten ist. Die Informationen, die Sie erhalten, beziehen sich jedoch auf die aktuelle Middleware und nicht auf die tatsächliche Fehlerquelle.

Um die Datei- und Zeileninformationen der tatsächlichen Fehlerquelle zu erhalten, können Sie das Paket pkg/errors verwenden. Dieses Paket bietet eine Möglichkeit, Fehler zu umschließen und Datei- und Zeileninformationen beizubehalten. Hier ist ein Beispiel dafür, wie Sie Ihren Code ändern, um dies zu erreichen:

import (
    "github.com/pkg/errors"
)

// ...

func (s *ProviderServer) Pay(ctx context.Context, in *payment.PayRequest) (string, error) {
    resp, err := ctx.Value(in.Provider).(provider.IPayment).Exec(ctx, in)

    if err != nil {
        // Wrap the error with file and line information
        err = errors.Wrap(err, "pay error")

        // Log the wrapped error
        s.log.Errorw("Error occurred", "error", err)

        return resp.Result, err
    } else {
        s.log.Infow("Request processed successfully", "response", resp)
        return resp.Result, nil
    }
}

Wenn Sie einen Fehler mit errors.wrap 函数包装错误,您可以将文件和行信息添加到错误中。然后,当使用 s.log.errorw protokollieren, enthält die Protokollnachricht einen vollständigen Stack-Trace, einschließlich der Datei- und Zeileninformationen, aus denen der Fehler stammt.

Auf diese Weise können Sie die vom errors-Paket bereitgestellten Informationen nutzen, um der tatsächlichen Fehlerquelle auf die Spur zu kommen.

Das obige ist der detaillierte Inhalt vonErmitteln Sie mithilfe der Uber/Zap-Protokollierung in der gRPC-Middleware die tatsächliche Fehlerquelle in Go. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Dieser Artikel ist reproduziert unter:stackoverflow.com. Bei Verstößen wenden Sie sich bitte an admin@php.cn löschen