네임스페이스마다 개별 StarRocks가 떠 있는 멀티 테넌트(Multi-tenant) 환경이라면, 범인을 찾는 과정이 조금 더 복잡해 보일 수 있지만 오히려 인프라 레벨에서 격리해서 확인하기에는 더 좋습니다.
이런 구조에서는 개별 StarRocks에 일일이 접속하기 전에, "어떤 네임스페이스의 어떤 Pod가 트래픽을 일으켰는가?"를 먼저 찾아내는 것이 순서입니다.
가장 먼저 전체 클러스터 관점에서 50Gbps를 쓴 Pod를 식별해야 합니다.
# 특정 시간대에 전송(Transmit) 트래픽이 가장 높았던 네임스페이스 찾기
sum(irate(container_network_transmit_bytes_total[5m])) by (namespace)# 특정 시간대에 Storage Cluster(MinIO)로 트래픽을 많이 보낸 소스 네임스페이스 확인
hubble observe --since 24h --dest-ip <MinIO-IP> -o wide | grep "50Gbps 수준의 트래픽 흐름"범인 네임스페이스(예: user-a-ns)를 찾았다면, 이제 그 네임스페이스 안에 있는 StarRocks FE의 Audit Log를 확인해야 합니다.
ScanBytes가 큰 쿼리를 찾습니다.# 모든 네임스페이스에서 'starrocks-fe' 라벨을 가진 파드의 로그 중 ScanBytes가 큰 것 검색
kubectl logs -l app=starrocks-fe --all-namespaces --tail=-1 | grep "ScanBytes" | awk -F'|' '$10 > 1000000000 {print $0}' (참고: $10은 log 포맷에 따라 다를 수 있으니 확인이 필요합니다. 보통 1GB 이상의 스캔을 찾도록 설정합니다.)MinIO는 모든 요청의 Source IP를 알고 있습니다.
GetObject가 폭주했는지 확인 가능합니다.mc admin trace --call get <MinIO-Alias> 출력되는 결과에서 Client IP를 확보한 뒤, kubectl get pods -A -o wide | grep <Client-IP>를 실행하면 어떤 유저의 StarRocks BE 노드인지 즉시 나옵니다.개인용 StarRocks들이라면 다음 상황일 확률이 매우 높습니다.
SELECT * 하거나 대규모 집계(Aggregation)를 수행한 경우.INSERT INTO SELECT를 통해 대량의 데이터를 다른 테이블로 옮기거나 스토리지로 내보내는 작업을 했을 때입니다.Namespace별 Network Transmit 차트를 열어 50Gbps 피크를 친 네임스페이스를 특정한다.fe.audit.log를 열고, 피크 시간대의 ScanBytes가 가장 큰 SQL 문장을 확보한다.GET TYPE_QUERY_DETAIL)을 떠서 분석한다.현재 네임스페이스별 트래픽을 볼 수 있는 Grafana 대시보드가 있으신가요? 없다면 kubectl 명령어로 특정 시간대 로그를 추출하는 것이 가장 빠릅니다. 어떤 네임스페이스들이 있는지 리스트를 확인해 보셨나요?