In this Page
This dialog is available only to Org Admins when you click on a Snaplex within SnapLogic Manager or create a new Snaplex within Manager.
The options available vary based on the type of Snaplex selected. |
SnapLogic supports the Slack messaging app within the SnapLogic platform communications, enabling you as an Org admin to add Slack channels and recipients for your SnapLogic communications. For details on adding Slack communications to your Org, see SnapLogic Notifications through Slack. |
The properties in this tab relate to the Snaplex.
Snaplex Type | Indicates if it is a standard Snaplex. | ||
---|---|---|---|
Name | The name of your Snaplex. Rename your Snaplex to provide a better description of the type or location. The name must not exceed 100 characters.
| ||
Location | Indicates whether the Snaplex is in the cloud or on the ground. | ||
Environment | Enter the value used to configure the Snaplex nodes. Alphanumeric characters and the following special characters are allowed: Example: Dev-10 Default value: No default value. Snaplex nodes are typically configured using a slpropz configuration file, located in the $SL_ROOT/etc folder. If you use the slpropz file as your Snaplex configuration, then:
| ||
Version | The version of the Snaplex. Update the version of your Snaplex by setting the Version in Manager. This manual update initiates a rolling restart of the nodes in the Snaplex. Each node is put offline with no new pipelines being sent to the node. The node waits a maximum of 15 minutes for currently running pipelines to finish and then restart itself with the new version of the Snaplex binaries. This process is repeated for each node. The Dashboard shows the updated nodes to be running with the new version. Consider the following three designations when selecting the Snaplex version:
| ||
Minimum node per Snaplex | This option makes sure that the application master keeps a certain number of nodes alive even when there is no activity in the Snaplex (useful for Pipeline validation through Designer). Minimum number is 1. | ||
Email address for notifications | Enter the email addresses for notification if one of the Snaplex nodes does not respond for fifteen minutes. | ||
Slack Channel for notifications | Enter the Slack channels, separated by commas, for notification if one of the Snaplex nodes does not respond for fifteen minutes. Example: dev Default value: None | ||
Slack Channel for notifications | Enter the Slack recipients, separated by commas, for notification if one of the Snaplex nodes does not respond for fifteen minutes. Example: testuser Default value: None | ||
Load balancer | The URL for the load balancer for Triggered Task execution requests. Example: https://snaplexlb.mydomain.com | ||
Ultra load balancer | The URL for the FeedMaster load balancer for Ultra Pipeline execution requests. This is available only to those Orgs subscribed to Ultra Pipeline Tasks. |
When developing Pipelines in SnapLogic Designer, the version of the Snaps that you use depends on the current Snap Catalog for the Org.
Between the release of the SnapLogic GA release and the Automatic Update, the UI alerts you if any Snaplex instances are outdated with the following indicators:
Snaplex nodes running deprecated version
.<Snaplex_name> deprecated version
.
Updating a Snaplex requires an Org admin to change the version of the Snaplex settings in Manager to the current recommended version. This version update initiates a rolling upgrade for the nodes in the Snaplex to the new version. The indicators no longer display once you upgrade to the latest version of SnapLogic or after the Automatic Update.
The properties in this tab control how the nodes write log messages to the files in the /opt/Snaplogic/run/log
directory. These log files provide the backing for the Pipeline logs viewable through the SnapLogic Dashboard. For more information on configuring Snaplex logs, see Configuration Options.
Logging updates happen with the next heartbeat check. No restart is required. |
Level | The logging level that log messages must meet to be captured in the main log file. Select one of the following options:
| |
---|---|---|
Log file size | The maximum log file size, given as a number with a unit. For example, 300 MB for 300 megabytes. | |
Main backup count | The number of backup log files to keep for the main log (jcc.json). | |
Error backup count | The number of backup log files to keep for the error log (jcc_error.json). | |
Access backup count | The number of backup log files to keep for the access log (jcc_access.json). |
This tab is used to configure properties for individual nodes. The first set of properties (Max slots, Reserved slots, and Max memory) affect how pipeline executions are assigned to nodes in the Snaplex by the control plane. For example, if all of the slots on a node have been used for executing other pipelines, any new executions will be sent to other nodes in the Snaplex or the control plane will try to leave the execution in a Queued state until resources become available.
The remaining properties are used to configure the SnapLogic software running on the nodes in a Groundplex. The Groundplex nodes must have been setup to use an .slpropz configuration file before changes to these properties will take effect. If you make changes that affect the software configuration, but there are nodes in the Snaplex that are not setup to use a .slpropz configuration file, a warning dialog will appear with a listing of the unmanaged nodes. See the Downloads section below for more information on setting up a node to use this configuration mechanism.
Updates to Node Properties may require a restart of the Snaplex. |
Maximum slots | The maximum number of slots available on each node in a Snaplex. Each Snap in a Pipeline will consume a slot, so Pipelines will only be executed on nodes where the number of slots currently in use is below this threshold. Otherwise, they will fail or be placed in the Queued state, depending on how they were executed. The number of slots-in-use corresponds to the number of active threads on a node, which can be viewed on the Monitoring Snaplex Health dashboard. A restart is not required with a change to this setting, which can be set to a user-specified value. Default value: 4000 | |
---|---|---|
Reserved slots % | The percentage of slots to reserve on a node for pipelines executed through the Designer tab. A restart is not required with a change to this setting. Default value: 15
| |
Maximum memory % | The threshold at which no more pipelines will be assigned to a node. A restart is not required with a change to this setting. Default value: 85 | |
Heap max size | Groundplex only. The maximum JVM heap size. Default value: auto (meaning that SnapLogic will automatically set the max heap size based on the available machine memory). | |
HTTP interface | Groundplex only. Choose where the Snaplex node will accept HTTP network connections from. Options include:
| |
HTTP port | Groundplex only. The HTTP port the Snaplex node will listen on for connections. Default Values: 8090 for a JCC node and 8091 for a FeedMaster. | |
HTTPS port | Groundplex only. The HTTPS port the Snaplex node will listen on for connections. Default Values: 8081 for a JCC node and 8084 for a FeedMaster. | |
Restart Max Wait Time | The maximum wait time before restarting a node. Enter the maximum wait time before restarting a node or click Forever for an infinite wait time. Default: 15 minutes Recommended. No greater than 60 minutes.
| |
Snaplex node types: Hostname/Server type pairs | Groundplex only. Specify the type of service a Snaplex node should provide. Applicable in Ultra-enabled environments. | |
Global properties: | Groundplex only. Internal configuration options. Do not edit these values without contacting SnapLogic Customer Support. |
This tab controls how the nodes can communicate with an HTTP/HTTPS proxy server to communicate with the outside world. The Groundplex nodes must have been setup to use an .slpropz configuration file before changes to these properties will take effect. If you make changes that affect the software configuration, but there are nodes in the Snaplex that are not setup to use a .slpropz configuration file, a warning dialog will appear with a listing of the unmanaged nodes. See the Downloads section below for more information on setting up a node to use this configuration mechanism.
Updates to the Node Proxies will trigger a rolling restart of the Snaplex. A confirmation dialog will warn you if that is the case. |
HTTP proxy | |
---|---|
Hostname and Port | HTTP proxy configuration |
Non-proxy hosts: Host pattern | The hostnames or IP addresses that should be contacted directly instead of through the proxy. Patterns may start or end with a * for wildcards. |
HTTPS proxy | |
Hostname and Port | HTTPS proxy configuration |
Non-proxy hosts: Host pattern | The hostnames or IP addresses that should be contacted directly instead of through the proxy. Patterns may start or end with a * for wildcards. |
To setup a new Groundplex node,
Download and install the appropriate package for your operating system.
The Downloads tab is not visible until after a Snaplex is created. You must be an Org admin to access the Download links. |
/opt/snaplogic/etc
directory and make sure the file name ends with .slpropz. The download link is valid for one hour. global.properties
file./opt/snaplogic/etc
directory and restart the JCC service. If the Groundplex fails to restart after a new configuration is installed, it reverts back to the last working configuration.
jcc.bat update_service
. The max heap space for the JCC process can be set incorrectly if the Monitor process is not updated.jcc.use_lease_urls
property in the Snaplex's Global Properties to False. This workaround works for all UTF-8 characters, and hence supports all global languages.By default, if the first run of an Ultra Task fails, SnapLogic attempts to run it for a total of five times. However, you can configure the number of times you want Ultra Tasks from a specific Snaplex to run by configuring the maximum number of allowed retries for an Ultra Task. To do so, modify the following parameter in Global Properties in Snaplex Update: ultra.max_redelivery_count
to indicate the number of times you want a failed Ultra Task to run.
We recommend that for your critical workloads on the production environment, you use a minimum of two worker nodes (and two FeedMaster nodes for Ultra) to avoid service disruption during Snaplex upgrades.
If you have a Snaplex running with a global.properties file in the $SL_ROOT/etc folder, you should consider migrating the Snaplex to use the slpropz mechanism for the configuration. Running with global.properties file requires that for any configuration change you must manually update the global.properties file, copy the updated configuration to all the nodes, and then restart all the nodes.
We recommended users migrate to the new slpropz mechanism for defining configuration files. |
To migrate the Snaplex configuration to the slpropz mechanism:
Update the Snaplex properties in Manager by adding custom configurations, which remain in the global.properties into the Snaplex properties.
If you do not complete this step, then the configuration changes applied to the nodes are not available when running with slpropz. |
Navigate to the Manager > Update Snaplex > Downloads tab, and download slpropz file into the $SL_ROOT/etc folder.
Backup the global.properties and keys.properties files, then remove them from the $SL_ROOT/etc folder.
Restart the JCC process on all the nodes through the Public API. Alternatively, as an Org admin you can restart the JCC node through the Dashboard by clicking on the target node and selecting Node Restart.
The Snaplex nodes should run with the new slpropz mechanism, allowing for remote configuration updates.