Dell NetWorker REST API: Simplified Troubleshooting

For more Information, check our Knowledge Base: //www.dell.com/support/kbdoc/14298 In this video we look at the basic connection to NetWorker using REST API, some examples of commands and how to triage an issue with this technology. REST API Developer Guide: //developer.dell.com/apis/2378/versions/v3/docs/GettingStarted.md

There are a number of rest API clients which can be used to connect to a network or server using rest API. For this example we are using a tool called postman but any rest API client tool plug in or operating system commands such as curl can be used to connect to the network or server. We need to add the following two headers content type with the value application JSON and accept with a value of application JSON. We will also need to enable basic authorization and enter the user name and password of the networker administrator account.


These are the same credentials that you would use to log into the networker management console or networker web user interface. An optional header can be used to redirect the user authentication to a specified networker authentication server. Typically this is the same host as the network or server. However in some environments with multiple network or server data zones the network of servers may be configured with user authentication on a specific network or server. An example of this header is X dash nw dash off C dash base dash URL in the value field enter the fully qualified domain name or IP address of the network or server. And this would be the network or server where the authentication is configured you also enter the authentication port which by default is 9090.

This header will instruct the rest API to use the authentication or the credentials you entered on the host specified instead of the network or server that is specified in the URL. In this example we will do a simple get to the network or servers rest API interface. As you can see we've entered the network of servers host name along with the authentication port 9090 then forward slash network arrest.

API you may need to disable SSL certificate verification from the rest API client. As you can see as I've done here a status of 200 is returned indicating that it was successful and we can see the various rest API N points. In most cases you will use the latest version available which currently is networker or is version three. We interact with the rest API through addresses called uniform resource identifier or UR I to connect to networker and display resources.

We can add global to the URIA list of available networker resources is shown. For example we can list what's currently available in networkers jobs database by adding jobs. All available end points are listed in the global UR I. This returns that we have currently 39 jobs in the Jobs database. We can query and filter information from this output by using the attributes and values shown in the UR I end point. For example we can query for jobs with completion statuses and then filter or client names and in some cases commands or messages depending on what is available in that ur I you can do this by adding Q equals and then the attribute that you want to filter for. So in this case status completion status is equal to succeeded. And then if we wanted to add another query we could do and Q equals type save job and then to filter for specific information we could do and fl equals client host name. This has now returned the completed backup jobs as well along with their client host names.

If you wanted to add additional information to the filter you could do comma and then the other value you would like to be presented. When encountering rest API issues there are a number of files you'll want to look at when engaging support collect these files along with system information you'll also need to define the rest API function being performed. For example a get post put or delete rest API function the UR I used so the full UR I any JSON body content when performing a put or post operation the rest API response code and any message returned when applicable.

If you're using an external authentication host as described in the first part of this video. You'll need to also collect the authentication logs from that off sea host. The system information can be provided using the NSR watch command on Linux or Windows network or servers from a root or admin command prompt run the command NSR watch collect the server host name the full networker version including the build number and the full operating system including its version to exit this screen hit Q on Linux hosts. The logs required are under the following path for the off sea authentication. Logs look at NSR of C logs.

The rest API logs are under NSR logs rest API and the networker service. Damon dot rock can also be useful. This is under NSR logs. Damon dot ra on servers where runtime rendering is enabled you will have a Damon dot log provide both the Damon dot raw and Damon dot log. The Damon dot log will be rendered in the servers local time zone. If only the Damon dot raw is available it will be rendered in the time zone of whichever server. The raw file was rendered on to collect the logs. You can run the following. Tar Tar CV ZF specify an output location.

In this case I'll place the bundle under the temp directory. You can use the following to generate the bundle with the host name and date along with the TGZ extension host name underscore date dash capital I dot TGZ specify the path to the OC logs NSROC logs the rest API logs NSR logs rest API and then the network of servers. Damon dot raw. And again you can also add the Damon dot log. If you have it we will now have a bundle with the server's host name and date under the temp directory on windows servers. You can find the logs under the installation drive.

In this case the default location was used C program files E MC networker NSR the authentication server logs are under off C dash server tomcat logs. The rest API logs will be under NSR logs rest API the network of servers. Damon dot raw and dot log file one available are under NSR logs for more complex issues. Rest API debugging can be enabled. The debugging is applied in rest API S log back dot XML file. The path of this file is under NSR off sea server tom cat web apps NW rest API web dash inf classes. You can make a copy of the file then modify the original file and when no longer needed you can revert the file back to the copy made. I'll be making the changes on a Linux server. However the changes are the same regardless of the servers operating system on Linux.

The file is under NSROC web apps NW API web dash inf classes and then log back dot XML. Towards the end of the file you'll see a section regarding the log levels. The supported log levels are error warn info debug and trace change the NW web API nw.com and NW dot U tail lines to debug below this you'll see a section that says for API call logging enable the following trace settings to do this. You'll need to remove the closed comment from the end of the blog. You can move it to the end of this line here. Now you'll see that the web API request and web API response lines are un commented and you can leave them set to trace or the spring framework and Jax RS dot provider lines you can change these to debug and the root level to debug. You do not need to restart network services.

These changes will take effect immediately to get de bug logging returned to the rest API client. Reproduce the error message performed on the network or server. You can open the rest API log and you'll see that trace and debug logging is enabled to revert these settings. Simply either go back to the file uh copy that you created or modify the file and go back to less debug settings. You can create a zip of the files and engage support.