Hubble flow logs 를 수집하려면 로그를 수집하는 로깅 시스템 구성이 필요하다.
로깅 시스템은 Loki + promtail + grafana 를 사용했다.
Loki는 로그를 수집하는 기능, promtail은 로그를 Loki로 전송, 그리고 grafana는 이를 시각화하는 역할을 한다.
Loki 스택 설치
helm 으로 설치한다.
values.yaml 내용은 아래와 같다
loki:
enabled: true
isDefault: true
persistence:
enabled: false # 디스크 저장 X , 메모리 기반 Loki만 사용
# accessModes:
# - ReadWriteOnce
# size: 10Gi
# storageClassName: default
promtail:
enabled: true
config:
clients:
- url: http://loki:3100/loki/api/v1/push
snippets:
pipeline_stages:
- cri: {} # containerd 또는 CRI 로그 구조에 대응
scrape_configs:
- job_name: kubernetes-pods
kubernetes_sd_configs:
- role: pod
relabel_configs:
- source_labels: [__meta_kubernetes_pod_label_app]
target_label: app
- job_name: hubble-relay
static_configs:
- targets: ['hubble-relay.kube-system.svc.cluster.local:4245'] # ← Hubble Relay 서비스 확인 필요
relabel_configs:
- source_labels: ['__address__']
target_label: 'job'
replacement: 'hubble-flow'
grafana:
enabled: true
adminPassword: "admin" # ← 필요시 보안 강화를 위해 수정
persistence:
enabled: false # 로컬 저장 X, pod 재시작 시 초기화 됨. 아래 설정은 true일 때만
# size: 5Gi
# accessModes:
# - ReadWriteOnce
# storageClassName: default
sidecar:
dashboards:
enabled: true
datasources:
enabled: false # 꼭 false로 할 것. grafana - loki 데이터 소스 연결에서 에러 발생
설치 및 확인 명령어
helm install hubble-loki grafana/loki-stack -f values.yaml -n monitoring --create-namespace
kubectl get pod -n monitoring
kubectl get svc -n monitoring

그리고 grafana Service를 Nodeport 로 변경
kubectl patch svc hubble-loki-grafana -n monitoring -p '{"spec": {"type": "NodePort"}}'

http://<노드IP>:30860으로 접속하면 된다. (Vagrant 기반 클러스터의 경우)
Grafana에서 데이터 소스 추가할 때 계속 connection 에러가 발생한다.
API응답은 전부 OK가 나왔다. 하지만 왜 connection 에러가 발생하는가?

Hubble UI에서는 문제가 없어 보인다. 네트워크적인 문제는 아닌 것 같다.

grafana 컨테이너의 로그를 확인해봤다.
kc logs hubble-loki-grafana-76b47d8bc4-d5zl6 -n monitoring -c grafana

뭔가 에러가 보인다. parsing error..
vector(1) + vector(1) 형식의 테스트 query를 loki에 날렸는데, 이건 PromQL 형식의 문법이고 그래서 Loki는 이해할 수 없다고 한다.
LogQL형식의 쿼리를 날려야 한다고 하는데..
Grafana UI에서는 아무리 찾아도 이걸 바꾸는 방법이 없다.
GPT 한테 물어본 결과.. Datasource 의 type을 Loki가 아닌 Prometheus로 오인하고, PromQL 형식의 쿼리를 날린다고 하는데..
즉 버그에 가까운 현상이라고 한다.
To be Continue..
'DevOps > cilium' 카테고리의 다른 글
| [Cilium Study] Routing (6) | 2025.08.02 |
|---|---|
| [Cilium study] IPAM 모드 (2) | 2025.07.31 |
| [Cilium Study] Network Observability with Hubble (3) | 2025.07.27 |
| Flannel 에서 cilium으로 마이그레이션 (1) | 2025.07.20 |
| Cillium 시스템 요구사항 점검 자동화 (1) | 2025.07.20 |