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
end

Dataway 1.8.0부터 Sinker/비 Sinker 두 가지 유형의 요청을 모두 수신할 수 있습니다. Dataway 하나만 배포하면 됩니다.

Dataway 계단식 모드¶

SaaS 사용자의 경우, 자체 환경(k8s Cluster)에 Dataway를 하나 배포하여 트래픽 분산 전용으로 사용한 다음 데이터를 Openway로 전달할 수 있습니다.

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

# 이 token은 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

Sinker 규칙 설정¶

Dataway Sinker 규칙은 JSON 형식의 구성 집합이며, 매칭 규칙의 작성 방식은 블랙리스트 작성 방식과 동일합니다. 여기를 참조하십시오.

현재 두 가지 구성 소스를 지원합니다.

• 로컬 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

# 역할의 key 권한 제한(여기서 /dw_sinker 및 /ping은 기본적으로 사용되는 두 key입니다.)
$ etcdctl role grant-permission sinker readwrite /dw_sinker
$ etcdctl role grant-permission sinker readwrite /ping       # 연결 상태 확인용

$ etcdctl --user name:password ...

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 규칙을 쓸 수 있습니다.

$ etcdctl --user dataway:PASSWORD put /dw_sinker "$(<sinker.json)"
OK

{
    "rules": [
        "{ host = 'my-host' OR cluster = 'cluster-A' }"
    ],
    "info": "이것은 yyy 워크스페이스입니다.",
    "url": "https://kodo.guance.com?token=tkn_yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy"
}

기본 규칙¶

Version-1.6.0

특정 규칙 항목에 as_default 식별자를 추가하면 해당 규칙을 기본 폴백 규칙으로 설정할 수 있습니다. 폴백 규칙은 매칭 조건을 설정하지 않아도 됩니다(rules 필드 미설치). 또한 일반 규칙 매칭에 참여하지 않아야 합니다. 권장되는 폴백 규칙은 다음과 같습니다.

{
    "as_default": true,
    "info": "이것은 기본 폴백 워크스페이스입니다.",
    "url": "https://kodo.guance.com?token=tkn_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}

참고: 폴백 규칙은 하나만 설정해야 합니다. sinker 설정에 여러 폴백 규칙이 있으면 마지막 규칙이 적용됩니다.

Token 규칙¶

Datakit은 Dataway의 token을 검사하므로, 여기서 설정하는 token(secret_token 포함)은 다음 조건을 충족해야 합니다.

token_ 또는 tkn_으로 시작하며, 이후 문자 길이는 32자입니다.

이 조건을 충족하지 않는 token의 경우 Datakit 설치가 실패합니다.

Datakit 설정¶

Datakit에서 몇 가지 설정을 수행하여 수집된 데이터에 특정 태그를 추가하여 그룹화할 수 있도록 해야 합니다.

• 전역 사용자 정의 Key 목록 구성

Datakit은 수집한 데이터에서 이러한 Key를 가진 필드(문자열 유형 필드만 찾음)를 찾아 그룹 전송 기준으로 추출합니다.

• 「전역 호스트 Tag」 및 「전역 선출 Tag」 구성

모든 Datakit이 업로드하는 데이터에는 구성된 이러한 전역 태그(tag key 및 tag value 포함)가 포함되어 그룹 전송 기준으로 사용됩니다.

Datakit Customer Key 설정¶

특정 Datakit이 수집한 데이터가 트래픽 분산 요구 사항을 충족하도록 하려면 다음 사항을 확인해야 합니다.

• Datakit에서 Sinker 기능이 활성화되어 있어야 합니다.
• Datakit에 유효한 Global Customer Key가 구성되어 있어야 합니다.

이 두 가지 설정은 다음과 같습니다.

# /usr/local/datakit/conf.d/datakit.conf
[dataway]

  # customer key 그룹 지정
  global_customer_keys = [
    # 예시: category와 class 두 개의 key 추가
    # 너무 많은 key를 구성하지 않는 것이 좋으며, 일반적으로 2~3개면 충분합니다.
    "category",
    "class",
  ]

  # sinker 기능 활성화
  enable_sinker = true

신서틱 테스트 데이터, 일반 데이터 분류 외에도 Session Replay 및 Profiling과 같은 바이너리 파일 데이터를 지원하므로 모든 필드 이름을 선택할 수 있습니다. 주의할 점은 문자열 유형이 아닌 필드는 구성하지 않아야 합니다. 일반적인 Key는 대부분 Tag에서 비롯됩니다(모든 Tag 값은 문자열 유형). Datakit은 문자열 유형이 아닌 필드를 트래픽 분산 기준으로 사용하지 않습니다.

전역 Tag의 영향¶

global_customer_keys 외에도 Datakit에 구성된 전역 Tag(전역 선출 Tag 및 전역 호스트 Tag 포함)도 트래픽 분산 표시에 영향을 줍니다. 즉, 데이터 포인트에 전역 Tag에 나타나는 필드(이 필드 값 유형은 문자열이어야 함)가 있으면 트래픽 분산에 포함됩니다. 전역 선출 Tag가 다음과 같다고 가정합니다.

# datakit.conf
[election.tags]
    cluster = "my-cluster"

다음 데이터 포인트의 경우:

pi,cluster=cluster_A,app=math,other_tag=other_value value=3.14 1712796013000000000

전역 선출 Tag에 cluster가 포함되어 있으므로(해당 Tag의 구성 값에 관계없이) 이 포인트 자체에도 cluster Tag가 있습니다. 최종 X-Global-Tags에는 cluster=cluster_A 키-값 쌍이 추가됩니다.

X-Global-Tags: cluster=cluster_A

global_customer_keys에 app key도 구성된 경우 최종 트래픽 분산 Header는 다음과 같습니다(두 키-값 쌍의 순서는 중요하지 않음).

X-Global-Tags: cluster=cluster_A,app=math

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을 사용하여 지정할 수 있습니다.

$ ./dataway sink --cfg-file dataway.yaml [--list...]

명령어 로그 설정

기본적으로 명령어의 출력 로그는 비활성화되어 있습니다. 로그를 확인해야 하는 경우 --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"
  }
]

규칙 추가

$ ./dataway sink --add rule.json

add 2 rules ok!

설정 내보내기

Sinker 구성을 로컬 파일로 내보낼 수 있습니다.

$ ./dataway sink --get --file sink-get.json

rules json was saved to sink-get.json!

설정 쓰기

로컬 규칙 파일을 sinker에 동기화합니다.

규칙 파일 sink-put.json을 생성하고 내용은 다음과 같이 작성합니다.

{
    "rules": [
        {
            "rules": [
                "{ workspace = 'test'}"
            ],
            "url": "https://openway.guance.com?token=tkn_xxxxxxxxxxxxxx"
        }
    ],
    "strict": true
}

설정 쓰기

$ ./dataway sink --put --file sink-put.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 token을 입력하십시오. 일반적으로 시스템 워크스페이스의 token입니다.
        - 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"
            }
         ]
    }

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: dataway-sinker
  namespace: utils
spec:
  ingressClassName: nginx
  rules:
  - host: datawaysinker-xxxx.com
    http:
      paths:
      - backend:
          service:
            name: dataway
            port:
              number: 9528
        path: /
        pathType: ImplementationSpecific

FAQ¶

폐기된 요청 세부 정보 확인¶

Version-1.3.7

요청이 Sinker 규칙과 일치하지 않으면 Dataway는 해당 요청을 폐기하고 메트릭에 폐기 횟수를 증가시킵니다. 그러나 디버깅 단계에서는 폐기된 요청의 구체적인 내용, 특히 요청 Header에 포함된 X-Global-Tags 정보를 알아야 합니다.

다음 명령을 사용하여 Dataway 로그를 검색할 수 있습니다.

$ cat <path/to/dataway/log> | grep dropped

출력 결과에서 다음과 유사한 출력을 볼 수 있습니다.

for API /v1/write/logging with X-Global-Tags <some-X-Global-Tags...> dropped

Datakit 요청 폐기 문제 해결¶

Version-1.3.9

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을 사용하게 되면, 이 token은 중앙(Kodo)에서 인식되지 않으므로 403 오류 kodo.tokenNotFound가 보고됩니다.

이 문제의 원인은 etcd 사용자 이름 또는 비밀번호가 잘못되어 Dataway가 Sinker 구성을 가져올 수 없고, 결과적으로 Dataway가 현재 sinker를 유효하지 않은 것으로 간주하여 모든 데이터를 중앙에 직접 전송하기 때문일 수 있습니다.

etcd 권한 구성 문제¶

Dataway 로그에 다음과 같은 오류가 있으면 권한 설정에 문제가 있을 수 있습니다.

sinker ping: etcdserver: permission denied, retrying(97th)

권한이 올바르게 구성되지 않은 경우 기존 Dataway 기반 권한을 모두 삭제하고 다시 구성할 수 있습니다. 자세한 내용은 여기를 참조하십시오.

Datakit Key의 덮어쓰기 관계¶

「전역 사용자 정의 Key 목록」을 구성할 때 「전역 호스트 Tag」 및 「전역 선출 Tag」에도 동일한 이름의 Key가 있는 경우, 수집된 데이터의 해당 Key-Value 쌍이 사용됩니다.

예를 들어, 구성된 「전역 사용자 정의 Key 목록」에 key1,key2,key3가 있고, 「전역 호스트 Tag」 또는 「전역 선출 Tag」에도 이러한 Key와 해당 값(예: key1=value-1)이 구성되어 있으며, 특정 데이터 수집에서 key1=value-from-data 필드도 있는 경우, 최종 그룹화 기준은 데이터의 key1=value-from-data를 사용하고 「전역 호스트 Tag」 및 「전역 선출 Tag」에 구성된 해당 Key의 Value는 무시됩니다.

「전역 호스트 Tag」와 「전역 선출 Tag」 사이에 동일한 이름의 Key가 있는 경우 「전역 선출 Tag」의 Key가 우선합니다. 요약하면 Key 값의 출처 우선순위는 다음과 같습니다(내림차순).

• 수집된 데이터
• 전역 선출 Tag
• 전역 호스트 Tag

내장된 「전역 사용자 정의 Key」¶

Datakit에는 다음과 같은 내장 사용자 정의 Key가 있습니다. 일반적으로 수집된 데이터에는 나타나지 않지만, Datakit은 이러한 Key를 사용하여 데이터를 그룹화할 수 있습니다. 이러한 Key 차원에서 트래픽 분산이 필요한 경우 「전역 사용자 정의 Key」 목록에 추가할 수 있습니다(이러한 Key는 기본적으로 구성되지 않음). 다음과 같은 내장 사용자 정의 Key를 사용하여 데이터 트래픽 분산을 구현할 수 있습니다.

• 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 Tracing, Scheck 및 Profiling에 사용됩니다.
• 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은 point 쓰기 요청(/v1/write/*)에만 Dataway Sinker header를 추가합니다. 중앙에서 리소스를 가져오거나, 신원 확인 또는 구성 동기화를 수행하는 다른 Dataway API는 더 이상 X-Global-Tags/X-Global-Tags-V2를 전송하지 않으므로 이러한 API에 대한 특수 트래픽 분산 규칙을 추가할 필요가 없습니다.

Datakit 2.0.0 이전 버전의 경우, Datakit이 보내는 일부 요청은 중앙에서 리소스를 가져오거나 자체 신원을 식별하기 위한 목적입니다. 이러한 동작 자체는 이미 원자적이며 더 이상 분할할 수 없고, 이러한 요청을 여러 워크스페이스에 분산할 수도 없습니다(Datakit은 이러한 API 요청의 반환을 처리하고 후속 동작을 결정해야 하므로). 따라서 이러한 API는 최대 하나의 워크스페이스로만 트래픽을 분산할 수 있습니다.

트래픽 분산 규칙에서 여러 조건을 충족하더라도 이러한 API는 첫 번째로 일치하는 규칙이 가리키는 워크스페이스로만 트래픽을 분산합니다.

다음은 Datakit 2.0.0 이전 버전에서 사용할 수 있는 호환 규칙 예시입니다.

이 규칙은 이전 버전 Datakit이 이러한 API를 특정 워크스페이스에 고정해야 하는 경우에만 추가하면 됩니다. 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>"
        }
    ]
}

Datakit 2.0.0 이전에는 __dataway_api key를 datakit.conf의 global_customer_keys에 구성할 필요가 없습니다. Dataway는 기본적으로 이 Key를 트래픽 분산 기준으로 사용하고, 현재 요청의 API 경로를 value로 사용합니다. 즉, 특정 API의 경우:

POST /v1/some/api
X-Global-Tags: cluster=cluster_A,app=math

최종 트래픽 분산에 참여하는 효과는 다음과 같습니다.

POST /v1/some/api
X-Global-Tags: cluster=cluster_A,app=math,__dataway_api=/v1/write/metrics

따라서 이전 버전 호환 시나리오에서는 Sink 규칙에서 __dataway_api KV 쌍을 직접 사용하여 매칭할 수 있습니다. 또한 이 특수 규칙에는 다른 중요한 데이터 업로드 API를 포함하지 않아야 합니다. 예를 들어 /v1/write/...와 같은 인터페이스는 데이터가 최종적으로 어느 공간에 저장될지 정의되지 않습니다. Datakit 2.0.0 이상에서는 이러한 비 point 쓰기 API가 더 이상 Sinker header를 전송하지 않으므로 __dataway_api 규칙에 의존할 필요가 없습니다.