Driven Administrator Guide

version 2.0.5

Configuring the Driven Server

Configure the Driven Server by using the driven.properties file that is in the ${INSTALL_DIR}/conf/ directory. (Throughout the documentation, ${INSTALL_DIR} stands for the Driven installation directory name. In general, values embedded in dollar-sign and curly-bracket syntax are usually variables that should be replaced with your real values.) Most required configuration tasks pertain to interoperability with Elasticsearch, which provides the datastore that Driven uses for persistence. You must also configure SMTP properties if you want to enable notifications features in Driven.

Configuring the Application Servlet Container

For a production or other larger-scale Driven deployment, set the following parameters to ensure sufficient memory on your system. The 4 gigabyte setting for the -Xmx and Xms parameters is a recommended minimum value.

-XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -Xmx=4G -Xms=4G

Configuring Connectivity to Elasticsearch

The driven.storage parameters in the driven.properties file configure connections to the Elasticsearch datastore. The parameters that you need to set and how you set them depends on the deployment environment that you are selecting. Follow the section below that pertains to your deployment.

Driven Storage Parameters for Embedded Elasticsearch Nodes

If you are deploying a basic single-node Driven Server installation with an embedded Elasticsearch datastore, review the settings of driven.storage properties. While most default settings in the driven.properties file are sufficient for the Driven Server to start up, the following parameters might need to be adjusted for your needs:

HTTP API Access: Set the following parameter to true if you want to permit API access to Elasticsearch on port 9200.

driven.storage.http.enable

CORS Requests: Set the following parameter to true if you want to enable cross-origin resource sharing (CORS) requests. The CORS mechanism can be useful for troubleshooting, such as running the elasticsearch-head plugin.

driven.storage.http.cors.enabled

Data Storage Location: By default, data is stored in the /driven directory, which is in the main directory of the Driven-packaged Tomcat installation. If you want to save data in a different location, specify the path in the following parameter.

driven.storage.data.path

Note	Most driven.storage properties are ignored when running with an external Elasticsearch datastore. When the datastore is external, Elasticsearch uses the settings in its own configuration file (elasticsearch.yml).

Driven Storage Parameters for Stand-alone Elasticsearch Nodes

To use an external Elasticsearch cluster, you must change the driven.properties file to tell Driven how to communicate with Elasticsearch. You can also customize settings for embedded Elasticsearch persistence, such as where the data is written to disk.

Review the following driven.properties file parameter information if you are deploying Driven to a clustered production environment:

runlocal Property: Set this property to false as shown in the following:

driven.storage.runlocal=false

Elasticsearch Host Information: You must specify the nodes of the Elasticsearch cluster by setting the driven.storage.cluster.discovery.unicast.hosts parameter. Set the parameter using the format in the following line, substituting ${NODE_1}, ${NODE_2}, and ${NODE_3} with distinct host IP or DNS values for your environment:

driven.storage.cluster.discovery.unicast.hosts=${NODE_1}:9300,${NODE_2}:9300,${NODE_3}:9300

Elasticsearch Cluster Name: You must specify the Elasticsearch cluster name for Driven. The setting for this property must match the setting for the cluster.name property in the elasticsearch.yml file for the external Elasticsearch cluster.

driven.storage.cluster.name

AWS-Hosted Elasticsearch Instances

If you run Elasticsearch on Amazon Web Services (AWS), the discovery settings in the elasticsearch.yml file can be configured to enable security groups or availability zones. You can configure Driven to support these discovery methods by setting the following relevant parameters in the driven.properties file:

driven.storage.cluster.discovery.groups
driven.storage.cluster.discovery.any_group
driven.storage.cluster.discovery.availability_zones

Enabling SMTP Notifications

You must enable and configure SMTP for Driven if you want the deployment to operate with notifications. Notifications support the Teams feature of Driven. (See Configuring Teams for Collaboration in the Driven User Guide for more information about this feature.) Notifications also are required if you want to allow users to reset their Driven passwords.

Enable and configure SMTP by setting the relevant parameters in the following properties list. In the following list, most parameter settings are only examples to show the format and source for your environment’s settings.
```
driven.smtp.enabled=true
driven.smtp.host=yoursmtphost.yourdomain.com
driven.smtp.port=587
driven.smtp.tls=true
driven.smtp.username=yourusername
driven.smtp.password=yourpassword
driven.smtp.from=info@yourdomain.com
```
Configure Driven with its external URL so that emails contain the correct hyperlinks by setting the following property:
```
driven.http.url=http://${HOST_NAME}:${PORT_NUMBER}
```

Access to Monitored Application Information

Driven teams are modeled to facilitate full access to application performance only to users who should have such permissions. By belonging to a team, a Driven user is associated with an API key that provides insight to all execution details of a particular application. However, administering and troubleshooting a full-scale data application environment often requires the flexibility to share some of the performance data with other Driven users who do not belong to the same team.

You can configure any of the two driven.apps.discoverability parameters and the two driven.apps.visibility parameters to control how broadly monitored applications and application execution details can be accessed or shared among users of different Driven teams. You can also set whether team leaders and the Driven system administrator are allowed to make access-control decisions instead. After the Driven Server is deployed and in production, neither an administrator nor a regular user can override the settings of these parameters unless they stop the server and reconfigure the driven.properties file.

The parameters determine how the following access-control levels are implemented:

Discoverability: A monitored application is discoverable for a user when the user can see the application on the Show All Apps page, in a Status View, or in an Application View. Clickable elements and links in the tables that go to deeper execution details do not function if the user does not have visibility rights.
Visibility: A user has visibility access to an application when the user can see details about an application execution, including unit-of-work and slice performance data.

Note	Discoverability and visibility operate independently of each other. Access to more detailed information (visibility) does not necessarily entail ability to see the same application in the higher-level Status View, Application View, or Show All Apps page.

Discoverability

By default, applications are discoverable by anyone logged in to Driven. Change the following parameter to false if you want to disable system-wide discoverability.

driven.apps.discoverability.default=true

By default, a team leader or a Driven administrator can change whether or not an application is discoverable. Change the following parameter to false if you do not want to grant team leaders or an admin permission to configure discoverability.

driven.apps.discoverability.team.config=true

Visibility

By default, application details are not visible to Driven users who do not belong the team that is associated with the application. Change the following parameter to true if you want users outside the application’s team to view details.

driven.apps.visibility.default=false

By default, a team leader or a Driven administrator can change whether or not an application’s details are visible. Change the following parameter to false if you do not want to grant team leaders or an admin permission to configure visibility.

driven.apps.visibility.team.config=true

Next Driven Server Task

Complete your Driven deployment by following the steps documented in Starting the Driven Server.