

![Logging for Observability Visual](/strands/observability-visuals/logging-for-observability/the-visual-1.png)

![Logging for Observability Visual](/strands/observability-visuals/logging-for-observability/the-visual-2.png)

Logging for Observability


![Logging for Observability Visual](/strands/observability-visuals/understanding-lambda-logging/the-visual-1.png)

![Logging for Observability Visual](/strands/observability-visuals/understanding-lambda-logging/the-visual-2.png)


Understanding Lambda Logging


![Logging for Observability Visual](/strands/observability-visuals/how-lambda-logging-works/the-visual.png)


How Lambda Logging Works


![Logging for Observability Visual](/strands/observability-visuals/how-you-log-matters/the-visual-1.png)

![Logging for Observability Visual](/strands/observability-visuals/how-you-log-matters/the-visual-2.png)


How You Log Matters


In the [Observability Strand](/strands/observability) there is a common theme revolving around:

* Logging data about what your users are doing
* Logging data about what your services are doing
* Logging data in a structured way
* Recognising scalability problems that cause Serverless to go wrong

These are all great activities and ideas of exactly **What You Log Matters!**.  This is where your [Observability Mindset](/strands/observability/mindset) kicks in and you start to look at the data you need to discover what is going on.


![Logging for Observability Visual](/strands/observability-visuals/what-you-log-matters/the-visual.png)


## Make Your Logs Structured

The primary message with what to log comes back to doing it in a structured way.  The exact structure you use depends on where you plan to use the log data to make sense of your logs.  In a busy, distributed system, being able to search and filter across **all your log data** is critical for full observability.

### Your Service Domains Drive Logging Data

Serverless systems are distributed, and typically a service will contain more than a single lambda function.  When we design these systems, we break down processing into defined domains or bounded contexts.  We need to think about each domain and make sure all log entries clearly define where they belong.  In this way, we should end up with a hierarchy of log data domains representing the services domains across your distributed system.

![Bounded Context Venn Diagram Example](/strands/observability-visuals/what-you-log-matters/bounded-context.png)

In the above diagram, we see a typical breakdown of domains for a system focused on selling products.  Each of these system domains may also include several smaller services which drive the functional processing.  Using this domain breakdown we can introduce two key data elements for all logging across the system - **namespace** representing each bounded context and **service** representing each unique service within each bounded context.  Doing this starts to logically breakdown the logging data we emit from all of our services and, when it is structured, we will be able to start querying this data to uncover the truth of what our system is doing.  The following sample shows how you can represent this data in a structured JSON log message.

![structured log sample with namespace and service](/strands/observability-visuals/what-you-log-matters/structured-log.png)

Thinking about **What You Log** is critical to understanding and reasoning about how your system functions and whether it is working, or not!


What You Log Matters

Observability is not a hard topic and we all struggle with it for many different reasons.  In this strand, we are publishing a list of visuals on Observability to help visual learners.


Logging for Observability

Understanding Lambda Logging

How Lambda Logging Works

How You Log Matters

What You Log Matters

Fundamentals

Observability