Overview of Services
The Syniti Knowledge Platform Connector and Associated Services is a set of capabilities that allow for connectivity and targeted processing for key capabilities provided by the Syniti Knowledge Platform (“SKP”). The services deployed with the Syniti Connector are:
SYNITI-RDC
The Remote Data Connectivity or “RDC” service is the main service that provides connectivity from the remote Syniti Knowledge Platform Connector machine and SKP. This service provides the software-managed secure connectivity by polling out from the Syniti Knowledge Platform Connector machine back to SKP on a regular basis ensuring a live and healthy connection between the Syniti Connector machine and SKP.
SYNITI-AGENT-REST
RESTful web service running on the Syniti Knowledge Platform Connector that serves as the broker for scanning, profiling and replication engines.
Service Troubleshooting
The two primary services that run on the Syniti Knowledge Platform Connector machine are developed so as to use standard operating system level logging for their actions.
If issues are thought to be with the services themselves, it is best to check the status of the services directly on the Syniti Knowledge Platform Connector machine:
- Check to see if the services are running.
-
If the status of the service is not “active (running)” then try the following:
- Restart the services using the restart commands in the below section. After restarting the services, check the status of the services.
- Check the recent logs for the services to check for error message that can further the troubleshooting.
If there are service issues it is recommended that troubleshooting start with the SYNITI-RDC service and then move to the SYNITI-AGENT-REST service. Both services are required for full SKP .
Key Commands
SYNITI-RDC Service
This command provides a status of the SYNITI-RDC service and whether it is actively running or not.
sudo systemctl status syniti-rdc
Figure 1: Running Service
This command restarts the SYNITI-RDC service:
sudo systemctl restart syniti-rdc
If the service is not running or you would like more details about the service, you can check the full logs of the service using the following command:
sudo journalctl -u syniti-rdc
This command gives you the full logs of the service. Some helpful flags to send this command are described here.
This command shows you all of the logs for the past 30 minutes. Notice the text in the quotes below can be changed to extend or shorten the timeframe of the logging.
sudo journalctl -u syniti-rdc --since "30 minutes ago"
The Syniti support team may request the copy and pasting of these log messages from your terminal session into a ticket.
The `-f` in the command below follows the log live on the screen so that you can watch in real time the status and state of the service:
sudo journalctl -u syniti-rdc --since "30 minutes ago" -f
Logging of all packets over the connector using the Wireshark format can be enabled on the machine running the syniti-rdc service. In order to view the logs, it is recommended that Wireshark is installed on the machine running the service.
To enable the Wireshark logging use the following command:
sudo systemctl enable --now syniti-packet-capture@wg0.service.
Running this command runs tcpdump and stores a cyclic buffer of packets transferred over the Wireguard interface in the following folder:
/var/log/syniti-pcap
With Whireshark installed, the resulting logs can be viewed using the following command:
tshark -r <log_file_name>.pcap -V
- NOTE: The above logging is supported on SUSE and Ubuntu agents only at this time.
- Redhat logging is in development and this article will be updated when it is deployed.
SYNITI-AGENT-REST Service
This command provides a status of the SYNITI-AGENT-REST service and whether it is actively running or not.
sudo systemctl status syniti-agent-rest
Additional commands can be made to the web service itself to check for the health of the service. There is a defined Health endpoint that can be called with the following command:
curl http://localhost:9100/health -i
If this commands returns a 200 or “OK” message than the service is running correctly:
Connectivity Troubleshooting
Invoking the Java Metadata Scanners Results When Name or Service is Not Known
You may encounter instances where the SKP Connector server is not properly registered with the DNS server, leading to the following (or similar) error message during the Metadata Scanning process:
----- Metadata Scanning -----
"{java.lang.Exception}: {java.lang.Exception: Exception in thread "main" com.*****.db.*****.exceptions.JDBCDriverException: SAP DBTech JDBC: Cannot connect to *****:*****://*****:*****/ [Cannot connect to host /*****:***** [<servername>:<servername>: Name or service not known]
To resolve this issue, ensure that the SKP Connector server is correctly registered with the relevant DNS server, allowing it to recognize the server's name and translate it to its respective IP address. As a temporary workaround, you can modify the hosts file on the SKP Connector server by adding an entry that allows the server to translate its name to the IP address.
- Run the
> hostname -d
command to confirm the issue. This command may return the following result:
hostname: Temporary failure in name resolution - Edit the
/etc/hosts
file with your preferred editor on the server. - Add an entry that translates the name of the server (short and long) to its IP address. For example, XX.XXX.XX.XXX <servername>.<domain>.<com> <servername>
- Save the hosts file.
Connecting SQL Server to Java Metadata Scanner
You can correct the issue if you receive this message when attempting to connect a SQL Server instance to the Java metadata scanner:
The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption. Error: "The server selected protocol version TLS10 is not accepted by client preferences [TLS13, TLS12]"
NOTE: The Java 11 default configuration disables TLS1.
NOTE: This task must be performed by a Linux administrator.
To fix the issue:
- Open the JVM file
conf/security/java.security.
- Search for the property
jdk.tls.disabledAlgorithms
. For OpenJDK 11, its contents are similar to:jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \ DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \ include jdk.disabled.namedCurves
- Remove the TLSv1.1 and/or TLSv1 entries to re-establish those versions back to the list of usable versions within the JDK.
NOTE: The administrator may also have to execute this command to enable older protocols in the operating system:
update-crypto-policies --set LEGACY
Syniti Knowledge Platform Connector Machine to External Customer Systems
One of the primary items to troubleshoot is the connectivity from the machine running the Syniti Knowledge Platform Connector and the external systems to which it needs to connect. What follows is troubleshooting steps for debugging Knowledge Platform Agent connectivity to external systems.
Replication Engine
This is the communication between the Syniti Knowledge Platform Connector machine and the Replication engine via web services.
The recommended approach to check for connectivity is by using CURL commands from the Syniti Knowledge Platform Connector machine to the Replication engine.
Health Check
curl http://<IP Address of the matching running the Engine>:58380/health -i
Example:
curl http://10.1.1.1:58380/health -i
If this command returns a 200 or “OK” then the replication engine is running and reachable:
List Replications
For a more detailed test, a call can be made to list the replications registered against the engine using this command:
http://<IP Address of the matching running the Engine>:58380/replications
Example:
curl http://10.1.1.1:58380:58380/replications
If there are registrations registered, this command will return a payload in JSON format of the replications registered against the engine.
If the Replication Engine is not connecting, please check the following :
- The configured Ports in the Replication Engine are open for traffic between the Replication Engine and the Syniti Knowledge Platform Connector machine.
- If ‘the Enable Agent HTTP SSL’ is set to True, use HTTPS type addresses when connecting to the test URLs.
Match API
The Match API is the communication between the Syniti Knowledge Platform Connector machine and the Match API via web services. To check for connectivity, use CURL commands from the Syniti Knowledge Platform Connector machine to the Match API.
Use this Linux command:
sudo ss -lptn
The Match API (process “Cortex_WebService“) is listening to either the port 59000 or 59001, depending on whether you have used an authorized SSL certificate or not.
Use the following CURL command to check that the service is working (changing the port if required):
curl -X GET http://10.4.1.66:59000/Cortex
An HTTP 200 OK return code should be produced, listing any instances of the service that have already been initialized.
The remote Match API generates a log file here:
/opt/syniti-match/service_log.txt
The service can be stopped and restarted using the code below, but note that any running jobs will be aborted if you run it:
sudo systemctl stop syniti-match
sudo systemctl start syniti-match
Connectivity through to the Match API can also be tested from the Admin module in the Syniti Knowledge Platform.
To test the connectivity:
- Select Admin from the Profile menu.
- Click Match in the Admin menu.
- Click the Remote Services tab.
- Click the Test connection button for the remote service to test.
If the test connection is successful, the version information is set for the service, indicating the version of the Match API that is running on the remote machine.
Active Metadata Scanning
The active metadata scanning that executes in the Syniti Knowledge Platform Connector machine uses a Java-based engine to run and execute metadata scans. This engine can be run directly from the command line of the Knowledge Platform Agent machine to test for connectivity and execution.
To test the scanning-based connectivity, first navigate to:
cd /opt/apps/syniti-scanners/
Once in that directory, run this command to test the connectivity of the scanners:
java -jar syniti-dispatcher-<version>.jar -s <type> -t schema -o test -c <JAVA connection string>
Example: java -jar syniti-dispatcher-1.2.0.jar -s sqlserver -t schema -o test -c "jdbc:sqlserver://10.4.256.256:1433;user=myUserID;password=myPassword"
If the test passes successfully, this message displays:
{"error":"","result":{"passed":true}}
Other messages that could be returned would contain more detailed error messaging that can be used for additional troubleshooting.
The Active Metadata Scanners log their progress and output to a dedicated folder on the executing machine. By default this folder is:
/var/syniti-agent/scanner/logs
In this folder, for each scan, these kinds of log files are stored:
- Technical Logs—Named with the prefix “tech_” and then the uniqueID of the scan, these logs contain the technical details of the scanner execution
- Scanner Logs—Named for the uniqueID of a scan, these logs contain the details of the scanner execution
- Test Connection Logs—These log files begin with `blank_requestid` and correspond to test connections being made by the scanner
In the dispatcher’s /opt/apps/syniti-agent/scanners/scan.properties.json
file, you can specify JVM arguments that will be passed when running a specific scanner. For example, if a scan fails due to an out-of-memory error you could increase the JVM’s memory allocation using:
- “jvmArguments”: “-Xms5G -Xmx5G”.
Adjust RFC_READ_TABLE ROWCOUNT
Administrators can adjust the RFC_READ_TABLE ROWCOUNT parameter by setting a JRE system property called rfc.rowCount. This property determines how many rows are read in each call to RFC_READ_TABLE for DD03L (SAP fields). The default value is 1000000. Adjusting the value to be greater than 1,000,000 will decrease runtime but increase user session memory in the SAP system.
A simple way to set this property is to use the jvmArguments value in the scanner control file /opt/apps/syniti-agent/scanners/scan.properties.json, for example "jvmArguments": "-Drfc.rowCount=500000".
Reconfigure SKP Connector Services
Change Regions and Connectivity from Development to Production Environments
If you must change the region (US, EU and AU) that the SKP Connector is communicating with or change connectivity between Dev and Prod environments, follow the steps in this section.
There are two files that are updated as part of this process.
/lib/systemd/system/syniti-agent-service
and
/etc/syniti-rdc/config.hcl
To reconfigure SKP Connector Services:
-
To display the first file’s contents:
cat /lib/systemd/system/syniti-agent-rest.service -
To allow you to edit the file:
sudo vi /lib/systemd/system/syniti-agent-rest.service
File Contents:
[Unit]Description=Syniti Agent Service
[Install]
WantedBy=multi-user.target
[Service]
Type=simple
ExecStart=/usr/bin/syniti-agent-rest -profile-data-dir "/var/syniti-agent/profiler" -scan-data-dir "/var/syniti-agent/scanner" -venv-path "/opt/apps/syniti-agent/profiler/.venv/" -status-url "https://api.syniti-dev.com/agent/notify/status-update"
Restart=on-failure
User=synitirdc
- Edit the entry in bold above to point to the relevant production environment:
- US Region—https://api.syniti.com/agent/notify/status-update
- EU Region—https://api.syniti.eu/agent/notify/status-update
- CA Region—https://api.syniti.ca/agent/notify/status-update
- AU Region—https://api.syniti.au/agent/notify/status-update
- Save the changes, and (press Escape WQ!) to save the file.
-
To display the contents of the second file:
cat /etc/syniti-rdc/config.hcl -
To allow you to edit the file:
sudo vi /etc/syniti-rdc/config.hcl
File Contents:
# Syniti Remote Data Connection Agent Configurationremote {
# Configuration server URL. This is the URL from which endpoint configuration
# will be fetched according to poll_interval.
#
# Default: https://onprem.syniti.com/rdc/config
url = "https://onprem.syniti-dev.com/rdc/config"
# How often to poll the configuration server for updated configuration.
# Expected to be in Go's duration format, e.g. "15m", "30s", "2h", etc.
#
# Default: 1m
poll_interval = "1m"
}
# Interface to configure.
#
# Default: wg0
interface = "wg0"
- Edit the entry in bold above to point to the relevant production environment:
- US Region—https://onprem.syniti.com/rdc/config
- EU Region—https://onprem.syniti.eu/rdc/config
- AU Region—https://onprem.syniti.au/rdc/config
-
Save the changes, press Escape WQ! to save the file.
NOTE: Run the following commands to restart the services:
-
To restart the daemon:
sudo systemctl daemon-reload
-
To stop the service:
sudo systemctl stop syniti-agent-rest
-
To start the service:
sudo systemctl start syniti-agent-rest
-
To stop the service:
sudo systemctl stop syniti-rdc
-
To start the service:
sudo systemctl start syniti-rdc
NOTE: You can run a sudo systemctl status command on each of the services to check that they are running correctly.