📊 MCD Level 2 Part 4: Observability, Logging & MUnit — Know What Your APIs Are Really Doing

Beyond MCD Level 1: Cracking the MuleSoft MCD Level 2 Certification — Part 4 of 5

Production visibility and automated testing are core competencies for an integration architect. The MCD Level 2 exam tests your ability to expose meaningful health metrics, trace distributed transactions, and build resilient MUnit test suites.

Production integration is not complete when the API returns the expected response.

A production-grade Mule application must also answer three questions:

• Is the application actually available?
• What happened when something failed?
• Can we prove that the application behaves correctly after every change?

That is where observability, logging, and automated testing become critical.

For MCD Level 2, these topics are less about remembering individual Studio components and more about understanding why a particular monitoring or testing strategy is appropriate.

1. Monitoring & Logging Architecture

Observability in Mule 4 goes beyond adding a Logger processor to a flow.

A useful production observability strategy normally combines:

Mule Application
                          |
          +---------------+---------------+
          |               |               |
          v               v               v
       Metrics          Logs           Traces
          |               |               |
          +---------------+---------------+
                          |
                          v
                 Anypoint Monitoring
                 / External Platform

Each provides a different view of the application.

• Metrics tell you what is happening at scale.
• Logs tell you what happened during execution.
• Tracing helps you follow an execution across processors and services.
• Functional monitoring verifies that an API actually behaves as expected.

The important architectural principle is:

Monitoring tells you that something is wrong; logging and tracing help you understand why.

2. Health Checks, Readiness & Functional Monitoring

These concepts are easy to confuse in an MCD Level 2 question.

Health Check

A health check is intended to determine whether an application or endpoint is responding as expected.

For example:

GET /health

200 OK
{
  "status": "UP"
}

When designing a health-check endpoint, understand what exactly you are trying to prove.

A simple endpoint might only prove that the application can accept an HTTP request.

A deeper health check might also verify mandatory dependencies.

However, these are different guarantees.

Basic Health Check

Client
  |
  v
Mule Application
  |
  v
200 OK

Meaning:
"The application endpoint responded."

versus:

Dependency-Aware Health Check

Client
  |
  v
Mule Application
  |
  +----> Database
  |
  +----> Salesforce
  |
  +----> External Service
  |
  v
Healthy / Unhealthy

The second approach gives stronger information, but it also introduces additional network calls and failure dependencies.

Therefore:

Do not automatically assume that every health check must call every backend system.

The correct design depends on what “healthy” means for that application.

Exam Tip: Health Check Port

A common MCD Level 2 scenario asks how to test whether a production API is operational.

Do not assume that the correct answer is always:

“Reuse the same port and listener as the business API.”

A dedicated health-check endpoint can be exposed using a separate listener/port when the goal is to isolate health monitoring from normal API traffic.

The key is understanding what is being tested and what component owns the health check.

For API Functional Monitoring, MuleSoft provides scheduled tests against API endpoints. These tests can validate HTTP responses and assertions from configured monitoring locations.

So distinguish:

Application Health
       |
       v
"Is the application endpoint responding?"

Readiness
       |
       v
"Can this instance safely receive traffic?"

Functional Monitoring
       |
       v
"Does the API actually behave as expected?"

These are related, but they are not interchangeable concepts.

3. Readiness Is Not the Same as Health

A readiness check answers a different question:

Should this instance receive traffic right now?

For example:

Application starts
       |
       v
Runtime initialized?
       |
      No
       |
       v
   NOT READY

       Yes
       |
       v
Mandatory dependencies available?
       |
      No
       |
       v
   NOT READY

       Yes
       |
       v
     READY

Whether a dependency should be included depends on whether that dependency is mandatory for serving traffic.

For example, if a database is required for every meaningful API operation, database availability may reasonably be part of readiness.

But if the application can continue serving requests using cached data or a degraded mode, making database availability a hard readiness requirement may be inappropriate.

This is an architectural decision — not a universal Mule rule.

4. Structured Logging with MDC

When processing high-volume events such as orders, manually adding an Order ID to every Logger message quickly becomes repetitive.

For example, this approach becomes difficult to maintain:

Logger:
"Starting order " ++ orderId

Logger:
"Calling payment service for " ++ orderId

Logger:
"Payment completed for " ++ orderId

Logger:
"Updating order " ++ orderId

Mule’s Tracing Module provides a cleaner approach.

The Set Logging Variable operation adds a variable to the logging context of the current Mule event.

For example:

Set Logging Variable

variableName = orderId
value        = #[payload.orderId]

Once configured correctly, the logging context can contain:

{
    correlationId: "...",
    processorPath: "...",
    orderId: "ORD-1001"
}

MuleSoft documents that MDC enriches logging for the current Mule event, while the Tracing Module allows additional logging variables to be added, removed, or cleared.

The conceptual flow is:

HTTP Request
     |
     v
Set Logging Variable
orderId = ORD-1001
     |
     +-----------------------+
     |                       |
     v                       v
   Logger              Internal Logs
     |                       |
     +-----------+-----------+
                 |
                 v
          Correlated Context

This is particularly useful when multiple processors generate logs during the same event execution.

Important Platform Consideration

MDC logging has deployment-specific limitations.

MuleSoft documentation currently states that MDC logging is not supported for applications deployed to Runtime Fabric or CloudHub 2.0.

Therefore, do not blindly assume that an MDC-based logging design behaves identically across every Mule deployment target.

For modern observability architectures, also be aware that Mule runtime supports OpenTelemetry, and logging variables can contribute custom attributes to spans and log records.

5. Log4j2: Logger vs Appender

Mule 4 uses Log4j2 for application logging.

One common exam trap is confusing a Logger with an Appender.

Think of them as two different responsibilities:

Logger
  |
  +--> Which logging category?
  |
  +--> What level?
  |
  v
ERROR / WARN / INFO / DEBUG

        +

Appender
  |
  +--> Where should the log go?
  |
  +--> Console?
  +--> File?
  +--> External destination?

For example, if you need additional logging for the VM connector, you can configure a connector-specific logger:

<AsyncLogger
    level="ERROR"
    name="org.mule.extensions.vm"/>

The important point is that the logger configuration controls the logging category and level.

The appender defines the destination/output behavior.

Therefore:

Do not use the Appenders section to configure which connector emits DEBUG or ERROR messages.

For troubleshooting, connector-specific logging is preferable to globally setting every Mule logger to DEBUG.

6. Connector-Level Metrics vs Raw Logs

Logs and metrics answer different questions.

Get Amritanshu Kaushik’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Suppose an application uses:

• HTTP
• Salesforce
• VM
• Database

A raw log search may help answer:

“What happened during this particular request?”

Connector-level metrics answer questions such as:

“How is this connector behaving over time?”

Examples include:

HTTP
 ├── Request volume
 └── Response-time behavior

Salesforce
 ├── Request volume
 └── Response-time behavior

These operational metrics should be analyzed through the appropriate Anypoint Monitoring views rather than treating Log Management as a replacement for metrics.

The distinction is important:

Logs
  |
  +--> Individual execution details

Metrics
  |
  +--> Aggregate operational behavior

Tracing
  |
  +--> Execution path and correlation

7. MUnit: Test Independence

MUnit is MuleSoft’s testing framework for Mule applications and integrates with Maven/Surefire for automated execution in CI/CD environments.

One of the most important testing principles is:

A test should not depend on the side effects produced by another test.

Consider:

Flow-1
   |
   +--> creates variable customerId
   |
   v
Flow-2
   |
   +--> expects customerId

It may be tempting to write:

Test Flow-1
      |
      v
Test Flow-2

and assume that Flow-2 can use state created by Flow-1.

That makes the test suite fragile.

Instead, test Flow-2 with the event it actually requires:

MUnit Test: Flow-2
       |
       v
Set Event
       |
       +--> Payload
       +--> Attributes
       +--> Variables
       |
       v
Flow-2
       |
       v
Assertions

The MUnit Set Event processor allows you to define payload, attributes, and variables explicitly for the test event.

8. Before Test vs Test-to-Test Dependency

There is an important distinction here.

MUnit supports Before Test and After Test scopes.

A Before Test scope executes before each test and can be useful for common setup.

For example:

Before Test
   |
   +--> Create common test data
   |
   v
Test A

and:

Before Test
   |
   +--> Create common test data
   |
   v
Test B

This is perfectly reasonable.

What should be avoided is:

Test A
   |
   +--> Creates state
           |
           v
       Test B
           |
           +--> Depends on Test A

The rule is therefore:

Share reusable setup, not test-specific state.

This makes tests deterministic and allows them to be executed independently.

9. MUnit Expected Errors

MUnit can explicitly expect an error from the execution under test.

For example:

<munit:test
    name="customErrorTest"
    expectedErrorType="APP:CUSTOM_ERROR">

    ...

</munit:test>

If the application throws:

APP:CUSTOM_ERROR

the expected-error condition is satisfied.

MUnit documentation demonstrates the same pattern with errors such as OS:INVALID_KEY.

But do not stop reading the test there.

An MUnit test can contain additional validation logic.

For example:

Expected Error
      |
      v
APP:CUSTOM_ERROR
      |
      v
Expected error condition PASSES

        BUT

Validation
      |
      v
true == false
      |
      v
Assertion Error
      |
      v
TEST FAILS

The important exam principle is:

An expected error does not automatically make every other validation in the test pass.

MUnit’s assertion processor throws MUNIT-TOOLS:ASSERTION_ERROR when its assertion condition fails.

Therefore, when reading an MUnit exam exhibit, trace the complete execution:

1. What event is initialized?
2. What mocks are configured?
3. What flow executes?
4. What error is produced?
5. Is that error expected?
6. What validations execute afterward?
7. Do those validations pass?

10. MUnit and Error Handling

MUnit is especially useful for testing Mule error-handling behavior.

Consider:

HTTP Request
     |
     v
HTTP:CONNECTIVITY
     |
     v
On Error Continue
     |
     v
Fallback Payload

The test should verify the behavior that the application actually exposes.

For example:

Mock HTTP Request
       |
       v
Throw HTTP:CONNECTIVITY
       |
       v
Application Error Handler
       |
       v
Fallback Response
       |
       v
Assert Response

MUnit can also test error-handling flows directly by constructing an event containing an error. MuleSoft documents the use of Set Event to inject an error into the event when testing separated error-handling logic.

This is an important distinction:

Test the error-handling behavior, not merely the existence of an error handler.

11. Testing XML SDK Custom Modules

Custom modules built with the XML SDK are Mule plugins and can be tested with MUnit.

MuleSoft’s XML SDK documentation provides a project structure similar to:

hello-mule-extension/
|
+-- pom.xml
|
+-- src/
    |
    +-- main/
    |    |
    |    +-- resources/
    |         |
    |         +-- module-Hello.xml
    |
    +-- test/
         |
         +-- munit/
              |
              +-- assertion-munit-test.xml

The MUnit test can invoke the XML SDK operation just as the module would be used from a Mule application.

Running:

mvn clean install

builds the module and executes the MUnit tests defined for it. MuleSoft’s current XML SDK documentation demonstrates this workflow explicitly.

This makes automated testing part of the module’s normal Maven build rather than something performed manually after development.

12. The MCD Level 2 Mental Model

For observability and testing questions, think in layers:

PRODUCTION API
                       |
        +--------------+--------------+
        |              |              |
        v              v              v
     Health         Metrics          Logs
        |              |              |
        |              |              v
        |              |             MDC
        |              |              |
        |              |              v
        |              |           Tracing
        |              |
        +--------------+
               |
               v
      Anypoint Monitoring
               |
               v
        Functional Tests

              DEVELOPMENT
                   |
                   v
                 MUnit
                   |
        +----------+----------+
        |          |          |
        v          v          v
     Mocking   Assertions   Verification
        |          |          |
        +----------+----------+
                   |
                   v
                Maven
                   |
                   v
                  CI/CD

The exam-level distinction is:

• Health checks tell you whether something is available.
• Readiness determines whether an instance should receive traffic.
• Functional monitoring verifies actual API behavior.
• Metrics show aggregate operational behavior.
• Logs explain individual execution details.
• MDC/Tracing add execution context.
• MUnit proves application behavior automatically.
• Mocks isolate dependencies.
• Assertions validate expected results.
• Expected errors validate negative scenarios.
• Maven integrates testing into the build lifecycle.

The goal is not simply to make an API work.

The goal is to make an API observable, testable, diagnosable, and safe to operate in production.

Final Takeaway

For MCD Level 2, don’t memorize observability and MUnit as isolated features.

Think like an architect:

Can I detect the problem?
        |
        v
Can I identify the failing component?
        |
        v
Can I trace the execution?
        |
        v
Can I reproduce the failure?
        |
        v
Can I automatically verify the fix?
        |
        v
Can I safely deploy the change?

That progression connects Monitoring → Logging → Tracing → MUnit → Maven → CI/CD into one production engineering discipline.

That is the mindset MCD Level 2 questions are really testing.

Disclaimer: This is an independent, self-created study resource based on my personal preparation experience, hands-on practice, practice tests, and the areas I focused on while preparing for the MuleSoft Certified Developer — Level 2 certification. It is not affiliated with, sponsored by, or endorsed by Salesforce or MuleSoft.