写Go项目的时候，很多人一开始都是用fmt.Println把信息直接打到控制台，项目小的时候勉强够用，等服务一上线、并发一高、需求一变，问题就全暴露了：日志没有级别区分，ERROR和普通信息混在一起；关键请求没有链路ID，出了问题根本串不起来；服务挂了没有指标可看，只能重启碰运气。日志和监控不是上线前才补的东西，而是项目骨架的一部分，越早接入成本越低。这篇文章就从一个初级项目的视角，讲讲日志该怎么组织、监控该怎么搭，给出的方案都不复杂，但足够规范。
一、日志设计：从随便打印到结构化输出
日志设计的第一步是选库。标准库的log包功能太弱，不支持级别、不支持结构化，只适合写demo。正式项目推荐用zap或者zerolog，这里以zap为例，它性能好、功能全，社区使用率也高。
先说级别。日志通常分Debug、Info、Warn、Error四档，Debug只在本机排查时开启，线上一般用Info级别。分级的目的不是形式，而是控制信噪比：半夜被报警吵醒的时候，你希望看到的是一条干净的ERROR，而不是几千条无关的普通输出。
再说结构化。所谓结构化日志，就是把每条日志写成键值对的形式，而不是拼字符串。拼字符串的问题在于没法检索，比如你想统计某个用户的所有请求日志，字符串日志只能靠grep，结构化日志直接按字段过滤就行。下面是一个可以直接用的初始化代码：
package logger
import (
"go.uber.org/zap"
"go.uber.org/zap/zapcore"
"gopkg.in/natefinch/lumberjack.v2"
)
func InitLog(logPath string) *zap.Logger {
encoderCfg := zapcore.EncoderConfig{
TimeKey: "ts",
LevelKey: "level",
MessageKey: "msg",
EncodeTime: zapcore.ISO8601TimeEncoder,
EncodeLevel: zapcore.LowercaseLevelEncoder,
EncodeDuration: zapcore.SecondsDurationEncoder,
}
// 输出到文件，并借助lumberjack实现自动轮转
w := zapcore.AddSync(&lumberjack.Logger{
Filename: logPath,
MaxSize: 100, // 单个文件最大100MB
MaxBackups: 5, // 保留5个备份
MaxAge: 30, // 最多保留30天
Compress: true,
})
core := zapcore.NewCore(
zapcore.NewJSONEncoder(encoderCfg),
w,
zapcore.InfoLevel,
)
return zap.New(core, zap.AddCaller(), zap.AddStacktrace(zapcore.ErrorLevel))
}这段代码里有两个细节值得注意。一是用JSON编码器，日志是标准的JSON格式，后续接ELK或者Loki都可以直接解析；二是用了lumberjack做轮转，避免日志文件无限膨胀把磁盘打满，这是很多初级项目容易忽略的一点，等服务跑半年磁盘满了才发现就晚了。
除了初始化，还有两个实践建议。第一，把logger做成全局单例或者通过依赖注入传递，不要在每个函数里重新创建，创建zap logger是有开销的。第二，Error级别的日志要附带足够上下文，比如用户ID、请求参数、错误堆栈，一条只写了"查询失败"的ERROR日志等于没写。
二、请求链路：让日志能串起来
单条日志有价值，但排查问题往往需要看一次请求的完整过程。做法是在请求入口生成一个trace ID，通过context在整条调用链里传递，每条日志都带上它。Go里用context.Context传递是最自然的方案。
先定义一个从context取logger的工具函数：
package logger
import (
"context"
"go.uber.org/zap"
)
type ctxKey struct{}
// WithLogger 把logger塞进context
func WithLogger(ctx context.Context, lg *zap.Logger) context.Context {
return context.WithValue(ctx, ctxKey{}, lg)
}
// FromCtx 取出logger，没有则返回全局默认值
func FromCtx(ctx context.Context) *zap.Logger {
if lg, ok := ctx.Value(ctxKey{}).(*zap.Logger); ok {
return lg
}
return zap.L()
}然后在HTTP中间件里生成trace ID并注入：
func TraceMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
traceID := uuid.NewString()
lg := zap.L().With(zap.String("trace_id", traceID))
ctx := WithLogger(r.Context(), lg)
next.ServeHTTP(w, r.WithContext(ctx))
})
}这样做之后，handler内部任何地方调用logger.FromCtx(ctx)拿到的logger都自带trace_id字段，grep一个ID就能看到这次请求的全部日志。另外别忘了在中间件里加panic恢复，把recover到的堆栈用Error级别记下来再返回500，否则进程直接崩掉，现场都没了：
func RecoverMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
defer func() {
if err := recover(); err != nil {
logger.FromCtx(r.Context()).Error("panic recovered",
zap.Any("error", err),
zap.String("path", r.URL.Path),
)
w.WriteHeader(http.StatusInternalServerError)
}
}()
next.ServeHTTP(w, r)
})
}三、监控设计：用Prometheus暴露核心指标
日志解决的是事后排查，监控解决的是实时感知。对初级项目来说，不需要一上来就上全套APM，用Prometheus暴露几个核心指标，再配Grafana画图，已经能覆盖百分之八十的需求。
Go侧接入非常简单，引入client_golang库，注册几个常用指标：
package metrics
import (
"github.com/prometheus/client_golang/prometheus"
"github.com/prometheus/client_golang/prometheus/promauto"
)
var (
HTTPRequests = promauto.NewCounterVec(prometheus.CounterOpts{
Name: "http_requests_total",
Help: "HTTP请求总数",
}, []string{"method", "path", "status"})
HTTPDuration = promauto.NewHistogramVec(prometheus.HistogramOpts{
Name: "http_request_duration_seconds",
Help: "HTTP请求耗时分布",
Buckets: []float64{0.01, 0.05, 0.1, 0.5, 1, 5},
}, []string{"method", "path"})
)然后在中间件里埋点，同时写一个/metrics端点供Prometheus抓取：
func MetricsMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
start := time.Now()
rw := &statusWriter{ResponseWriter: w, status: 200}
next.ServeHTTP(rw, r)
HTTPRequests.WithLabelValues(r.Method, r.URL.Path,
strconv.Itoa(rw.status)).Inc()
HTTPDuration.WithLabelValues(r.Method, r.URL.Path).
Observe(time.Since(start).Seconds())
})
}
// 注册指标端点
http.Handle("/metrics", promhttp.Handler())指标的选择有讲究。初级项目重点看三类：请求量（QPS）、错误率（非2xx占比）、延迟分布（P95、P99）。Counter适合累计值，Histogram适合看分布，不要用Gauge去存请求数这种单调递增的量。另外path标签要做归一化，把带ID的路径统一成模板形式，否则标签基数爆炸会把Prometheus内存吃垮。
Grafana那边导入官方的Go runtime dashboard，再把自定义的两个指标配上面板，配上错误率超过阈值就报警的规则，一套基础监控就成型了。
四、健康检查：给运维留一个入口
最后补一块容易被忽略的内容：健康检查接口。K8s的探针、负载均衡的存活检测都依赖它。初级项目至少提供两个端点：/healthz只表示进程活着，/readyz表示依赖是否就绪（数据库能连上、缓存可用）：
func healthz(w http.ResponseWriter, r *http.Request) {
w.WriteHeader(http.StatusOK)
w.Write([]byte("ok"))
}
func readyz(db *sql.DB) http.HandlerFunc {
return func(w http.ResponseWriter, r *http.Request) {
if err := db.PingContext(r.Context()); err != nil {
logger.FromCtx(r.Context()).Error("依赖检查失败", zap.Error(err))
w.WriteHeader(http.StatusServiceUnavailable)
return
}
w.WriteHeader(http.StatusOK)
}
}区分这两个接口的意义在于滚动发布：服务启动中还没就绪时，readyz返回失败，流量不会被切过来；而进程卡死时liveness探测失败会触发重启。两者混用一个接口，经常会出现服务还在预热就被误杀的情况。
总结一下，这套方案的核心思路是：结构化日志加trace ID保证可查，Prometheus指标保证可见，健康检查保证可管。三个部分加起来代码量不到两百行，但对项目稳定性的提升是实打实的。等业务复杂了，再考虑接入分布式追踪和告警系统，基础打得牢，后面扩展都不难。