You are viewing documentation for an older version of Lenses.io View latest documentation here

Configuration

Lenses configuration is driven by a single configuration file lenses.conf, which is divided into sections enclosed by the lenses block. The main configuration options are described in this section. Check here the full list of options.

  lenses {
    ........
  }

Once downloaded and extracted the content of the Lenses folder looks like:

  .
  ├── LICENSE.txt
  ├── NOTICE.txt
  ├── bin
  ├── jre8u131
  ├── lenses.conf
  ├── lib
  ├── licenses
  ├── logback-debug.xml
  └── logback.xml

The bin folder contains the start scripts.

Lenses can always run with a specific configuration. Simply pass the configuration full file path to the startup script:

  bin/lenses lenses.conf

Java Options 

The following environment variables control the Java configuration options when starting Lenses:

  • LENSES_HEAP_OPTS - The heap space settings, the default is -Xmx3g -Xms512m
  • LENSES_JMX_OPTS - JMX options so set
  • LENSES_LOG4J_OPTS - Logging options
  • LENSES_PERFORMANCE_OPTS - Any extra options, default is -server -XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:+DisableExplicitGC -Djava.awt.headless=true

Logging 

Lenses uses Logback for logging. The logback.xml is picked up from the installation folder. To point to a different location for the Logback configuration file just export LENSES_LOG4J_OPTS:

    export LENSES_LOG4J_OPTS="-Dlogback.configurationFile=file:mylogback.xml"

Log levels 

Logback enables hot loading of changes to the logback.xml file. The default scan window is 30 seconds, and this can be adjusted via the configuration element:

<configuration scan="true" scanPeriod="30 seconds" >
  ...
</configuration>

Default log level is set to INFO. To change adjust the configuration in <logger name="akka" level="DEBUG"/>.

The default appenders are:

<logger name="akka" level="INFO"/>
<logger name="org.apache.zookeeper.ClientCnxn" level="ERROR"/>
<logger name="com.typesafe.sslconfig.ssl.DisabledComplainingHostnameVerifier" level="ERROR"/>
<logger name="org.apache.kafka.clients.consumer.ConsumerConfig" level="ERROR"/>
<logger name="org.apache.kafka.common.utils.AppInfoParser" level="WARN"/>
<logger name="org.apache.kafka.clients.consumer.internals.AbstractCoordinator" level="WARN"/>
<logger name="io.confluent.kafka.serializers.KafkaAvroDeserializerConfig" level="WARN"/>
<logger name="org.I0Itec.zkclient" level="WARN"/>
<logger name="org.apache.zookeeper" level="WARN"/>
<logger name="org.apache.calcite" level="OFF"/>

The default pattern is %d{ISO8601} %-5p [%c{2}:%L] %m%n.

Log location 

All the logs Lenses produces can be found in the logs directory; however we recommend following the Twelve Factor App approach to logging and log to stdout, especially when using a container orchestration engine such as Kubernetes. Leave log collection to agents such as filebeats, logstash, fluentd and flume.

Ports 

At startup Lenses will bind to the IP and port set in the configuration file. To change the address and port just set the ip and port configuration entries. By default Lenses binds to port 9991.

lenses {
    # Set the ip:port for Lenses to bind to
    ip = 0.0.0.0
    port = 9991
}

License 

Lenses requires a license file which can be obtained from us. Once you have received your license token store it in a file ( i.e. license.file) and update the configuration to point to it. Please provide full file path in the configuration.

lenses {

  ...

  # License file allowing connecting to up to N brokers
  license.file="license.json"
}

The license folder contains all the third-party licenses for all the software libraries used by Lenses. A complete list is also available at https://lenses.io/third-party-software

System Topics 

Lenses requires a number of system topics for monitoring, auditing, user profiles and processors information. These topics are created by Lenses during its startup and their names are configured by the topics configuration block:

lenses {

   ...

   # topics created on start-up which Lenses uses to store state
   topics {
     audits = "_kafka_lenses_audits"
     metrics = "_kafka_lenses_metrics"
     profiles = "_kafka_lenses_profiles"
     processors = "_kafka_lenses_processors"
   }
}

Warning: Do not alter the configuration of these topics. They are managed by Lenses. If you are using ACLs grant the user running Lenses permissions to manage these topics.

If ACLs are already enabled on your Kafka cluster set the ACLs for the Lenses user and server for the following topics _kafka_lenses_audits, _kafka_lenses_metrics, _kafka_lenses_profiles and _kafka_lenses_processors.

kafka-acls \
  --authorizer-properties zookeeper.connect=my_zk:2181 \
  --add \
  --allow-principal User:Lenses \
  --allow-host lenses-host \
  --operation Read \
  --operation Write \
  --operation Alter \
  --operation Delete \
  --topic topic

JMX Monitoring 

To use the full potential of Lenses for cluster monitoring, JMX should be enabled for Kafka Brokers, Schema Registry and Zookeeper.

Enable Kafka JMX 

To enable JMX the JMX_PORT environment variable should be set for each software with the port that it should listen for JMX connections. Additional options should be set in order to access JMX remotely.

For Kafka Brokers set the JMX_PORT and KAFKA_JMX_OPTS environment variables:

    export JMX_PORT=[JMX_PORT]
    export KAFKA_JMX_OPTS="-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.local.only=false -Dcom.sun.management.jmxremote.rmi.port=[JMX_PORT]"

For Kafka Connect set the JMX_PORT and KAFKA_JMX_OPTS environment variables:

    export JMX_PORT=[JMX_PORT]
    export KAFKA_JMX_OPTS="-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.local.only=false -Dcom.sun.management.jmxremote.rmi.port=[JMX_PORT]"

For Schema Registry set the JMX_PORT and SCHEMA_REGISTRY_JMX_OPTS environment variables:

    export JMX_PORT=[JMX_PORT]
    export SCHEMA_REGISTRY_JMX_OPTS="-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.local.only=false -Dcom.sun.management.jmxremote.rmi.port=[JMX_PORT]"

For Zookeeper set the JMX_PORT and ZOOKEEPER_SERVER_OPTS environment variables:

    export JMX_PORT=[JMX_PORT]
    export ZOOKEEPER_SERVER_OPTS="$ZOOKEEPER_SERVER_OPTS -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.local.only=false -Dcom.sun.management.jmxremote.rmi.port=[JMX_PORT]"

Configuring Lenses 

Lenses integrates and monitors Kafka Brokers, Zookeepers, Schema Registries and Kafka Connect Clusters. To configure which cluster to monitor set the respective endpoints in the lenses.conf file. Use the jmx configuration section to let Lenses know about the JMX endpoints. Below you can find an example of such configuration:

lenses {

  ...

  # Set up infrastructure end-points
  kafka.brokers        = "PLAINTEXT://host1:9092,PLAINTEXT://host2:9092,PLAINTEXT://host3:9092"
  zookeeper.hosts      = "zkhost1:2181,zkhost2:2181,zkhost3:2181"
  schema.registry.urls = "http://schema-host:8081"
  connect = [
    {dev: "http://kafka-connect-dev-host-or-ip:connect-port"},
    {uat: "http://connect1:8082,http://connect2:8082,http://connect3:8082"}
  ]

  # Set up monitoring end-points
  jmx {
    brokers = "host1:broker-jmx-port,host2:broker-jmx-port,host3:broker-jmx-port"
    schema.registry = "schema-host:jmx-port"
    zookeepers = "zkhost1:jmx-port,zkhost2:jmx-port,zkhost3:jmx-port"
    connect = [ {dev: "kafka-connect-dev-host-or-ip:jmx-port"} ]
  }
}

Expose Lenses JMX 

Lenses also exposes its own JMX and therefore other systems can monitor it. To enable JMX in Lenses set the jmx.port option; to disable it please comment out the entry. The Prometheus JMX exporter <https://github.com/prometheus/jmx_exporter>__ can also be used which will make Lenses metrics available to Prometheus. A JMX exporter config file jmx_config.yaml is provided in etc. The JMX exporter from Prometheus runs as javaagent and can be set via the LENSES_OPTS environment variable:

  export LENSES_OPTS="-javaagent:/opt/jmx_exporter/jmx_prometheus_javaagent-0.7.jar=9102:/etc/jmx_exporter/config.yaml"

For monitoring from remote hosts, JMX remote access should be enabled as well.

  export LENSES_JMX_OPTS="-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.local.only=false -Dcom.sun.management.jmxremote.rmi.port=[JMX_PORT]"

Kafka SQL Configuration 

The Lenses Kafka SQL Engine allows users to browse topics or even build and execute Kafka streams flow with a SQL like syntax. There are currently three execution modes available: IN_PROC, CONNECT and KUBERNETES. The last two are available only for enterprise usage, and offer configurable and reliable scale out of Kafka Streams apps built via Lenses SQL.

Configuration of the SQL Engine execution mode is set in the sql section. When running with the execution mode set to CONNECT a SQL enabled Kafka Connect Cluster is required. To enable a cluster for Lenses SQL the Lenses SQL Connector must be installed in the cluster. The best way to archive this is via the isolated classpath loader introduced by Connect framework in Kafka 0.11.

  1. Create a folder called plugins/lib and place the Lenses SQL Connector jar inside.
  2. Set the plugin.path in the worker properties file to this location.
  3. Restart the Connect worker.

Warning: This must be done for all workers in the cluster.

#  create folder
mkdir -p plugins/lib

# copy in the jar
cp lenses-sql-runners-XXX-all.jar plugins/libs

# add plugins path to the worker properties file, ensure this is the only uncommented entry
echo $PWD/plugins/lib > worker.properties

# restart the workers
bin/connect-distributed worker.properties

If you are using Kafka versions 0.10.x the plugin.path classloader isolation is not available then set the connector first on the classpath

    export CLASSPATH=lenses-sql-runners-XX-all.jar

The Lenses SQL Connector returns metrics and state information from the KStreams application instances they are running. To control the frequency of these updates is done via the metric.return.frequency configuration entry.

In order to support Kafka Connect pause functionality and stop the SQL processors inside the connector, Lenses also needs to know the configured status topic of the target Connect cluster, the default is connect-statuses. You can find this information in the worker.properties file you started the Connect workers look for this configuration:

status.storage.topic=connect-statuses

lenses {

  ...

  # sql.execution.mode can be IN_PROC or CONNECT (to scale-out)
  # You need to deploy lenses-SQL connector to the classpath, and set your connect clusters
  sql {
    execution.mode = "CONNECT"
    connect.clusters = [ {sql: "https://ip-or-host/api/kafka-connect"} ]
    # Metric return frequency in milliseconds for connect
    connect.metric.return.frequency = 5000
    # Metric topic
    metric.topic = _kafka_lenses_metrics
    # Location to store the kstreams local state
    state.dir = logs/kstreams-state-store-dir
  }
}

Warning: For enterprise usage, the lenses.sql.state.dir must be available for all workers in any of the SQL enabled Connect Cluster and the lenses.sql.status.topic must be set to the status backing topic of the Connect cluster

Important: The connector artifacts are delivered after an initial commercial agreement

Security 

Lenses has support for the following security modes: BASIC and LDAP. The mode is configured through the security.mode option. If set to BASIC the users and roles can be set via the security.users option. For example:

lenses {

  ...

  security {
    mode = BASIC
    users = [
     {"username": "admin", "password": "admin", "displayname": "Lenses Admin", "roles": ["admin", "write", "read"]},
     {"username": "write", "password": "write", "displayname": "Write User", "roles": ["write", "read"]},
     {"username": "read", "password": "read", "displayname": "Read Only", "roles": ["read"]}
    ]
  }
}

If you want to map LDAP roles to Lenses roles you have to set security.mode value to LDAP and use the ldap configuration section to set the mapping:

security {
  mode = LDAP
  ldap {
    url = your_ldap_url
    base = your_base
    user = your_ldap_user
    password = your_ldap_password
    login.filter = the_login_filter
    memberOf.key = the_member_of_ldap_entry
    group.extract.regex = the_group_name_regex_extractor
    roles {
      admin = []
      read = []
      write = []
      nodata = []
    }
  }
}

Note: The properties admin, read, write and nodata should list user roles not users.

KeyDescriptionOptionalTypeDefault
urlThe LDAP server url. For example: ldap://mycompany.com:10389NoStringN/A
baseYour LDAP base. For example: dc=jboss,dc=orgNoStringN/A
userYour LDAP user. For example: uid=admin,ou=systemNoStringN/A
passwordYour LDAP user passwordNoStringN/A
login.filterThe LDAP search filter - must result in a unique result. See default value. <user> is required since is replaced at runtime with the current user id.YesString(&(objectClass=person)(sAMAccountName=<user>))
memberOf.keyYour LDAP member of key entry. This is the key for which a role is attached to the user entry. For example, memberOf: cn=AdminR,ou=Groups,dc=jboss,dc=org - links AdminR role to the current user entryYesStringmemberOf
group.extract.regexThe regular expression syntax to extract the role for the each memberOf(see above) entry. The default value matches the earlier example for memberOf.YesString(?i)CN=(\\w+),ou=Groups.*
roles.adminThe list of LDAP roles for which you want to grant admin rightsNoString[]N/A
roles.writeThe list of LDAP roles for which you want to grant write rightsNoString[]N/A
roles.readThe list of LDAP roles for which you want to grant read rightsNoString[]N/A
roles.nodataThe list of LDAP roles for which you want to grant nodata rightsNoString[]N/A

Kafka JAAS 

In order for Lenses to access Kafka in an environment set up with Kerberos (SASL) you need to create a standard JAAS file and start Lenses:

KafkaClient {
  com.sun.security.auth.module.Krb5LoginModule required
  useKeyTab=true
  keyTab="/full/path/keytab-file"
  storeKey=true
  useTicketCache=false
  serviceName="kafka"
  principal="kafka@MYREALM";
};

And then, add the additional option, before starting Lenses

  export LENSES_OPTS="-Djava.security.auth.login.config=/opt/lenses/jaas.conf"

Example 

lenses {

  # Set the ip:port for Lenses to bind to
  ip = 0.0.0.0
  port = 9991

  # The port to start the JMX agent to allow Lenses to be monitored - comment to disable
  jmx.port = 9015

  # License file allowing connecting to up to N brokers
  license.file="license.json"

  # topics created on start-up that Lenses uses to store state
  topics {
    audits = "_kafka_lenses_audits"
    metrics = "_kafka_lenses_metrics"
    profiles = "_kafka_lenses_profiles"
    processors = "_kafka_lenses_processors"
  }

  # Set up infrastructure end-points
  kafka.brokers        = "PLAINTEXT://host1:9092,PLAINTEXT://host2:9092"
  zookeeper.hosts      = "zkhost1:2181,zkhost2:2181,zkhost3:2181"
  schema.registry.urls = "http://schema-host:8081"
  connect = [
    {dev: "http://kafka-connect-dev-host-or-ip:connect-port"},
    {uat: "http://connect1:8082,http://connect2:8082,http://connect3:8082"}
  ]

  # Set up monitoring end-points
  jmx {
    brokers = "host1:jmx-port,host2:jmx-port,host3:jmx-port"
    schema.registry = "schema-host:jmx-port"
    zookeepers = "zkhost1:jmx-port,zkhost2:jmx-port,zkhost3:jmx-port"
    connect = [ {dev: "kafka-connect-dev-host-or-ip:jmx-port"} ]
  }

  # sql.execution.mode can be IN_PROC or CONNECT (to scale-out)
  # You need to deploy Lenses SQL connector to the classpath, and set your connect clusters
  sql {
    execution.mode = "CONNECT"
    connect.clusters = [ {sql: "https://ip-or-host/api/kafka-connect"} ]
    # Metric return frequency in milliseconds for connect
    connect.metric.return.frequency = 5000
    # Metric topic
    metric.topic = _kafka_lenses_metrics
    # Location to store the kstreams local state
    state.dir = logs/kstreams-state-store-dir
  }
}

Lenses Instances 

We recommend running 1 instance of Lenses per Kafka cluster. Running multiple instances against the same infrastructure, (if not configured appropriately) could result in SQL processors duplicating data.

Kafka Tool 

If you are looking for the best Kafka Development Tool download and use it for free.

Options Reference 

Bellow is a list of all available configuration options:

ConfigDescription
lenses.license.fileThe full path to the license file
lenses.akka.system.nameAkka Http actor system name
lenses.ipBind HTTP at the given endpoint
lenses.portThe HTTP port the HTTP server listen for connections
lenses.akka.request.timeout.msThe maximum time in milliseconds to wait for an Akka Actor to reply
lenses.akka.actors.warmup.msTime to allow Lenses actor to warm up on startup
lenses.zookeeper.hostsSpecifies the ZooKeeper connection string. Use the form hostname:port where host and port are the host and port of a ZooKeeper server. Provide multiple hosts in the form hostname1:port1,hostname2:port2,hostname3:port3 and you can add a /znode path if you are using it
lenses.zookeeper.max.session.msThe max time in milliseconds to wait for the Zookeeper server to reply for a request. The implementation requires that the timeout be a minimum of 2 times the tickTime (as set in the server configuration)
lenses.curator.initial.sleep.time.msThe initial amount of time to wait between retries when reading JMX metrics for the brokers, schema registry, connect, zk services
lenses.curator.retriesThe number of attempts to read the metrics from JMX endpoints for the brokers, schema registry, zk and connect services
lenses.zookeeper.max.connection.msThe time in msec to wait for the Zookeeper client to establish a new connection
lenses.kafka.brokersA list of host/port pairs to use for establishing the initial connection to the Kafka cluster. The client will make use of all servers irrespective of which servers are specified here for bootstrapping, this list only impacts the initial hosts used to discover the full set of servers. This list should be in the form host1:port1,host2:port2,. Since these servers are just used for the initial connection to discover the full cluster membership (which may change dynamically), this list does not require ALL brokers to be specified
lenses.schema.registry.urlsA list of host/port pairs to use for establishing the connection to the Schema Registry cluster. This list should be in the form host1:port1,host2:port2,. List all instances in case some of them are down or list the load balancer address used.
lenses.connectThe Kafka Connect clusters to use. List of key/value of cluster name and host:port
lenses.schema.registry.check.msThe interval in milliseconds to check the instances of Schema Registry are up and running
lenses.kafka.control.topicsList of Kafka topics to be marked as system topics
lenses.kafka.ws.max.poll.recordsThis is part of the WebSocket functionality for Kafka. It specifies the maximum number of records returned in a single call to poll(). It will impact how many records will be pushed at once to the WS client
lenses.sql.connect.clustersThe connect cluster if lenses.sql.execution.mode is set to CONNECT. List of key/value of cluster name and host:port
lenses.sql.execution.modeThe SQL execution mode, IN_PROC or CONNECT
lenses.sql.metric.topicThe topic to listen for SQL Connector KStream metrics on
lenses.sql.connect.metric.return.frequencyThe frequency, in milliseconds a SQL Connector should return metrics
lenses.sql.status.topicThe status backing topic of the SQL enabled Connect clusters
lenses.sql.state.dirDirectory location for state store for KStream flows. This location must exist on each worker of a SQL enabled Kafka Connect Cluster
lenses.interval.consumersThe interval in milliseconds to read the information about all consumers from Kafka
lenses.kafka.settings.consumerAllow additional Kafka consumer settings to be specified. When Lenses creates an instance of KafkaConsumer class it will use these properties during initialization
lenses.kafka.settings.producerAllow additional Kafka producer settings to be specified. When Lenses creates an instance of KafkaProducer class it will use these properties during initialization
lenses.kafka.settings.kstreamAllow additional Kafka KStream settings to be specified. When Lenses creates an instance of KStream class it will use these properties during initialization
lenses.kafka.read.max.polling.msWhen reading data from a Kafka topic, this is the time in milliseconds the call to brokers will block waiting on new records
lenses.kafka.read.max.recordsThe maximum number of records to read from a Kafka topic at once. Used for topic browsing functionality
lenses.access.control.allow.originRestrict cross-origin HTTP requests made from within Lenses client
lenses.access.control.allow.methodsRestrict the HTTP verbs allowed to initiate a cross-origin HTTP request made from within Lenses client
lenses.allow.weak.SLLAllows connecting with https:// services even if they are using self-signed certificates
lenses.sqlSampleNumber of messages to take in every sampling attempt
lenses.sqlSampleWindowHow frequently to sample a topic for new messages
lenses.kafka.ws.poll.msThis is part of the WebSocket functionality for Apache Kafka. The amount of time to wait before it reads records from the Kafka consumer
lenses.kafka.ws.consumer.buffer.sizeThis is part of the WebSocket functionality for Apache Kafka. The number of records to cache for the client. If the client can’t consume them fast enough records will be dropped
lenses.kafka.ws.heartbeat.msThis is part of the WebSocket functionality. The interval to send messages to the client in order to keep the TCP connection opened
lenses.security.modeEstablishes which mechanism to use for authentication/authorization. Available values are: NONE, BASIC and LDAP. For NONE, all requests are allowed. BASIC uses a user-password-role approach. If LDAP is chosen then the authentication is made against the given LDAP server and authorization is based on LDAP GROUPS
lenses.security.userThis only applies if lenses.security.mode has been set to BASIC. The entry should contain an array of user structures defining the user, password and access rights. Lenses support the following roles: Admin, Write, Read
lenses.security.ldap.urlThis only applies if lenses.security.mode has been set to LDAP. Contains url of the LDAP server
lenses.security.ldap.baseThis only applies if lenses.security.mode has been set to LDAP. Set the base suffix from which all operations should origin. If a base suffix is set, you will not have to (and, indeed, must not) specify the full distinguished names in any operations performed
lenses.security.ldap.userThis only applies if lenses.security.mode has been set to LDAP. Set the user distinguished name (principal) to use for getting authenticated contexts
lenses.security.ldap.passwordThis only applies if lenses.security.mode has been set to LDAP. The password (credentials) to use for getting authenticated contexts when querying LDAP
lenses.security.ldap.login.filterThe LDAP search filter - must result in a unique result. See default value. <user> is required since is replaced at runtime with the current user id
lenses.security.memberOf.keyYour LDAP member of key entry. This is the key for which a role is attached to the user entry. For example, memberOf: cn=AdminR,ou=Groups,dc=jboss,dc=org links AdminR role to the current user entry
lenses.security.group.extract.regexThe regular expression syntax to extra the role for the each memberOf (see above) entry. The default value matches the earlier example for memberOf
lenses.security.ldap.roles.adminThis only applies if lenses.security.mode has been set to LDAP. Contains all the LDAP groups allowing full admin rights for Lenses
lenses.security.ldap.roles.readThis only applies if lenses.security.mode has been set to LDAP. Contains all the LDAP groups allowing read access for Lenses
lenses.security.ldap.roles.nodataThis only applies if lenses.security.mode has been set to LDAP. Contains all the LDAP groups allowing access without seeing data
lenses.alert.buffer.sizeThe number of last raised alerts to keep. The client can call to get the alerts raised and therefore the response size is linked directly to this number and of course how many alerts have been raised
lenses.alert.consumers.lag.thresholdThe threshold beyond which an alert is raised for a consumer being too slow reading data of a topic and partition in milliseconds
lenses.jmx.portThe port to start the JMX agent to allow Lenses monitoring
lenses.jmx.brokersThe JMX ports for the Kafka Brokers. The format is hostname:port[,hostname:port]
lenses.jmx.zookeeperThe JMX ports for the Zookeeper instances. The format is hostname:port[,hostname:port]
lenses.jmx.connectThe JMX ports for the Kafka Connect instances. The format is hostname:port[,hostname:port]
lenses.jmx.schema.registryThe JMX ports for the Schema Registry instances. The format is hostname:port[,hostname:port]
lenses.jmx.kafka.lensesThe JMX ports for the Lenses instances. The format is hostname:port[,hostname:port]

Default Values

ConfigDefault
lenses.ip0.0.0.0
lenses.port9991
lenses.jmx.port9015
lenses.akka.system.namelenses
lenses.akka.request.timeout.ms1000
lenses.akka.actors.warmup.ms2000
lenses.zookeeper.max.session.ms10000
lenses.zookeeper.max.connection.ms10000
lenses.curator.initial.sleep.time.ms3000
lenses.curator.retries3
lenses.schema.registry.check.ms30000
lenses.kafka.ws.max.poll.records1000
lenses.sql.execution.modeIN_PROC
lenses.sql.metric.topic_kafka_lenses_metrics
lenses.sql.metric.return.frequency5000
lenses.sql.status.topicconnect-statuses
lenses.sql.state.dirlogs/lenses-kafka-streams
lenses.interval.consumers30000
lenses.kafka.read.max.polling.ms1000
lenses.kafka.read.max.records1000
lenses.access.control.allow.origin*
lenses.access.control.allow.methodsGET,POST,PUT,DELETE,OPTIONS
lenses.allow.weak.SLLtrue
lenses.sqlSample2
lenses.sqlSampleWindow200
lenses.kafka.ws.poll.ms1000
lenses.kafka.ws.consumer.buffer.size10000
lenses.kafka.ws.heartbeat.ms30000
lenses.security.modeBASIC
lenses.security.ldap.login.filter(&(objectClass=person)(sAMAccountName=))
lenses.security.ldap.memberOf.keymemberOf
lenses.security.group.extract.regex(?i)CN=(\w+),ou=Groups.*
lenses.alert.buffer.size100
lenses.alert.consumers.lag.threshold10000
lenses.kafka.control.topics“connect-configs, connect-offsets, connect-statuses, _schemas, __consumer_offsets”