Command-line Client

The Seq command-line client supports logging (seqcli log), searching (search), tailing (tail), querying (query) and JSON or plain-text log file ingestion (ingest), as well as a number of administration tasks.

Getting started

Install or unzip the release for your operating system.

To set a default server URL, run:

seqcli config -k connection.serverUrl -v https://your-seq-server

The API key will be stored in your SeqCli.json configuration file; on Windows, this is encrypted using DPAPI; on Mac/Linux the key is currently stored in plain text. As an alternative to storing the API key in configuration, it can be passed to each command via the --apikey= argument.

seqcli is also available as a Docker container under datalust/seqcli:

docker run --rm datalust/seqcli:latest <command> [<args>]

Use Docker networks and volumes to make local files and other containers accessible to seqcli within its container.

Commands

Usage:

seqcli <command> [<args>]

Available commands:

• apikey
  • apikey create — Create an API key for ingestion.
  • apikey list — List available API keys.
  • apikey remove — Remove an API key from the server.
• app-run — Host a .NET [SeqApp] plug-in.
• config — View and set fields in the SeqCli.json file; run with no arguments to list all fields.
• dashboard
  • dashboard list — List dashboards.
  • dashboard remove — Remove a dashboard from the server.
  • dashboard render — Produce a CSV or JSON result set from a dashboard chart.
• help — Show information about available commands.
• ingest — Send log events from a file or STDIN.
• log — Send a structured log event to the server.
• print — Pretty-print events in CLEF/JSON format, from a file or STDIN.
• profile
  • profile create — Create or replace a connection profile.
  • profile list — List connection profiles.
  • profile remove — Remove a connection profile.
• query — Execute an SQL query and receive results in CSV format.
• search — Retrieve log events that match a given filter.
• signal
  • signal create — Create a signal.
  • signal import — Import signals in newline-delimited JSON format.
  • signal list — List available signals.
  • signal remove — Remove a signal from the server.
• tail — Stream log events matching a filter.
• user
  • user create — Create a user.
  • user list — List users.
  • user remove — Remove a user from the server.
• version — Print the current executable version.

apikey remove

Remove an API key from the server.

Example:

seqcli apikey remove -t 'Test API Key'

apikey list

List available API keys.

Example:

seqcli apikey list

apikey create

Create an API key for ingestion.

Example:

seqcli apikey create -t 'Test API Key' -p Environment=Test

app run

Host a .NET [SeqApp] plug-in.

Example:

seqcli tail --json | seqcli app run -d "./bin/Debug/netstandard2.2" -p [email protected]

config

View and set fields in the SeqCli.json file; run with no arguments to list all fields.

dashboard render

Produce a CSV or JSON result set from a dashboard chart.

Example:

seqcli dashboard render -i dashboard-159 -c 'Response Time (ms)' --last 7d --by 1h

dashboard remove

Remove a dashboard from the server.

Example:

seqcli dashboard remove -i dashboard-159

dashboard list

List dashboards.

Example:

seqcli dashboard list

help

Show information about available commands.

Example:

seqcli help search

ingest

Send log events from a file or STDIN.

Example:

seqcli ingest -i log-*.txt --json --filter="@Level <> 'Debug'" -p Environment=Test

log

Send a structured log event to the server.

Example:

seqcli log -m 'Hello, {Name}!' -p Name=World -p App=Test

print

Pretty-print events in CLEF/JSON format, from a file or STDIN.

Example:

seqcli print -i log-20201028.clef

profile remove

Remove a connection profile.

Example:

seqcli profile remove -n Production

profile list

List connection profiles.

Example:

seqcli profile list

profile create

Create or replace a connection profile.

Example:

seqcli profile create -n Production -s https://seq.example.com -a th15ISanAPIk3y

query

Execute an SQL query and receive results in CSV format.

Example:

seqcli query -q "select count(*) from stream group by @Level" --start="2018-02-28T13:00Z"

search

Retrieve log events that match a given filter.

Example:

seqcli search -f "@Exception like '%TimeoutException%'" -c 30

signal remove

Remove a signal from the server.

Example:

seqcli signal remove -t 'Test Signal'

signal list

List available signals.

Example:

seqcli signal list

signal import

Import signals in newline-delimited JSON format.

Example:

seqcli signal import -i ./Exceptions.json

signal create

Create a signal.

Example:

seqcli signal create -t 'Exceptions' -f "@Exception is not null"

tail

Stream log events matching a filter.

user remove

Remove a user from the server.

Example:

seqcli user remove -n alice

user list

List users.

Example:

seqcli user list

user create

Create a user.

Example:

seqcli user create -n alice -d 'Alice Example' -r 'User (read/write)' --password-stdin

version

Print the current executable version.

Extraction patterns

The seqcli ingest command can be used for parsing plain text logs into structured log events.

seqcli ingest -x "{@t:timestamp} [{@l:level}] {@m:*}{:n}{@x:*}"

The -x argument above is an extraction pattern that will parse events like:

2018-02-21 13:29:00.123 +10:00 [ERR] The operation failed
System.DivideByZeroException: Attempt to divide by zero
  at SomeClass.SomeMethod()

Syntax

Extraction patterns have a simple high-level syntax:

• Text that appears in the pattern is matched literally - so a pattern like Hello, world! will match logging statements that are made up of this greeting only,
• Text between {curly braces} is a match expression that identifies a part of the event to be extracted, and
• Literal curly braces are escaped by doubling, so {{ will match the literal text {, and }} matches }.

Match expressions have the form:

{name:matcher}

Both the name and matcher are optional, but either one or the other must be specified. Hence {@t:timestamp} specifies a name of @t and value timestamp, {IPAddress} specifies a name only, and {:n} a value only (in this case the built-in newline matcher).

The name is the property name to be extracted; there are four built-in property names that get special handling:

• @t - the event's timestamp
• @m - the textual message associated with the event
• @l - the event's level
• @x - the exception or backtrace associated with the event

Other property names are attached to the event payload, so {Elapsed:dec} will extract a property called Elapsed, using the dec decimal matcher.

Match expressions with no name are consumed from the input, but are not added to the event payload.

Matchers

Matchers identify chunks of the input event.

Different matchers are needed so that a piece of text like 200OK can be separated into separate properties, i.e. {StatusCode:nat}{Status:alpha}. Here, the nat (natural number) matcher also coerces the result into a numeric value, so that it is attached to the event payload numerically as 200 instead of as the text "200".

There are three kinds of matchers:

• Matchers like alpha and nat are built-in named matchers.
• The special matchers *, ** and so-on, are non-greedy content matchers; these will match any text up until the next pattern element matches (*), the next two elements match, and so-on. We saw this in action with the {@m:*}{:n} elements in the example - the message is all of the text up until the next newline.
• More complex compound matchers are described using a sub-expression. These are prefixed with an equals sign =, like {Phone:={:nat}-{:nat}-{:nat}}. This will extract chunks of text like 123-456-7890 into the Phone property.

Processing

Extraction patterns are processed from left to right. When the first non-matching pattern is encountered, extraction stops; any remaining text that couldn't be matched will be attached to the resulting event in an @unmatched property.

Multi-line events are handled by looking for lines that start with the first element of the extraction pattern to be used. This works well if the first line of each event begins with something unambiguous like an iso8601dt timestamp; if the lines begin with less specific syntax, the first few elements of the extraction pattern might be grouped to identify the start of events more accurately:

{:=[{@t} {@l}]} {@m:*}

Here the literal text [, a timestamp token, adjacent space , level and closing ] are all grouped so that they constitute a single logical pattern element to identify the start of events.

When logs are streamed into seqcli ingest in real time, a 10 ms deadline is applied, within which any trailing lines that make up the event must be received.

Examples

Tail systemd logs

journalctl -f -n 0 |
  seqcli ingest -x "{@t:syslogdt} {host} {ident:*}: {@m:*}{:n}" --invalid-data=ignore

Tail /var/log/syslog

tail -c 0 -F /var/log/syslog |
  seqcli ingest -x "{@t:syslogdt} {host} {ident:*}: {@m:*}{:n}"

Ingest an IIS/W3C web server log

This example ingests log files in the format:

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) 
cs(Referer) sc-status sc-substatus sc-win32-status sc-bytes cs-bytes time-taken

The extraction pattern is wrapped in the example for display purposes, and must appear all in one string argument when invoked.

seqcli ingest -i http.log --invalid-data=ignore -x "{@t:w3cdt} {ServerIP} {@m:={Method} {RequestPath}} 
{Query} {Port:nat} {Username} {ClientIP} {UserAgent} {Referer} {StatusCode:nat} {Substatus:nat} 
{Win32Status:nat} {ResponseBytes:nat} {RequestBytes:nat} {Elapsed}{:n}"

A nested {@m:= pattern is used to collect a substring of the log line for display as the event's message.