Diagnostics

Diagnostics data, collected during the execution run and uploaded once execution is completed, can be accessed by using the sas url diagnosticsLocation received in the response when calling the GET/api/compute/execution/{executionId}/diagnostics endpoint with the ID of the corresponding engine execution, e.g.:

Click to show example commands to get execution diagnostics

HTTP REST APISDK

projectId="<replacewithprojectid>"
openapikey="<replacewithopenapikey>"
executionId="<replacewithexecutionid>"

# get execution diagnostics
curl -L -X GET "https://api.mike-cloud-dev.com/api/compute/execution/$executionId/diagnostics" \
  -H 'api-version: 2' \
  -H 'dhi-service-id: engine' \
  -H "dhi-project-id: $projectId" \
  -H "dhi-open-api-key: $openapikey"

var computeClient = new ComputeClient(PlatformEnvironment.Dev /* your target environment */, new OpenApiKeyPolicy("your openapi key"));

var location = await computeClient.GetExecutionDiagnosticsLocationAsync(projectId, executionId);

{
    "executionId": "13ef752b-1b93-45b9-9677-37cd0316b049",
    "diagnosticsLocation": "https://coreenginedev0data.blob.core.windows.net/13ef752b-1b93-45b9-9677-37cd0316b049-diag?sv=2018-03-28&sr=c&sig=SFhbJletoW0t23s0Z9jlk2UJbNiV8%2BywA0mEYZ3p7oo%3D&se=2020-11-02T08%3A03%3A27Z&sp=rl"
}

See how to Obtain the results for an example on how to access the blobs.

Execution runner application collects following information:

File name	File content
stderr.txt	Error output of engine run
stdout.log	Output of engine run
taskinfo.json	Information from Azure Batch task
runnerexception.txt	Exception handled in runner program main, if any
runnerunhandledexception.txt	Unhandled exception in runner program, if any

There will be a work directory included for each executed setup. The files will be stored in 0-indexed folder:

File name	File content
workingdircontent.txt	List of files in working dir (recursive)
runnerprocessresult.json	Exit code, output, error output, process parameter and process file name

Restarted executions

An execution can be restarted by the compute platform, for instance when the node it runs on is reclaimed or requeued. Diagnostics are uploaded when the task process exits, which decides what the container holds afterwards. If the replaced attempt's process never exited - a reclaimed node - it uploaded nothing, and the container holds the latest attempt only. If it did exit and the compute platform started it again, its diagnostics were uploaded and the new attempt overwrites them file by file, so the container can hold files from both attempts. The restart's timestamp in the status history is what tells them apart.

That a restart happened is recorded elsewhere:

• in the execution's status history, which comes back with the execution details and names the reason, where the compute platform reported one;
• as an EngineExecutionRestartedMessage event carrying the same facts plus the node involved, where the compute platform still says which it was.

See Troubleshooting for how to use them.