How Do I Locate a Job Submission Failure?

Symptom

A user cannot submit jobs through DataArts Studio or on the MRS console.

Impact

Jobs cannot be submitted, and services are interrupted.

Job Processing

1. All requests pass through the APIG first and are controlled by throttling configured on the APIG.
2. The APIG forwards the requests to the api-gateway of the MRS management and control plane.
3. The API node on the MRS management and control plane polls the Knox of the active and standby OMS nodes to determine the Knox of the active OMS node.
4. The API of the MRS management and control plane submits a job to the Knox of the active OMS.
5. The Knox forwards the requests to the Executor process of the current node.
6. The Executor process submits a job to Yarn.

Figure 1 Job process

Procedure

Preparations:

• Determine whether the job is submitted through DataArts Studio or the MRS console.
• Prepare the information listed in Table 1.

  Table 1 Preparations to be made before the rectification

  No.	Item	Operation
  1	Cluster account information	Obtain the password of user admin for the cluster.
  2	Node account information	Obtain the passwords of users omm and root of cluster nodes.
  3	Secure Shell (SSH) remote login tool	Obtain such tools as PuTTY or SecureCRT.
  4	Client	Install the client.

1. Locate the cause of the exception.

   View the error code in the job log and check whether the error is reported for the APIG or MRS.

   • For an error of the public APIG (starting with APIGW), contact public APIG maintenance personnel.
   • For an MRS error, go to the next step.

2. Check the running status of services and processes.
   1. Log in to Manager and check whether a service fault occurs. If a job-related service fault or an underlying service fault occurs, rectify the fault.
   2. Check whether a critical alarm is generated.
   3. Log in to the active master node.
   4. Run the following command to check whether the OMS status is normal and whether the Executor and Knox processes on the active OMS node are normal. Knox is deployed on dual active nodes, and Executor is deployed on a single active node.

      /opt/Bigdata/om-0.0.1/sbin/status-oms.sh

   5. Run the jmap -heap PID command as user omm to check the memory usage of the Knox and Executor processes. If the old-generation memory usage is 99.9%, the memory overflow occurs.

      Run the netstat -anp | grep 8181 | grep LISTEN command to query the PID of the Executor process.

      Run the ps -ef|grep knox | grep -v grep command to query the PID of the Knox process.

      If the memory overflows, run the jmap -dump:format=b,file=/home/omm/temp.bin PID command to export the memory information and restart the process.

   6. View the native Yarn page to check the queue resource usage and whether the job has been submitted to Yarn.
      On the native Yarn page, choose Components > Yarn > ResourceManager WebUI > ResourceManager (Active).

      Figure 2 Queue resource usage on the Yarn page
      

3. Locate the fault causing the job submission failure.
   1. Log in to the MRS console and click the cluster name to go to the cluster details page.
   2. On the Jobs page, locate the row that contains the target job and click View Log in the Operation column.
   3. If there is no log or the log information is not detailed, copy the job ID in the Name/ID column.
   4. Run the following command on the active OMS node to check whether the job request is sent to Knox. If the request is not sent to Knox, Knox may be faulty. In this case, restart Knox to rectify the fault.

      grep "mrsjob" /var/log/Bigdata/knox/logs/gateway-audit.log | tail -10

   5. Search for the job ID in the Executor log and view the error information.

      Log file path: /var/log/Bigdata/executor/logs/exe.log

   6. Modify the /opt/executor/webapps/executor/WEB-INF/classes/log4j.properties file to enable the DEBUG log of the Executor. Submit the test job and view the Executor log. Check the error reported during job submission.

      Log file path: /var/log/Bigdata/executor/logs/exe.log

   7. If an error occurs in the Executor, run the following command to print the jstack information of the Executor and check the current execution status of the thread:

      jstack PID > xxx.log

   8. On the cluster details page, click the Jobs tab. Locate the row that contains the target job, and click View Details in the Operation column to obtain the actual job ID (application ID).
      Figure 3 Job details
      
   9. On the cluster details page, choose Components > Yarn > ResourceManager WebUI > ResourceManager (Active). On the native Yarn page that is displayed, click the application ID.
      Figure 4 Yarn applications
      
   10. View logs on the task details page.
       Figure 5 Task logs