정교한 주문 처리 시스템 구현에 관한 시리즈의 다섯 번째 기사에 오신 것을 환영합니다! 이전 게시물에서는 기본 아키텍처 설정부터 고급 워크플로 구현 및 포괄적인 모니터링까지 모든 내용을 다루었습니다. 오늘 우리는 마이크로서비스 아키텍처에서 관찰 가능성을 유지하는 데 중요한 두 가지 구성 요소인 분산 추적 및 로깅의 세계를 살펴보겠습니다.
마이크로서비스 아키텍처에서는 단일 사용자 요청이 여러 서비스에 걸쳐 있는 경우가 많습니다. 이러한 분산 특성으로 인해 요청 흐름을 이해하고 문제가 발생할 때 이를 진단하는 것이 어렵습니다. 분산 추적 및 중앙 집중식 로깅은 다음을 제공하여 이러한 문제를 해결합니다.
분산 추적 및 로깅을 구현하기 위해 두 가지 강력한 도구 세트를 사용합니다.
OpenTelemetry: 단일 API, 라이브러리, 에이전트 및 수집기 서비스 세트를 제공하여 애플리케이션에서 분산 추적 및 측정항목을 캡처하는 클라우드 기반 소프트웨어용 관찰 프레임워크입니다.
ELK 스택 : 로그 수집, 저장 및 시각화를 위한 강력한 플랫폼을 함께 제공하는 Elastic의 세 가지 오픈 소스 제품(Elasticsearch, Logstash, Kibana) 컬렉션입니다.
이 게시물이 끝나면 다음을 수행할 수 있습니다.
들어가자!
구현을 시작하기 전에 분산 추적 및 로깅 설정에 중요한 몇 가지 주요 개념을 검토해 보겠습니다.
분산 추적은 분산 시스템의 다양한 서비스를 통해 요청이 흐르는 과정을 추적하는 방법입니다. 이는 다음을 포함하여 요청의 전체 수명주기를 이해하는 방법을 제공합니다.
트레이스는 일반적으로 하나 이상의 범위로 구성됩니다. 범위는 작업 단위 또는 작업 단위를 나타냅니다. 요청이 수행된 특정 작업을 추적하고 작업 시작 및 종료 시간과 기타 데이터를 기록합니다.
OpenTelemetry는 클라우드 기반 소프트웨어를 위한 관찰 프레임워크입니다. 이는 애플리케이션에서 분산 추적 및 지표를 캡처하기 위한 단일 API, 라이브러리, 에이전트 및 수집기 서비스 세트를 제공합니다. 주요 구성 요소는 다음과 같습니다.
분산 시스템의 효과적인 로그인에는 신중한 고려가 필요합니다.
ELK 스택은 로그 관리에 널리 사용되는 선택입니다.
로그 집계에는 다양한 소스에서 로그 데이터를 수집하여 중앙 위치에 저장하는 작업이 포함됩니다. 이는 다음을 가능하게 합니다:
로그 분석에는 로그 데이터에서 다음과 같은 의미 있는 통찰력을 추출하는 과정이 포함됩니다.
이러한 개념을 염두에 두고 주문 처리 시스템에서 분산 추적을 구현해 보겠습니다.
OpenTelemetry를 사용하여 주문 처리 시스템에 분산 추적을 구현하는 것부터 시작해 보겠습니다.
먼저 Go 서비스에 OpenTelemetry를 추가해야 합니다. go.mod 파일에 다음 종속성을 추가합니다.
require (
go.opentelemetry.io/otel v1.7.0
go.opentelemetry.io/otel/exporters/jaeger v1.7.0
go.opentelemetry.io/otel/sdk v1.7.0
go.opentelemetry.io/otel/trace v1.7.0
)
다음으로 주요 기능에서 추적 프로그램 공급자를 설정해 보겠습니다.
package main
import (
"log"
"go.opentelemetry.io/otel"
"go.opentelemetry.io/otel/attribute"
"go.opentelemetry.io/otel/exporters/jaeger"
"go.opentelemetry.io/otel/sdk/resource"
tracesdk "go.opentelemetry.io/otel/sdk/trace"
semconv "go.opentelemetry.io/otel/semconv/v1.4.0"
)
func initTracer() func() {
exporter, err := jaeger.New(jaeger.WithCollectorEndpoint(jaeger.WithEndpoint("http://jaeger:14268/api/traces")))
if err != nil {
log.Fatal(err)
}
tp := tracesdk.NewTracerProvider(
tracesdk.WithBatcher(exporter),
tracesdk.WithResource(resource.NewWithAttributes(
semconv.SchemaURL,
semconv.ServiceNameKey.String("order-processing-service"),
attribute.String("environment", "production"),
)),
)
otel.SetTracerProvider(tp)
return func() {
if err := tp.Shutdown(context.Background()); err != nil {
log.Printf("Error shutting down tracer provider: %v", err)
}
}
}
func main() {
cleanup := initTracer()
defer cleanup()
// Rest of your main function...
}
이는 널리 사용되는 분산 추적 백엔드인 Jaeger로 추적을 내보내는 추적 공급자를 설정합니다.
이제 주문 처리 워크플로에 추적을 추가해 보겠습니다. CreateOrder 함수부터 시작하겠습니다.
import (
"context"
"go.opentelemetry.io/otel"
"go.opentelemetry.io/otel/attribute"
"go.opentelemetry.io/otel/trace"
)
func CreateOrder(ctx context.Context, order Order) error {
tr := otel.Tracer("order-processing")
ctx, span := tr.Start(ctx, "CreateOrder")
defer span.End()
span.SetAttributes(attribute.Int64("order.id", order.ID))
span.SetAttributes(attribute.Float64("order.total", order.Total))
// Validate order
if err := validateOrder(ctx, order); err != nil {
span.RecordError(err)
span.SetStatus(codes.Error, "Order validation failed")
return err
}
// Process payment
if err := processPayment(ctx, order); err != nil {
span.RecordError(err)
span.SetStatus(codes.Error, "Payment processing failed")
return err
}
// Update inventory
if err := updateInventory(ctx, order); err != nil {
span.RecordError(err)
span.SetStatus(codes.Error, "Inventory update failed")
return err
}
span.SetStatus(codes.Ok, "Order created successfully")
return nil
}
이렇게 하면 CreateOrder 함수에 대한 새 범위가 생성되고 관련 속성이 추가됩니다. 또한 프로세스의 각 주요 단계에 대해 하위 범위를 생성합니다.
다른 서비스를 호출할 때 추적 컨텍스트를 전파해야 합니다. HTTP 클라이언트로 이 작업을 수행하는 방법의 예는 다음과 같습니다.
import (
"net/http"
"go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp"
)
func callExternalService(ctx context.Context, url string) error {
client := http.Client{Transport: otelhttp.NewTransport(http.DefaultTransport)}
req, err := http.NewRequestWithContext(ctx, "GET", url, nil)
if err != nil {
return err
}
_, err = client.Do(req)
return err
}
otelhttp 패키지를 사용하여 HTTP 헤더의 추적 컨텍스트를 자동으로 전파합니다.
비동기 작업의 경우 추적 컨텍스트가 올바르게 전달되는지 확인해야 합니다. 작업자 풀을 사용하는 예는 다음과 같습니다.
func processOrderAsync(ctx context.Context, order Order) {
tr := otel.Tracer("order-processing")
ctx, span := tr.Start(ctx, "processOrderAsync")
defer span.End()
workerPool <- func() {
processCtx := trace.ContextWithSpan(context.Background(), span)
if err := processOrder(processCtx, order); err != nil {
span.RecordError(err)
span.SetStatus(codes.Error, "Async order processing failed")
} else {
span.SetStatus(codes.Ok, "Async order processing succeeded")
}
}
}
이렇게 하면 비동기 작업을 위한 새로운 범위가 생성되어 작업자 함수에 전달됩니다.
OpenTelemetry를 임시 워크플로와 통합하려면 go.opentelemetry.io/contrib/instrumentation/go.temporal.io/temporal/oteltemporalgrpc 패키지를 사용할 수 있습니다.
import (
"go.temporal.io/sdk/client"
"go.temporal.io/sdk/worker"
"go.opentelemetry.io/contrib/instrumentation/go.temporal.io/temporal/oteltemporalgrpc"
)
func initTemporalClient() (client.Client, error) {
return client.NewClient(client.Options{
HostPort: "temporal:7233",
ConnectionOptions: client.ConnectionOptions{
DialOptions: []grpc.DialOption{
grpc.WithUnaryInterceptor(oteltemporalgrpc.UnaryClientInterceptor()),
grpc.WithStreamInterceptor(oteltemporalgrpc.StreamClientInterceptor()),
},
},
})
}
func initTemporalWorker(c client.Client, taskQueue string) worker.Worker {
w := worker.New(c, taskQueue, worker.Options{
WorkerInterceptors: []worker.WorkerInterceptor{
oteltemporalgrpc.WorkerInterceptor(),
},
})
return w
}
OpenTelemetry 계측을 사용하여 임시 클라이언트와 작업자를 설정합니다.
이미 initTracer 함수에서 Jaeger를 추적 백엔드로 설정했습니다. 추적을 시각화하려면 docker-compose.yml에 Jaeger를 추가해야 합니다.
services:
# ... other services ...
jaeger:
image: jaegertracing/all-in-one:1.35
ports:
- "16686:16686"
- "14268:14268"
environment:
- COLLECTOR_OTLP_ENABLED=true
이제 http://localhost:16686에서 Jaeger UI에 액세스하여 추적을 보고 분석할 수 있습니다.
다음 섹션에서는 분산 추적 설정을 보완하기 위해 ELK 스택을 사용하여 중앙 집중식 로깅을 설정하겠습니다.
이제 분산 추적이 완료되었으므로 ELK(Elasticsearch, Logstash, Kibana) 스택을 사용하여 중앙 집중식 로깅을 설정해 보겠습니다.
먼저 docker-compose.yml에 Elasticsearch를 추가해 보겠습니다.
services:
# ... other services ...
elasticsearch:
image: docker.elastic.co/elasticsearch/elasticsearch:7.14.0
environment:
- discovery.type=single-node
- "ES_JAVA_OPTS=-Xms512m -Xmx512m"
ports:
- "9200:9200"
volumes:
- elasticsearch_data:/usr/share/elasticsearch/data
volumes:
elasticsearch_data:
driver: local
개발 목적으로 단일 노드 Elasticsearch 인스턴스를 설정합니다.
Next, let’s add Logstash to our docker-compose.yml:
services:
# ... other services ...
logstash:
image: docker.elastic.co/logstash/logstash:7.14.0
volumes:
- ./logstash/pipeline:/usr/share/logstash/pipeline
ports:
- "5000:5000/tcp"
- "5000:5000/udp"
- "9600:9600"
depends_on:
- elasticsearch
Create a Logstash pipeline configuration file at ./logstash/pipeline/logstash.conf:
input {
tcp {
port => 5000
codec => json
}
}
filter {
if [trace_id] {
mutate {
add_field => { "[@metadata][trace_id]" => "%{trace_id}" }
}
}
}
output {
elasticsearch {
hosts => ["elasticsearch:9200"]
index => "order-processing-logs-%{+YYYY.MM.dd}"
}
}
This configuration sets up Logstash to receive JSON logs over TCP, process them, and forward them to Elasticsearch.
Now, let’s add Kibana to our docker-compose.yml:
services:
# ... other services ...
kibana:
image: docker.elastic.co/kibana/kibana:7.14.0
ports:
- "5601:5601"
environment:
ELASTICSEARCH_URL: http://elasticsearch:9200
ELASTICSEARCH_HOSTS: '["http://elasticsearch:9200"]'
depends_on:
- elasticsearch
You can access the Kibana UI at http://localhost:5601 once it’s up and running.
To send structured logs to Logstash, we’ll use the logrus library. First, add it to your go.mod:
go get github.com/sirupsen/logrus
Now, let’s set up a logger in our main function:
import (
"github.com/sirupsen/logrus"
"gopkg.in/sohlich/elogrus.v7"
)
func initLogger() *logrus.Logger {
log := logrus.New()
log.SetFormatter(&logrus.JSONFormatter{})
hook, err := elogrus.NewElasticHook("elasticsearch:9200", "warning", "order-processing-logs")
if err != nil {
log.Fatalf("Failed to create Elasticsearch hook: %v", err)
}
log.AddHook(hook)
return log
}
func main() {
log := initLogger()
// Rest of your main function...
}
This sets up a JSON formatter for our logs and adds an Elasticsearch hook to send logs directly to Elasticsearch.
Now, let’s update our CreateOrder function to use structured logging:
func CreateOrder(ctx context.Context, order Order) error {
tr := otel.Tracer("order-processing")
ctx, span := tr.Start(ctx, "CreateOrder")
defer span.End()
logger := logrus.WithFields(logrus.Fields{
"order_id": order.ID,
"trace_id": span.SpanContext().TraceID().String(),
})
logger.Info("Starting order creation")
// Validate order
if err := validateOrder(ctx, order); err != nil {
logger.WithError(err).Error("Order validation failed")
span.RecordError(err)
span.SetStatus(codes.Error, "Order validation failed")
return err
}
// Process payment
if err := processPayment(ctx, order); err != nil {
logger.WithError(err).Error("Payment processing failed")
span.RecordError(err)
span.SetStatus(codes.Error, "Payment processing failed")
return err
}
// Update inventory
if err := updateInventory(ctx, order); err != nil {
logger.WithError(err).Error("Inventory update failed")
span.RecordError(err)
span.SetStatus(codes.Error, "Inventory update failed")
return err
}
logger.Info("Order created successfully")
span.SetStatus(codes.Ok, "Order created successfully")
return nil
}
This code logs each step of the order creation process, including any errors that occur. It also includes the trace ID in each log entry, which will be crucial for correlating logs with traces.
Now that we have both distributed tracing and centralized logging set up, let’s explore how to correlate this information for a unified view of system behavior.
We’ve already included the trace ID in our log entries. To make this correlation even more powerful, we can add a custom field to our spans that includes the log index:
span.SetAttributes(attribute.String("log.index", "order-processing-logs-"+time.Now().Format("2006.01.02")))
This allows us to easily jump from a span in Jaeger to the corresponding logs in Kibana.
We’ve already added trace IDs to our log entries in the previous section. This allows us to search for all log entries related to a particular trace in Kibana.
To link our Prometheus metrics to traces, we can use exemplars. Here’s an example of how to do this:
import (
"github.com/prometheus/client_golang/prometheus"
"github.com/prometheus/client_golang/prometheus/promauto"
"go.opentelemetry.io/otel/trace"
)
var (
orderProcessingDuration = promauto.NewHistogramVec(
prometheus.HistogramOpts{
Name: "order_processing_duration_seconds",
Help: "Duration of order processing in seconds",
Buckets: prometheus.DefBuckets,
},
[]string{"status"},
)
)
func CreateOrder(ctx context.Context, order Order) error {
// ... existing code ...
start := time.Now()
// ... process order ...
duration := time.Since(start)
orderProcessingDuration.WithLabelValues("success").Observe(duration.Seconds(), prometheus.Labels{
"trace_id": span.SpanContext().TraceID().String(),
})
// ... rest of the function ...
}
This adds the trace ID as an exemplar to our order processing duration metric.
With logs, traces, and metrics all correlated, we can create a unified view of our system’s behavior:
This allows you to seamlessly navigate between metrics, traces, and logs, providing a comprehensive view of your system’s behavior and making it easier to debug issues.
With our logs centralized in Elasticsearch, let’s explore some strategies for effective log aggregation and analysis.
For high-volume services, logging every event can be prohibitively expensive. Implement log sampling to reduce the volume while still maintaining visibility:
func shouldLog() bool {
return rand.Float32() < 0.1 // Log 10% of events
}
func CreateOrder(ctx context.Context, order Order) error {
// ... existing code ...
if shouldLog() {
logger.Info("Order created successfully")
}
// ... rest of the function ...
}
In Kibana, create dashboards that provide insights into your system’s behavior. Some useful visualizations might include:
Use Kibana’s alerting features to set up alerts based on log patterns. For example:
Elasticsearch provides machine learning capabilities that can be used for anomaly detection in logs. You can set up machine learning jobs in Kibana to detect:
These machine learning insights can help you identify issues before they become critical problems.
In the next sections, we’ll cover best practices for logging in a microservices architecture and explore some advanced OpenTelemetry techniques.
When implementing logging in a microservices architecture, there are several best practices to keep in mind to ensure your logs are useful, manageable, and secure.
Consistency in log formats across all your services is crucial for effective log analysis. In our Go services, we can create a custom logger that enforces a standard format:
import (
"github.com/sirupsen/logrus"
)
type StandardLogger struct {
*logrus.Logger
ServiceName string
}
func NewStandardLogger(serviceName string) *StandardLogger {
logger := logrus.New()
logger.SetFormatter(&logrus.JSONFormatter{
FieldMap: logrus.FieldMap{
logrus.FieldKeyTime: "timestamp",
logrus.FieldKeyLevel: "severity",
logrus.FieldKeyMsg: "message",
},
})
return &StandardLogger{
Logger: logger,
ServiceName: serviceName,
}
}
func (l *StandardLogger) WithFields(fields logrus.Fields) *logrus.Entry {
return l.Logger.WithFields(logrus.Fields{
"service": l.ServiceName,
}).WithFields(fields)
}
This logger ensures that all log entries include a “service” field and use consistent field names.
Contextual logging involves including relevant context with each log entry. In a microservices architecture, this often means including a request ID or trace ID that can be used to correlate logs across services:
func CreateOrder(ctx context.Context, logger *StandardLogger, order Order) error {
tr := otel.Tracer("order-processing")
ctx, span := tr.Start(ctx, "CreateOrder")
defer span.End()
logger := logger.WithFields(logrus.Fields{
"order_id": order.ID,
"trace_id": span.SpanContext().TraceID().String(),
})
logger.Info("Starting order creation")
// ... rest of the function ...
}
It’s crucial to ensure that sensitive information, such as personal data or credentials, is not logged. You can create a custom log hook to redact sensitive information:
type SensitiveDataHook struct{}
func (h *SensitiveDataHook) Levels() []logrus.Level {
return logrus.AllLevels
}
func (h *SensitiveDataHook) Fire(entry *logrus.Entry) error {
if entry.Data["credit_card"] != nil {
entry.Data["credit_card"] = "REDACTED"
}
return nil
}
// In your main function:
logger.AddHook(&SensitiveDataHook{})
In a production environment, you need to manage log retention and rotation to control storage costs and comply with data retention policies. While Elasticsearch can handle this to some extent, you might also want to implement log rotation at the application level:
import (
"gopkg.in/natefinch/lumberjack.v2"
)
func initLogger() *logrus.Logger {
logger := logrus.New()
logger.SetOutput(&lumberjack.Logger{
Filename: "/var/log/myapp.log",
MaxSize: 100, // megabytes
MaxBackups: 3,
MaxAge: 28, //days
Compress: true,
})
return logger
}
For certain operations, you may need to maintain an audit trail for compliance reasons. You can create a separate audit logger for this purpose:
type AuditLogger struct {
logger *logrus.Logger
}
func NewAuditLogger() *AuditLogger {
logger := logrus.New()
logger.SetFormatter(&logrus.JSONFormatter{})
// Set up a separate output for audit logs
// This could be a different file, database, or even a separate Elasticsearch index
return &AuditLogger{logger: logger}
}
func (a *AuditLogger) LogAuditEvent(ctx context.Context, event string, details map[string]interface{}) {
span := trace.SpanFromContext(ctx)
a.logger.WithFields(logrus.Fields{
"event": event,
"trace_id": span.SpanContext().TraceID().String(),
"details": details,
}).Info("Audit event")
}
// Usage:
auditLogger.LogAuditEvent(ctx, "OrderCreated", map[string]interface{}{
"order_id": order.ID,
"user_id": order.UserID,
})
Now that we have a solid foundation for distributed tracing, let’s explore some advanced techniques to get even more value from OpenTelemetry.
Custom span attributes and events can provide additional context to your traces:
func ProcessPayment(ctx context.Context, order Order) error {
_, span := otel.Tracer("payment-service").Start(ctx, "ProcessPayment")
defer span.End()
span.SetAttributes(
attribute.String("payment.method", order.PaymentMethod),
attribute.Float64("payment.amount", order.Total),
)
// Process payment...
if paymentSuccessful {
span.AddEvent("PaymentProcessed", trace.WithAttributes(
attribute.String("transaction_id", transactionID),
))
} else {
span.AddEvent("PaymentFailed", trace.WithAttributes(
attribute.String("error", "Insufficient funds"),
))
}
return nil
}
Baggage allows you to propagate key-value pairs across service boundaries:
import (
"go.opentelemetry.io/otel/baggage"
)
func AddUserInfoToBaggage(ctx context.Context, userID string) context.Context {
b, _ := baggage.Parse(fmt.Sprintf("user_id=%s", userID))
return baggage.ContextWithBaggage(ctx, b)
}
func GetUserIDFromBaggage(ctx context.Context) string {
if b := baggage.FromContext(ctx); b != nil {
if v := b.Member("user_id"); v.Key() != "" {
return v.Value()
}
}
return ""
}
For high-volume services, tracing every request can be expensive. Implement a sampling strategy to reduce the volume while still maintaining visibility:
import (
"go.opentelemetry.io/otel/sdk/trace"
"go.opentelemetry.io/otel/sdk/trace/sampling"
)
sampler := sampling.ParentBased(
sampling.TraceIDRatioBased(0.1), // Sample 10% of traces
)
tp := trace.NewTracerProvider(
trace.WithSampler(sampler),
// ... other options ...
)
While we’ve been using Jaeger as our tracing backend, you might want to create a custom exporter for a different backend or for special processing:
type CustomExporter struct{}
func (e *CustomExporter) ExportSpans(ctx context.Context, spans []trace.ReadOnlySpan) error {
for _, span := range spans {
// Process or send the span data as needed
fmt.Printf("Exporting span: %s\n", span.Name())
}
return nil
}
func (e *CustomExporter) Shutdown(ctx context.Context) error {
// Cleanup logic here
return nil
}
// Use the custom exporter:
exporter := &CustomExporter{}
tp := trace.NewTracerProvider(
trace.WithBatcher(exporter),
// ... other options ...
)
OpenTelemetry can be integrated with many existing monitoring tools. For example, to send traces to both Jaeger and Zipkin:
jaegerExporter, _ := jaeger.New(jaeger.WithCollectorEndpoint(jaeger.WithEndpoint("http://jaeger:14268/api/traces")))
zipkinExporter, _ := zipkin.New("http://zipkin:9411/api/v2/spans")
tp := trace.NewTracerProvider(
trace.WithBatcher(jaegerExporter),
trace.WithBatcher(zipkinExporter),
// ... other options ...
)
These advanced techniques will help you get the most out of OpenTelemetry in your order processing system.
In the next sections, we’ll cover performance considerations, testing and validation strategies, and discuss some challenges and considerations when implementing distributed tracing and logging at scale.
When implementing distributed tracing and logging, it’s crucial to consider the performance impact on your system. Let’s explore some strategies to optimize performance.
type AsyncLogger struct {
ch chan *logrus.Entry
}
func NewAsyncLogger(bufferSize int) *AsyncLogger {
logger := &AsyncLogger{
ch: make(chan *logrus.Entry, bufferSize),
}
go logger.run()
return logger
}
func (l *AsyncLogger) run() {
for entry := range l.ch {
entry.Logger.Out.Write(entry.Bytes())
}
}
func (l *AsyncLogger) Log(entry *logrus.Entry) {
select {
case l.ch <- entry:
default:
// Buffer full, log dropped
}
}
func (l *AsyncLogger) SampledLog(entry *logrus.Entry, sampleRate float32) {
if rand.Float32() < sampleRate {
l.Log(entry)
}
}
sampler := trace.ParentBased(
trace.TraceIDRatioBased(0.1), // Sample 10% of traces
)
tp := trace.NewTracerProvider(
trace.WithSampler(sampler),
// ... other options ...
)
func ProcessOrder(ctx context.Context, order Order) error {
ctx, span := tracer.Start(ctx, "ProcessOrder")
defer span.End()
// Don't create a span for this quick operation
validateOrder(order)
// Create a span for this potentially slow operation
ctx, paymentSpan := tracer.Start(ctx, "ProcessPayment")
err := processPayment(ctx, order)
paymentSpan.End()
if err != nil {
return err
}
// ... rest of the function
}
Use the OpenTelemetry SDK’s built-in batching exporter to reduce the number of network calls:
exporter, err := jaeger.New(jaeger.WithCollectorEndpoint(jaeger.WithEndpoint("http://jaeger:14268/api/traces")))
if err != nil {
log.Fatalf("Failed to create Jaeger exporter: %v", err)
}
tp := trace.NewTracerProvider(
trace.WithBatcher(exporter,
trace.WithMaxExportBatchSize(100),
trace.WithBatchTimeout(5 * time.Second),
),
// ... other options ...
)
PUT _ilm/policy/logs_policy
{
"policy": {
"phases": {
"hot": {
"actions": {
"rollover": {
"max_size": "50GB",
"max_age": "1d"
}
}
},
"delete": {
"min_age": "30d",
"actions": {
"delete": {}
}
}
}
}
}
Use a caching layer like Redis to store frequently accessed logs and traces:
import (
"github.com/go-redis/redis/v8"
)
func getCachedTrace(traceID string) (*Trace, error) {
val, err := redisClient.Get(ctx, "trace:"+traceID).Bytes()
if err == redis.Nil {
// Trace not in cache, fetch from storage and cache it
trace, err := fetchTraceFromStorage(traceID)
if err != nil {
return nil, err
}
redisClient.Set(ctx, "trace:"+traceID, trace, 1*time.Hour)
return trace, nil
} else if err != nil {
return nil, err
}
var trace Trace
json.Unmarshal(val, &trace)
return &trace, nil
}
Proper testing and validation are crucial to ensure the reliability of your distributed tracing and logging implementation.
Use the OpenTelemetry testing package to unit test your trace instrumentation:
import (
"testing"
"go.opentelemetry.io/otel/sdk/trace/tracetest"
)
func TestProcessOrder(t *testing.T) {
sr := tracetest.NewSpanRecorder()
tp := trace.NewTracerProvider(trace.WithSpanProcessor(sr))
otel.SetTracerProvider(tp)
ctx := context.Background()
err := ProcessOrder(ctx, Order{ID: "123"})
if err != nil {
t.Errorf("ProcessOrder failed: %v", err)
}
spans := sr.Ended()
if len(spans) != 2 {
t.Errorf("Expected 2 spans, got %d", len(spans))
}
if spans[0].Name() != "ProcessOrder" {
t.Errorf("Expected span named 'ProcessOrder', got '%s'", spans[0].Name())
}
if spans[1].Name() != "ProcessPayment" {
t.Errorf("Expected span named 'ProcessPayment', got '%s'", spans[1].Name())
}
}
Set up integration tests that cover your entire tracing pipeline:
func TestTracingPipeline(t *testing.T) {
// Start a test Jaeger instance
jaeger := startTestJaeger()
defer jaeger.Stop()
// Initialize your application with tracing
app := initializeApp()
// Perform some operations that should generate traces
resp, err := app.CreateOrder(Order{ID: "123"})
if err != nil {
t.Fatalf("Failed to create order: %v", err)
}
// Wait for traces to be exported
time.Sleep(5 * time.Second)
// Query Jaeger for the trace
traces, err := jaeger.QueryTraces(resp.TraceID)
if err != nil {
t.Fatalf("Failed to query traces: %v", err)
}
// Validate the trace
validateTrace(t, traces[0])
}
Test your Logstash configuration to ensure it correctly parses and processes logs:
input {
generator {
message => '{"timestamp":"2023-06-01T10:00:00Z","severity":"INFO","message":"Order created","order_id":"123","trace_id":"abc123"}'
count => 1
}
}
filter {
json {
source => "message"
}
}
output {
stdout { codec => rubydebug }
}
Run this configuration with logstash -f test_config.conf and verify the output.
Perform load tests to understand the performance impact of tracing:
func BenchmarkWithTracing(b *testing.B) {
// Initialize tracing
tp := initTracer()
defer tp.Shutdown(context.Background())
b.ResetTimer()
for i := 0; i < b.N; i++ {
ctx, span := tp.Tracer("benchmark").Start(context.Background(), "operation")
performOperation(ctx)
span.End()
}
}
func BenchmarkWithoutTracing(b *testing.B) {
for i := 0; i < b.N; i++ {
performOperation(context.Background())
}
}
Compare the results to understand the overhead introduced by tracing.
Set up monitoring for your tracing and logging systems:
As you implement and scale your distributed tracing and logging system, keep these challenges and considerations in mind:
이 게시물에서는 주문 처리 시스템에 대한 포괄적인 분산 추적 및 로깅을 다루었습니다. OpenTelemetry로 추적을 구현하고, ELK 스택으로 중앙 집중식 로깅을 설정하고, 상관 로그와 추적을 설정하고, 고급 기술과 고려 사항을 살펴봤습니다.
시리즈의 다음이자 마지막 부분에서는 생산 준비 상태와 확장성에 중점을 둘 것입니다. 우리가 다룰 내용은 다음과 같습니다.
정교한 주문 처리 시스템을 마무리하여 대규모 생산에 사용할 수 있도록 준비하는 동안 계속 지켜봐 주시기 바랍니다!
어려운 문제에 직면했거나 새로운 아이디어나 프로젝트에 대한 외부 관점이 필요합니까? 제가 도와드릴 수 있어요! 대규모 투자를 하기 전에 기술 개념 증명을 구축하려는 경우나 어려운 문제에 대한 지침이 필요한 경우 제가 도와드리겠습니다.
저와 함께 일하는 데 관심이 있으시면 hangaikevin@gmail.com으로 이메일을 보내주세요.
당신의 도전을 기회로 바꾸세요!
위 내용은 주문 처리 시스템 구현: 부품 분산 추적 및 로깅의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
