MLflow 跟踪服务器

MLflow 跟踪服务器是一个独立的 HTTP 服务器，为跟踪运行/实验提供多个 REST API 端点。虽然 MLflow 跟踪可以在本地环境中使用，但在团队开发工作流程中托管跟踪服务器非常强大：

协作：多个用户可以将运行记录到同一个端点，并查询其他用户记录的运行和模型。
共享结果: 跟踪服务器还提供跟踪用户界面端点，团队成员可以轻松浏览彼此的结果。
集中访问：跟踪服务器可以作为元数据和工件远程访问的代理运行，从而更容易保护和审计对数据的访问。

启动跟踪服务器

启动跟踪服务器就像运行以下命令一样简单：

mlflow server --host 127.0.0.1 --port 8080

一旦服务器开始运行，您应该会看到以下输出：

[2023-11-01 10:28:12 +0900] [28550] [INFO] Starting gunicorn 20.1.0
[2023-11-01 10:28:12 +0900] [28550] [INFO] Listening at: http://127.0.0.1:8080 (28550)
[2023-11-01 10:28:12 +0900] [28550] [INFO] Using worker: sync
[2023-11-01 10:28:12 +0900] [28552] [INFO] Booting worker with pid: 28552
[2023-11-01 10:28:12 +0900] [28553] [INFO] Booting worker with pid: 28553
[2023-11-01 10:28:12 +0900] [28555] [INFO] Booting worker with pid: 28555
[2023-11-01 10:28:12 +0900] [28558] [INFO] Booting worker with pid: 28558
...

有许多选项可以配置服务器，更多详情请参阅配置服务器。

重要

服务器默认监听 http://localhost:5000，并且仅接受来自本地机器的连接。要让服务器接受来自其他机器的连接，您需要传递 --host 0.0.0.0 以监听所有网络接口（或特定接口地址）。这在运行服务器 在 Kubernetes pod 或 Docker 容器中 时通常是必需的配置。

请注意，出于安全原因，不建议对运行在公共网络上的服务器执行此操作。您应考虑使用 NGINX 或 Apache httpd 等反向代理，或通过 VPN 连接（更多详情请参见安全跟踪服务器）。

记录到跟踪服务器

一旦你启动了跟踪服务器，你可以通过将 MLFLOW_TRACKING_URI 环境变量设置为服务器的URI，连同其方案和端口（例如，http://10.0.0.1:5000），或者调用 mlflow.set_tracking_uri() 来连接你的本地客户端。

然后，mlflow.start_run()、mlflow.log_param() 和 mlflow.log_metric() 调用会向您的远程跟踪服务器发出API请求。

import mlflow

remote_server_uri = "..."  # set to your server URI
mlflow.set_tracking_uri(remote_server_uri)
mlflow.set_experiment("/my-experiment")
with mlflow.start_run():
    mlflow.log_param("a", 1)
    mlflow.log_metric("b", 2)

library(mlflow)
install_mlflow()
remote_server_uri = "..." # set to your server URI
mlflow_set_tracking_uri(remote_server_uri)
mlflow_set_experiment("/my-experiment")
mlflow_log_param("a", "1")

import org.mlflow.tracking.MlflowClient

val remoteServerUri = "..." // set to your server URI
val client = new MlflowClient(remoteServerUri)

val experimentId = client.createExperiment("my-experiment")
client.setExperiment(experimentId)

val run = client.createRun(experimentId)
client.logParam(run.getRunId(), "a", "1")

备注

在 Databricks 上，传递给 mlflow_set_experiment 的实验名称必须是工作区中的有效路径，例如 /Workspace/Users/mlflow-experiments/my-experiment

配置服务器

本节描述如何为一些常见用例配置跟踪服务器。请运行 mlflow server --help 以获取完整的命令行选项列表。

后端存储

默认情况下，跟踪服务器将运行元数据记录到 ./mlruns 目录下的本地文件系统中。您可以通过添加 --backend-store-uri 选项来配置不同的后端存储：

示例

mlflow server --backend-store-uri sqlite:///my.db

这将在当前目录中创建一个 SQLite 数据库 my.db，并且来自客户端的日志请求将指向此数据库。

远程工件存储

使用跟踪服务器进行代理的工件访问

默认情况下，跟踪服务器将其工件存储在其本地文件系统的 ./mlartifacts 目录下。要配置跟踪服务器以连接到远程存储并提供工件，请使用 --artifacts-destination 标志启动服务器。

mlflow server \
    --host 0.0.0.0 \
    --port 8885 \
    --artifacts-destination s3://my-bucket

通过此设置，MLflow 服务器作为访问远程工件的代理。MLflow 客户端通过向服务器发出 HTTP 请求来获取工件。

重要

如果你使用的是远程存储，你必须为服务器配置访问工件的凭证。请注意，MLflow 工件代理访问服务使用户能够拥有一个 假设的角色来访问所有工件，这些工件可以被跟踪服务器访问。更多详情请参考管理访问。

跟踪服务器解析客户端跟踪请求中的uri mlflow-artifacts:/ 到其他显式的对象存储目标（例如，”s3:/my_bucket/mlartifacts”）以与工件进行接口。以下模式都将解析为配置的代理对象存储位置（在上面的例子中，s3://my-root-bucket/mlartifacts）：

https://<host>:<port>/mlartifacts

http://<host>/mlartifacts

mlflow-artifacts://<host>/mlartifacts

mlflow-artifacts://<host>:<port>/mlartifacts

mlflow-artifacts:/mlartifacts

重要

MLflow 客户端会基于每次运行缓存工件位置信息。因此，不建议在运行终止前更改其工件位置。

使用不代理工件访问的跟踪服务器

在某些情况下，您可能希望直接访问远程存储，而不通过跟踪服务器进行代理。在这种情况下，您可以使用 --no-serve-artifacts 标志启动服务器，并将 --default-artifact-root 设置为您希望重定向请求的远程存储URI。

mlflow server --no-serve-artifacts --default-artifact-root s3://my-bucket

通过此设置，MLflow 客户端仍然会向跟踪服务器发出最少的 HTTP 请求以获取适当的远程存储 URI，但可以直接上传 / 下载远程存储中的工件。虽然这可能不是访问和安全治理的良好实践，但在您希望避免通过跟踪服务器代理工件的开销时，这可能会有用。

备注

如果 MLflow 服务器 未配置 --serve-artifacts 选项，客户端将直接将工件推送到工件存储。默认情况下，它不会通过跟踪服务器代理这些工件。

因此，客户端需要直接访问工件存储。有关设置这些凭据的说明，请参阅工件存储文档。

备注

当创建一个实验时，跟踪服务器的配置中的工件存储位置会被记录在实验的元数据中。当启用代理工件存储时，任何在非代理模式下运行的跟踪服务器创建的现有实验将继续使用非代理的工件位置。为了使用代理工件记录，必须创建一个新的实验。如果启用跟踪服务器的 -serve-artifacts 模式的目的是消除客户端对底层存储进行身份验证的需求，那么应该为客户端创建新的实验，以便跟踪服务器在迁移后可以处理身份验证。

可选地使用一个专门用于处理工件的跟踪服务器实例

MLflow 跟踪服务器可以配置为使用不同的后端存储和工件存储，并为客户端提供一个单一的端点。

然而，如果跟踪服务器请求的量足够大并且注意到性能问题，可以配置跟踪服务器以 --artifacts-only 模式运行，同时与指定 --no-serve-artifacts 的实例协同工作。这种配置确保了工件的处理与其他所有跟踪服务器事件处理隔离。

当跟踪服务器在 --artifacts-only 模式下配置时，除了与工件处理相关的任务（即模型记录、加载模型、记录工件、列出工件等）之外的任何任务都将返回一个 HTTPError。请参见以下示例，该示例展示了在 Python 中尝试从配置为 --artifacts-only 模式的服务器列出实验的客户端 REST 调用：

# Lauch the artifact-only server
mlflow server --artifacts-only ...

import requests

# Attempt to list experiments from the server
response = requests.get("http://0.0.0.0:8885/api/2.0/mlflow/experiments/list")

输出

>> HTTPError: Endpoint: /api/2.0/mlflow/experiments/list disabled due to the mlflow server running in `--artifacts-only` mode.

使用一个额外的 MLflow 服务器专门处理工件对于大规模 MLOps 基础设施可能是有用的。将工件处理的长时间运行和计算密集型任务与跟踪 API 请求的其他更快、更高容量的元数据功能分离，可以帮助减轻单个 MLflow 服务器处理两种类型负载的负担。

备注

如果一个 MLflow 服务器正在使用 --artifacts-only 标志运行，客户端应通过在 uri 位置引用中包含 host 或 host:port 定义来显式与此服务器交互。否则，所有工件请求都将路由到 MLflow 跟踪服务器，从而违背运行独立工件服务器的初衷。

安全跟踪服务器

--host 选项将服务暴露在所有接口上。如果在生产环境中运行服务器，我们建议不要广泛暴露内置服务器（因为它未经身份验证且未加密），而是将其放在反向代理（如 NGINX 或 Apache httpd）后面，或通过 VPN 连接。

然后，您可以使用这些环境变量将身份验证头传递给 MLflow。

MLFLOW_TRACKING_USERNAME 和 MLFLOW_TRACKING_PASSWORD - 用于HTTP基本认证的用户名和密码。要使用基本认证，你必须设置两者环境变量。
MLFLOW_TRACKING_TOKEN - 用于HTTP Bearer认证的令牌。如果设置了基本认证，则优先使用基本认证。
MLFLOW_TRACKING_INSECURE_TLS - 如果设置为字面值 true，MLflow 不会验证 TLS 连接，这意味着它不会验证 https:// 跟踪 URI 的证书或主机名。不建议在生产环境中使用此标志。如果设置为 true，则 MLFLOW_TRACKING_SERVER_CERT_PATH 必须不设置。
MLFLOW_TRACKING_SERVER_CERT_PATH - 指向一个CA包的路径。设置 requests.request 函数的 verify 参数（参见 requests 主接口）。当你使用自签名服务器证书时，你可以使用这个来在客户端验证它。如果设置了此项，则 MLFLOW_TRACKING_INSECURE_TLS 必须未设置（为false）。
MLFLOW_TRACKING_CLIENT_CERT_PATH - SSL 客户端证书文件的路径 (.pem)。设置 requests.request 函数的 cert 参数（参见 requests 主接口）。这可以用于使用（自签名）客户端证书。

跟踪服务器版本控制

服务器上运行的 MLflow 版本可以通过查询 /version 端点找到。这可以用来在运行实验之前检查客户端的 MLflow 版本是否与远程跟踪服务器保持最新。例如：

import requests
import mlflow

response = requests.get("http://<mlflow-host>:<mlflow-port>/version")
assert response.text == mlflow.__version__  # Checking for a strict version match