Scala
Completed
-
Section 1: Getting Started
-
Section 2: Core Syntax
-
Section 3: Object-Oriented Scala
-
Section 4: Functional Scala
-
Section 5: Collections in Depth
-
Section 6: Type System
-
Section 7: Concurrency and Ecosystem
-
Section 8: Practical Projects
-
Section 9: Interview Practice
-
Section 10: Data Structures and Algorithms in Scala
-
Section 11: More Practice Exercises
-
Section 12: Advanced Functional Patterns
-
Section 13: More Ecosystem
-
Section 14: Scala Collections Library Deep Dive
-
Section 15: Scala Standard Library Deep Dive
-
Section 16: Akka Ecosystem Deep Dive
-
Section 17: Cats and Cats Effect Deep Dive
-
Section 18: Play Framework Deep Dive
-
Section 19: Apache Spark with Scala Deep Dive
-
Section 20: Scala Build Tools Deep Dive
-
Section 21: Scala 3 Specific Features
-
90: Union and Intersection Types
-
Section 22: Scala Testing Deep Dive
-
Section 23: Functional Domain Modeling
-
Section 24: More Data Structures and Algorithms in Scala
-
Section 25: Scala for Data Engineering
-
Section 26: More Practical Projects
-
Section 27: More Interview and Review
-
Section 28: ZIO Ecosystem Deep Dive
-
Section 29: Scala for Machine Learning
-
Section 30: Scala Microservices Architecture
-
Section 31: Scala Type System Deep Dive
-
Section 32: More Practice and Drills
-
Section 33: Scala Performance Deep Dive
-
Section 34: Scala Ecosystem Tooling
-
Section 35: Scala for Reactive Systems
-
Section 36: More Real-World Case Studies
-
Section 37: Scala for Financial Systems
-
Section 38: Scala GraphQL and gRPC
-
Section 39: More Final Projects
-
Section 40: More Interview and Final Review
-
Section 41: Scala for Streaming Data
-
Section 42: Scala Security Practices
-
Section 43: More Language Deep Dive
-
Section 44: Scala Command-Line Tools
-
Section 45: Scala Documentation and Style
-
Section 46: Scala Dependency Management
-
Section 47: More Practical Backend Patterns
-
Section 48: Scala for Event-Driven Architecture
-
Section 49: More Practice Drills Round 2
-
Section 50: Scala Compiler Deep Dive
-
Section 51: Scala for Web Frontends
-
Section 52: More Data Engineering Practice
-
Section 53: Scala Observability
-
Section 54: More Advanced Practice Projects
-
Section 55: Scala for Legacy Java Integration
-
Section 56: More Testing Practice
-
Section 57: Final Mastery Review
-
Section 58: Scala History and Ecosystem Context
-
Section 59: More Concurrency Patterns
-
Section 60: Scala for Configuration Management
-
Section 61: More Domain Modeling Practice
210: Structured Logging in Scala Applications
I once spent an entire Tuesday morning writing a complex regular expression to parse through five gigabytes of production logs. I was trying to find every instance where a specific set of payment parameters caused a timeout, but because the original developer used string interpolation for everything, the logs looked like this: Processed payment for user 123 with amount 50.00 in 200ms. Simple, right? Until another developer changed it to Payment processed: user=123, amt=50.00, time=200ms. My regex broke, and I wasted hours chasing a ghost.
case class PaymentRequest(userId: String, amount: Double, currency: String)
class PaymentService {
val logger = org.slf4j.LoggerFactory.getLogger(getClass)
def processPayment(req: PaymentRequest): Unit = {
// This looks fine during local development...
logger.info(s"Processing payment for user ${req.userId} of ${req.amount} ${req.currency}")
try {
// simulate logic
} catch {
case e: Exception =>
logger.error(s"Payment failed for user ${req.userId}: ${e.getMessage}")
}
}
}
The Nightmare of String Interpolation
The code above is what I call "human-readable, machine-useless." When you're staring at a terminal, Processing payment for user 123... is great. But when you move to a log aggregator like ELK (Elasticsearch, Logstash, Kibana) or Datadog, you don't want to "read" logs; you want to query them. If you want to find the average payment amount for users in the last hour, you can't do that with a string. You'd have to pull every single log line and run a regex parser over them in your head or via a slow script.
Turning Logs into Searchable Data
Structured logging flips the script. Instead of baking the data into a message string, we treat the log message as a static identifier and the data as a set of key-value pairs. In the Scala ecosystem, we usually achieve this by using a library like logback-scala or log4cats, paired with a JSON encoder (like the Logstash Logback Encoder).
Here is how I would rewrite that service to actually be useful in a production environment:
import net.logstash.logback.argument.StructuredArguments._
class PaymentService {
val logger = org.slf4j.LoggerFactory.getLogger(getClass)
def processPayment(req: PaymentRequest): Unit = {
// We use a static message and pass the data as structured arguments
logger.info("Processing payment",
kv("userId", req.userId),
kv("amount", req.amount),
kv("currency", req.currency)
)
try {
// simulate logic
} catch {
case e: Exception =>
logger.error("Payment failed",
kv("userId", req.userId),
kv("error", e.getMessage),
kv("stacktrace", e.getStackTrace)
)
}
}
}
Why This Actually Works
When this code runs with a JSON appender, it doesn't produce a sentence. It produces a JSON object:
{ "@timestamp": "2023-10-27T10:00:00.000Z", "message": "Processing payment", "userId": "123", "amount": 50.00, "currency": "USD", "level": "INFO" }Now, if I need to find all payments over $1,000, I don't write a regex. I write a query:
amount > 1000. It's instantaneous, it's precise, and it doesn't break when someone changes the word "Processing" to "Handling".One thing to watch out for: don't go overboard. I've seen developers log entire 50-field domain objects into every single log line. This bloats your storage costs and can actually slow down your application because of the serialization overhead. Only log the IDs and the specific fields you actually intend to filter or aggregate by.
📋 Practical Task
Refactoring the OrderProcessing Pipeline for JSON Log Observability
You have been handed a legacy OrderProcessor class that uses standard string interpolation for its logging. This has made it impossible for the SRE team to track order failure rates by region.
Your Task: Refactor the processOrder method to use structured logging. Replace the string interpolation in both the success and error paths with kv("key", value) pairs using the net.logstash.logback.argument.StructuredArguments library.
case class Order(id: String, customerId: String, total: Double, region: String)
class OrderProcessor {
val logger = org.slf4j.LoggerFactory.getLogger(getClass)
def processOrder(order: Order): Unit = {
// TODO: Refactor this log to be structured
logger.info(s"Starting processing for order ${order.id} in region ${order.region}")
try {
if (order.total < 0) throw new IllegalArgumentException("Negative total")
// TODO: Refactor this log to be structured
logger.info(s"Successfully processed order ${order.id} for customer ${order.customerId}")
} catch {
case e: Exception =>
// TODO: Refactor this log to be structured
logger.error(s"Order ${order.id} failed: ${e.getMessage}")
}
}
}
Requirements:
- The "Starting" log must include
orderIdandregion. - The "Success" log must include
orderIdandcustomerId. - The "Failure" log must include
orderIdand the error message. - All log messages must be converted to static strings (no
s"...").
There are no comments for now.