View Source Oban.Telemetry (Oban v2.15.0)
Telemetry integration for event metrics, logging and error reporting.
initialization-events
Initialization Events
Oban emits the following telemetry event when an Oban supervisor is started:
[:oban, :supervisor, :init]
- when the Oban supervisor is started this will execute
The initialization event contains the following measurements:
:system_time
- The system's time when Oban was started
The initialization event contains the following metadata:
:conf
- The configuration used for the Oban supervisor instance:pid
- The PID of the supervisor instance
job-events
Job Events
Oban emits the following telemetry events for each job:
[:oban, :job, :start]
— at the point a job is fetched from the database and will execute[:oban, :job, :stop]
— after a job succeeds and the success is recorded in the database[:oban, :job, :exception]
— after a job fails and the failure is recorded in the database
All job events share the same details about the job that was executed. In addition, failed jobs provide the error type, the error itself, and the stacktrace. The following chart shows which metadata you can expect for each event:
event | measures | metadata |
---|---|---|
:start | :system_time | :conf , :job , :state |
:stop | :duration , :queue_time | :conf , :job , :state , :result |
:exception | :duration , :queue_time | :conf , :job , :state , :kind , :reason , :stacktrace |
metadata
Metadata
:conf
— the executing Oban instance's config:job
— the executingOban.Job
:state
— one of:success
,:failure
,:cancelled
,:discard
or:snoozed
:result
— theperform/1
return value, included unless job failed with an exception or crash
For :exception
events the metadata also includes details about what caused the failure. The
:kind
value is determined by how an error occurred. Here are the possible kinds:
:error
— from an{:error, error}
return value. Some Erlang functions may also throw an:error
tuple, which will be reported as:error
.:exit
— from a caught process exit:throw
— from a caught value, this doesn't necessarily mean that an error occurred and the error value is unpredictable
engine-events
Engine Events
Oban emits telemetry span events for the following Engine operations:
[:oban, :engine, :init, :start | :stop | :exception]
[:oban, :engine, :refresh, :start | :stop | :exception]
[:oban, :engine, :put_meta, :start | :stop | :exception]
event | measures | metadata |
---|---|---|
:start | :system_time | :conf , :engine |
:stop | :duration | :conf , :engine |
:exception | :duration | :conf , :engine , :kind , :reason , :stacktrace |
Events for bulk operations also include :jobs
for the :stop
event:
[:oban, :engine, :cancel_all_jobs, :start | :stop | :exception]
[:oban, :engine, :fetch_jobs, :start | :stop | :exception]
[:oban, :engine, :insert_all_jobs, :start | :stop | :exception]
[:oban, :engine, :prune_jobs, :start | :stop | :exception]
[:oban, :engine, :retry_all_jobs, :start | :stop | :exception]
[:oban, :engine, :stage_jobs, :start | :stop | :exception]
event | measures | metadata |
---|---|---|
:start | :system_time | :conf , :engine |
:stop | :duration | :conf , :engine , :jobs |
:exception | :duration | :conf , :engine , :kind , :reason , :stacktrace |
Events for job-level Engine operations also include the job
[:oban, :engine, :cancel_job, :start | :stop | :exception]
[:oban, :engine, :complete_job, :start | :stop | :exception]
[:oban, :engine, :discard_job, :start | :stop | :exception]
[:oban, :engine, :error_job, :start | :stop | :exception]
[:oban, :engine, :insert_job, :start | :stop | :exception]
[:oban, :engine, :retry_job, :start | :stop | :exception]
[:oban, :engine, :snooze_job, :start | :stop | :exception]
event | measures | metadata |
---|---|---|
:start | :system_time | :conf , :engine , :job |
:stop | :duration | :conf , :engine , :job |
:exception | :duration | :conf , :engine , :job , :kind , :reason , :stacktrace |
metadata-1
Metadata
:conf
— the Oban supervisor's config:engine
— the module of the engine used:job
- theOban.Job
in question:jobs
— zero or more maps with thequeue
,state
for each modified job:kind
,:reason
,:stacktrace
— see the explanation in job metadata above
notifier-events
Notifier Events
Oban emits a telemetry span event each time the Notifier is triggered:
[:oban, :notifier, :notify, :start | :stop | :exception]
event | measures | metadata |
---|---|---|
:start | :system_time | :conf , :channel , :payload |
:stop | :duration | :conf , :channel , :payload |
:exception | :duration | :conf , :channel , :payload , :kind , :reason , :stacktrace |
metadata-2
Metadata
:conf
— the Oban supervisor's config:channel
— the channel on which the notification was sent:payload
- the decoded payload that was sent:kind
,:reason
,:stacktrace
— see the explanation in job metadata above
plugin-events
Plugin Events
All the Oban plugins emit telemetry events under the [:oban, :plugin, *]
pattern (where *
is
either :init
, :start
, :stop
, or :exception
). You can filter out for plugin events by
looking into the metadata of the event and checking the value of :plugin
. The :plugin
field
is the plugin module that emitted the event. For example, to get Oban.Plugins.Cron
specific
events, you can filter for telemetry events with a metadata key/value of plugin: Oban.Plugins.Cron
.
Oban emits the following telemetry event whenever a plugin executes (be sure to check the documentation for each plugin as each plugin can also add additional metadata specific to the plugin):
[:oban, :plugin, :init]
— when the plugin first initializes[:oban, :plugin, :start]
— when the plugin beings performing its work[:oban, :plugin, :stop]
— after the plugin completes its work[:oban, :plugin, :exception]
— when the plugin encounters an error
The following chart shows which metadata you can expect for each event:
event | measures | metadata |
---|---|---|
:init | :conf , :plugin | |
:start | :system_time | :conf , :plugin |
:stop | :duration | :conf , :plugin |
:exception | :duration | :conf , :plugin , :kind , :reason , :stacktrace |
peer-events
Peer Events
Oban emits a telemetry span event each time an Oban Peer election occurs:
[:oban, :peer, :election, :start | :stop | :exception]
event | measures | metadata |
---|---|---|
:start | :system_time | :conf , :leader , :peer , |
:stop | :duration | :conf , :leader , :peer , |
:exception | :duration | :conf , :leader , :peer , :kind , :reason , :stacktrace |
metadata-3
Metadata
:conf
,:kind
,:reason
,:stacktrace
— see the explanation in notifier metadata above:leader
— whether the peer is the current leader:peer
— the module used for peering
default-logger
Default Logger
A default log handler that emits structured JSON is provided, see attach_default_logger/0
for
usage. Otherwise, if you would prefer more control over logging or would like to instrument
events you can write your own handler.
Here is an example of the JSON output for the job:stop
event:
{
"args":{"action":"OK","ref":1},
"attempt":1,
"duration":4327295,
"event":"job:stop",
"id":123,
"max_attempts":20,
"meta":{},
"queue":"alpha",
"queue_time":3127905,
"source":"oban",
"state":"success",
"tags":[],
"worker":"Oban.Integration.Worker"
}
All timing measurements are recorded as native time units but logged in microseconds.
examples
Examples
A handler that only logs a few details about failed jobs:
defmodule MicroLogger do
require Logger
def handle_event([:oban, :job, :exception], %{duration: duration}, meta, nil) do
Logger.warn("[#{meta.queue}] #{meta.worker} failed in #{duration}")
end
end
:telemetry.attach("oban-logger", [:oban, :job, :exception], &MicroLogger.handle_event/4, nil)
Another great use of execution data is error reporting. Here is an example of integrating with Honeybadger, but only reporting jobs that have failed 3 times or more:
defmodule ErrorReporter do
def handle_event([:oban, :job, :exception], _, %{attempt: attempt} = meta, _) do
if attempt >= 3 do
context = Map.take(meta, [:id, :args, :queue, :worker])
Honeybadger.notify(meta.reason, metadata: context, stacktrace: meta.stacktrace)
end
end
end
:telemetry.attach("oban-errors", [:oban, :job, :exception], &ErrorReporter.handle_event/4, [])
Link to this section Summary
Functions
Attaches a default structured JSON Telemetry handler for logging.
Undoes Oban.Telemetry.attach_default_logger/1
by detaching the attached logger.
Link to this section Functions
attach_default_logger(opts \\ [encode: true, level: :info])
View Source (since 0.4.0)@spec attach_default_logger(Logger.level() | Keyword.t()) :: :ok | {:error, :already_exists}
Attaches a default structured JSON Telemetry handler for logging.
This function attaches a handler that outputs logs with the following fields:
args
— a map of the job's raw argumentsattempt
— the job's execution atttemptduration
— the job's runtime duration, in the native time unitevent
— eitherjob:stop
orjob:exception
depending on reporting telemetry eventerror
— a formatted error banner, without the extended stacktraceid
— the job's idmeta
— a map of the job's raw metadataqueue
— the job's queuesource
— always "oban"state
— the execution state, one of "success", "failure", "cancelled", "discard", or "snoozed"system_time
— when the job started, in microsecondstags
— the job's tagsworker
— the job's worker module
options
Options
:level
— The log level to use for logging output, defaults to:info
.:encode
— Whether to encode log output as JSON, defaults totrue
examples
Examples
Attach a logger at the default :info
level with JSON encoding:
:ok = Oban.Telemetry.attach_default_logger()
Attach a logger at the :debug
level:
:ok = Oban.Telemetry.attach_default_logger(level: :debug)
Attach a logger with JSON logging disabled:
:ok = Oban.Telemetry.attach_default_logger(encode: false)
@spec detach_default_logger() :: :ok | {:error, :not_found}
Undoes Oban.Telemetry.attach_default_logger/1
by detaching the attached logger.
examples
Examples
Detach a previously attached logger:
:ok = Oban.Telemetry.attach_default_logger()
:ok = Oban.Telemetry.detach_default_logger()
Attempt to detach when a logger wasn't attached:
{:error, :not_found} = Oban.Telemetry.detach_default_logger()