Logging in LLD - Learning Module

Loading content...

0/246

What to Log

The Art of Capturing the Right Information

You're investigating a payment failure that affected 47 customers last night. The ERROR log says:

2024-01-15 03:47:23 ERROR PaymentProcessor - Payment failed

That's it. No transaction ID. No user ID. No amount. No error code. No indication of which payment gateway was involved or what stage of processing failed.

This log is almost worse than no log at all—it tells you something happened without giving you any way to understand what happened or how to fix it.

Compare this to a well-crafted log:

{
  "timestamp": "2024-01-15T03:47:23.847Z",
  "level": "ERROR",
  "event": "PAYMENT_PROCESSING_FAILED",
  "transactionId": "txn_a1b2c3d4e5",
  "orderId": "ord_f6g7h8i9j0",
  "userId": "usr_k1l2m3n4o5",
  "amount": 149.99,
  "currency": "USD",
  "gateway": "stripe",
  "stage": "CHARGE",
  "errorCode": "card_declined",
  "errorMessage": "Your card was declined due to insufficient funds.",
  "declineCode": "insufficient_funds",
  "cardLast4": "4242",
  "processingTimeMs": 847,
  "correlationId": "req_p6q7r8s9t0",
  "serviceVersion": "2.4.1"
}

With this log, you can immediately identify the affected customers, understand the failure reason, and know exactly where in the process it failed. The difference is not volume—it's precision.

What You Will Learn

By the end of this page, you will know exactly what information to capture in your logs: identifiers for correlation, context for understanding, metadata for analysis, and timing for performance. You'll learn to balance completeness with conciseness, and you'll understand what to never log.

The Fundamental Principle: Log for Investigation

Every log entry should answer one question: "When I'm investigating an issue at 3 AM with incomplete information, what will I need to know?"

This principle guides all decisions about what to log. You're not logging for yourself right now—you're logging for a stressed engineer (possibly yourself) in the future who has:

Limited context about the code
Limited time to investigate
Limited ability to reproduce the issue
A need to understand what happened from the logs alone

Good logs provide self-contained context. Someone unfamiliar with the code should be able to read the logs and understand what the system was trying to do, what state it was in, and what went wrong.

The Five W's of Logging

•WHO — Who initiated this action? User ID, service account, system process, external client
•WHAT — What operation was performed? What was the outcome? What was the input and output?
•WHEN — When did this happen? Precise timestamps with timezone, duration of operations
•WHERE — Where in the system? Server, service, component, method, line number (for errors)
•WHY — Why did something fail? Error codes, exception messages, validation failures, business rule violations

The Context Question

Before writing any log statement, ask: 'If this is the only log I see, what else would I need to know?' Then include that information. Logs should minimize the need to check other sources.

Identifiers and Correlation: Connecting the Dots

Identifiers are the glue that connects related log entries. Without them, logs are scattered puzzle pieces; with them, you can reconstruct the complete picture of any operation.

Essential Identifiers to Log

•Request/Correlation ID — A unique identifier for each request that flows through the entire system. This is the single most important identifier—it lets you trace a request across all services and components.
•User/Actor ID — Who triggered the operation. Essential for debugging user-reported issues and for audit trails.
•Session ID — Links multiple requests from the same user session. Useful for understanding user journey and diagnosing stateful issues.
•Transaction ID — Identifies business transactions that may span multiple requests or processes. Critical for financial systems.
•Entity IDs — The primary keys of domain objects involved: order ID, product ID, customer ID, etc.
•Trace/Span ID — If using distributed tracing, include trace and span IDs for deep diving in tracing tools.

CorrelationExample.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
public class OrderController {
    private static final Logger logger = LoggerFactory.getLogger(OrderController.class);
    
    @PostMapping("/orders")
    public ResponseEntity<OrderResponse> createOrder(
            @RequestBody CreateOrderRequest request,
            @RequestHeader("X-Correlation-Id") String correlationId,
            @AuthenticationPrincipal User user) {
        
        // MDC (Mapped Diagnostic Context) adds these to ALL logs in this thread
        MDC.put("correlationId", correlationId);
        MDC.put("userId", user.getId());
        MDC.put("sessionId", user.getSessionId());
        
        try {
            // All subsequent logs automatically include correlation context
            logger.info("ORDER_CREATE_STARTED: itemCount={}, totalAmount={}",
                request.getItems().size(), request.getTotalAmount());
            
            Order order = orderService.createOrder(request);
            
            // Add order ID to context for remaining operations
            MDC.put("orderId", order.getId());
            
            logger.info("ORDER_CREATED: status={}", order.getStatus());
            
            // All these identifiers help correlate:
            // - This request with requests from the same user session
            // - This order with all subsequent operations on it
            // - This request with calls to downstream services
            
            return ResponseEntity.ok(OrderResponse.from(order));
            
        } finally {
            MDC.clear();
        }
    }
}
 
public class OrderService {
    private static final Logger logger = LoggerFactory.getLogger(OrderService.class);
    
    public Order createOrder(CreateOrderRequest request) {
        // MDC values (correlationId, userId, sessionId) are automatically included
        String orderId = generateOrderId();
        MDC.put("orderId", orderId);
        
        logger.debug("Validating order items");
        validateItems(request.getItems());
        
        logger.debug("Checking inventory");
        InventoryResult inventory = inventoryService.checkAvailability(request.getItems());
        
        logger.debug("Processing payment");
        PaymentResult payment = paymentService.charge(request.getPaymentDetails());
        
        // Every log from every service can be correlated by correlationId
        // Every log about this order can be found by orderId
        // Every log from this user can be found by userId
        
        return orderRepository.save(new Order(orderId, request, payment));
    }
}

MDC/Context Propagation

Most logging frameworks support Mapped Diagnostic Context (MDC) or similar mechanisms. Use them! Setting identifiers in MDC means every log statement automatically includes them without cluttering your code.

Operational Context: Understanding the Environment

Beyond identifiers, logs need operational context—information about the environment and infrastructure that helps you understand where and how something happened.

Operational Context to Include
Category	Fields	Why It Matters
Service Identity	serviceName, serviceVersion, instanceId	Know which exact version of which service produced this log
Environment	environment (prod/staging/dev), region, datacenter, cluster	Distinguish production issues from dev noise; localize regional problems
Host Information	hostname, containerIdeventId, pod name (K8s)	Identify specific instances; correlate with infrastructure metrics
Deployment	deploymentId, buildNumber, gitCommit	Link behavior to specific deployments; identify regression sources
Thread/Process	threadName, processId	Debug concurrency issues; understand parallel execution

LogConfiguration.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
/**
 * Startup configuration that sets up operational context
 * in MDC for all logging throughout the application lifecycle.
 */
@Component
public class LoggingContextInitializer implements ApplicationListener<ContextRefreshedEvent> {
    
    @Value("${spring.application.name}")
    private String serviceName;
    
    @Value("${app.version}")
    private String serviceVersion;
    
    @Value("${app.environment}")
    private String environment;
    
    @Value("${app.instance-id:${random.uuid}}")
    private String instanceId;
    
    @Override
    public void onApplicationEvent(ContextRefreshedEvent event) {
        // These will be included in every log entry
        MDC.put("serviceName", serviceName);
        MDC.put("serviceVersion", serviceVersion);
        MDC.put("environment", environment);
        MDC.put("instanceId", instanceId);
        MDC.put("hostname", getHostname());
        
        // Git commit if available (set during build)
        String gitCommit = System.getenv("GIT_COMMIT");
        if (gitCommit != null) {
            MDC.put("gitCommit", gitCommit.substring(0, 7)); // Short SHA
        }
        
        logger.info("LOGGING_CONTEXT_INITIALIZED: Operational context set for all logs");
    }
    
    private String getHostname() {
        try {
            return InetAddress.getLocalHost().getHostName();
        } catch (UnknownHostException e) {
            return System.getenv("HOSTNAME");
        }
    }
}
 
/**
 * Example log output with full operational context:
 * 
 * {
 *   "timestamp": "2024-01-15T10:30:45.123Z",
 *   "level": "INFO",
 *   "logger": "com.example.OrderService",
 *   "message": "ORDER_CREATED",
 *   "serviceName": "order-service",
 *   "serviceVersion": "2.4.1",
 *   "environment": "production",
 *   "instanceId": "i-0abc123def456",
 *   "hostname": "order-service-5f7b8c9d-xyz",
 *   "gitCommit": "a1b2c3d",
 *   "correlationId": "req-123-456-789",
 *   "userId": "usr-abc-123",
 *   "orderId": "ord-xyz-789",
 *   "orderAmount": 149.99,
 *   "itemCount": 3
 * }
 */

Why Operational Context Matters:

Imagine you're investigating an intermittent error. Without operational context:

You don't know if it's happening in one region or globally
You can't tell if it started after a deployment
You can't identify if one instance is misbehaving

With operational context, you can immediately narrow down:

"This only happens in us-east-1"
"This started with version 2.4.0"
"This is only from instance i-0abc123def456"

Business and Domain Data: The Substance of Logs

Identifiers and operational context are metadata. The substance of your logs is business and domain data—the specific information about what your application is actually doing.

Business Data to Log

•Event Type/Name — A clear, searchable identifier for what happened: ORDER_CREATED, PAYMENT_PROCESSED, USER_REGISTERED
•Operation Inputs — Key parameters that drove the operation (but NOT sensitive data)
•Operation Outputs — Result status, key output values, identifiers of created entities
•Decision Points — When code takes different paths, log why: 'Using cached result', 'Applying discount rule X'
•State Transitions — When entities change state: 'Order status changed from PENDING to CONFIRMED'
•Quantities and Amounts — Numbers that help understand scope: item count, total amount, batch size
•External Interactions — Calls to external services, their inputs and outputs

BusinessLogging.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
public class OrderProcessor {
    private static final Logger logger = LoggerFactory.getLogger(OrderProcessor.class);
    
    public OrderResult process(Order order) {
        logger.info("ORDER_PROCESSING_STARTED: orderId={}, status={}, itemCount={}, totalAmount={}, currency={}",
            order.getId(), order.getStatus(), order.getItems().size(), 
            order.getTotalAmount(), order.getCurrency());
        
        // Log decision point: which pricing rules applied
        PricingResult pricing = pricingEngine.calculate(order);
        logger.info("PRICING_CALCULATED: orderId={}, subtotal={}, discount={}, discountReason={}, tax={}, total={}",
            order.getId(), pricing.getSubtotal(), pricing.getDiscount(),
            pricing.getDiscountReason(), pricing.getTax(), pricing.getTotal());
        
        // Log state transition
        OrderStatus previousStatus = order.getStatus();
        order.setStatus(OrderStatus.PROCESSING);
        logger.info("ORDER_STATUS_CHANGED: orderId={}, previousStatus={}, newStatus={}, reason=PROCESSING_STARTED",
            order.getId(), previousStatus, order.getStatus());
        
        // Log external interaction
        PaymentResult payment = paymentGateway.charge(order);
        logger.info("PAYMENT_CHARGED: orderId={}, transactionId={}, gateway={}, amount={}, currency={}, responseCode={}",
            order.getId(), payment.getTransactionId(), payment.getGateway(),
            payment.getAmount(), payment.getCurrency(), payment.getResponseCode());
        
        // Log final state
        order.setStatus(OrderStatus.CONFIRMED);
        logger.info("ORDER_CONFIRMED: orderId={}, transactionId={}, processingTimeMs={}",
            order.getId(), payment.getTransactionId(), 
            System.currentTimeMillis() - startTime);
        
        return new OrderResult(order, payment);
    }
}

Balance Detail with Volume

Don't log every field of every object. Focus on the fields that are: (1) useful for investigation, (2) useful for business metrics, or (3) needed for audit. Logging entire objects is verbose and often includes sensitive data accidentally.

Timing and Performance Data

Timing information transforms logs from a debugging tool into a performance analysis platform. By logging durations, you can identify bottlenecks, track performance over time, and detect degradation before it becomes critical.

Timing Data to Capture

•Total operation duration — End-to-end time for the complete operation
•Stage/step durations — Time spent in each significant phase (database, external API, computation)
•Queue wait times — How long items waited before processing
•Timestamps at key points — Start time, completion time, key milestones
•Timeout thresholds — When logging timeouts, include what the threshold was
•Retry timing — Time between retries, total time including retries

TimingExample.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
public class PerformanceAwareService {
    private static final Logger logger = LoggerFactory.getLogger(PerformanceAwareService.class);
    
    public SearchResult search(SearchRequest request) {
        long startTime = System.currentTimeMillis();
        
        // Phase 1: Parse and validate
        long parseStart = System.currentTimeMillis();
        ParsedQuery query = queryParser.parse(request.getQuery());
        long parseMs = System.currentTimeMillis() - parseStart;
        
        // Phase 2: Execute search
        long searchStart = System.currentTimeMillis();
        List<Document> results = searchIndex.search(query);
        long searchMs = System.currentTimeMillis() - searchStart;
        
        // Phase 3: Rank results
        long rankStart = System.currentTimeMillis();
        List<RankedDocument> ranked = ranker.rank(results, query);
        long rankMs = System.currentTimeMillis() - rankStart;
        
        // Phase 4: Fetch metadata
        long metadataStart = System.currentTimeMillis();
        List<EnrichedDocument> enriched = metadataService.enrich(ranked);
        long metadataMs = System.currentTimeMillis() - metadataStart;
        
        long totalMs = System.currentTimeMillis() - startTime;
        
        // Log with full timing breakdown
        logger.info("SEARCH_COMPLETED: query={}, resultCount={}, totalMs={}, " +
            "parseMs={}, searchMs={}, rankMs={}, metadataMs={}, " +
            "percentSearch={}, percentMetadata={}",
            request.getQuery(), enriched.size(), totalMs,
            parseMs, searchMs, rankMs, metadataMs,
            (searchMs * 100.0 / totalMs), (metadataMs * 100.0 / totalMs));
        
        // Alert if performance degrades
        if (totalMs > PERFORMANCE_THRESHOLD_MS) {
            logger.warn("SEARCH_SLOW: query={}, totalMs={}, threshold={}, " +
                "slowestPhase={}, slowestPhaseMs={}",
                request.getQuery(), totalMs, PERFORMANCE_THRESHOLD_MS,
                getSlowestPhase(parseMs, searchMs, rankMs, metadataMs),
                Math.max(Math.max(parseMs, searchMs), Math.max(rankMs, metadataMs)));
        }
        
        return new SearchResult(enriched, totalMs);
    }
}

Timing Enables Dashboards

With timing data in logs, you can build dashboards showing p50/p95/p99 latencies, breakdown by phase, trends over time, and automatic anomaly detection. This is often cheaper and faster than dedicated APM tools.

Error Information: Diagnosing Failures

When things go wrong, the quality of your error logs determines how quickly you can diagnose and fix the issue. Error logs need to be complete and actionable.

Essential Error Information

•What was attempted — The operation that failed, with enough context to understand the goal
•What input/state triggered the failure — Parameters, entity state, request details (sanitized)
•What exactly failed — Error type, error code, error message
•Stack trace — For unexpected exceptions, the full stack trace is essential
•Where in the flow it failed — Which stage/step of a multi-step operation
•What was the impact — Did the operation fail entirely? Partially succeed? Was data affected?
•What can be done — For recoverable errors, what actions might help?

Bad
1
2
3
4
5
6
7
8
9
10
11
12
13
// ❌ USELESS ERROR LOG
try {
    processOrder(order);
} catch (Exception e) {
    logger.error("Error processing order");
    // No context, no exception, nothing useful
}
 
// Or even worse:
} catch (Exception e) {
    logger.error(e.getMessage());
    // Just "null" or cryptic message, no stack trace
}

Good
1
2
3
4
5
6
7
8
9
10
11
12
13
// ✅ ACTIONABLE ERROR LOG
try {
    processOrder(order);
} catch (PaymentException e) {
    logger.error("PAYMENT_FAILED: orderId={}, userId={}, " +
        "amount={}, gateway={}, stage={}, " +
        "errorCode={}, errorMessage={}, retryable={}",
        order.getId(), order.getUserId(),
        order.getAmount(), paymentGateway.getName(),
        e.getStage(), e.getErrorCode(),
        e.getMessage(), e.isRetryable(), e);
    // Full context + exception with stack trace
}

ComprehensiveErrorLogging.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
public class RobustDataProcessor {
    private static final Logger logger = LoggerFactory.getLogger(RobustDataProcessor.class);
    
    public ProcessResult processRecord(DataRecord record) {
        try {
            // Attempt processing
            validateRecord(record);
            TransformResult transformed = transform(record);
            return persist(transformed);
            
        } catch (ValidationException e) {
            // Expected error - data quality issue
            logger.warn("RECORD_VALIDATION_FAILED: recordId={}, source={}, " +
                "validationErrors={}, fieldsFailed={}, action=SKIPPED",
                record.getId(), record.getSource(),
                e.getErrors(), e.getFailedFields());
            return ProcessResult.skipped(e.getErrors());
            
        } catch (TransformException e) {
            // Processing logic failed - might be a bug or edge case
            logger.error("RECORD_TRANSFORM_FAILED: recordId={}, source={}, " +
                "transformStage={}, inputValue={}, error={}, " +
                "action=SENT_TO_DLQ",
                record.getId(), record.getSource(),
                e.getStage(), sanitize(e.getInputValue()),
                e.getMessage(), e);
            deadLetterQueue.send(record, e);
            return ProcessResult.failed(e);
            
        } catch (DatabaseException e) {
            // Infrastructure failure - might need intervention
            logger.error("RECORD_PERSIST_FAILED: recordId={}, source={}, " +
                "database={}, operation={}, sqlState={}, " +
                "error={}, retryable={}, action=RETRY_QUEUED",
                record.getId(), record.getSource(),
                dbConfig.getHost(), e.getOperation(),
                e.getSqlState(), e.getMessage(),
                e.isRetryable(), e);
            if (e.isRetryable()) {
                retryQueue.enqueue(record, e);
                return ProcessResult.willRetry();
            } else {
                deadLetterQueue.send(record, e);
                return ProcessResult.failed(e);
            }
            
        } catch (Exception e) {
            // Unexpected error - definitely needs investigation
            logger.error("RECORD_PROCESSING_UNEXPECTED_ERROR: recordId={}, " +
                "source={}, recordType={}, recordSize={}, " +
                "exceptionType={}, error={}, action=SENT_TO_DLQ_FOR_INVESTIGATION",
                record.getId(), record.getSource(),
                record.getType(), record.getSize(),
                e.getClass().getName(), e.getMessage(), e);
            deadLetterQueue.send(record, e);
            return ProcessResult.failed(e);
        }
    }
}

What NOT to Log: Sensitive Data and Security

Equally important as what to log is what not to log. Logging sensitive data creates security vulnerabilities, compliance violations, and privacy breaches. This isn't optional—it's a critical security practice.

Never Log These

•Passwords and secrets — Passwords, API keys, tokens, encryption keys, private keys, credentials of any kind
•Payment card data — Full card numbers, CVV/CVC, PINs. PCI-DSS compliance prohibits this.
•Personal Identifiable Information (PII) — SSN, passport numbers, driver's license, full birthdates, precise geolocation
•Health information — Medical records, diagnoses, prescriptions (HIPAA compliance)
•Authentication tokens — JWTs, session tokens, OAuth tokens, refresh tokens
•Financial account numbers — Full bank account numbers, routing numbers
•Internal system secrets — Database connection strings with passwords, internal service credentials

SafeLogging.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
public class SafeLoggingExamples {
    private static final Logger logger = LoggerFactory.getLogger(SafeLoggingExamples.class);
    
    // ❌ DANGEROUS - NEVER DO THIS
    public void dangerousLogging(PaymentRequest request) {
        logger.info("Processing payment: cardNumber={}, cvv={}, expiry={}", 
            request.getCardNumber(),  // Full card number!
            request.getCvv(),         // CVV!
            request.getExpiry());     // Could be sensitive
    }
    
    // ✅ SAFE - Masked/truncated sensitive data
    public void safeLogging(PaymentRequest request) {
        logger.info("Processing payment: cardLast4={}, cardType={}, expiryMonth={}", 
            maskCard(request.getCardNumber()),
            detectCardType(request.getCardNumber()),
            request.getExpiryMonth());
    }
    
    // ❌ DANGEROUS - Logging full request bodies
    public void dangerousRequestLogging(HttpRequest request) {
        logger.debug("Received request: body={}", request.getBody());
        // Body might contain passwords, tokens, or other secrets!
    }
    
    // ✅ SAFE - Sanitized logging
    public void safeRequestLogging(HttpRequest request) {
        logger.debug("Received request: path={}, method={}, contentType={}, contentLength={}",
            request.getPath(), request.getMethod(),
            request.getContentType(), request.getContentLength());
    }
    
    // Utility methods for safe logging
    private String maskCard(String cardNumber) {
        if (cardNumber == null || cardNumber.length() < 4) return "****";
        return "****" + cardNumber.substring(cardNumber.length() - 4);
    }
    
    private String maskEmail(String email) {
        if (email == null || !email.contains("@")) return "***@***";
        String[] parts = email.split("@");
        return parts[0].charAt(0) + "***@" + parts[1];
    }
    
    private String maskToken(String token) {
        if (token == null || token.length() < 8) return "***";
        return token.substring(0, 4) + "..." + token.substring(token.length() - 4);
    }
}

Compliance Is Not Optional

Logging sensitive data can violate GDPR, HIPAA, PCI-DSS, SOX, and other regulations. Violations can result in fines in the millions, lawsuits, and criminal liability. Implement automated scanning for sensitive data in logs.

Safe Practices for Sensitive Context

•Mask or truncate — Show only last 4 digits of cards/accounts, first initial of names
•Hash identifiers — If you need to correlate without exposing, hash the value consistently
•Log references, not values — 'Using credentials from vault:payment-api' not the actual credentials
•Allowlist fields — Instead of logging all fields, explicitly log only safe fields
•Automated scanning — Use tools to scan logs for accidentally exposed secrets
•Encryption at rest — Even safe logs should be encrypted, but never rely on this for sensitive data

Logging at System Boundaries

System boundaries—where your code interacts with external systems, receives requests, or sends data out—are the most important places to log. These are where issues most often occur and where visibility is most valuable.

Key Boundary Types

•Inbound requests — API endpoints, message consumers, webhook handlers
•Outbound calls — HTTP clients, database queries, message producers, external APIs
•Authentication/Authorization — Login attempts, permission checks, token validation
•File I/O — Reading/writing files, S3 operations, file uploads
•Queue interactions — Publishing messages, consuming messages, acknowledgments

BoundaryLogging.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
@Aspect
@Component
public class BoundaryLoggingAspect {
    private static final Logger logger = LoggerFactory.getLogger(BoundaryLoggingAspect.class);
    
    /**
     * Log all inbound API requests
     */
    @Around("@annotation(org.springframework.web.bind.annotation.RequestMapping) || " +
            "@annotation(org.springframework.web.bind.annotation.GetMapping) || " +
            "@annotation(org.springframework.web.bind.annotation.PostMapping)")
    public Object logInboundRequest(ProceedingJoinPoint joinPoint) throws Throwable {
        HttpServletRequest request = getCurrentRequest();
        long startTime = System.currentTimeMillis();
        
        logger.info("HTTP_REQUEST_RECEIVED: method={}, path={}, remoteAddr={}, userAgent={}",
            request.getMethod(), request.getRequestURI(),
            request.getRemoteAddr(), request.getHeader("User-Agent"));
        
        try {
            Object result = joinPoint.proceed();
            long duration = System.currentTimeMillis() - startTime;
            
            logger.info("HTTP_REQUEST_COMPLETED: method={}, path={}, status=200, durationMs={}",
                request.getMethod(), request.getRequestURI(), duration);
            
            return result;
        } catch (Exception e) {
            long duration = System.currentTimeMillis() - startTime;
            
            logger.error("HTTP_REQUEST_FAILED: method={}, path={}, error={}, durationMs={}",
                request.getMethod(), request.getRequestURI(), e.getMessage(), duration, e);
            
            throw e;
        }
    }
    
    /**
     * Log all outbound HTTP calls
     */
    @Around("execution(* org.springframework.web.client.RestTemplate.*(..))")
    public Object logOutboundHttp(ProceedingJoinPoint joinPoint) throws Throwable {
        Object[] args = joinPoint.getArgs();
        String url = extractUrl(args);
        String method = extractMethod(joinPoint);
        long startTime = System.currentTimeMillis();
        
        logger.debug("HTTP_OUTBOUND_STARTED: method={}, url={}", method, url);
        
        try {
            Object result = joinPoint.proceed();
            long duration = System.currentTimeMillis() - startTime;
            
            logger.info("HTTP_OUTBOUND_COMPLETED: method={}, url={}, durationMs={}",
                method, url, duration);
            
            return result;
        } catch (Exception e) {
            long duration = System.currentTimeMillis() - startTime;
            
            logger.error("HTTP_OUTBOUND_FAILED: method={}, url={}, error={}, durationMs={}",
                method, url, e.getMessage(), duration);
                
            throw e;
        }
    }
    
    /**
     * Log database queries (be careful with query content - may contain PII)
     */
    @Around("execution(* javax.persistence.EntityManager.*(..)) || " +
            "execution(* org.springframework.data.repository.CrudRepository.*(..))")
    public Object logDatabaseOperation(ProceedingJoinPoint joinPoint) throws Throwable {
        String operation = joinPoint.getSignature().getName();
        long startTime = System.currentTimeMillis();
        
        try {
            Object result = joinPoint.proceed();
            long duration = System.currentTimeMillis() - startTime;
            
            // Log slow queries at WARN level
            if (duration > 100) {
                logger.warn("DATABASE_SLOW_QUERY: operation={}, durationMs={}, threshold=100",
                    operation, duration);
            } else {
                logger.debug("DATABASE_QUERY: operation={}, durationMs={}", operation, duration);
            }
            
            return result;
        } catch (Exception e) {
            long duration = System.currentTimeMillis() - startTime;
            
            logger.error("DATABASE_ERROR: operation={}, error={}, durationMs={}",
                operation, e.getMessage(), duration, e);
            throw e;
        }
    }
}

Summary: What to Log

Let's consolidate the key insights about what to include in your logs:

Key Takeaways

•Log for investigation — Every log should help the stressed 3 AM investigator understand what happened
•Include identifiers — Correlation ID, user ID, entity IDs. These are the glue that connects related logs.
•Add operational context — Service name, version, environment, host. Know where logs came from.
•Capture business data — What was attempted, what was the input, what was the outcome
•Include timing — Duration enables performance analysis without separate instrumentation
•Make errors actionable — Full context, the exception, what can be done about it
•Never log secrets — Passwords, tokens, PII, card numbers. No exceptions.
•Focus on boundaries — Inbound requests, outbound calls, database operations, message handling

What's Next:

Now that we know what information to capture, the next page covers structured logging—how to format logs for machine parsing, analysis, and efficient querying at scale.

Page Complete

You now understand what information to capture in your logs. Good logs tell a complete story with identifiers, context, business data, timing, and actionable error information—all while protecting sensitive data. Next, we'll explore structured logging for efficient analysis at scale.