전체 글
Opentelemetry - Collector filtering span
opentelemetry collector를 이용하여 trace 데이터를 수집하다보면, 꼭 수집하지 않아도 되는 데이터를 발견할 수 있습니다. 예를 들어, application health check나 prometheus에서 해당 application의 metric을 scrape할 때 호출하는 request에 대한 것은 이미 정상 작동이 확인되었다면 그 이후에는 trace 데이터를 수집하는 것이 비효율적일 수 있습니다. (필요 없는 데이터가 너무 많아지기 때문) 따라서, span 이름을 기반으로 filter하는 방법을 알아보게 되었고, 여러 방법 중 opentelemetry collector에서 filtering을 하는 방법으로 적용했습니다. apiVersion: opentelemetry.io/v1alp..
Opentelemetry - auto instrumentation with specific libraries
Application의 trace 데이터를 수집하기 위해 auto instrumentation을 활성화했으나 cpu가 거의 3~4코어까지 치고 계속해서 shutdown 훅이 실행되면서 컨테이너가 실행을 멈춰서 crashloopback이 되어 재시작을 무한대로 하는 현상이 있었습니다. https://opentelemetry.io/docs/instrumentation/java/automatic/agent-config/#suppressing-specific-auto-instrumentation 위 링크를 참조하여 java opentelemetry agent의 default instrumentation을 비활성화하고, helmdall-apps에서 사용한 라이브러리만 활성화시키도록 변경했습니다. 개발 과정에서 사..
Opentelemetry - auto instrumentation
auto instrumentation은 Application Code 수정 없이 Opentelemetry로 trace, metric, log 데이터를 수집할 때 사용합니다. Application을 작성한 언어를 기반으로, 미리 만들어져있는 라이브러리를 주입하는 방식입니다. Docker image에서 해당 라이브러리를 주입하는 방식도 존재하지만, kubernetes 환경에서는 더욱 간단하게 application pod에 initcontainer로 라이브러리를 주입하도록 할 수 있습니다. 참조 링크 : https://opentelemetry.io/docs/k8s-operator/automatic/ 저는 otlp http protocol을 이용하여 trace data를 수집하기 위한 테스트를 진행했습니다. 1..
Prometheus-adapter를 이용한 custom.metrics.k8s.io API 사용 (for HPA v2beta2 target)
HPA에 custom metric을 target으로 적용시키기 위한 내용입니다. ex) nginx-ingress request 증가량 필요한 환경 kubernetes cluster에 아래 항목들 구성 prometheus metrics-server nginx-ingress ( + ServiceMonitor ) test용 nginx 개념 Default : metrics-server API(metrics.k8s.io) + HPA 특이한 세팅 없이 metrics-server를 구축하고 hpa를 적용하면 cpu, memory 기준으로 pod autoscaling을 할 수 있습니다. 작동 방식은 metrics-server의 API service인 metrics.k8s.io을 통해 HPA가 현재 pod의 cpu, m..
Loki Deployment to k8s
1. Deployment modes https://grafana.com/docs/loki/latest/fundamentals/architecture/deployment-modes/ Loki를 배포하는 방식은 크게 3가지로 나눌 수 있습니다. Monolithic mode Simple scalable deployment mode Microservices mode https://grafana.com/blog/2022/12/19/the-only-helm-chart-you-need-for-grafana-loki-is-here/ 위 링크의 글에 따르면, 이 세 가지 방식에 따라 helm chart도 나누어져 있습니다. 1.0. Deployment mode를 이해하기 위한 정보 배포 방식을 나누는 기준은, Loki의..
Prometheus ISSUE
PV PVC, PV Mount 현재 생성되어 있는 PV와 Prometheus pod가 scheduling된 Node의 AZ이 동일해야 함 PVC 크기 retention, System 크기(Metric 수집량)에 따라 PVC 용량을 잘 선정해야 함 경험에 의하면, retention 30d이면 최소 30G 이상은 해야 함 (50G 이상을 추천) Resource Prometheus 예약 resource 특히, Grafana에서 Prometheus에 날리는 Query가 복잡하면 Resource 사용량이 늘기 때문에 더더욱 limit을 크게 잡아두고 사용해야 함 request를 적게 주더라도 limit은 크게 주고 운영하다가 추후에 사용량을 기반으로 다시 request와 limit을 최적화하는 것을 추천 정리하면..
TSDB의 데이터 수집 방식 (polling, trapping)
Polling DB가 Agent에게 요청하고, Agent가 응답하는 방식 ex. Prometheus & Node Exporter → 네트워크 지연 상황에서 대처가 느릴 수 있음 Trapping Agent가 특정 이벤트에 따라 DB에게 보내주는 방식 ex. Loki & Promtail → 계속 데이터를 보내기 때문에 데이터가 안 오는 즉시 장애가 났다고 판단 가능 혹은 pull / push 방식이라고도 함
Prometheus Recording Rule
Recording rule https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/#configuring-rules example https://github.com/prometheus-community/helm-charts/blob/52dfc37b648001202edd9179effaec6aa188d887/charts/kube-prometheus-stack/templates/prometheus/rules-1.14/node-exporter.rules.yaml 적용방법 helm chart에 values.yaml에서 additionalPrometheusRulesMap additionalPrometheusRulesMap: test-ru..