Skip to main content
Supported Regions:上海

Troubleshooting

Log troubleshooting is the most important method for fault diagnosis in WeDa private deployment. Due to the streamlined resource configuration in private environments, the system does not provide independent log services. All logs are stored in container internal directories and are retained for 7 days by default.

1. Core Service Architecture​

WeDa private deployment includes the following core services:

1.1 Core Business Services​

  • weda-allin-one-design (Design-time Service)

    • Responsible for application design, page editing, and other design-time functions
    • Log path: /data/log

  • allin-one-runtime (Runtime Service)

    • Responsible for data models, approval flows, API interfaces, permission management, and other runtime functions
    • Log path: /data/log

1.2 Infrastructure Services​

  • proxy

    • Request forwarding proxy service, responsible for routing distribution
    • Log viewing: View directly through docker logs or kubectl logs

  • weda-plugin-adaptors

    • External data source connection service
    • Log path: /data/log

  • gitness

    • Application build and deployment service

  • idaasserver

    • User authentication and identity verification service
    • Log path: /logs

2. Troubleshooting Process​

2.1 Determine Problem Scope​

When errors occur in the frontend interface, follow these steps to locate the problem:

  1. Get RequestId: From the browser developer tools' network panel, find the RequestId in the response headers or response body of the error interface
  2. Determine related services: Judge the involved services based on operation type
    • Page design related → weda-allin-one-design
    • Data operations, API calls → allin-one-runtime
    • External data sources → weda-plugin-adaptors

2.2 Enter Service Container​

Standalone Deployment​

# Enter runtime service container
docker exec -it allin-one-runtime bash

# Enter design-time service container
docker exec -it weda-allin-one-design bash

Cluster Deployment​

# 1. View Pod list (replace software with actual namespace)
kubectl -n software get pods | grep "allin-one-runtime"

# 2. Enter specified Pod (replace with actual Pod name)
kubectl -n software exec -it allin-one-runtime-xxxx-yyyy -- bash

2.3 Log Analysis​

After entering the container, execute the following commands for log troubleshooting:

# Switch to log directory
cd /data/log

# Search related logs by RequestId
grep "a839bbb426b028" ./*

# View latest error logs
grep -i "ERROR" ./* | tail -100

# View logs for specific time period
grep "2024-01-15 14:" ./*

Log Analysis Key Points:

  • Focus on ERROR level log information
  • Check the timeline and call chain of error occurrence
  • If the problem cannot be directly located, it is recommended to save complete logs for technical support analysis

3. Issue Feedback Standards​

To improve problem handling efficiency, please organize problem information according to the following format:

3.1 Basic Information​

  1. Error Screenshots

    • Include complete error message information
    • Browser console error information

  2. Version Information

    # Check current deployment version
    docker images | grep weda

  3. Reproduction Steps

    • Detailed description of operation steps
    • Provide test data or configuration information
    • Explain the frequency of error occurrence

3.2 Technical Information​

  1. Interface Information

    • Error API interface address
    • RequestId (if available)
    • Request parameters and response content

  2. Log Information

    • Related error log fragments
    • It is recommended to provide 50-100 lines of context logs before and after

By providing complete problem information, the efficiency of problem location and resolution can be significantly improved.