[observability] Vector

개요

• 사이트
• 관측 가능성 데이터를 제어할 수 있게 해주는 고성능 관측 가능성 데이터 파이프라인
• 관측 가능성 데이터(모든 로그, 지표 및 추적)를 수집, 변환 및 라우팅
  • sources -> transforms -> sinks
• 관측 가능성 파이프라인
  • 컨트롤 플레인에서 파이프라인 관리
    • 구축, 수정, 적용
  • 모니터링
    • 파이프라인 상태 파악
    • 병목 현상과 지연 시간을 식별
    • 성능 미세 조정
    • 데이터 전달 검증
    • 기여자 조사
  • 볼륨을 최적화하고 비용을 제어
  • 민감한 데이터를 스캔하고 수정
• 완전한 엔드투엔드 플랫폼
• 특징
  • 단일 바이너리
    • 종속성이 없고 런타임이 없으며 메모리가 안전
  • Rust로 구현하여 빠르고 안정적
  • 데몬, 사이드카 또는 애그리게이터로 배포 가능
  • 로그와 메트릭을 지원하므로 모든 관측 가능성 데이터를 쉽게 수집하고 처리 가능
  • 특정 벤더 플랫폼을 선호하지 않으며 고객의 이익을 최우선으로 생각하는 공정하고 개방적인 생태계를 조성
  • 변환(transforms)은 프로그래밍 가능한 런타임의 모든 기능을 제공
  • 어떤 보증을 제공하는지 명확하게 설명

개념

• Events
  • 개별 데이터 단위
  • 종류
    • Logs
      • 일반적인 키/값 표현
    • Metrics
      • 시계열에서 수행되는 수치 연산
      • 완벽하게 상호 운용 가능
    • Traces
      • 특별한 종류의 로그 이벤트
      • Note: Support for traces is limited and is in alpha.
• Components
  • Sources
    • 벡터가 데이터를 가져와야 하는 위치 또는 푸시된 데이터를 수신하는 방법을 정의
    • 토폴로지에는 소스가 여러 개 있을 수 있으며, 데이터를 수집하면서 이를 이벤트로 정규화
  • Transforms
    • 이벤트의 변형을 담당
    • 구문 분석, 필터링, 샘플링 또는 집계가 포함
  • Sinks
    • 이벤트의 목적지
    • 설계 및 전송 방법은 상호 작용하는 다운스트림 서비스에 따라 결정
      • 소켓 싱크는 개별 이벤트를 스트리밍
      • aws_s3 싱크는 데이터를 버퍼링하고 플러시
• Pipeline
  • components의 방향성 비순환 그래프
  • 각 component는 방향이 있는 간선을 갖는 그래프의 노드
  • 데이터는 sources에서 sinks로 한 방향으로 흐름
• Buffers
  • Sinks는 가능한 빨리 이벤트를 전송하려고 시도
  • 전송할 수 없을 경우 전송될 수 있을 때까지 이벤트를 보관
  • 기본적으로는 인메모리 버퍼 사용
  • buffer.when_full = block일 경우 버퍼가 가득 차면 Backpressure 적용
• Backpressure
  • 모든 transforms에 전파되고 sources도 전파
  • sources는 데이터를 제공하는 시스템에 Backpressure를 전파하려고 시도
    • HTTP는 429 응답 발생
    • Kafka는 fetch 속도를 조정
• Roles
  • Agent(Daemon, Sidecar)
    • Vector를 엣지에 배포하도록 설계
  • Aggregator
    • 여러 업스트림 소스에서 데이터를 수집하고 처리하도록 설계
    • 업스트림 소스
      • 다른 Vector 에이전트
      • Syslog-ng와 같은 Vector가 아닌 에이전트
• Topology
  • Vector를 인프라에 배포한 최종 결과

Architecture

• Data model
  • Log events
    • 특정 시점 이벤트를 구조적으로 표현한 것
  • Metric events
    • 이념적 순수성보다 정확성과 정확성을 선호
      • 메트릭 유형은 Prometheus 및 StatsD와 같이 실제로 발견되는 다양한 메트릭 유형의 집합체
      • 메트릭 데이터가 시스템 간에 올바르게 상호 운용
• End-to-end Acknowledgements
  • 클라이언트가 목적지 싱크로 데이터가 전달되었는지 확인할 수 있는 기능
  • 설계
    • 소스가 이벤트 또는 이벤트 배치를 수신하면 선택적으로 해당 이벤트에 대한 batch notifier 생성 가능
    • batch notifier는 두 부분으로 구성
      • 한 부분은 소스에 유지
      • 다른 부분은 이벤트에 연결
    • 이벤트가 대상 싱크에 도달하고 싱크에서 처리되면 다운스트림 서비스의 응답 상태를 캡처하고 이를 사용하여 일괄 알림을 업데이트
    • 이를 통해 이벤트가 성공적으로 처리되었는지 여부 표현 가능
    • 이벤트가 싱크에 도달했는지 여부에 관계없이 이벤트에 대한 batch notifier가 항상 업데이트되도록 보장
      • 이벤트가 의도적으로 삭제되거나 의도치 않게 삭제된 경우에도 batch notifier를 업데이트하여 이벤트 처리 상태를 표시
    • 소스는 자신이 생성한 batch notifier의 나머지 절반을 유지하며 batch notifier가 업데이트되면 알림을 수신
    • 알림을 받으면 소스는 해당 batch notifier 상태를 다시 업스트림으로 전파
  • Ensuring acknowledgement of events even through fanout, batching, aggregation, etc
  • End-to-end acknowledgement support between sources and sinks
• Pipeline model
  • 독립적인 하위 그래프를 포함하는 구성 요소의 방향성 비순환 그래프 기반
  • 이벤트는 소스에서 싱크로 단일 방향으로 흘러야 하며 주기를 만들 수 없음
  • 그래프의 각 구성 요소는 0개 이상의 이벤트를 생성 가능
  • Defining pipelines
    • YAML, TOML 또는 JSON 구성 파일을 통해 정의
    • 유지 관리를 위해 Jsonnet 또는 CUE와 같은 구성 및 데이터 템플릿 언어 사용 권장
    • 구성은 파이프라인 컴파일 시간(벡터 부팅 시)에 확인
      • 단순한 실수를 방지하고 DAG 속성 적용 가능
  • In-flight manipulation
    • 파이프라인은 Vector를 다시 시작하지 않고도 실시간으로 조정 가능
    • Reload
      • 구성 변경 사항을 적용하기 위한 핫 리로딩을 지원
      • SIGHUP 프로세스 신호를 Vector의 프로세스로 전송함으로써 달성
    • API
      • 실행 중인 Vector 인스턴스를 실시간으로 관찰하고 조작할 수 있는 API 제공
• Buffering model
• Concurrency model
• Runtime Model

Networking

• Adaptive request concurrency (ARC)

설치

설정

• Sources
• Transforms
• Sinks
• …

Vector Remap Language (VRL)