SeqLoggers.jl

Author ueliwechsler
Popularity
4 Stars
Updated Last
1 Year Ago
Started In
October 2020

SeqLoggers.jl

Dev Build Status Coverage

SeqLoggers.jl is a tool for sending log events to a Seq log server using the Julia Programming language.

SeqLoggers.jl extends the AbstractLogger interface to create log events using the macros:

  • @debug,
  • @info,
  • @warn and
  • @error.

Log events are subsequently posted to the Seq log server using HTTP.jl and the Seq raw-event API.

Additionally, features from LoggingExtras.jl are used to provide more complex logger types.

⚠️ Coping-pasting the examples on this page might introduce invisible extra characters that cannot be handled by the Seq server. When in doubt, replicate the examples without copying the log event strings.

Install Seq

The Seq software is avabilable for free for development purposes or single-user deployment (Installation instructions).

Logging in julia

Using the Logging module, log events are created by inserting a logging statement into the source code using the macros @debug, @info, @warn and @error.

@info "Log Event with `Information` level"

The currently active global logger can be obtained by running

using Logging
global_logger() # ConsoleLogger(...)

As default, a ConsoleLogger is provided, which prints the logging event directly to the Julia REPL.

The global logger can be set to any logger newLogger<:AbstractLogger by calling global_logger(newLogger).

Alternatively, a code section can be wrapped inside a with_logger do-block to use a specific logger for the execution of the code contained in the do-block.

Logging.with_logger(newLogger) do
    ...
end

Within the scope of the do-block, the active logger can be obtained by calling current_logger().

SeqLoggers.jl

SeqLoggers.jl provides a new logger type SeqLogger<:AbstractLogger to replace the default logger to enable the user to post log events to a Seq log server.

Basics

A SeqLogger is constructed by calling the constructor with the same name.

using SeqLoggers
seqLogger = SeqLogger("http://localhost:5341"; # `Seq` server url
                      minLevel=Logging.Info, # define minimal level for log events
                      apiKey="", # api-key for registered Apps
                      batchSize=1,
                      App="Trialrun", # additional log event properties
                      Env="UAT")

The resulting logger seqLogger posts each log event separately to the Seq server with url "http://localhost:5341".

If the performance overhead from posting the log events separately is to high, log events can be stored and posted in a batch. The constructor keyword argument batchSize defines the size of a log event batch. Once the logger has received a number of log events equal to batchSize, all events are sent to the Seq log server in one post. By default, batchSize=10.

Therefore, for proper functionality with batchSize>1, it is required to use the SeqLogger by calling with_logger (and not add it as a global logger) to ensure that all log events will be sent to the log server.

Logging.with_logger(seqLogger) do
    @info "Log me into `Seq` with property user = {user}" user="Me"
end

In this example, besides the global log event properties App="Trialrun" and Env="Test" also a local log event property user="Me" was added.

Note, that all elements surrounded by curly brackets, e.g. {user}, will be replaced (on the server-side) by the corresponding log event property if it exists.

Interaction with LoggingExtras.jl

SeqLoggers can also be combined with the functionality of LoggingExtras.jl .

using LoggingExtras
combinedLogger = TeeLogger(Logging.current_logger(), seqLogger)

In this example, the combinedLogger logs both to the Julia REPL (if the current logger was a ConsoleLogger) and the Seq log server defined by seqLogger.

Explanation of SeqLoggers.PostType

In the SeqLogger constructor, there is an second argument postType. For most cases, one can ignore this argument and use the default value Serial().

However, if the performance of the SeqLogger is not satisfying, it might pay off to experiment with the different settings.

  • Serial(): the log event are posted without any multi-threading.
  • Parallel(): the log event are posted using Threads.@spawn which allows to use multi-threading.
  • Background(nWorkers): the log event are posted using WorkerUtilities.@spawn which allows to use multi-threading and run the post action as a true background task where nWorkers is the amount of background workers used.

FAQ

Used By Packages

No packages found.