Deploying an Agent
This page describes the install of the Lenses Agent via an archive on Linux.
To install the Agent from the archive you must:
Extract the archive
Configure the Agent
Start the Agent
Extracting the archive
Extract the archive using the following command. It unpacks into a lenses-agent/ directory:
tar -xzf lenses-agent-latest-linux64.tar.gzInside the extracted archive, you will find.
lenses-agent
├── lenses-agent.conf.sample ← copy to lenses-agent.conf and edit
├── security.conf.sample ← empty file (see "Starting the Agent")
├── logback.xml
├── logback-debug.xml
├── bin/ ← bin/lenses launcher
├── lib/
├── licenses/
├── logs/ ← created when you run Lenses
├── plugins/ ← create it yourself to add custom plugins to the classpath
├── storage/ ← created when you run Lenses (embedded DB)
└── ui/Configure the Agent
To configure the agents connection to Postgres and its provisioning file. See here in the quickstart.
Once the agent files are configure you can continue to start the agent.
Provisioning
Configure Kafka Connection
There are many Kafka flavours today in the market. Good news is that Lenses support all flavours of Kafka and we are trying hard to keep documention up to date.
In the following link you can find provisioning examples for the most common Kafka flavours.
Other connections
There are also provisioning examples for other components:
Configure Database
Last step is to configure a database to which Agent will be connecting to.
Running Agent with Postgres database
Running Agent with H2 embedded database
In order to run Agent with embedded database, your lenses-agent.conf should not carry any property starting with lenses.storage.postgres.*
Provisioning example file
This provisioning file includes connections to:
Starting the Agent
Start Lenses by running:
or pass the location of the config file:
If you do not pass the location of lenses-agent.conf, the Agent will look for it inside the current (runtime) directory. If it does not exist, it will try its installation directory.
To stop Lenses, press CTRL+C.
File permissions
Set the permissions of the lenses-agent.conf to be readable only by the lenses user.
The agent needs write access in 4-5 places in total:
[RUNTIME DIRECTORY]When the Agent runs, it will create at least one directory under the directory it is run in:[RUNTIME DIRECTORY]/logsWhere logs are stored[RUNTIME DIRECTORY]/logs/sql-kstream-stateWhere SQL processors (when In Process mode) store state. To change the location for the processors’ state directory, uselenses.sql.state.diroption.[RUNTIME DIRECTORY]/storageWhere the H2 embedded database is stored when PostgreSQL is not set. To change this directory, use thelenses.storage.directoryoption./run(Global directory for temporary data at runtime) Used for temporary files. If Lenses does not have permission to use it, it will fall back to/tmp./tmp(Global temporary directory) Used for temporary files (if access/runfails), and JNI shared libraries.
JNI libraries
The Agent and Kafka use two common Java libraries that take advantage of JNI and are extracted to /tmp.
You must either:
Mount /tmp without noexec
or set org.xerial.snappy.tempdir and java.io.tmpdir to a different location
SystemD example
If your server uses systemd as a Service Manager, then manage the Agent (start upon system boot, stop, restart). Below is a simple unit file that starts the Agent automatically on system boot. It assumes you moved the extracted lenses-agent directory to /opt/lenses-agent.
Global Truststore
The Agent uses the default trust store (cacerts) of the system’s JRE (Java Runtime) installation. The trust store is used to verify remote servers on TLS connections, such as Kafka Brokers with an SSL protocol, JMX over TLS, and more. Whilst for some types of connections (e.g. Kafka Brokers) a separate keystore can be provided at the connection’s configuration, for some other connections (JMX over TLS) we always rely on the system trust store.
It is possible to set up a global custom trust store via the LENSES_OPTS environment variable:
Hardware & OS
Run on any Linux server (review ulimits or container technology (docker/kubernetes). For RHEL 6.x and CentOS 6.x use docker.
Linux machines typically have a soft limit of 1024 open file descriptors. Check your current limit with the ulimit command:
Increase as a super-user the soft limit to 4096 with:
Use 8GB RAM /4 CPUs and 20GB disk space.
Last updated
Was this helpful?


