Install on a plain JVM¶
For an application started with java -jar that logs through Logback. You add the agent to the
java command and restart once.
Level control only in 1.0
On a plain JVM with Logback, 1.0 changes and resets logger levels, and applies the level
settings of vendor defaults files and recipes. Handler levels, drop and trim rules, top,
doctor and storm detection need java.util.logging or JBoss LogManager, so today they work
on WildFly only. A plain JVM that logs through java.util.logging alone isn't picked up yet.
See the support table.
What you need¶
- JDK 17, 21 or 25 running the application, which logs through Logback (directly or through SLF4J).
- A JDK, not just a JRE, wherever you run
logctl. logctlruns on the same machine and as the same operating-system user as the application.
Install¶
-
Download
logaperture-<version>.zipfrom the releases page and unzip it, for example to/opt/logaperture. -
Put
bin/on yourPATH, so you can type plainlogctl:export PATH="$PATH:/opt/logaperture/bin" -
Add the agent to the
javacommand, before-jar:java -javaagent:/opt/logaperture/lib/logaperture-agent.jar -jar myapp.jarIf the application is started by a script you can't edit, the
JAVA_TOOL_OPTIONSenvironment variable works too:export JAVA_TOOL_OPTIONS="-javaagent:/opt/logaperture/lib/logaperture-agent.jar"
Check it works¶
logctl env
logctl list loggers --show-all
env shows the agent's version and where it keeps its state file. The application's own log
also has one line from LogAperture at startup, LogAperture <version> active (JVM).
list loggers --show-all lists the application's loggers and their levels.
Then change one for a few minutes and watch the log:
logctl set logger com.example DEBUG for 5m
logctl status
The Quick start is written for WildFly, but its level, tier and reset steps
work the same here.
Several applications on one machine¶
logctl picks the JVM by itself when exactly one is running with the agent. With several, on a
terminal it lists them to pick from; in a script, pass --pid <n>. See
Work with several JVMs.
Each JVM keeps its sticky changes in its own state file under ~/.logaperture/instances/,
named after the directory the JVM was started from. Two applications started from the same
directory can't share one: the second one to start can't keep sticky changes, and says so in its
log. Give each its own state file with -Dlogaperture.instanceId=<name>.
Uninstall¶
Remove the -javaagent option and restart the application. Optionally delete its state file,
whose path logctl env shows.