Check to see what the web browser response is. Is the login page presented? Are there any errors presented on the web page?
- This may seem like an obvious starting point, but often, the web browser display can offer some interesting hints.
- Check to see if the URL being used is correct, which should be http://XFLOW-SERVER:9002/#/login, for a non-SSL configured environment.
- You can also bring up the Browser Console to see if there are any problems establishing connection.
If there is load balancing or friendly URL involved, check to see if an individual xFlow server accessed directly shows any issues
- Sometimes, there may also be an issue with how the load balancer or the friendly URL is operating.
- A good practise is to bypass both and try direct access to the xFlow server address itself.
On the xFlow server, check Task Manager. How many xFlow related processes are present?
Most xFlow installations will have around 5 processes running. These represent the microservices that comprise xFlow functionality. When viewed from Task Manager, sorting by Command Line and Process Name "Java.exe", you will find a list of entries such as this:
The above shows five such entries, with their http port circled for illustration.
Of concern in particular is the incident microservice, which usually operates on http port 9002 or https port 9444 and needs to be running to allow access to xFlow via web UI. Port allocations are often arbitrary, but
default port values are often used.
A lack of the above entry will usually mean the incident microservice is not running.
For a given affected process, check the logging to see what indications are present
Depending on which microservice is affected, check the corresponding logging, and if needed,
enable debug/trace logging for that microservice