Debugging Guide
A guide to debug common issues and get help.
This page documents a series of how-tos for efficient debugging and getting help.
๐ก Introduction
If you stumbled upon this page, chances are youโre facing issues with using ZenML. This page documents suggestions and best practices to let you debug, get help, and solve issues quickly.
๐ท When to get help?
We suggest going through the following before asking for help:
- Search on Slack using the built-in Slack search function at the top of the page.
- Search on GitHub issues.
- Search the docs using the search bar in the top right corner of the page.
- Search on https://open.crowd.dev/zenml for issues older than 90 days on our Slack channel.
- Check out the Common errors section below.
- Understand the problem by studying the additional logs and client/server logs.
Chances are youโd find your answers there. If you canโt find any clue, then itโs time to post your question on Slack. Join our Slack channel here.
๐ฏ How to post on Slack?
When posting on Slack itโs useful to provide the following information (when applicable) so that we get a complete picture before jumping into solutions.
1๏ธโฃ System Information
Let us know relevant information about your system. We recommend running the following in your terminal and attaching the output to your question.
The output should look something like this:
System information provides more context to your issue and also eliminates the need for anyone to ask when theyโre trying to help. This increases the chances of your question getting answered and saves everyoneโs time.
2๏ธโฃ What happened?
Tell us briefly:
- What were you trying to achieve?
- What did you expect to happen?
- What actually happened?
3๏ธโฃ How to reproduce the error?
Walk us through how to reproduce the same error you had step-by-step, whenever possible. Use the format you prefer. Write it in text or record a video, whichever lets you get the issue at hand across to us!
4๏ธโฃ Relevant log output
As a general rule of thumb, always attach relevant log outputs and the full error traceback to help us understand what happened under the hood. If the full error traceback does not fit into a text message, attach a file or use a service like Pastebin.
Along with the error traceback, we recommend to always share the output of the following commands:
zenml status
zenml stack describe
When applicable, also attach logs of the orchestrator. For example, if youโre using the Kubeflow orchestrator, include the logs of the pod that was running the step that failed.
Usually, the default log you see in your terminal is sufficient, in the event itโs not, then itโs useful to provide additional logs. Additional logs are not shown by default, youโll have to toggle an environment variable for it. Read the next section to find out how.
๐ Additional logs
When the default logs are not helpful, ambiguous, or do not point you to the root of the issue, you can toggle the value of the ZENML_LOGGING_VERBOSITY
environment variable to change the type of logs shown. The default value of ZENML_LOGGING_VERBOSITY
environment variable is:
You can pick other values such as WARN
, ERROR
, CRITICAL
, DEBUG
to change whatโs shown in the logs. And export the environment variable in your terminal. For example in Linux:
Read more about how to set environment variables for:
See System Environment Variable for more information on other environment variables that affect the behavior of ZenML.
๐ View client and server logs
When facing a ZenML Server-related issue you can view the logs of the server to introspect deeper.
To see the logs of the local ZenML Server deployment run:
To see the logs for ZenML Server deployed using Docker containers, first you have to get ID of the Docker container:
and view the logs from the container:
To see logs for ZenML Server deployed on Kubernetes using Helm chart or zenml deploy
, first get the pod name:
and the view the logs:
For example
The logs from a healthy server should look something like this
โ Common errors
This section documents frequently encountered errors among users and solutions to each.
๐ข Error initializing rest store
Typically, the error presents itself as:
If you restarted your machine after deploying ZenML then you have to run zenml up
again after each restart. Local ZenML deployments donโt survive machine restarts.
๐ข Column โstep_configurationโ cannot be null
sqlalchemy.exc.IntegrityError: (pymysql.err.IntegrityError) (1048, โColumn โstep_configurationโ cannot be nullโ)
This happens when a step configuration is too long. We changed the limit from 4K to 65K chars, but it could still happen if you have excessively long strings in your config.
๐ข โNonetypeโ object has no attribute โnameโ
This is also a common error you might encounter when you do not have the necessary stack components registered on the stack.
For example:
In the above error snippet, the step
on line 24 expects an experiment tracker but could not find it on the stack. To solve it, register an experiment tracker of your choice on the stack. For example
and update your stack with the experiment tracker:
This also applies to all other stack components. Read more about registering stacks here.
๐ข Install ZenML on Apple Silicon without Rosetta
Our recommended, and tested approach is to install via Rosetta
.
But a community member recently discovered a way to install ZenML on Apple Silicon without Rosetta. Join the conversation here.