WB_BF Project Problem Description and Exploration

What I mentioned in the WB_BF project group now is "According to the test script running log, after bf ran for about 31 hours, the error message that the api call returned to nginx began to appear. After that, the bf client could not be opened." Just to clarify, I reproduced this problem on my machine this morning. For the case where the api call will return nginx error information and the bf client cannot be opened.

Now write the procedure for troubleshooting:

First check the database field for problems:

First, make sure that the bf server starts normally. When the services are running normally, enter the command in the terminal:

docker ps -a

View the currently running services and find the brainframedatabase:

input the command:

docker exec -it <数据库名称> bash

Enter the brainframe_database_1 database:

Enter the command after entering:

psql -d brainframe -U user

To list the field table, enter the command \d:

 Detect the maximum value in the three tables of total_count, zone_alarm_count_condition, and zone_alarm_rate_condition. I have no data here. After you extract it, check the maximum value in the table to troubleshoot database errors, as shown in the figure:

 

 

 Then talk about the problem that the bf server cannot start normally:

Case 1:

First of all, when the brainframe sever cannot be opened normally, you can try to solve it by restarting it. Enter the brainframe compose down command in the terminal to shut down the relevant services of the server:

Then enter the command sudo brainframe compose up -d to try to restore the bf server:

 Or directly enter the command brainframe compose restart:

 Case two:

When the above operation encounters obstacles and an error occurs in a certain service, use the docker ps command to check whether the service is normal. If there is a problem, the following is a simple process of analyzing the problem:

As mentioned in the group before, it can be passed:

docker ps

Command to judge whether the service is running normally. If the bf client fails to start, the reason will be displayed, or it will be displayed directly in the client, as shown in the figure:

This is a typical example where bf cannot be started. The problem is pointed to the conflict of Port 80, which is specifically reflected here:

 We first positioned the problem on the port.

Then perform a restart operation and find that the problem is on Creating brainframe_http_proxy_1, and it shows that the port is already occupied.

You can filter out the applications that are using port 80 through commands, and you can choose to uninstall or kill the process, as long as the bf service can be started.

Let’s go back to the 504 Gateway Time-out issue mentioned in the WB_BF group:

According to the pictures posted in the group:

 The problem is located in the 504 gateway. There are many reasons for the 504 gateway error. As mentioned above, first we can restart the service.

The second solution is to increase the configuration timeout of the nginx proxy. I don’t know much about the details of the brainframe api call, but I think you can check whether the timeout is set for the previous call interface? The 504 error of the interface needs to optimize the interface performance, which is not feasible in the short term.