Instrument MATLAB Code with OpenTelemetry Tracing

Add OpenTelemetry tracing spans to MATLAB functions with correct implicit context propagation, RAII lifecycle, and semantic conventions.

Prerequisites

The OpenTelemetry-MATLAB package (Version 1.11.0 or newer) must be installed. It provides the opentelemetry.trace.* namespace used throughout this skill. Requires MATLAB R2022b or newer.

Key Functions

MATLAB API Differences

The MATLAB OpenTelemetry API differs slightly from C++, Java, and Python implementations. Do not rely on general OTel knowledge from other languages — when unsure about a function, use help opentelemetry.trace.Span or similar to check what exists. Common traps:

• setAttribute (singular) does not exist — use setAttributes (plural)
• opentelemetry.trace.StatusCode.Ok / StatusCode.Error enums do not exist — pass the strings "Ok" or "Error" directly to setStatus

When to Use

• User asks to add tracing or spans to MATLAB code
• User asks to instrument code with OpenTelemetry
• User asks to add observability and tracing is part of the request
• User wants parent-child span relationships across functions

When NOT to Use

• User wants metrics only (counters, histograms, gauges) — no tracing skill needed
• User wants logging only (structured log records) — no tracing skill needed
• User wants to configure the TracerProvider/SDK (exporters, samplers, resource) — that belongs in a separate setup script
• User wants to propagate context across network boundaries (inject/extract into HTTP headers)
• User wants to instrument inside parfor loops — OTel context is not thread-safe in MATLAB

Absolute Rules

These rules override all other considerations. Violating any of them produces incorrect instrumentation.

1. Never modify function signatures

Instrumentation must be invisible to callers. Never add parameters (tracer, context, span) to a function. Never change return values. Each function obtains its own tracer internally:

tr = opentelemetry.trace.getTracer("tracer_name");

This is a cheap lookup from the global provider, not a resource allocation.

2. Spans are RAII — never call endSpan at function exit

The MATLAB Span object holds a C++ shared pointer. When the span variable goes out of scope (function returns, error thrown), the C++ destructor automatically ends the span. Only call endSpan when you need to end a span mid-function before the variable naturally goes out of scope.

3. Scope is RAII — never call clear(scope) at function exit

The Scope object returned by makeCurrent restores the previous context when it goes out of scope. Assign it to a variable to control its lifetime. The %#ok<NASGU> pragma suppresses the "unused variable" warning because the variable's lifetime is its purpose, not its value. Exception: inside loops, clear is required to restore the parent context before the next iteration (see loop pattern).

4. Always call makeCurrent on every span

Every span must be made current so child spans created in called functions automatically become children. Without makeCurrent, child spans become orphaned root spans.

5. Never pass explicit "Context" to startSpan

When makeCurrent is used consistently, startSpan automatically picks up the current span as parent. Passing "Context" explicitly is redundant and error-prone. The only exception is when creating a span that must be a child of a different span than the current one (rare).

6. Always set span status

Every span must have its status set before it ends:

• setStatus(span, "Ok") on the success path
• setStatus(span, "Error", message) on the failure path

A span without explicit status is ambiguous in trace viewers.

7. Use getTracer directly

tr = opentelemetry.trace.getTracer("tracer_name");

Never use opentelemetry.sdk.trace.TracerProvider() or opentelemetry.trace.Provider.getTracerProvider() followed by getTracer. The one-liner above is the correct entry point.

8. Use snake_case attribute names with meaningful domain nouns

All attribute names must be lowercase, dot-separated, and use snake_case within each component. The namespace (left of the dot) must be a meaningful domain noun — not a generic word like "total", "numeric", or "count". See the Semantic Conventions section below for the full pattern and examples.

Workflow

Step 1: Analyze the code

Identify:

• Entry-point function (top-level function the user calls)
• Sub-functions and local functions that represent distinct units of work
• I/O operations (file read/write, network calls, database)
• Error-prone sections (file I/O, external systems, parsing)
• Computationally significant operations worth tracking

Step 2: Choose a tracer name

Derive from the file name or containing package:

• processSensorData.m → "processSensorData"
• +mypackage/analyze.m → "mypackage"

All functions in the same workflow should share the same tracer name.

Step 3: Instrument each function

Apply the core pattern to every function that represents a meaningful unit of work. Do not instrument trivial helpers (< 5 lines, no I/O) or functions called thousands of times in tight loops.

Step 4: Add error handling where needed

Add try-catch with recordException only for functions that perform I/O or call external systems. Do not add try-catch around pure computation.

Step 5: Add attributes and events

Add attributes that would help with debugging: input sizes, key parameters, output characteristics. Record events for significant milestones. Follow semantic conventions (see references/semantic-conventions.md).

Step 6: Verify

Run the instrumented code via mcp__matlab__evaluate_matlab_code or mcp__matlab__run_matlab_file to confirm it executes without error.

Core Pattern

This is the one correct pattern for every instrumented function:

function result = processData(inputData, method)
    tr = opentelemetry.trace.getTracer("myService");
    span = startSpan(tr, "processData");
    scope = makeCurrent(span); %#ok<NASGU>

    % --- original function body (unchanged) ---
    result = transform(inputData, method);

    setStatus(span, "Ok");
end

Key points:

• getTracer inside the function — never passed as argument
• startSpan with no "Context" — inherits from current context automatically
• scope = makeCurrent(span) — makes this span the parent for any child spans
• %#ok<NASGU> — suppresses false warning; scope lifetime is the point
• setStatus before the function returns
• No endSpan — span ends via RAII when function returns

Multi-function example

function results = runPipeline(inputFile)
    tr = opentelemetry.trace.getTracer("pipeline");
    span = startSpan(tr, "runPipeline");
    scope = makeCurrent(span); %#ok<NASGU>

    data = loadData(inputFile);
    cleaned = cleanData(data);
    results = analyze(cleaned);

    setStatus(span, "Ok");
end

function data = loadData(filepath)
    tr = opentelemetry.trace.getTracer("pipeline");
    span = startSpan(tr, "loadData");
    scope = makeCurrent(span); %#ok<NASGU>

    data = readtable(filepath);

    setStatus(span, "Ok");
end

function cleaned = cleanData(data)
    tr = opentelemetry.trace.getTracer("pipeline");
    span = startSpan(tr, "cleanData");
    scope = makeCurrent(span); %#ok<NASGU>

    cleaned = rmmissing(data);

    setStatus(span, "Ok");
end

function results = analyze(data)
    tr = opentelemetry.trace.getTracer("pipeline");
    span = startSpan(tr, "analyze");
    scope = makeCurrent(span); %#ok<NASGU>

    results = summary(data);

    setStatus(span, "Ok");
end

Each function independently obtains a tracer and creates its own span. Parent-child relationships are established automatically through makeCurrent.

Error Handling Pattern

Use for functions with I/O or external system calls:

function data = fetchData(url)
    tr = opentelemetry.trace.getTracer("myService");
    span = startSpan(tr, "fetchData", SpanKind="client");
    scope = makeCurrent(span); %#ok<NASGU>
    setAttributes(span, "url.full", url);

    try
        data = webread(url);
        setAttributes(span, "http.response.status_code", 200);
    catch ME
        recordException(span, ME);
        setStatus(span, "Error", ME.message);
        rethrow(ME);
    end

    setStatus(span, "Ok");
end

Key points:

• recordException captures the full MException (identifier, message, stack trace, cause)
• setStatus(span, "Error", ...) marks the span as errored in trace viewers
• rethrow(ME) preserves the original error — span still ends via RAII after rethrow
• Both recordException and setStatus are needed: one records detail, the other sets the visual indicator
• setStatus(span, "Ok") goes after the try-catch block, not inside try — rethrow exits the function so "Ok" is only reached on success

Attributes

Set attributes with setAttributes (plural, never singular setAttribute which does not exist):

setAttributes(span, "input.rows", height(data), "input.columns", width(data));

Or using a dictionary at span creation:

span = startSpan(tr, "processData", Attributes=dictionary( ...
    ["input.file", "input.format"], ...
    {filepath, "csv"}));

Numeric values do not need type casting — the API handles all MATLAB numeric types natively.

Events

Record events for significant milestones within a span:

addEvent(span, "validationComplete", "rows.valid", validCount, "rows.rejected", rejectCount);

SpanKind

Set SpanKind only when the operation involves remote communication. Do not set it for internal operations (the default is "internal").

span = startSpan(tr, "fetchData", SpanKind="client");

When to Use endSpan

Only use endSpan when ending a span mid-function — before the variable would naturally go out of scope:

function results = batchProcess(items)
    tr = opentelemetry.trace.getTracer("myService");
    span = startSpan(tr, "batchProcess");
    scope = makeCurrent(span); %#ok<NASGU>

    results = cell(numel(items), 1);
    for i = 1:numel(items)
        itemSpan = startSpan(tr, "processItem");
        itemScope = makeCurrent(itemSpan); %#ok<NASGU>
        setAttributes(itemSpan, "item.index", i);
        results{i} = processOne(items{i});
        setStatus(itemSpan, "Ok");
        endSpan(itemSpan);  % Needed: itemSpan must end each iteration
        clear("itemScope");  % Needed: restore parent context before next iteration
    end

    setStatus(span, "Ok");
end

Both lines at the end of the loop body are mandatory:

• endSpan(itemSpan) — ends the span's timing. Without it, the span duration extends until the variable is overwritten on the next iteration (wrong timing).
• clear("itemScope") — restores the parent span as the current context. Without it, makeCurrent on the next iteration would make the new span a child of the previous iteration's span (nested chain) instead of a sibling under the parent (correct flat list).

Semantic Conventions

Attribute names must follow the {object}.{property} pattern:

• Lowercase and dot-separated — never camelCase
• snake_case within each component — total_paths not totalPaths
• Namespace is a meaningful domain noun — the word left of the dot must be a concrete object in the domain (e.g., batch, file, result, data), not a generic adjective or quantifier (total, numeric, count)

See references/semantic-conventions.md for full guidance on code attributes, file I/O attributes, HTTP client attributes, and domain-specific patterns.

Common Mistakes

What NOT to Instrument

• Trivial helper functions (< 5 lines, no I/O)
• Functions called thousands of times in tight loops (overhead)
• Anonymous functions or callbacks (unless significant work)
• Code inside parfor blocks (context is not thread-safe)

Copyright 2026 The MathWorks, Inc.