Oracle Cloud Infrastructure Documentation

Logs

You can integrate the Logging service into Data Science to create and manage custom logs.

A custom log is a first-class OCI resource that stores and captures log events collected in a given context. You can use the Logging service to enable, manage, and search Data Science custom logs for these resources:

Note

This integration is optional for all supported resources.

Job Logs

You can integrate jobs resources with the Logging service to record job run details in a custom log.

Both standard out (stdout) and standard error (stderr) outputs from your job artifact are captured and made available in the custom log. These outputs are not available to the Data Science service. We highly recommended that you enable the logging integration for jobs, both for debugging any potential issues and for monitoring the progress of running your job artifacts.

Standard out messages are categorized under the "com.oraclecloud.datascience.jobrun.stdout" type, while standard error messages are under the "com.oraclecloud.datascience.jobrun.stderr" type. For both types, the log metadata includes the "source", which is the OCID of the job run that outputs the messages.

When logging integration is enabled in the job logging configurations, you can either:

  • Provide your own log group and your own log to capture job run outputs. You can configure all the job runs to use the same log though we don't recommended it. Log messages are easier to read when each job run outputs to its own log.

    Or

  • Provide your own log group, but enable the Data Science service to automatically create custom logs on your behalf at the start of each job run within your specified log group. If automatic log creation is enabled, there is no need for you to configure logs yourself before each job run. The log created is named in the jobrun-<partial-jobrun-ocid>-logs, but the name can be edited as needed. It won't impact the logging integration with the job run.

Note

You manage the lifecycle of the logs including logs that are automatically created for you by the Data Science service.

Logs aren't deleted when the job and job runs are deleted.

For either type of logging configuration, the job run resource principal must have permissions to write to your custom logs.

Model Deployment Logs

When you integrate the Logging for model deployments, access and predict log categories are created:

Access Logs

The access log category is a custom log that captures detailed information about requests sent to the model endpoint. This information includes the time the request was received, error codes, and so on. If you are experiencing problems with your model deployment, access logs are generally the first log you want to look at.

The metadata captured by model deployment access logs are:

logEmissionTime

The time, in UTC, when the log was emitted from the code.

message

The request path.

modelLatency

The time taken to process a request on the model server in milliseconds.

opcRequestId

The request Id. This value is the same requestId that is retrieved in the response.

status

The request response status code.

For example, an access log entry for model deployment could be:

"data": {
  "logEmissionTime": "2021-01-25T07:23:39.101Z",
  "message": "POST /predict 1.1",
  "modelLatency": 4.43,
  "opcRequestId": "0BC0860C17DC46D79A0A1A7B4F139829",
  "status": 200
}
Predict Logs

Predict logs originate from logging (stdout and stderr) calls made custom code execution in the model artifact Python files. Predict logs can emit useful information about the model and are entirely customizable. Configuring access and predict logs is part of the create and edit actions.

The metadata captured by model deployment predict logs are:

MD_OCID

The model deployment OCID value.

level

The logger level. Also referred to as the severity level of the log message.

logEmissionTime

Time, in UTC, when the log was emitted from the code.

message

A custom message emitted from the model artifact Python code.

name

The name of the logger used.

For example, a predict log entry for model deployment could be:

"data": {
      "MD_OCID": "ocid1.datasciencemodeldeployment.oc1.iad.amaaaaaav66vvniauqakarfnyvn6gd2qt4fjpv2ffdnrthqyhqpapevmmh6a",
      "level": "ERROR",
      "logEmissionTime": "2021-01-27T08:43:04.029Z",
      "message": "exception :: name 'function' is not defined",
      "name": "root"
    },

You can create two separate logs for predict and access or you can use the same one for both.

Configuring Logs

Create a log group and configure a custom log in the Logging service if you don't have one already:

  1. Open the navigation menu and click Observability & Management. Under Logging, click Log Groups.
  2. Choose a compartment you have permission to work in and click Create Log Group.

    The Create Log Group panel is displayed.

  3. Enter the following:
    • Compartment: The compartment in which you want to create the log group. This field is pre-filled based on your compartment choice.

    • Name: A name for this log group. The first character of a log group name must be a letter. For more, see Log and Log Group Names. Avoid entering confidential information.

    • Description: A friendly description.
    • (Optional) Enter tagging information.
  4. Click Create

    The log group detail page is then displayed.

  5. Click Logs.
  6. Click Create custom log.
  7. Enter a name for the custom log.
  8. (Optional) Select a different compartment.
  9. Select the log group.
  10. Select Add configuration later because jobs and model deployments aren't integrated into the Logging service agent configuration.
  11. Click Create custom log.

Accessing the Logs

You can access the logs for your jobs and model deployments from the OCI Console under Solutions and Platform by selecting the Logging service and then click Search.

In the Search box, click Select logs to search. Select a compartment, a log group, and a log. Apply filters if necessary.

You should see log data in the Explore tab, see searching logs.

Tip

Copy the log OCID using Copy to use in the jobs and model deployment resources. For example, you can paste a job log OCID into multiple job runs for different configurations that can run simultaneously.