Dataway Sink¶
Version-1.14.0 バージョンの Datakit で、ここで説明する Sinker 機能を使用できます。
Dataway Sinker 機能¶
日常のデータ収集において、複数の異なるワークスペースが存在するため、データをそれぞれ異なるワークスペースに送信する必要が生じることがあります。たとえば、共有の Kubernetes クラスターでは、収集されるデータが異なるチームや事業部門にまたがる可能性があります。このような場合、特定の属性を持つデータをそれぞれ異なるワークスペースに送信することで、インフラストラクチャ共有環境における細粒度の収集を実現できます。
Sink リクエストの処理フローは次のとおりです。
sequenceDiagram
autonumber
participant dk as DataKit
box Dataway server
participant etcd
participant dw as DataWay
participant rmatch as Rule matching
participant drop as Drop
end
box Workspaces
participant wksp1 as Workspace
participant wkspx as Default workspace
end
etcd ->> dw: pull sinker rules
activate dw
dk ->> dw: upload
deactivate dw
alt non-sink request
dw ->> wksp1: write
else sink request
dw ->> rmatch: matching
end
alt match ok(at lease 1 workspace)
rmatch ->> wksp1: write
else match failed but enabled default workspace
rmatch ->> wkspx: write
else no default workspace
rmatch ->> drop: drop
endDataway 1.8.0 は Sinker リクエストと非 Sinker リクエストの両方を受信できるため、Dataway を1つだけデプロイすれば十分です。
Dataway カスケードモード¶
SaaS ユーザーの場合、ローカル（k8s Cluster）に Dataway をデプロイし、専用のトラフィック分散装置として使用した後、データを Openway に転送できます。
Warning
カスケードモードでは、クラスター内の Dataway でカスケード（cascaded）オプションを有効にする必要があります。インストールドキュメントの環境変数の説明を参照してください。
sequenceDiagram
autonumber
participant dk as DataKit
box local Dataway server
participant etcd
participant dw1 as DataWay
end
box SAAS Dataway server
participant dw2 as DataWay
end
box Workspaces
participant wksp1 as Workspace
end
etcd ->> dw1: pull sinker rules
dk ->> dw1: upload data
dw1 ->> dw1: sink rule matching
dw1 ->> dw2: deliver request
dw2 ->> wksp1: writeカスケードによる影響：
- 一部の API の動作が異なる場合があります。歴史的な理由により、Datakit から送信されるリクエストと Kodo 上のリクエスト URL には差異があり、Dataway は API 変換機能を担っています。カスケードの場合、API 変換機能は無効になります。
- カスケードされた Dataway は、センターにハートビートリクエストを送信しません。これは、次の階層の Dataway がこのリクエストを処理しないためです（そのため 404 になります）。
- カスケードされた Dataway が受信したリクエストは、次の Dataway に送信される際に、API の署名は行われません。
Dataway インストール¶
こちらを参照してください。
Dataway 設定¶
Dataway の通常の設定に加えて、いくつかの追加設定が必要です（/usr/local/cloudcare/dataflux/dataway/dataway.yaml に設定します）。
# Dataway のアップロード先アドレスを設定します。通常は Kodo ですが、別の Dataway でも構いません。
remote_host: https://kodo.guance.com
# アップロード先が Dataway の場合は、ここを true に設定して Dataway カスケードを示します。
cascaded: false
# このトークンは Dataway 上で任意に設定するトークンです。これを Datakit の
# datakit.conf 設定に記入する必要があります。適切な長さと形式を維持する必要があります。
secret_token: tkn_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
# sinker ルール設定
sinker:
etcd: # etcd をサポート
urls:
- http://localhost:2379
dial_timeout: 30s
key_space: /dw_sinker
username: "dataway"
password: "<PASSWORD>"
#file: # ローカルファイル方式もサポート。デバッグによく使われます。
# path: /path/to/sinker.json
Warning
secret_token を設定しない場合、Datakit から送信されるすべてのリクエストが通過可能になり、データの問題は発生しません。ただし、Dataway がパブリックネットワークにデプロイされている場合は、secret_token を設定することをお勧めします。
Sinker ルール設定¶
Dataway Sinker ルールは JSON 形式の設定の集まりです。マッチングルールの記述方法はブラックリストと同じです。こちらを参照してください。
現在、2 種類の設定ソースをサポートしています。
- ローカルで JSON ファイルを指定する方法。主に Sinker ルールのデバッグに使用します。この場合、JSON ファイル内の Sinker ルールを更新した後、Dataway を再起動する必要があります。
- etcd：デバッグ済みのルールファイルを etcd に保存します。後でルールを微調整する場合、etcd を直接更新するだけでよく、Dataway を再起動する必要はありません。
実際には、etcd に保存される JSON とローカルファイルの JSON は同じ内容です。以下では、etcd による管理方法のみを説明します。
etcd 設定¶
以下のコマンドはすべて Linux で実行します。
Dataway は etcd クライアントとして、etcd に以下のユーザー名とロールを設定できます（etcd 3.5+）。こちらを参照してください。
dataway アカウントと対応するロールを作成します。
# ユーザー名を追加します。ここでパスワードの入力を求められます。
$ etcdctl user add dataway
# sinker ロールを追加します。
$ etcdctl role add sinker
# dataway をロールに追加します。
$ etcdctl user grant-role dataway sinker
# ロールのキー権限を制限します（ここでは /dw_sinker と /ping がデフォルトで使用される 2 つのキーです）。
$ etcdctl role grant-permission sinker readwrite /dw_sinker
$ etcdctl role grant-permission sinker readwrite /ping # 接続確認に使用されます。
なぜロールを作成するのですか？
ロールは、対応するユーザーの特定のキーに対する権限を制御するために使用されます。ここでは、ユーザーが既存の etcd サービスを使用している可能性があるため、Dataway ユーザーのデータ権限を制限する必要があります。
Warning
etcd で認証モードが有効になっている場合、etcdctl コマンドを実行する際には、対応するユーザー名とパスワードを指定する必要があります。
Sinker ルールの書き込み¶
新しいバージョン（1.3.6）の Dataway は、
datawayコマンドを使用して etcd 内の Sinker ルールを操作することをサポートしています。
sinker.json ルール定義が次のようになっていると仮定します。
{
"strict":true,
"rules": [
{
"rules": [
"{ host = 'my-host'}"
],
"url": "https://kodo.guance.com?token=tkn_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
},
{
"rules": [
"{ host = 'my-host' OR cluster = 'cluster-A' }"
],
"url": "https://kodo.guance.com?token=tkn_yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy"
}
]
}
次のコマンドで Sinker ルール設定を書き込めます。
ワークスペース情報の識別
sinker.json ではコメントがサポートされていないため、JSON に info フィールドを追加してメモとして使用し、コメントの効果を達成できます。
デフォルトルール¶
特定のルールエントリに as_default 識別子を追加すると、そのルールをデフォルトのフォールバックルールとして設定できます。フォールバックルールは、マッチング条件を設定しなくても構いません（rules フィールドを設定しない）。同時に、通常のルールマッチングには参加すべきではありません。推奨されるフォールバックルールは次のとおりです。
{
"as_default": true,
"info": "これはデフォルトのフォールバックワークスペースです",
"url": "https://kodo.guance.com?token=tkn_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
注意：フォールバックルールは1つだけ設定する必要があります。sinker 設定に複数のフォールバックルールが存在する場合、最後のものが優先されます。
トークンルール¶
Datakit は Dataway 上のトークンをチェックするため、ここで設定するトークン（secret_token を含む）は次の条件を満たす必要があります。
token_またはtkn_で始まり、その後の文字列長は 32 である必要があります。
この条件を満たさないトークンでは、Datakit のインストールは失敗します。
Datakit 側の設定¶
Datakit では、収集したデータに特定のタグを付けてグループ化できるように、いくつかの設定を行う必要があります。
- グローバルカスタムキーリストの設定
Datakit は、収集したデータからこれらのキーを持つフィールド（文字列型のフィールドのみを検索）を検索し、それらを抽出してグループ送信の基準とします。
- 「グローバルホストタグ」と「グローバル選挙タグ」の設定
すべての Datakit がアップロードするデータには、これらの設定されたグローバルタグ（タグキーとタグ値を含む）が付加され、グループ送信の基準となります。
Datakit 側のカスタマーキー設定¶
特定の Datakit が収集したデータをトラフィック分散の要件に適合させたい場合は、いくつかの点を確認する必要があります。
- Datakit で Sinker 機能が有効になっていること。
- Datakit に有効なグローバルカスタマーキーが設定されていること。
これら 2 つの設定は次のとおりです。
# /usr/local/datakit/conf.d/datakit.conf
[dataway]
# カスタマーキーのグループを指定します。
global_customer_keys = [
# 例：category と class の 2 つのキーを追加します。
# ここではあまり多くのキーを設定しないでください。通常は 2～3 個で十分です。
"category",
"class",
]
# sinker 機能を有効にします。
enable_sinker = true
Synthetic テストデータ、通常のデータカテゴリに加えて、Session Replay や Profiling などのバイナリファイルデータもサポートしています。そのため、ここではすべてのフィールド名を選択できます。ただし、文字列型以外のフィールドを設定しないでください。通常のキーは通常、タグ（すべてのタグ値は文字列型）から取得されます。Datakit は、文字列型以外のフィールドをトラフィック分散の基準として使用しません。
グローバルタグの影響¶
global_customer_keys に加えて、Datakit に設定されたグローバルタグ（グローバル選挙タグとグローバルホストタグを含む）もトラフィック分散のマーキングに影響を与えます。つまり、データポイントにグローバルタグに含まれるフィールド（これらのフィールドの値の型は文字列型である必要があります）が含まれている場合、それもトラフィック分散の対象となります。グローバル選挙タグが次のようになっていると仮定します。
次のデータポイントの場合：
グローバル選挙タグに cluster（タグの設定値に関係なく）が含まれているため、このポイント自体にも cluster タグがあり、最終的な X-Global-Tags には、cluster=cluster_A というキーと値のペアが追加されます。
global_customer_keys に app キーも設定されている場合、最終的なトラフィック分散ヘッダーは次のようになります（2 つのキーと値のペアの出現順序は重要ではありません）。
Note
ここでの例では、datakit.conf で設定された cluster の値とデータポイント内の cluster フィールドの値を意図的に異なるものに設定し、主にタグキーの影響を強調しています。データポイントに条件を満たすグローバルタグキーが含まれている場合、その効果は、このグローバルタグキーが global_customer_keys に追加されたのと同じであると理解できます。
Dataway sink コマンド¶
Dataway はバージョン Version-1.3.6 以降、コマンドラインで sinker の設定を管理することをサポートしています。具体的な使用方法は次のとおりです。
$ ./dataway sink --help
Usage of sink:
-add string
single rule json file
-cfg-file string
configure file (default "/usr/local/cloudcare/dataflux/dataway/dataway.yaml")
-file string
file path of the rule json, only used for command put and get
-get
get the rule json
-list
list rules
-log string
log file path (default "/dev/null")
-put
save the rule json
-token string
rules filtered by token, eg: xx,yy
設定ファイルの指定
コマンド実行時、デフォルトで読み込まれる設定ファイルは /usr/local/cloudcare/dataflux/dataway/dataway.yaml です。別の設定ファイルを読み込む場合は、--cfg-file で指定します。
コマンドログの設定
デフォルトでは、コマンドの出力ログは無効になっています。確認する必要がある場合は、--log パラメータを設定します。
# output log to stdout
$ ./dataway sink --list --log stdout
# output log to file
$ ./dataway sink --list --log /tmp/log
ルール一覧の表示
# list all rules
$ ./dataway sink --list
# list all rules filtered by token
$ ./dataway sink --list --token=token1,token2
CreateRevision: 2
ModRevision: 41
Version: 40
Rules:
[
{
"rules": [
"{ workspace = 'zhengb-test'}"
],
"url": "https://openway.guance.com?token=token1"
}
]
ルールの追加
ルールファイル rule.json を作成します。内容は次の例を参考にしてください。
[
{
"rules": [
"{ host = 'HOST1'}"
],
"url": "https://openway.guance.com?token=tkn_xxxxxxxxxxxxx"
},
{
"rules": [
"{ host = 'HOST2'}"
],
"url": "https://openway.guance.com?token=tkn_yyyyyyyyyyyyy"
}
]
ルールを追加します。
設定のエクスポート
設定をエクスポートして、sinker 設定をローカルファイルに保存できます。
設定の書き込み
ローカルルールファイルを sinker に同期します。
ルールファイル sink-put.json を作成します。内容は次の例を参考にしてください。
{
"rules": [
{
"rules": [
"{ workspace = 'test'}"
],
"url": "https://openway.guance.com?token=tkn_xxxxxxxxxxxxxx"
}
],
"strict": true
}
設定を書き込みます。
設定例¶
Kubernetes での dataway.yaml の例（クリックして展開）
yaml 内で sinker JSON を直接指定します。
---
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: deployment-utils-dataway
name: dataway
namespace: utils
spec:
replicas: 1
selector:
matchLabels:
app: deployment-utils-dataway
template:
metadata:
labels:
app: deployment-utils-dataway
annotations:
datakit/logs: |
[{"disable": true}]
datakit/prom.instances: |
[[inputs.prom]]
url = "http://$IP:9090/metrics" # ここでのポート番号（デフォルト 9090）は状況に応じて変更してください
source = "dataway"
measurement_name = "dw" # このメジャーメントに固定
interval = "10s"
[inputs.prom.tags]
namespace = "$NAMESPACE"
pod_name = "$PODNAME"
node_name = "$NODENAME"
spec:
affinity:
podAffinity: {}
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- deployment-utils-dataway
topologyKey: kubernetes.io/hostname
containers:
- image: registry.jiagouyun.com/dataway/dataway:1.3.6 # 適切なバージョン番号を指定してください
#imagePullPolicy: IfNotPresent
imagePullPolicy: Always
name: dataway
env:
- name: DW_REMOTE_HOST
value: "http://kodo.forethought-kodo:9527" # 実際の Kodo アドレス、または次の Dataway アドレスを指定してください
- name: DW_BIND
value: "0.0.0.0:9528"
- name: DW_UUID
value: "agnt_xxxxx" # 実際の Dataway UUID を指定してください
- name: DW_TOKEN
value: "tkn_oooooooooooooooooooooooooooooooo" # 実際の Dataway トークン（通常はシステムワークスペースのトークン）を指定してください
- name: DW_PROM_LISTEN
value: "0.0.0.0:9090"
- name: DW_SECRET_TOKEN
value: "tkn_zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz"
- name: DW_SINKER_FILE_PATH
value: "/usr/local/cloudcare/dataflux/dataway/sinker.json"
ports:
- containerPort: 9528
name: 9528tcp01
protocol: TCP
volumeMounts:
- mountPath: /usr/local/cloudcare/dataflux/dataway/cache
name: dataway-cache
- mountPath: /usr/local/cloudcare/dataflux/dataway/sinker.json
name: sinker
subPath: sinker.json
resources:
limits:
cpu: '4'
memory: 4Gi
requests:
cpu: 100m
memory: 512Mi
# nodeSelector:
# key: string
imagePullSecrets:
- name: registry-key
restartPolicy: Always
volumes:
- hostPath:
path: /root/dataway_cache
name: dataway-cache
- configMap:
name: sinker
name: sinker
---
apiVersion: v1
kind: Service
metadata:
name: dataway
namespace: utils
spec:
ports:
- name: 9528tcp02
port: 9528
protocol: TCP
targetPort: 9528
nodePort: 30928
selector:
app: deployment-utils-dataway
type: NodePort
---
apiVersion: v1
kind: ConfigMap
metadata:
name: sinker
namespace: utils
data:
sinker.json: |
{
"strict":true,
"rules": [
{
"rules": [
"{ project = 'xxxxx'}"
],
"url": "http://kodo.forethought-kodo:9527?token=tkn_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
},
{
"rules": [
"{ project = 'xxxxx'}"
],
"url": "http://kodo.forethought-kodo:9527?token=tkn_yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy"
}
]
}
Ingress 設定例（クリックして展開）
FAQ¶
破棄されたリクエストの詳細を確認する¶
リクエストが Sinker ルールに一致しない場合、Dataway はそのリクエストを破棄し、メトリクスに破棄カウントを追加します。ただし、デバッグ段階では、破棄されたリクエストの詳細、特にリクエストヘッダーに含まれる X-Global-Tags 情報を確認する必要があります。
次のコマンドで Dataway のログを検索できます。
出力結果には、次のような出力が表示されます。
Datakit リクエストが破棄された場合の調査¶
Datakit リクエストが Dataway によって破棄されると、Dataway は対応する HTTP エラーを返します。Datakit のログには、次のようなエラーが表示されます。
post 3641 to http://dataway-ip:9528/v1/write/metric failed(HTTP: 406 Not Acceptable):
{"error_code":"dataway.sinkRulesNotMatched","message":"X-Global-Tags: `host=my-host',
URL: `/v1/write/metric'"}, data dropped
このエラーは、リクエスト /v1/write/metric の X-Global-Tags が Dataway のすべてのルールを満たしていないために破棄されたことを示しています。
同時に、Datakit monitor（datakit monitor -V）の右下にある DataWay APIs パネルで、Status 列に Not Acceptable が表示されます。これは、対応する Dataway API リクエストが破棄されたことを示しています。
Datakit 自身のメトリクスを確認しても、対応するメトリクスを確認できます。
$ curl -s http://localhost:9529/metrics | grep datakit_io_dataway_api_latency_seconds_count
datakit_io_dataway_api_latency_seconds_count{api="/v1/datakit/pull",status="Not Acceptable"} 50
datakit_io_dataway_api_latency_seconds_count{api="/v1/write/metric",status="Not Acceptable"} 301
Datakit が 403 エラーを報告する¶
Dataway の sinker 設定に誤りがあり、すべての Datakit リクエストが secret_token を使用する場合、このトークンはセンター（Kodo）で認識されないため、403 エラー kodo.tokenNotFound が報告されます。
この問題の原因として、etcd のユーザー名またはパスワードが誤っている可能性があります。これにより、Dataway が Sinker 設定を取得できず、Dataway は現在の sinker が無効であると判断し、すべてのデータがセンターに直接送信されます。
etcd 権限設定の問題¶
Dataway のログに次のようなエラーが表示される場合、権限設定に問題がある可能性があります。
権限設定が適切でない場合は、既存の Dataway ベースの権限をすべて削除してから再設定できます。詳細はこちらを参照してください。
Datakit 側のキーの優先順位¶
「グローバルカスタムキーリスト」を設定する際に、「グローバルホストタグ」と「グローバル選挙タグ」にも同じ名前のキーが含まれている場合、収集されたデータ内の対応するキーと値のペアが使用されます。
たとえば、設定された「グローバルカスタムキーリスト」に key1,key2,key3 があり、「グローバルホストタグ」または「グローバル選挙タグ」にもこれらのキーと対応する値（例：key1=value-1）が設定されている場合、特定のデータ収集で key1=value-from-data というフィールドも含まれている場合、最終的なグループ化の基準は、データ内の key1=value-from-data が使用され、「グローバルホストタグ」と「グローバル選挙タグ」で設定された対応するキーの値は無視されます。
「グローバルホストタグ」と「グローバル選挙タグ」の間に同じ名前のキーがある場合、優先順位は「グローバル選挙タグ」のキーが優先されます。つまり、キーの値の取得元の優先順位は次のとおりです（降順）。
- 収集されたデータ
- グローバル選挙タグ
- グローバルホストタグ
組み込みの「グローバルカスタムキー」¶
Datakit には、以下の使用可能な組み込みカスタムキーがあります。これらは通常、収集データには含まれませんが、Datakit はこれらのキーを使用してデータをグループ化できます。これらのキーの次元でトラフィック分散のニーズがある場合は、それらを「グローバルカスタムキーリスト」に追加できます（これらのキーはデフォルトでは設定されていません）。以下の組み込みカスタムキーを使用してデータのトラフィック分散を実現できます。
Warning
追加する「グローバルカスタムキー」は、データ送信時にパケット分割を引き起こします。粒度が細かすぎると、Datakit のアップロード効率が大幅に低下します。通常、「グローバルカスタムキー」は 3 つを超えないことをお勧めします。
classオブジェクトデータを対象とします。有効にすると、オブジェクトの分類に基づいてトラフィックを分散します。たとえば、Pod のオブジェクト分類がkubelet_podの場合、Pod に対してトラフィック分散ルールを定義できます。
{
"strict": true,
"rules": [
{
"rules": [
"{ class = 'kubelet_pod' AND other_conditon = 'some-value' }",
],
"url": "https://kodo.guance.com?token=<YOUR-TOKEN>"
},
{
... # other rules
}
]
}
measurementメトリクスデータを対象とします。特定のメジャーメントを特定のワークスペースに送信できます。たとえば、ディスクのメジャーメント名がdiskの場合、次のようにルールを記述できます。
{
"strict": true,
"rules": [
{
"rules": [
"{ measurement = 'disk' AND other_conditon = 'some-value' }",
],
"url": "https://kodo.guance.com?token=<YOUR-TOKEN>"
},
{
... # other rules
}
]
}
sourceログ（L）、eBPF ネットワークメトリクス（N）、イベント（E）、および RUM データを対象とします。service分散型トレーシング、Scheck、およびプロファイリングを対象とします。categoryすべての通常のデータカテゴリを対象とします。その値は、対応するデータカテゴリの「名前」列（時系列の場合はmetric、オブジェクトの場合はobjectなど）です。ログを例にとると、次のようにログのみを対象としたトラフィック分散ルールを定義できます。
{
"strict": true,
"rules": [
{
"rules": [
"{ category = 'logging' AND other_conditon = 'some-value' }",
],
"url": "https://kodo.guance.com?token=<YOUR-TOKEN>"
},
{
... # other rules
}
]
}
特殊なトラフィック分散動作¶
Version-2.0.0 以降、Datakit はポイント書き込み要求（/v1/write/*）にのみ Dataway Sinker ヘッダーを追加します。センターからリソースをプルしたり、ID を識別したり、設定を同期したりするその他の Dataway API には、X-Global-Tags/X-Global-Tags-V2 が付与されなくなります。したがって、これらの API に特殊なトラフィック分散ルールを追加する必要はありません。
Datakit 2.0.0 より前のバージョンでは、Datakit から送信される一部のリクエストは、センターからリソースをプルしたり、自身の ID を識別したりすることを目的としており、その動作自体がすでにアトミックであり、分割できません。また、これらのリクエストを複数のワークスペースに分散することはできません（Datakit はこれらの API リクエストの戻り値を処理し、その後の動作を決定する必要があるため）。したがって、これらの API は、最大でも 1 つのワークスペースにのみトラフィック分散できます。
トラフィック分散ルールで複数の条件が満たされている場合、これらの API は最初に条件を満たすルールによって示されるワークスペースにのみトラフィック分散されます。
以下は、Datakit 2.0.0 より前のバージョンで使用可能な互換性ルールの例です。
これらの API を特定のワークスペースに固定する必要がある場合にのみ、古いバージョンの Datakit にこのルールを追加する必要があります。Datakit 2.0.0 以降では追加する必要はありません。
{
"strict": true,
"info": "特殊ワークスペース（データプルなどの API のみに使用）",
"rules": [
{
"rules": [
"{ __dataway_api in ['/v1/datakit/pull', '/v1/election', '/v1/election/heartbeat', '/v1/query/raw', '/v1/workspace', '/v1/object/labels', '/v1/check/token'] }"
],
"url": "https://kodo.guance.com?token=<SOME-SPECIAL-WORKSPACE-TOKEN>"
}
]
}
Info
これらの API URL の説明は次のとおりです。
/v1/election：選挙リクエスト/v1/election/heartbeat：選挙ハートビートリクエスト/v1/datakit/pull：センターの Pipeline とブラックリストの設定をプル/v1/query/raw：DQL クエリ/v1/workspace：ワークスペース情報の取得/v1/object/labels：オブジェクトデータの更新/削除/v1/check/token：ワークスペーストークン情報の確認
Datakit 2.0.0 より前では、__dataway_api キーを datakit.conf の global_customer_keys に設定する必要はありません。Dataway はデフォルトでこれをトラフィック分散のキーとして使用し、現在のリクエストの API ルートをその値として使用します。つまり、特定の API の場合：
その最終的なトラフィック分散への参加効果は、以下の場合と同じです。
したがって、古いバージョンの互換性シナリオでは、Sink ルールで __dataway_api の KV ペアを直接使用してマッチングできます。これは、この特殊なルールには、/v1/write/... などの他の重要なデータアップロード API を含めないでくださいという注意事項も示しています。含めた場合、データが最終的にどのスペースに送信されるかは未定義です。Datakit 2.0.0 以降では、これらの非ポイント書き込み API は Sinker ヘッダーを運ばないため、__dataway_api ルールに依存したトラフィック分散は不要です。