Configurable Settings - Java Static Agent on Linux

How to apply changes to the Controller environment

Changes in the installation.yaml can be applied by running the install script or the upgrade script. Note that re-running the install script will delete any information that would have been stored previously.

Required fields in installation.yaml

Variable Name
Key Value
Explanation of the Variable and Key Values
controller.name
 String This will be the identifier used in the VF Server UI. So, this should be as precise a name as possible, e.g. "UAT Viper" or "Prod App1"
controller.host
 String The controller.host is the address that the vFunction Server address with which the Controller will connect. The value needs to start with http:// or https://. The value can be an IP Address or a FQDN
controller.org_id
controller.app_id
controller.client_id
controller.client_secret
Strings Once the Server is installed, the Admin can log into the UI and create the App. In the UI's Install Controller dialog box, the YAML values for the org_id, app_id, client_id and client_secret will be displayed. The values for this YAML file should be copied for the Server UI to here
controller.type
 String "java"
viper.archives
 List of Strings Path(s) to the Monolithic Application's Binary Archives, such as /opt/application/lib/*.jar

Sample with required fields in installation.yaml

controller:
  name: ProdApp
  host: http://10.0.0.1
  org_id: 111111-1111-1111-1111-111111
  app_id: 111111-1111-1111-1111-111111
  client_id: 111111-1111-1111-1111-111111
  client_secret: 111111-1111-1111-1111-111111
  instance_id: Prod
  type: java
  jolokia_port: 8778
  tags:
    - prod
    - app
  client_certificate:
    crt: |
      -----BEGIN CERTIFICATE-----
      ...
      -----END CERTIFICATE-----      
    key: |
      -----BEGIN PRIVATE KEY-----
      ...
      -----END PRIVATE KEY-----      

server_application:
#  name:
#  include_classes: com.
#  allowed_users:

viper:
  port: 8090
  archives:
    - /tmp/vfunction/binaries/*.war
#    - /opt/<my-application>/**/*.jar
#    - /opt/<my-application>/**/*.
  ### Supported only for Oracle databases!
  stored_procedure:
#    db_url:
#    db_user:
#    db_password:
  spring:
    custom_context_roots:
#      - path/to/custom-conf.xml
#      - another-custom-conf.xml
    root_bean_classes:
#      - a.b.c.Foo
#      - a.b.c.Bar

Optional fields in installation.yaml

controller.instance_id
Installation.yaml Configuration
Details
controller:
   instance_id: containerized
  • Used for containerized vFunction controllers
  • Can be set to any String value (e.g., ID1234)
  • Used to prevent an ongoing increase in the number of Down Controllers in the vFunction Server UI's Select Controllers page when Controllers are down
  • Maps a restarted controllers (i.e., a container that went down and came back up) with a controller in the down state that has the same ID
controller.tags
Installation.yaml Configuration
Details
controller:
   tags:
      - prod
      - web
  • Use Tags to organize Agents by functionality, environment or other logical groupings
  • Assign Tags to help with Scheduled or Triggered Learning.
  • Tags are useful when the application is re-deployed on different nodes (VM/Pods) and the IDs of the controllers are changed because of it.
  • Tags are assigned during install, they are not updated when restarting the controller
viper.debug_mode
Installation.yaml Configuration
Details
viper:
   debug_mode: true
  • Adds additional logging to the output of the vfviper.log
viper.jvm_memory_params
Installation.yaml Configuration
Details
viper:
   jvm_memory_params: "-Xms300m -Xmx4g -Xss50m"
  • By default, the Viper service is started with the Memory-related settings:
    -Xms300m -Xmx3g -Xss50m
  • For larger applications, this may cause the static analysis to run slowly
  • Increase the Max Heap Size (Xmx setting) to speed up the static analysis

The table below can help to set the viper.jvm_memory_params’s Xmx value depending on the number of Classes in the Namespaces of the Application’s Business Logic.

Classes in Namespaces(s) Recommended RAM
Less than 8k 2gb
8k-20k 4gb
20k-100k 8gb
viper.stored_procedure
Prerequisites for viper.stored_procedure

The following prerequisites are needed for tracking Stored Procedures with vFunction:

  1. Oracle database using Stored Procedures
  2. An Oracle database user who has SELECT access to the DBA_DEPENDENCIES table in the Oracle database

As a best practice, create a new user for the purpose of gathering Stored Procedures information for the vFunction Analysis:

  1. Log into the DB as an Administrator
  2. Create a new user
  • Find-and-replace $USERNAME with the actual Username
  • Find-and-replace $PASSWORD with the desired Password
create user $USERNAME identified by "$PASSWORD";
  1. Grant access to DBA_DEPENDENCIES
  • Find-and-replace $USERNAME with the actual Username
grant select on DBA_DEPENDENCIES to $USERNAME;
  1. The URL to access the Oracle Database from the VF Controller, including the Driver Type used in the DB Connection and whether the connection is made using SIDs or a Service Name
  2. The Username and Password for the Oracle database user
Settings for viper.stored_procedure

The following settings should be added to the installation.yaml:

Installation.yaml Configuration
Details
viper:
   stored_procedure:
      db_url: jdbc:oracle:thin://@10.0.0.43:15421/XE
      ### Format displayed: jdbc:oracle:thin://@HOST:PORT/SERVICE_NAME
      ### If the user is a sysoper or sysdba, use the internal_login parameter: jdbc:oracle:thin://@HOST:PORT/SERVICE_NAME?internal_login=SYSDBA
      ### Alternate format using SID: jdbc:oracle:thin:@\HOST:PORT:SID
      ### Alternate format using OCI driver: jdbc:oracle:oci://@DATABASE_NAME
      db_username: charlotteLee
      db_password: c0mpleX!
  • For organizations using an Oracle database for Stored Procedures
  • vFunction displays the database tables used by the Stored Procedures that are seen in the Static Analysis
  • Information about Stored Procedures is gathered through the Viper process
  • It will not be necessary to redo Dynamic Learning if setting up Stored Procedures on an existing Application

Global.yaml Settings

Overview

The installation.yaml defines the settings for individual instances. The global.yaml defines the settings for all instances in the environment. The settings in the global.yaml are distinct from the settings in the installation.yaml

Location of Global.yaml
  • Root / Sudo Installation: /etc/sysconfig/vfunction/installation/global.yaml
  • Sudoless Installation: BASE_DIRECTORY/vfunction/etc/sysconfig/vfunction/installation/global.yaml
Optional Global.yaml Settings
agent.use_java_6_or_7_jre
Global.yaml Configuration
Details
agent:
   use_java_6_or_7_jre: true
  • Uncomment this value to change from the default value of "false"to the value "true"
  • Setting this value to "true" will allow the installation to use a distinct vFunction Agent version intended for Applications that run on Java 6 or 7
  • Leaving this value as "false" or commented out will allow the installation to use the vFunction Agent intended for Applications that run on Java 8, 11 or 17
controller.poll_interval_secs
Global.yaml Configuration
Details
controller:
   poll_interval_secs: 5
  • By default, the vFunction Agents attempt to reach the vFunction Server every five seconds with an Alive message. This workflow helps the Server know which Agents are Up. And, the Server's response to this Alive message initiates the Learning process for the Agents
  • The polling interval can be increased or decreased as desired
controller.upload_interval_secs
Global.yaml Configuration
Details
controller:
   upload_interval_secs: 15
  • By default when in Learning, the vFunction Agent collects all traces from the Application and sends these traces to the vFunction Server every 15 seconds for analysis
  • This upload interval can be increased or decreased as desired
general.custom_logs_folder
Global.yaml Configuration
Details
general:
   custom_logs_folder: /path/to/desired/folder
  • By default, the vFunction Agent writes logs to (sudo) /var/log/vfunction/instances/$INSTANCE_NAME or (sudoless) $BASE_INSTALL_DIR/vfunction/var/log/vfunction/instances/$INSTANCE_NAME. The logging directory can be changed to a separate location as desired
general.sleep_after_service_start
Global.yaml Configuration
Details
general:
   sleep_after_service_starts:
  • This setting is useful for Viper only. After running the installation / upgrade / restart script, the script and / or Service goes to sleep for 1 second by default. Then the Service attempts to connect to the vFunction Server. This setting adjusts the amount of time before the connectivity attempt is made
general.sleep_after_service_stop
Global.yaml Configuration
Details
general:
   sleep_after_service_stop:
  • This setting is useful for Viper only. After running the installation / upgrade / restart script, the script and / or Service attempts to confirm that the Service is actually stopped. This setting adjusts the amount of time before the attempt is made to confirm that the Service was actually stopped
proxy.http_proxy
Global.yaml Configuration
Details
proxy:
   http_proxy:
  • Ensures that all HTTP outbound requests from the vFunction Agent to the vFunction Server are routed through a proxy
  • Formatting should include the protocol and port, e.g. http://proxy.address:2197
proxy.https_proxy
Global.yaml Configuration
Details
proxy:
   https_proxy:
  • Ensures that all HTTPS outbound requests from the vFunction Agent to the vFunction Server are routed through a proxy
  • Formatting should include the protocol and port, e.g. https://proxy.address:2198
proxy.no_proxy
Global.yaml Configuration
Details
general:
   no_proxy:
  • This setting ensures that specific addresses are not routed through the HTTP_PROXY and / or HTTPS_PROXY address. This setting is useful if some traffic, such as to a logging processor, are routed internally rather than through a proxy
viper.use_machine_java_for_viper
Global.yaml Configuration
Details
viper:
   use_machine_java_for_viper: true
  • With this value set to "false" or commented out, the vFunction installation installs its own version of Java in order for the Viper process to run
  • If uncommented and set to "true", the vFunction installation will use the Java version running on the machine where the installation is run

Updated on 30 Dec 2025