An application log records messages about service activity. In a live microservice system, logs help explain what happened when a problem occurs and reveal application-level anomalies, such as rising error rates. They complement metrics and traces: a metric can expose an anomaly, while related logs provide detail about activity at that time. section 9.3.7 section 9.4
Logs from multiple services are hard to read as one operation unless they share a filterable field. Include an operation’s distributed trace ID in each relevant entry so a logging backend can retrieve its messages together. Structured key-value fields, such as an order ID, provide another way to narrow a search. section 9.3.7
...
type serviceLogger struct {
formatter log.JSONFormatter #1
}
func (l serviceLogger) Format(entry *log.Entry) ([]byte, error) {
span := trace.SpanFromContext(entry.Context) #2
entry.Data["trace_id"] = span.SpanContext().TraceID().String()
entry.Data["span_id"] = span.SpanContext().SpanID().String()
//Below injection is Just to understand what Context has
entry.Data["Context"] = span.SpanContext()
return l.formatter.Format(entry) #3
}
...
This Go logrus formatter reads span data from the log entry’s context, adds trace and span IDs, and emits the entry through a JSON formatter. A log call must carry its context for the formatter to use that span. section 9.3.7
For a Go gRPC service, configure the formatter at startup and write contextual entries during operations such as CreateOrder. A cluster-level pipeline can collect logs with Fluent Bit, store them in Elasticsearch, and search or visualize them in Kibana. Log patterns can also support alerts. section 9.3.7 section 9.4
