Kapacitor

Kapacitor는 Influx Data에서 밀고 있는 TICK 스택 ( Telegraf, InfluxDB, Crongraf, Kapacitor ) 중 하나로 오픈 소스의 데이터 처리 프레임 워크로 경고 생성,  ETL 작업 실행 , 이상 징후 감지 등 다양한 데이터 처리가 가능함 

 

 

공식 문서에 따르면 현재 Kapacitor에 큰 효율을 가지는 기능들은 아래와 같다.

• 스트리밍 데이터 & 배치 데이터 모두 처리 가능
• 일정에 따른 데이터 쿼리 및 Influx DB를 통한 다양한 방식의 데이터 수신 가능 
• InfluxQL에 맞춰 데이터 변환 가능 
• 변환된 데이터를 다시 InfluxDB에 저장 가능 
• 사용자 정의 함수 추가 가능 

 

Kapacitor 설치 

• 기본 포트는 9092를 사용함
• 모든 API 및 쓰기 호출에 대해 TCP 보트에서 수신 대기 
• 구독을 통해 무작위 UDP 포트에 바인딩 가능 
• Kapacitor 설치 후 두개의 바이너리가 존재함
  • kapacitor : API를 호출하기 위한 CLI 프로그램
  • kapacitord : Kapacitor 서버 데몬 

설치 링크 : https://docs.influxdata.com/kapacitor/v1.6/introduction/installation/

Install Kapacitor | Kapacitor 1.6 Documentation

 

 

 

 

Kapacitor 시작 

 

[1] Kapacitor 구성 파일을 생성 

kapacitord config > kapacitor.conf

 

[2] 구성 파일 설정 후 Kapacitor 서비스 시작 

$ sudo systemctl start kapacitor

 

[3] 작업 실행 

TICKscript 시작 부분에서 데이터가 포함된 데이터베이스 및 보존 정책을 지정함 

dbrp "telegraf"."autogen"

// ...

<Kapacitor가 데이터베이스 및 지정된 것과 일치하는 보존 정책에서 데이터를 수신하면 Kapacitor는 TICKscript를 실행함>

 

 

 

 

현재 우리 시스템에서 사용하는 CQ의 갯수가 제법 있다보니 Kapactior를 추가하는 것을 고려하고 있다.

하지만 공식 문서에 따르면 CQ도 복잡한 쿼리나 엄청난 양의 계산 쿼리가 많지 않다면 충분히 사용가능하다고 한다.

그래서 Kapactior 적용 여부는 추후 CQ로 무리 없이 시스템이 동작하는지  테스팅 후 추가할지 검토하기로 하였다.

 

공식문서를 잠깐 정리하면 아래와 같다.

 

1. CQ보다 Kapacitor가 유리한 경우

[1] 상당한 수의 CQ를 수행하고 작업 부하를 격리하려는 경우

   - 집계함수 수행 시 InfluxDB 성능 프로필이 Kapacitor와 분리되어 안정적인 유지 가능

[2] 쿼리를 수행하는 것 이상의 사용자 정의 함수가 필요한 경우

   - Kapacitor는 훨씬 더 많은 작업과 다양한 데이터 변환 수행이 가능해 큰 유연성을 가짐

 

2. CQ보다 Kapactior가 불리한 경우

[1] 보존 정책에 대한 다운 샘플링을 수행하는 경우

   - CQ는 최소한으로 유지하는 것이 좋다