概要
このチェックは、Datadog Agent を通じて TorchServe を監視します。
セットアップ
ホストで実行されている Agent 用にこのチェックをインストールおよび構成する場合は、以下の手順に従ってください。コンテナ環境の場合は、オートディスカバリーのインテグレーションテンプレートのガイドを参照してこの手順を行ってください。
インストール
Agent リリース 7.47.0 から、TorchServe チェックは Datadog Agent パッケージに含まれています。サーバーに追加インストールする必要はありません。
このチェックでは、
OpenMetrics を使って TorchServe が公開できる OpenMetrics エンドポイントからメトリクスを収集します。
前提条件
TorchServe チェックは、3 つの異なるエンドポイントを使用して TorchServe のメトリクスとパフォーマンスデータを収集します。
TorchServe のドキュメントで説明されているように、config.properties
ファイルを使用してこれらのエンドポイントを構成することができます。例:
inference_address=http://0.0.0.0:8080
management_address=http://0.0.0.0:8081
metrics_address=http://0.0.0.0:8082
metrics_mode=prometheus
number_of_netty_threads=32
default_workers_per_model=10
job_queue_size=1000
model_store=/home/model-server/model-store
workflow_store=/home/model-server/wf-store
load_models=all
このコンフィギュレーションファイルは、インテグレーションがインスタンスを監視するために使用できる 3 つの異なるエンドポイントを公開します。
OpenMetrics エンドポイント
Prometheus エンドポイントを有効にするには、2 つのオプションを構成する必要があります。
metrics_address
: メトリクス API のバインディングアドレス。デフォルトは http://127.0.0.1:8082
です。metrics_mode
: TorchServe では log
と prometheus
の 2 つのメトリクスモードがサポートされています。デフォルトは log
です。このエンドポイントからメトリクスを収集するには prometheus
に設定する必要があります。
例:
metrics_address=http://0.0.0.0:8082
metrics_mode=prometheus
この場合、OpenMetrics のエンドポイントは次の URL で公開されます: http://<TORCHSERVE_ADDRESS>:8082/metrics
構成
これら 3 つの異なるエンドポイントは独立して監視することができ、インスタンスごとに 1 つの API をコンフィギュレーションファイルで個別に設定する必要があります。利用可能なすべての構成オプションについてはサンプル torchserve.d/conf.yaml を参照してください。
OpenMetrics エンドポイントの構成
OpenMetrics エンドポイントの構成オプションはコンフィギュレーションファイルの TorchServe OpenMetrics endpoint configuration
セクションにあります。最小構成では openmetrics_endpoint
オプションだけが必要です。
init_config:
...
instances:
- openmetrics_endpoint: http://<TORCHSERVE_ADDRESS>:8082/metrics
その他のオプションについては、サンプル torchserve.d/conf.yaml
ファイルを参照してください。
TorchServe は、カスタムサービスのコードから、設定した metrics_mode
に応じて利用できるメトリクスを出力できます。extra_metrics
オプションを使って、このインテグレーションがそれらのメトリクスを収集するように設定してください。これらのメトリクスには、このエンドポイント由来の他のメトリクスと同様に torchserve.openmetrics
プレフィックスが付きます。
これらのカスタム TorchServe メトリクスは、Datadog では標準メトリクスとみなされます。
Inference API の構成
このインテグレーションでは、TorchServe インスタンスの全体的なステータスを取得するために Inference API に依存しています。Inference API の構成オプションはコンフィギュレーションファイルの TorchServe Inference API endpoint configuration
セクションにあります。最小構成では inference_api_url
オプションのみが必要です。
init_config:
...
instances:
- inference_api_url: http://<TORCHSERVE_ADDRESS>:8080
このインテグレーションは Ping エンドポイントを利用して、TorchServe サーバーの全体的な健全性ステータスを収集します。
Management API の構成
Management API を利用することで、TorchServe サーバーで実行中のモデルに関するメトリクスを収集することができます。Inference API の構成オプションはコンフィギュレーションファイルの TorchServe Management API endpoint configuration
セクションにあります。最小構成では management_api_url
オプションのみが必要です。
init_config:
...
instances:
- management_api_url: http://<TORCHSERVE_ADDRESS>:8081
デフォルトでは、インテグレーションはすべてのモデルからデータを収集します。これは limit
、include
、exclude
オプションで変更できます。例:
init_config:
...
instances:
- management_api_url: http://<TORCHSERVE_ADDRESS>:8081
limit: 25
include:
- my_model.*
この構成では、my_model.*
正規表現にマッチするモデル名 (最大 25 モデル) のメトリクスのみを収集します。
また、一部のモデルを除外することもできます。
init_config:
...
instances:
- management_api_url: http://<TORCHSERVE_ADDRESS>:8081
exclude:
- test.*
この構成では、test.*
正規表現にマッチしないモデル名 (最大 100 モデル) ごとにメトリクスを収集します。
同じ構成で `include` と `exclude` オプションを使用することができます。`exclude` フィルターは `include` フィルターの後に適用されます。
デフォルトでは、インテグレーションはチェックを実行するたびにモデルの完全なリストを取得します。このチェックのパフォーマンスを向上させるために、interval
オプションを使用してこのリストをキャッシュすることができます。
`interval` オプションを使うと、メトリクスやイベントを遅らせることもできます。
完全な構成
この例では、前のセクションで説明した 3 つの異なる API を活用した完全な構成を示します。
init_config:
...
instances:
- openmetrics_endpoint: http://<TORCHSERVE_ADDRESS>:8082/metrics
# 独自の TorchServe メトリクスも収集します
extra_metrics:
- my_custom_torchserve_metric
- inference_api_url: http://<TORCHSERVE_ADDRESS>:8080
- management_api_url: http://<TORCHSERVE_ADDRESS>:8081
# 正規表現にマッチするモデル名をすべて含めます
include:
- my_models.*
# ただし、`-test` で終わるものはすべて除外します
exclude:
- .*-test
# 1 時間ごとにモデルリストのみを更新します
interval: 3600
構成変更後、Agent を再起動します。
この例では、docker-compose.yml
内の Docker ラベルとして、前のセクションで説明した 3 つの異なる API を活用した完全な構成を示します。
labels:
com.datadoghq.ad.checks: '{"torchserve":{"instances":[{"openmetrics_endpoint":"http://%%host%%:8082/metrics","extra_metrics":["my_custom_torchserve_metric"]},{"inference_api_url":"http://%%host%%:8080"},{"management_api_url":"http://%%host%%:8081","include":["my_models.*"],"exclude":[".*-test"],"interval":3600}]}}'
この例では、Torchserve ポッド上の Kubernetes アノテーションとして、前のセクションで説明した 3 つの異なる API を活用した完全な構成を示します。
apiVersion: v1
kind: Pod
metadata:
name: '<POD_NAME>'
annotations:
ad.datadoghq.com/torchserve.checks: |-
{
"torchserve": {
"instances": [
{
"openmetrics_endpoint": "http://%%host%%:8082/metrics",
"extra_metrics": [
"my_custom_torchserve_metric"
]
},
{
"inference_api_url": "http://%%host%%:8080"
},
{
"management_api_url": "http://%%host%%:8081",
"include": [
".*"
],
"exclude": [
".*-test"
],
"interval": 3600
}
]
}
}
# (...)
spec:
containers:
- name: 'torchserve'
# (...)
検証
Agent の status サブコマンドを実行し、Checks セクションの torchserve
を探します。
収集データ
メトリクス
torchserve.management_api.model.batch_size (gauge) | Maximum batch size that a model is expected to handle. |
torchserve.management_api.model.is_loaded_at_startup (gauge) | Whether or not the model was loaded when TorchServe started. 1 if true, 0 otherwise. |
torchserve.management_api.model.max_batch_delay (gauge) | The maximum batch delay time in ms TorchServe waits to receive batch_size number of requests. Shown as millisecond |
torchserve.management_api.model.version.is_default (gauge) | Whether or not this version of the model is the default one. 1 if true, 0 otherwise. |
torchserve.management_api.model.versions (gauge) | Total number of versions for a given model. |
torchserve.management_api.model.worker.is_gpu (gauge) | Whether or not this worker is using a GPU. 1 if true, 0 otherwise. |
torchserve.management_api.model.worker.memory_usage (gauge) | Memory used by the worker in byte. Shown as byte |
torchserve.management_api.model.worker.status (gauge) | The status of a given worker. 1 if ready, 2 if loading, 3 if unloading, 0 otherwise. |
torchserve.management_api.model.workers.current (gauge) | Current number of workers of a given model. |
torchserve.management_api.model.workers.max (gauge) | Maximum number of workers defined of a given model. |
torchserve.management_api.model.workers.min (gauge) | Minimum number of workers defined of a given model. |
torchserve.management_api.models (gauge) | Total number of models. |
torchserve.openmetrics.cpu.utilization (gauge) | CPU utilization on host. Shown as percent |
torchserve.openmetrics.disk.available (gauge) | Disk available on host. Shown as gigabyte |
torchserve.openmetrics.disk.used (gauge) | Memory used on host. Shown as gigabyte |
torchserve.openmetrics.disk.utilization (gauge) | Disk utilization on host. Shown as percent |
torchserve.openmetrics.gpu.memory.used (gauge) | GPU memory used on host. Shown as megabyte |
torchserve.openmetrics.gpu.memory.utilization (gauge) | GPU memory utilization on host. Shown as percent |
torchserve.openmetrics.gpu.utilization (gauge) | GPU utilization on host. Shown as percent |
torchserve.openmetrics.handler_time (gauge) | Time spent in backend handler. Shown as millisecond |
torchserve.openmetrics.inference.count (count) | Total number of inference requests received. Shown as request |
torchserve.openmetrics.inference.latency.count (count) | Total inference latency in Microseconds. Shown as microsecond |
torchserve.openmetrics.memory.available (gauge) | Memory available on host. Shown as megabyte |
torchserve.openmetrics.memory.used (gauge) | Memory used on host. Shown as megabyte |
torchserve.openmetrics.memory.utilization (gauge) | Memory utilization on host. Shown as percent |
torchserve.openmetrics.prediction_time (gauge) | Backend prediction time. Shown as millisecond |
torchserve.openmetrics.queue.latency.count (count) | Total queue latency in Microseconds. Shown as microsecond |
torchserve.openmetrics.queue.time (gauge) | Time spent by a job in request queue in Milliseconds. Shown as millisecond |
torchserve.openmetrics.requests.2xx.count (count) | Total number of requests with response in 200-300 status code range. Shown as request |
torchserve.openmetrics.requests.4xx.count (count) | Total number of requests with response in 400-500 status code range. Shown as request |
torchserve.openmetrics.requests.5xx.count (count) | Total number of requests with response status code above 500. Shown as request |
torchserve.openmetrics.worker.load_time (gauge) | Time taken by worker to load model in Milliseconds. Shown as millisecond |
torchserve.openmetrics.worker.thread_time (gauge) | Time spent in worker thread excluding backend response time in Milliseconds. Shown as millisecond |
メトリクスには、API を使って以下のプレフィックスが付けられます。
- OpenMetrics エンドポイントからのメトリクスには
torchserve.openmetrics.*
。 - Inference API からのメトリクスには
torchserve.inference_api.*
。 - Management API からのメトリクスには
torchserve.management_api.*
。
イベント
TorchServe インテグレーションには、Management API を使用した 3 つのイベントがあります。
torchserve.management_api.model_added
: このイベントは、新しいモデルが追加されたときに発生します。torchserve.management_api.model_removed
: このイベントは、モデルが削除されたときに発生します。torchserve.management_api.default_version_changed
: このイベントは、指定されたモデルにデフォルトのバージョンが設定されたときに発生します。
コンフィギュレーションファイルで `submit_events` オプションを `false` に設定することで、イベントを無効にすることができます。
サービスチェック
torchserve.openmetrics.health
Returns CRITICAL
if the Agent is unable to connect to the OpenMetrics endpoint, otherwise returns OK
.
Statuses: ok, critical
torchserve.inference_api.health
Returns CRITICAL
if the Agent is unable to connect to the Inference API endpoint or if it is unhealthy, otherwise returns OK
.
Statuses: ok, critical
torchserve.management_api.health
Returns CRITICAL
if the Agent is unable to connect to the Management API endpoint, otherwise returns OK
.
Statuses: ok, critical
Logs
TorchServe インテグレーションは、TorchServe のサービスからログを収集し、Datadog に転送することができます。
Datadog Agent で、ログの収集はデフォルトで無効になっています。以下のように、datadog.yaml
ファイルでこれを有効にします。
torchserve.d/conf.yaml
ファイルのログ構成ブロックのコメントを解除して編集します。これがその例です。
logs:
- type: file
path: /var/log/torchserve/model_log.log
source: torchserve
service: torchserve
- type: file
path: /var/log/torchserve/ts_log.log
source: torchserve
service: torchserve
すべてのログを収集する方法については、コンフィギュレーションファイルの例を参照してください。
TorchServe でのログ構成については、TorchServe 公式ドキュメントを参照してください。
`access_log.log` ファイルからログを収集することもできます。ただし、これらのログは `ts_log.log` ファイルに含まれるため、両方のファイルを構成すると Datadog のログが重複することになります。
トラブルシューティング
ご不明な点は、Datadog のサポートチームまでお問合せください。