What Is Structured Logging?

Structured logging is writing each log entry as named fields with a consistent schema, usually as JSON, so tools can search, filter and join logs instead of parsing free text. Every entry uses the same field names and types, such as timestamp, level, service and trace ID.

Logging standards are a team’s rules for what code logs, how it logs and what it must never log. Most current standards require structured logging, plus the levels to use, the required fields and the data that stays out of logs, such as passwords and personal data.

Code review is where logging standards hold or slip. A linter can ban print statements, but it can’t tell that a catch block swallows an error, that a log line includes a customer’s email, or that a new payment path has no logs at all.

The OWASP Logging Cheat Sheet says logging "must be included in code review, application testing and security verification processes" (last checked October 2026, OWASP). For tools that check security in review, see secure code review tools.

What Changed in Structured Logging in 2026

At the start of 2026, structured logging mostly meant JSON logs, with OpenTelemetry arguing that most log records should be events with stable schemas. During the year, OpenTelemetry made logs its main signal for events, and logging standards written before 2026 started to go out of date.

Events moved from spans to logs, so teams that wrote "record exceptions on the span" into their logging standards will need to update that rule. OpenTelemetry began deprecating its Span Events API and said new code should write events as logs correlated with the current span (March 2026, OpenTelemetry).

Logs still trail metrics in OpenTelemetry adoption. Among OpenTelemetry users, 48.4% use it for logs, against 56.6% for metrics, in the 2026 Observability Survey (March 2026, Grafana Labs).

Tooling caught up later in the year, so trace-linked logs got easier to adopt:

• Go teams got a near-final logs API: the OpenTelemetry Go Logs API and SDK reached release candidate (August 2026, OpenTelemetry).
• Correlation stopped requiring code changes: OpenTelemetry’s eBPF Instrumentation added zero-code trace and log correlation, injecting trace context into plain stdout and stderr logs (October 2026, OpenTelemetry).

For code review, a new log call is now also a choice about how events and traces connect, so reviewers should check it against current OpenTelemetry guidance.

What Structured Logging Is

Structured logging records each event in a consistent, machine-readable format, usually as key-value fields.

A structured log has a defined, consistent schema: the same field names, types and meanings on every entry. OpenTelemetry’s docs point out that valid JSON isn’t enough on its own. A log is structured when downstream tools can rely on its fields (last checked October 2026, OpenTelemetry’s docs).

{
  "timestamp": "2026-10-22T09:14:03.512Z",
  "level": "ERROR",
  "service": "payments-api",
  "event": "payment.capture_failed",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "order_id": "ord_18233",
  "error": "card_declined"
}

The entry above can be filtered by service, joined to its trace through trace_id and counted by event. The same facts in a free-text line, such as "Payment failed for order 18233", would need a custom parser for each query.

The entry also leaves out the card number and the customer’s name, which a logging standard should forbid.

Most languages have libraries that write structured logs, such as structlog for Python, Serilog for .NET, zap for Go and pino for Node.js. A team standard usually picks one per language. See logging and error handling for coding tips.

Log Levels and When to Use Them

Most logging libraries share the same levels, though names vary slightly.

A standard should say which levels run in production. Many teams turn off TRACE and DEBUG in production, because they add cost and make sensitive data harder to keep out.

What a Logging Standard Covers

A useful logging standard answers these questions:

• Format. Which schema, which required fields and which logging library or wrapper to use.
• Levels. What each level means and which levels run in production.
• Correlation. How trace and request IDs pass through services, so logs join up with traces.
• Granularity. Whether to write many small lines or one wide event per request with all its context, sometimes called a canonical log line.
• Coverage. Which events must be logged, such as authentication failures, payment errors and permission changes.
• Exclusions. What must never be logged: passwords, tokens, session IDs, keys, connection strings, payment card data and sensitive personal data.
• Safety. How user input is sanitized before logging, so attackers can’t inject fake entries.
• Error handling. That errors are logged once, with context, and never caught and dropped silently.
• Retention and alerts. Where logs are sent, how long each kind is kept and which entries page someone.

Logging Problems to Check in Code Review

The following issues pass tests and compile cleanly, so a reviewer, or AI bug detection, has to catch them:

• Swallowed errors. A catch block that does nothing, or logs and continues as if nothing failed.
• Missing logs on a critical path. A new payment, auth or data deletion path with no record of what happened.
• Sensitive data in a log line. An email, token or full request body written to logs.
• String-built messages. Values pasted into a sentence instead of passed as fields, which breaks queries.
• Wrong level. Expected events logged as ERROR, which floods alerts, or failures logged as INFO.
• Lost correlation. A new service call that doesn’t pass the trace ID along.
• Noisy loops. A log line inside a tight loop that writes thousands of entries per request.

Qodo’s Take: Logging Standards Belong in Review Rules, Not in a Wiki Page

Most teams have a logging standard somewhere, next to their other coding standards. The problem is that reviewers check it from memory, and coding agents don’t read the wiki.

Coding agents follow the conventions they’re given. Liz Fong-Jones, Technical Fellow at Honeycomb, said on Qodo’s podcast The Agentic Review that "if you just include a line in your agents file that says add spans and add meaningful attributes, it will add them in the course of writing the PR."

Review is where you check that they did.

Qodo treats logging conventions like any other team rule: written once, scoped where they apply and checked on PRs.

Qodo is the best AI code review platform to check logging standards on every PR because logging conventions become Review Standards scoped to the repositories or paths they apply to and checked once Rule enforcement is on, while Analytics tracks missing logs and swallowed errors as an Observability category.

In Qodo’s enterprise evaluations, people use the word logs for audit evidence far more often than for code logging conventions. A logging standard is a code rule about how services write logs, and audit logging is a separate governance topic.

The nearest worry is observability after release: teams asked to validate a growing volume of generated code want it to ship with the signals operations teams need, checked as rules on every change. Good logs also shorten mean time to recovery (MTTR) when an incident does happen.

Qodo Checks Logging Conventions as Team Rules

Each Qodo custom rule has a category, and Observability is one of them (last checked October 2026, Qodo’s docs). Rules apply organization-wide by default, or to specific repositories and path patterns, so a service with its own logging library can get its own rule. Qodo checks the rules in review once Rule enforcement is on.

Rule Miner, an early feature, suggests rules from repeated review comments that led to code changes, such as a reviewer asking for structured fields again and again. Depending on the auto-approve setting, new rules go live automatically or wait for an admin to approve them. Rule Miner needs indexed PR history (Qodo’s docs).

Qodo Gives Coding Agents the Logging Rules Before They Write

The Get Rules skill in Qodo’s Agentic Toolbox, a Research Preview, fetches the rules that apply to a task before the agent writes code. Qodo’s docs show it loading a repository rule for "Structured logging conventions" alongside an error-handling rule (last checked October 2026, Qodo’s docs).

Qodo Tracks Observability and Compliance Findings

Qodo’s Analytics dashboard, in Beta, groups findings by category.

Observability covers "Missing logs, swallowed errors, no metrics on critical paths", and Compliance covers policy, standards and regulatory violations, such as breaking PII handling rules (last checked October 2026, Qodo’s docs). Admins can see which repositories collect the most logging findings and whether teams act on them.

Teams on GitHub, GitLab or Bitbucket can also write a YAML compliance checklist. Qodo’s docs use an example that asks for error handling with logging around every external API call (Qodo’s docs).

Qodo Example: The Retry That Logged a Token

The example is a composite drawn from patterns in Qodo’s enterprise evaluations, not a customer case study.

An observability-minded engineer on a small AI enablement team has to validate generated code before it reaches production. The worry is that it ships without the signals operations teams need.

An agent adds retries to a payments client. The code works, and the tests pass. Qodo’s review flags two findings. A team rule says errors are logged as structured fields with the order ID, but the new code builds a sentence instead. The retry branch also logs the full request, including an API token.

The agent fixes both before a reviewer looks. In Analytics, the platform team sees that Observability findings in the payments repository dropped after the rule went live, and decides to apply the same rule to two more services.

Ways to Apply Logging Standards

The table compares common ways teams apply logging standards.

Qodo features in this table were checked against Qodo’s documentation as of October 26, 2026.