Skip to main content

Syniti Knowledge Platform Connector Troubleshooting

Jenny Drummey
  • Updated

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: 

  1. Check to see if the services are running. 
  2. 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 
 troubleshooting1.png

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 
 troubleshooting2.png

 

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: 

troubleshooting3.png

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.

  1. Run the > hostname -d command to confirm the issue. This command may return the following result:
    hostname: Temporary failure in name resolution
  2. Edit the /etc/hosts file with your preferred editor on the server.
  3. 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>
  4. 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: 

    1. Open the JVM file conf/security/java.security.
    2. 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

    3. 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: 

troubleshooting4.png

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. 

troubleshooting5.png

  • 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:

  1. Select Admin from the Profile menu.
  2. Click Match in the Admin menu.
  3. Click the Remote Services tab.
  4. 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:

  1. To display the first file’s contents:
    cat /lib/systemd/system/syniti-agent-rest.service
  2. 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

  1. 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
  1. Save the changes, and (press Escape WQ!) to save the file.
  2. To display the contents of the second file:
    cat /etc/syniti-rdc/config.hcl
  3. To allow you to edit the file:  

    sudo vi /etc/syniti-rdc/config.hcl

    File Contents:
    # Syniti Remote Data Connection Agent Configuration

     

    remote {

    # 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"

     

  1. Edit the entry in bold above to point to the relevant production environment:
  1. Save the changes, press Escape WQ! to save the file.

    NOTE: Run the following commands to restart the services:

  1. To restart the daemon:

    sudo systemctl daemon-reload

  1. To stop the service:

    sudo systemctl stop syniti-agent-rest 

  1. To start the service: 

    sudo systemctl start syniti-agent-rest

  1. To stop the service: 

    sudo systemctl stop syniti-rdc

  1. 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.

 

Related articles