前のトピックで説明した LLM トラフィックルーティング機能に加えて、ASM は LLM シナリオにおける可観測性を強化しています。このトピックでは、ASM のアクセスログと監視メトリクスを使用して LLM リクエスト情報を観測する方法について説明します。
すべての機能を実証するため、このトピックでは、トラフィックルーティング: ASM を使用して LLM トラフィックを効率的に管理するのすべてのステップを完了していることを前提としています。そのトピックのステップ 1 とステップ 2 のみを完了している場合でも、ステップ 2 のコマンドを使用してテストリクエストを送信できます。可観測性データを表示するコマンドは、このトピックのコマンドと同じです。
ステップ 1: アクセスログによる LLM リクエストの観測
アクセスログの設定
ASM は LLM リクエストのログ記録を強化しています。この情報をアクセスログで表示するには、カスタムアクセスログ形式を更新するだけです。詳細については、「カスタムデータプレーンアクセスログ」をご参照ください。
ASM コンソール にログインします。左側のナビゲーションウィンドウで、 を選択します。
[メッシュ管理] ページで、ASM インスタンスの名前をクリックします。左側のナビゲーションウィンドウで、 を選択します。
-
グローバルの Log Settings で、次の 3 つのフィールドを追加します。
テキストの内容は次のとおりです:
request_model FILTER_STATE(wasm.asm.llmproxy.request_model:PLAIN) request_prompt_tokens FILTER_STATE(wasm.asm.llmproxy.request_prompt_tokens:PLAIN) request_completion_tokens FILTER_STATE(wasm.asm.llmproxy.request_completion_tokens:PLAIN)フィールドの定義は次のとおりです:
-
request_model: 現在の LLM リクエストで使用した実際のモデル (
qwen-turboやqwen1.5-72b-chatなど)。 -
request_prompt_tokens: リクエストの入力トークン数。
-
request_completion_tokens: リクエストの出力トークン数。
ほとんどの LLM サービスプロバイダーは、トークン使用量に基づいて課金します。このデータを使用すると、トークンを消費するリクエストを追跡し、使用されたモデルを特定できます。
-
検証
-
ACK クラスターの kubeconfig を使用して、次の 2 つのコマンドを個別に実行します。
kubectl exec deployment/sleep -it -- curl --location 'http://dashscope.aliyuncs.com' \ --header 'Content-Type: application/json' \ --data '{ "messages": [ {"role": "user", "content": "Please introduce yourself"} ] }'kubectl exec deployment/sleep -it -- curl --location 'http://dashscope.aliyuncs.com' \ --header 'Content-Type: application/json' \ --header 'user-type: subscriber' \ --data '{ "messages": [ {"role": "user", "content": "Please introduce yourself"} ] }'kubectl exec deployment/sleep -it -- curl --location 'http://dashscope.aliyuncs.com' \ --header 'Content-Type: application/json' \ --data '{ "messages": [ {"role": "user", "content": "Please introduce yourself."} ] }'kubectl exec deployment/sleep -it -- curl --location 'http://dashscope.aliyuncs.com' \ --header 'Content-Type: application/json' \ --header 'user-type: subscriber' \ --data '{ "messages": [ {"role": "user", "content": "Please introduce yourself."} ] }' -
次のコマンドを実行してアクセスログを表示します。
kubectl logs deployments/sleep -c istio-proxy | tail -2想定される出力:
{"bytes_received":"85","bytes_sent":"617","downstream_local_address":"47.93.xxx.xx:80","downstream_remote_address":"192.168.34.235:39066","duration":"7640","istio_policy_status":"-","method":"POST","path":"/compatible-mode/v1/chat/completions","protocol":"HTTP/1.1","request_id":"d0e17f66-f300-411a-8c32-xxxxxxxxxxxxx","requested_server_name":"-","response_code":"200","response_flags":"-","route_name":"-","start_time":"2024-07-12T03:20:03.993Z","trace_id":"-","upstream_cluster":"outbound|80||dashscope.aliyuncs.com","upstream_host":"47.93.xxx.xx:443","upstream_local_address":"192.168.34.235:38476","upstream_service_time":"7639","upstream_response_time":"7639","upstream_transport_failure_reason":"-","user_agent":"curl/8.8.0","x_forwarded_for":"-","authority_for":"dashscope.aliyuncs.com","request_model":"qwen1.5-72b-chat","request_prompt_tokens":"3","request_completion_tokens":"55"} {"bytes_received":"85","bytes_sent":"809","downstream_local_address":"47.93.xxx.xx:80","downstream_remote_address":"192.168.34.235:41090","duration":"2759","istio_policy_status":"-","method":"POST","path":"/compatible-mode/v1/chat/completions","protocol":"HTTP/1.1","request_id":"d89faada-6af3-4ac3-b4fd-xxxxxxxxxxxxx","requested_server_name":"-","response_code":"200","response_flags":"-","route_name":"vip-route","start_time":"2024-07-12T03:20:30.854Z","trace_id":"-","upstream_cluster":"outbound|80||dashscope.aliyuncs.com","upstream_host":"47.93.xxx.xx:443","upstream_local_address":"192.168.34.235:38476","upstream_service_time":"2759","upstream_response_time":"2759","upstream_transport_failure_reason":"-","user_agent":"curl/8.8.0","x_forwarded_for":"-","authority_for":"dashscope.aliyuncs.com","request_model":"qwen-turbo","request_prompt_tokens":"11","request_completion_tokens":"90"} -
フォーマット後のログの内容は次のとおりです:
{ "duration": "7640", "response_code": "200", "authority_for": "dashscope.aliyuncs.com", // 実際にアクセスした LLM プロバイダー "request_model": "qwen1.5-72b-chat", // 現在のリクエストで使用したモデル "request_prompt_tokens": "3", // 現在のリクエストの入力トークン数 "request_completion_tokens": "55" // 現在のリクエストの出力トークン数 }{ "duration": "2759", "response_code": "200", "authority_for": "dashscope.aliyuncs.com", // 実際にアクセスした LLM プロバイダー "request_model": "qwen-turbo", // 現在のリクエストで使用したモデル "request_prompt_tokens": "11", // 現在のリクエストの入力トークン数 "request_completion_tokens": "90" // 現在のリクエストの出力トークン数 }
ASM は SLS と統合されています。これらのアクセスログを収集して保存することで、リクエストレベルの LLM 呼び出しを観測し、カスタムアラートルールを定義し、洞察に富んだダッシュボードを構築できます。詳細については、「データプレーンログ収集の有効化」をご参照ください。
ステップ 2: トークン消費メトリクスの追加
アクセスログは詳細な情報を提供しますが、監視メトリクスはより俯瞰的なビューを提供します。ASM メッシュプロキシは、ワークロードレベルでトークン消費を監視メトリクスとしてエクスポートするため、ワークロードのトークン使用量をリアルタイムで観測できます。
ASM は次の 2 つの新しいメトリクスを追加します。
-
asm_llm_proxy_prompt_tokens: 入力トークン数。
-
asm_llm_proxy_completion_tokens: 出力トークン数。
デフォルトでは、これらの 2 つのメトリクスには次のディメンションがあります。
-
llmproxy_source_workload: リクエストを送信するワークロードの名前。
-
llmproxy_source_workload_namespace: リクエストソースが配置されている名前空間。
-
llmproxy_destination_service: 宛先プロバイダー。
-
llmproxy_model: 現在のリクエストのモデル。
ワークロード構成を変更して新しいメトリクスを出力する
このステップでは、default 名前空間の sleep Deployment を例として使用します。
-
ACK クラスターの kubeconfig ファイルを使用して、
asm-llm-proxy-bootstrap-config.yamlという名前のファイルを作成します。apiVersion: v1 kind: ConfigMap metadata: name: asm-llm-proxy-bootstrap-config data: custom_bootstrap.json: | "stats_config": { "stats_tags":[ { "tag_name": "llmproxy_source_workload", "regex": "(\\|llmproxy_source_workload=([^|]*))" }, { "tag_name": "llmproxy_source_workload_namespace", "regex": "(\\|llmproxy_source_workload_namespace=([^|]*))" }, { "tag_name": "llmproxy_destination_service", "regex": "(\\|llmproxy_destination_service=([^|]*))" }, { "tag_name": "llmproxy_model", "regex": "(\\|llmproxy_model=([^|]*))" } ] } -
次のコマンドを実行して、
asm-llm-proxy-bootstrap-configという名前の ConfigMap を作成します。kubectl apply -f asm-llm-proxy-bootstrap-config.yaml -
次のコマンドを実行して、
sleepDeployment を変更し、Pod にアノテーションを追加します。kubectl patch deployment sleep -p '{"spec":{"template":{"metadata":{"annotations":{"sidecar.istio.io/bootstrapOverride":"asm-llm-proxy-bootstrap-config"}}}}}'
検証
-
次の 2 つのコマンドを個別に実行してテストリクエストを送信します。
kubectl exec deployment/sleep -it -- curl --location 'http://dashscope.aliyuncs.com' \ --header 'Content-Type: application/json' \ --data '{ "messages": [ {"role": "user", "content": "Please introduce yourself"} ] }'kubectl exec deployment/sleep -it -- curl --location 'http://dashscope.aliyuncs.com' \ --header 'Content-Type: application/json' \ --header 'user-type: subscriber' \ --data '{ "messages": [ {"role": "user", "content": "Please introduce yourself"} ] }' -
次のコマンドを実行して、
sleepアプリケーションのサイドカーがエクスポートした Prometheus メトリクスを表示します。kubectl exec deployments/sleep -it -c istio-proxy -- curl localhost:15090/stats/prometheus | grep llmproxy想定される出力:
asm_llm_proxy_completion_tokens{llmproxy_source_workload="sleep",llmproxy_source_workload_namespace="default",llmproxy_destination_service="dashscope.aliyuncs.com",llmproxy_model="qwen1.5-72b-chat"} 55 asm_llm_proxy_completion_tokens{llmproxy_source_workload="sleep",llmproxy_source_workload_namespace="default",llmproxy_destination_service="dashscope.aliyuncs.com",llmproxy_model="qwen-turbo"} 90 asm_llm_proxy_prompt_tokens{llmproxy_source_workload="sleep",llmproxy_source_workload_namespace="default",llmproxy_destination_service="dashscope.aliyuncs.com",llmproxy_model="qwen1.5-72b-chat"} 3 asm_llm_proxy_prompt_tokens{llmproxy_source_workload="sleep",llmproxy_source_workload_namespace="default",llmproxy_destination_service="dashscope.aliyuncs.com",llmproxy_model="qwen-turbo"} 11この出力から、サイドカーがメトリクスをエクスポートしており、それぞれに 4 つのデフォルトディメンションが含まれていることがわかります。
ASM は ARMS と統合されています。より詳細な分析と視覚化を行うには、収集ルールを設定してこれらのメトリクスを Managed Service for Prometheus に送信します。詳細については、「Managed Service for Prometheus への監視メトリクスの収集」をご参照ください。
ステップ 3: ネイティブメトリクスへの LLM ディメンションの追加
サービスメッシュは、HTTP および TCP プロトコルの詳細情報を表示する多くのデフォルトのメトリクスを提供します。これらのメトリクスは豊富なディメンションを提供し、ASM はこれらに基づいて強力な組み込み Prometheus ダッシュボードを提供します。
ただし、これらのメトリクスには LLM リクエストに関する情報が含まれていません。この問題に対処するため、ASM では、ディメンションをカスタマイズすることで、既存のメトリクスに LLM リクエスト情報を追加できます。
カスタムディメンションの設定: model
このセクションでは、REQUEST_COUNT メトリクスに model ディメンションを追加する方法を示します。
ASM コンソール にログインします。左側のナビゲーションウィンドウで、 を選択します。
[メッシュ管理] ページで、ASM インスタンスの名前をクリックします。左側のナビゲーションウィンドウで、 を選択します。
-
[Edit dimension] の Edit dimension をクリックし、Custom Dimension タブを選択して、Custom Dimensions をクリックします。[Dimension Name] を
modelに、[Value] をfilter_state["wasm.asm.llmproxy.request_model"]に設定します。
検証
-
次の 2 つのコマンドを個別に実行してテストリクエストを送信します。
kubectl exec deployment/sleep -it -- curl --location 'http://dashscope.aliyuncs.com' \ --header 'Content-Type: application/json' \ --data '{ "messages": [ {"role": "user", "content": "Please introduce yourself"} ] }'kubectl exec deployment/sleep -it -- curl --location 'http://dashscope.aliyuncs.com' \ --header 'Content-Type: application/json' \ --header 'user-type: subscriber' \ --data '{ "messages": [ {"role": "user", "content": "Please introduce yourself"} ] }' -
次のコマンドを実行して、
sleepアプリケーションのサイドカーがエクスポートした Prometheus メトリクスを表示します。kubectl exec deployments/sleep -it -c istio-proxy -- curl localhost:15090/stats/prometheus | grep istio_requests_total想定される出力:
istio_requests_total{reporter="source",source_workload="sleep",source_canonical_service="sleep",source_canonical_revision="latest",source_workload_namespace="default",source_principal="unknown",source_app="sleep",source_version="",source_cluster="cce8d2c1d1e8d4abc8d5c180d160669cc",destination_workload="unknown",destination_workload_namespace="unknown",destination_principal="unknown",destination_app="unknown",destination_version="unknown",destination_service="dashscope.aliyuncs.com",destination_canonical_service="unknown",destination_canonical_revision="latest",destination_service_name="dashscope.aliyuncs.com",destination_service_namespace="unknown",destination_cluster="unknown",request_protocol="http",response_code="200",grpc_response_status="",response_flags="-",connection_security_policy="unknown",model="qwen1.5-72b-chat"} 1 istio_requests_total{reporter="source",source_workload="sleep",source_canonical_service="sleep",source_canonical_revision="latest",source_workload_namespace="default",source_principal="unknown",source_app="sleep",source_version="",source_cluster="cce8d2c1d1e8d4abc8d5c180d160669cc",destination_workload="unknown",destination_workload_namespace="unknown",destination_principal="unknown",destination_app="unknown",destination_version="unknown",destination_service="dashscope.aliyuncs.com",destination_canonical_service="unknown",destination_canonical_revision="latest",destination_service_name="dashscope.aliyuncs.com",destination_service_namespace="unknown",destination_cluster="unknown",request_protocol="http",response_code="200",grpc_response_status="",response_flags="-",connection_security_policy="unknown",model="qwen-turbo"} 1この出力から、
istio_requests_totalメトリクスにmodelディメンションが追加されたことがわかります。これらの監視メトリクスを使用して、ARMS で分析ルールを設定し、より深い洞察を得ることができます。次に例を示します。
-
特定のモデルのリクエスト成功率。
-
特定のモデルまたはプロバイダーの平均レスポンスレイテンシー。
-
まとめ
このトピックは、「トラフィックルーティング: ASM を使用して LLM トラフィックを効率的に管理する」に基づいており、ASM を使用して LLM トラフィックの詳細な観測と俯瞰的な観測の両方を実行する方法について説明しています。クラスター構成をわずかに変更するだけで、多次元の可観測性機能を有効にできます。ASM は、より詳細で柔軟なソリューションを提供するために、LLM トラフィックにおける可観測性機能を継続的に改善しています。