Semantic Logger is a high-performance, asynchronous structured logging framework for Ruby and Rails that pushes log events onto an in-memory queue and writes them to one or more destinations from a separate background thread.

What it is

Semantic Logger is an Apache-2.0 licensed Ruby gem in the logging and observability space, distributed through RubyGems as semantic_logger and documented at logger.reidmorrison.com. It takes the place of an ordinary Ruby or Rails logger and changes two things about how logging works. First, it logs structured data rather than plain strings, so each entry can carry a payload hash, an exception with its backtrace, a duration, metrics, and tags, and that data survives all the way to the destination instead of being flattened into text. Second, it logs asynchronously: events go to an in-memory queue serviced by a background thread, so the application does not wait while log output is written.

The concrete problem it solves is log throughput and log searchability. Traditional logging makes the application wait while each log line is saved, which becomes a bottleneck at high volume. Semantic Logger decouples the caller from the write path so an application can log thousands of lines per second without slowing down. On the searchability side, because the payload is preserved, fields such as duration, table, or order_id stay queryable in the destination rather than being lost inside a formatted string. Within Rails, the specific thing it replaces is the Rails default logger, which the companion gem rails_semantic_logger swaps out automatically.

Key capabilities

• Asynchronous delivery through an in-memory queue serviced by a dedicated thread, keeping log writes off the application's critical path.
• Structured entries that carry an arbitrary payload hash, an exception, a duration, metrics, and tags, with that structure preserved to the destination.
• Runtime configuration through SemanticLogger.default_level and SemanticLogger.add_appender, including the built-in formatter :color for screen output.
• Block timing through measurements such as logger.measure_info, along with convenience calls like logger.info and logger.error that accept exception and context fields.
• Out-of-the-box appenders for File, Screen, ElasticSearch, Graylog, BugSnag, NewRelic, Splunk, MongoDB, Honeybadger, Sentry, HTTP, TCP, UDP, Syslog, CloudWatch Logs, and OpenTelemetry.
• Sentry support covering both the legacy sentry-raven gem and the modern sentry-ruby gem.
• Interoperability options: any existing Ruby logger can be attached as another destination, and custom appenders can be written.
• Optional per-appender dependencies, such as the bugsnag gem for the Bugsnag appender and the mongo gem family for MongoDB, which are not pulled in automatically.

Who uses it and how

• Rails applications, which adopt it indirectly through rails_semantic_logger so the framework's default logger is replaced without manual wiring.
• Background processing setups, including jobs running under the sister project Rocket Job, where job metrics are sent through Semantic Logger to dashboards.
• Teams centralizing logs in search and analytics platforms, pairing the ElasticSearch appender with Kibana for dashboards and visualizations, or routing to Splunk, Graylog, or CloudWatch Logs.
• Operations that need multiple simultaneous destinations, since one event can be fanned out to several appenders from the same queue-servicing thread.
• Error-tracking workflows that forward exceptions and events to Sentry, BugSnag, or Honeybadger while still retaining local file or screen output.
• High-volume services where write latency from the logging path is a measurable cost.

Getting started

Install the semantic_logger gem from RubyGems and configure it in code with SemanticLogger.default_level and SemanticLogger.add_appender. Rails users should install rails_semantic_logger instead of wiring Semantic Logger directly, because it replaces the default Rails logger automatically.

How it compares

The facts do not provide a list of paid products this project replaces, so the honest positioning is among the tools it names. It is the general-purpose base library, while rails_semantic_logger is the Rails integration layer that supersedes the framework's default logger, and Rocket Job is the sister batch system that fully supports it for background jobs. Every destination it writes to, from ElasticSearch and Splunk to Syslog and OpenTelemetry, is an endpoint it feeds rather than a product it substitutes.

When to use it — and when not to

A self-hoster must run whatever the chosen appenders point at, which can mean ElasticSearch and Kibana, MongoDB, Graylog, Splunk, CloudWatch Logs, or a Syslog and OpenTelemetry endpoint, and must add the optional gems each appender needs. Because writes happen on a background thread from an in-memory queue, the trade-off is that delivery depends on a running process rather than a synchronous write, so it suits services that value throughput over blocking guarantees. Teams outside Ruby and Rails should not pick it, and anyone expecting a batteries-included stack with no external destination to operate will find the initial setup heavier than a plain file logger.

require "semantic_logger"

SemanticLogger.default_level = :info
SemanticLogger.add_appender(io: $stdout, formatter: :color)

logger = SemanticLogger["MyApp"]

# A plain message, plus structured data that stays searchable
logger.info("Queried users table", duration: 54, result: :ok, table: "users")

# Log an exception with its full backtrace, plus context
logger.error("Failed to process order", exception: exception, order_id: 42)

# Measure and log how long a block takes to run
logger.measure_info("Reindexing users") { reindex_users }

gem install semantic_logger

require 'semantic_logger'

# Set the global default log level
SemanticLogger.default_level = :trace

# Log to a file, and use the colorized formatter
SemanticLogger.add_appender(file_name: 'development.log', formatter: :color)