Validating your installation
This page describes how to validate your Stardog Kubernetes installation.
Page Contents
Overview
Perform the following steps to validate if you have installed Stardog with Kubernetes correctly.
Prerequisites
curlor the Stardog CLI- For installation, install Stardog on your operating system.
- For usage, please see Using a Password File and Command Line Interface.
kubectlfor troubleshooting
Checklist
Connectivity
Desktop/Laptop
Check connectivity from desktop to Stardog server with one of the following commands:
curl -LI $SERVER_ENDPOINT -o /dev/null -w '%{http_code}\n' -s- It should return 200.
stardog-admin --server $SERVER_ENDPOINT server status
If these do not work, jump to Networking Troubleshooting.
Stardog Cloud
Add your HTTP endpoint to Stardog Cloud by going to “Manage endpoints” > “Connect to an Existing Endpoint” > enter your credentials and endpoint URL, and create a name for the connection.
From there, open Stardog Studio and connect to the endpoint you just added. If you’ve connected successfully, you’ll see a green box in the bottom right corner that says “You’ve connected to the Stardog endpoint!”.
Repeat this process as many times as necessary to account for any variations in VPN/network or device type you may have.
Launchpad
Check connectivity to your STARDOG_EXTERNAL_ENDPOINT by entering the URL for the Launchpad web server into your browser. If you’re prompted with credentials, you can connect.
If Launchpad does not load, refer to Networking Troubleshooting. If a diagnostic page shows an issue, review your IDP configuration.
All Platforms
- Verify correct permissions are associated with your superusers/admins and any other planned user roles.
- If using an IDP: Verify users are created, can authenticate, and inherit roles and permissions correctly via OAuth/Azure AD.
- Create a new project in Designer. Add a resource and new data source. Ensure that all the data sources you will use appear as available options. Create a virtual graph for each data source, and verify you’re able to select tables from the dropdown and see table data previews in Designer.
- If you have any questions about how to perform these steps or about Designer in general, see our Designer training.
- If you have enabled the BI service: Add your TLS endpoint to Tableau or PowerBI and verify the connection is successful.
- Note, the BI/SQL endpoint is distinct from your Stardog endpoint. The default port for a Stardog endpoint is 5820, whereas the port for a BI/SQL endpoint is 5806.
- If using Databricks or other coding notebooxs: Create a Databricks, Python, or R notebook and test your ability to connect to Stardog. Execute a query using the PyStardog or stardogR libraries.
- Execute a query that includes locally materialized data as well as virtualized data from at least one external data source.
- Execute a query that will take more than 60 seconds to complete to ensure you do not see a “Failed to fetch” error in Stardog or a CORS error in your browser’s JS Console.
- These errors are often caused by a timeout from your load balancer, so configure this property if you see these errors.
- Can you add data using Stardog Studio or CLI? Try loading a large file (>512MB) in an RDF format such as Turtle or TriG and ensure the data loads completely without errors. Note we recommend you do not try to load files that take more than 10 minutes. For those, we recommend using our Spark loader.
Networking Troubleshooting
- Is the Stardog server up and running?
- Did the service domain resolve? If unsure, you can run the following command:
❯ nslookup sparql.example.org
Server: 192.168.2.1
Address: 192.168.2.1#53
Non-authoritative answer:
Name: sparql.example.org
Address: 40.88.206.121
- If not, ensure your DNS is configured properly to access your load balancer or Application Gateway.
- Did your service register with your ingress controller correctly?
❯ kubectl get service -n stardog-ns
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
stardog-ns-stardog ClusterIP 10.0.158.63 <none> 5820/TCP,5806/TCP 43m
stardog-ns-stardog-launchpad ClusterIP 10.0.129.237 <none> 8080/TCP 43m
- If using nginx as ingress controller: Can you access your service from your ingress controller?
- First, get the service IP and port you are interested in testing:
❯ kubectl get service -n stardog-ns
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
stardog-ns-stardog ClusterIP 10.0.158.63 <none> 5820/TCP,5806/TCP 43m
stardog-ns-stardog-launchpad ClusterIP 10.0.129.237 <none> 8080/TCP 43m
- Second, get the name of an ingress controller:
❯ kubectl get pods -n ingress-objects
NAME READY STATUS RESTARTS AGE
ingress-nginx-controller-694464f74f-5jxp6 1/1 Running 0 64m
ingress-nginx-controller-694464f74f-75p7x 1/1 Running 0 64m
- Then, assuming we want to test the connectivity to the SPARQL endpoint, run the following command:
❯ kubectl exec -n ingress-objects ingress-nginx-controller-694464f74f-5jxp6 -- curl -LI http://10.0.158.63:5820/admin/alive -o /dev/null -w '%{http_code}\n' -s
200
- If it returns 200, the issue is most likely between your load balancer and the ingress controller (VPC, firewall, etc.).
- To troubleshoot, configure your setup to only to have one replica for the ingress controller to ensure all communication goes through that pod. Then check your ingress controller logs.
❯ kubectl logs -n ingress-objects ingress-nginx-controller-694464f74f-5jxp6
- While an unlikely source of error, you can check that your service can communicate with the pods serving the service:
- First, get a pod within the Stardog namespace:
❯ kubectl get pod -n stardog-ns
NAME READY STATUS RESTARTS AGE
stardog-ns-stardog-0 1/1 Running 0 64m
stardog-ns-stardog-launchpad-bc68df46c-pwg5k 1/1 Running 0 64m
- Assuming we want to test the connectivity to the SPARQL endpoint, run the following command:
❯ kubectl exec -n stardog-ns stardog-ns-stardog-0 -- curl -LI http://10.0.158.63:5820/admin/alive -o /dev/null -w '%{http_code}\n' -s
200
- You should get 200 returned.