# prometheus

sawa1989

업로드중.. https://grafana.com/docs/loki/latest/get-started/components/ 설치 loki-s3-policy.json trust-relationship.json s3 확인 grafana 확인

kin5080

문제 오토 스케일링을 적용하여 가변적으로 늘어나는 서버의 상태를 개발자가 수정하는 작업 없이 자동으로 grafana에 적용되도록 하는 방법. 해결 방법 aws의 읽기전용 사용자를 생성하고 인스턴스에 태그를 부여해서 그라파나 구동서버에서 자동으로 수집할 수 있도록 prometheus 설정 파일을 수정한다. prometheus.yml 각각의 job에게 사용자 권한을 부여하고 PrometheusScrape이라는 태그가 Enabled 이라는 값을 가지고있는 인스턴스들을 불러와서 private ip, tag group, instance_type 정보를 받아온다. 사실 중요한건 private ip 정보 뿐이다. 오토 스케일링으로 생성되는 인스턴스들은 시작 템플릿에 적용된 정보를 기반으로 생성되는데 이 때 인스턴스에 적용될 태그를 설정할 수 있다. ![](https://velog.velcdn.com/images/kin5080/post/f8e50fbf-6c1a-47aa-9b25-e

kin5080

대규모 트래픽 환경을 컨트롤하는 프로젝트에서 서버의 상태를 알아보기 위한 모니터링 시스템을 만들어보았다. 결과적으로 분산 서버 환경과 오토스케일링으로 늘어나는 서버에서 발생하는 메트릭을 자동으로 수집하는 환경을 구현하였다. 모니터링 환경을 구현하는 시스템들은 여러가지가있다 AWS의 CloudWatch, Pinpoint, prometheus 등등 그리고 수집한 메트릭 정보를 UI로 그려주는 Grafana가 있다. 네이버 클라우드에도 모니터링을 지원하고 와탭이라는 모니터링 서비스 플랫폼도 존재한다. 여러 방법이 있는데 이 중에 나는 grafana에 prometheus를 물려서 모니터링 하는 방식을 선택했다 이유는 두 가지인데 비용이 들지 않는다. jvm 정보도 같이 수집하고싶었다. 비용 문제는 서버가 ec2 환경에서 구동 되기 때문에 cloudwatch를 사용하면 간편하게 받을 수 있지만 비용이 발생할 수 있다고 해서 최대한 지원금을 아껴보고자 포기했고, jvm 정

akeka0303

개발환경 온프레미스 쿠버네티스 클러스터 / 온프레미스에 설치한 Redis Redis-Exporter 설치과정 명령어 참고 확인 사이트 https://github.com/oliver006/redis_exporter Redis-servicemonitor 헬름 설치 위 template https://artifacthub.io/packages/helm/ygqygq2/redis-servicemonitor?modal=template&template=prometheusrule.yaml 설치 후 Target 확인하기

keikang

1. 목표 모니터링을 위한 개발이 필요해서 리서치를 하던 중 prometheus라는 오픈소스를 알게되어 그것을 기반으로 개발을 하기로 했다. prometheus의 architect이다. 대략적으로 설명하자면 jobs exporter들을 promethus에 등록하여 모니터링 항목(metric이라 부름)을 수집하고 해당 데이터들을 Stroage에 저장하는데 모니터링은 시간의 흐름이 중요하므로 시간에 따라 저장이 되는 Time series DB(시계열 DB)를 사용한다. 관계형DB(RDB)의 한계를 극복하기 위해 등장하였다. 그리고 해당 DB를 PromQL이라는 쿼리를 사용하여 내가 원하는 모니터링 항목을 추출한다. exporter와 prometheus간에는 http 통신을 이용하여 데이터를 전달받는다. U

sdsd0908

CPU 사용량, DB 커넥션 풀, 메모리 사용량 등등 기본 메트릭을 통해서 여러 유용한 정보를 파악할 수 있다. 하지만 이는 공통적인 메트릭이다. >내가 회원가입을 진행한 사람의 수를 보고 싶다면? 내가 만든 서비스에 특정 기능을 사용한 수를 보고 싶다면? 이런 서비스에서 제공하는 정보들은 기본 제공 메트릭을 통해서 확인할 수 없다. 이런 경우는 개발자가 메트릭을 따로 만들어줘야 한다. 메트릭으로 자주 사용하는 것은 3가지가 있다. 게이지(@Gauge), 카운터(@Counter), 타이머(@Timer)이다. 메트릭에 대한 설정은 무조건 마이크로미터의 것을 사용한다는 것을 잊지 말자. 상상해보자. (AOP) AOP를 이해하고 있다면 생략하셔도 됩니다. 이전에 힘겹게 만들어 놓은 컨트롤러가 있다고 생각해보자. 이제 여기에 우리가 직접 호출 수를 카운트와 동작 시간에 대한 로그를 남기는 기능을 만든다고 해보자. 이제 우리가 만들었던 중요_서비스는 이제 3가지

ddangle

스프링부트 액추에이터 (Actuator) 스프링 부트 액추에이터(Actuator)는 스프링 부트 프로젝트에서 운영 환경에서의 모니터링과 관리를 쉽게 할 수 있도록 도와주는 라이브러리입니다. 이는 스프링 부트 애플리케이션의 내부 상태와 메타데이터에 접근할 수 있는 강력한 기능을 제공하여, 애플리케이션의 운영 중 상태를 실시간으로 파악하고, 문제를 진단하며, 필요한 조치를 취하는 데 도움을 줍니다. 스프링부트 액추에이터는 다양한 엔드포인트(Endpoint)를 제공하는데, 이 엔드포인트들을 통해 애플리케이션의 다양한 정보와 통계를 조회할 수 있습니다. 몇 가지 주요한 엔드포인트는 다음과 같습니다. 이들에 대한 정보는 "{server-base-url}/actuator" 에서 확인할 수 있습니다. health : 서버의 구동 여부를 나타내는 엔드포인트 info : 애플리케이션에 관련된 정보를 제공하는 엔드포인트 metrics : 애플리케이션의 여러 메트릭 정보를

97gkswn

본 포스팅은 Mac OS를 기준으로 작성 했습니다. 개요 Grafana를 이용해 서버를 모니터링 할 수 있게 설정하는 방법은 이미 꽤 많은 사람들이 자세하게 작성해 놓은 블로그들이 있습니다. 따라서 제가 또 적기보다는 나중에 제가 까먹었을 때 보고 참고하거나 다른 분들도 뭘 봐야할지 모르겠고 설정할 때 큰 흐름을 모르실 때 참고할 수 있게끔 적어보려고 합니다. 모니터링 원리 우선 Actuator , 프로메테우스(Prometheus), Grafana 이 3개가 필요합니다. 최종적으로 우리 눈으로 Grafana에서 직접 그래프로 관찰할 수 있게 될텐데 이것의 원리를 알고가는게 좋을 것 같습니다. > - 모니터링 원리의 큰 흐름 Spring boot의 actuator 라이브러리라는 친구가 현재 내 프로젝트의 메트릭 정보를 노출시킵니다. 프로메테우스는 actuator가 노출시킨 메트릭 정보 를 수집하고 저장합니다. 마지막으로 프로메테우스가 수집한 정보들

bw1611

프로젝트 설정 docker-compose.yml docker-compose.yml은 여러 Docker 컨테이너들을 정의하고 실행하기 위한 설정을 담는다. volumes로 프로젝트 내에 만든 prometheus.yml 파일을 원래 위치해야 하는 파일 위치와 마운트 시켜준다. prometheus.yml targets으로 local 수준에서 서로 통신할 수 있도록 설정해준다. docker에서 prometheus와 grafama 실행 docker compose up -d docker compose로 실행된 서비스들을 백그라운드로 실행 > 만약 “docker: Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: (중략)” 와 같은 오류가 나온다면 dokcer-compose.yml에 적은 prom

nefertiri

개요 이전 포스트에서 스프링 액추에이터, 마이크로미터, 프로메테우스, 그라파나 등을 사용하여 컨테이너의 애플리케이션 모니터링 환경을 구축하였습니다. 스프링 액추에이터에서 기본으로 제공되는 메트릭을 프로메테우스에 연동하여 내부 데이터베이스에 저장하고, 그라파나의 대시보드에 프로메테우스에 저장된 데이터를 시각화하였습니다. 이번 포스트에서는 애플리케이션에 사용자 정의 메트릭을 추가하여 비즈니스에 특화된 부분을 모니터링 해보겠습니다. 사용자 정의 메트릭 스프링 액추에이터의 마이크로미터에서 제공되는 메트릭은 JVM(메모리 사용량 등), 시스템(CPU, 디스크 사용량 등), 톰캣, 데이터 소스, HTTP 요청 등 모든 애플리케이션에서 공통으로 사용할 수 있는 메트릭입니다. 사용자 정의 메트릭은 애플리케이션에서 제공하는 비즈니스 로직에 특화된 메트릭을 말합니다. 예를 들어 쇼핑 애플리케이션이라면 주문수, 주문 취소수, 재고 수량 같은 수치들을 모니터링하는 메트릭이 될 것 입니다.

ssha

오픈소스 모니터링 시스템으로 잘 알려져 있는 prometheus 설치 방법을 공유하고자 작성하였습니다. 개인적으로 실무에서 유용하게 잘 사용중인 서비스들중 하나입니다. 시각화 서비스인 Grafana에 연결하여 Node Exporter로 수집한 메트릭을 시각화한다던가 alertmanager 라는 부가 서비스를 통해 CPU 사용량이 일정량을 넘었을 때 Slack으로 알람을 오게 한다던가 AWS ec2 인스턴스의 CPU / RAM / STORAGE 등을 node exporter 라는 에이전트로 모니터링 할 때도 유용합니다. '정말 간단하게' 라는 문구를 덧붙였는데, 그 이유는 rpm으로 설치하며 리눅스 데몬까지 등록을 해주어 일일이 prometheus 유저 생성 및 서비스를 만들지 않아서 인데요. 그럼 사용중인

hoonki

이슈 서비스를 운영하다가 Production 환경에서 Celery worker 및 백엔드 서버에서 RabbitMQ Connection Refused 문제가 발생했다. 처음에는 오류 개수가 많지 않아서 일시적인 오류라 생각했으나, 꽤 많은 건수의 보고가 잡혀서 원인을 파악하고 문제를 해결해야 했다. 원인 파악 현재 Aws EKS 환경에서 RabbitMQ Cluster Operator를 활용해서 EKS 클러스터 내 RabbitMQ 를 운영하고 있다. 애플리케이션 및 노드 그리고 RabbitMQ 의 성능을 모니터링하기 위해 사내에서 Grafana + Prometheus를 활용하고 있다. 그 중 RabbitMQ 대시보드를 통해 Publisher, Consumer 수 In/out 메시지 per second 등 여러 가지 성능 지표들을 볼 수 있다.

nefertiri

개요 이번 포스트에서는 컨테이너 환경에서 애플리케이션을 모니터링하는 방법을 알아보겠습니다. 프로메테우스를 사용해 애플리케이션에서 측정된 수치를 수집하고 그라파나를 이용해 시각화하는 형태로 사용합니다. 먼저 예제 프로젝트는 이전 포스트에서의 마지막 커밋을 사용하겠습니다. (https://github.com/nefertirii/docker-example/tree/3021a5cac264318ff34b519ed16daefe6017aa08) 프로메테우스 도커 연동 먼저 프로메테우스는 애플리케이션에서 데이터를 수집하여 DB에 저장하는 기능을 제공하는 도구입니다. 프로메테우스도 컨테이너에서 실행될 수 있습니다. 프로메테우스는 애플리케이션 뿐만 아니라 도커 엔진의 측정 값도 추출할 수 있습니다. 이 기능을 사용하려면 도커 엔진 설정에서 측정 값을 공개하도록 설정해야합니다. 도커 엔진을 사용한다면 /etc/docker/daemon.json 파일에 아래 내용을 추가합니다.

sdsd0908

환경 다음 환경에서 간단하게 액추에이터, 프로메테우스와 그라파나를 사용한 모니터링 환경 구성을 해보겠다. 필요한 내용만 확인하고 빠르게 모니터링 환경을 구성하기 위한 글이다. 자세한 내용은 따로 공부하도록 하자. 스프링 부트 환경 설정 build.gradle 설정 액추에이터 스프링 액추에이터는 동작하고 있는 서버의 내부 정보를 확인할 수 있도록 만들어준다. 로깅 정보, 애플리케이션 정보 등등 많은 데이터들이 있다. 또한 외부에서 POST 요청을 통해 설정을 바꿀 수 있는 것들도 있다.(Shutdown, 로그 레벨 등등) git 현재 동작중인 서버의 Git 브랜치 명, 커밋 시간 등등의 정보를 추가적으로 제공한다. git을 사용하지 않는다면 제외해도 상관없다. 프로메테우스 마이크로미터 ![](https://velog.velcdn.com/images/sdsd0908/post/69faf75d-5a28-4109-8fb9-d01399bc

ooweatah

Docker > • Container 라는 형태로 프로그램을 빌드하고 배포, 실행하는 플랫폼 • Light-weigh 한 고립된 환경에서 프로그램과 의존성들을 패키징 • 로컬환경에서 작동하던걸 쉽게 다른곳에 이식가능 • 장점 • 이식성, 상호 운용성, 경량성, 모듈화와 확장성 • 단점 • 보안 - host system , kernel 공유 =>덜 격리 됨. 하나의 컨테이너 문제 => 영향을 끼칠 수 있다 • 데이터 관리 - 컨테이너로 만든 app은 임시적이다. 데이터를 영구적으로 보존 x Docker-compose >여러개의 docker container 로 구성된 애플리케이션을 정의하고 실행시키는 도구 yaml 파일로 설정 ex) DB , APP1 , APP2의 관계를 적어놓으면 관리 가능 • 장점 • 단순성 • 개발 효율성 • 서비스간 종속성 관리 • 단점 • 상용 환경에서의 제한 • 보안 문제 >• Distributed system 프로파일링의 어려움

js_moon

Keda 공식 홈페이지 > > > KEDA > > Keda 구성 시 참고 주소 > > > KEDA | Scaling Deployments, StatefulSets & Custom Resources > > 과연 kubernetes에서 제공해주는 기본 hpa 말고 개발환경에 맞는 pod 오토스케일링은 안되는 걸까? 라는 호기심으로 시작하여 알아보니 prometheus와 연동하여 prometheus의 지표를 사용하여 오토스케일링 하는 방법이 있어 적용하는 과정입니다 ! Keda란? Kubernetes 이벤트 기반 기반 자동 확장 솔루션입니다. Kubernetes-based Event Driven Autoscaler 모든

723poil

진행중인 프로젝트에서 Thread pool 외에 각 API 성능을 확인하기 위해 모니터링 시스템을 만들고자 했다. 그래서 오픈소스인 Prometheus와 Grafana를 사용하기로 했다. 🎈Build.gradle Spring boot 내의 정보들을 다룰 수 있도록 하는 Actuator와 Prometheus를 의존성 주입 🎈Actuator management.endpoints.web.exposure.include 옵션을 통해 /actuator 페이지에 노출시킬 엔드포인트 설정 가능 /actuator 주소로 들어가면 확인할 수 있다. 🎈Micrometer Prometheus에서 api의 성능 정보를 얻기 위해 우리는 micrometer의 Timed annotation을 사용할 것이다. 이렇게 어노테이션을 설정해주면 데이터를 받아올 수 있다. 🎈Prometheus 위의 작업으로 Metrics를 추가하고, Prometheus에서 actuator

hyungzin0309

cpu는 memory나 disk처럼 현재의 사용량을 직접적으로 나타내기 어렵다. 단일 CPU 코어는 1초 동안 다양한 애플리케이션에서 오는 요청을 처리할 수 있다. 이는 운영 체제의 스케줄러(scheduler) 덕분인데, 스케줄러는 CPU 시간을 여러 프로세스 또는 스레드 간에 공평하게 분배하는 역할을 한다. 운영 체제는 각 애플리케이션을 실행하는데 필요한 작업을 작은 '시간 조각(time slice)'으로 나눈다. 이 시간 조각은 보통 밀리세컨드(ms) 단위로, 운영 체제의 스케줄러는 이러한 시간 조각을 사용하여 각 애플리케이션에 CPU의 사용 시간을 할당한다. 이 과정을 통해 CPU 코어는 동시에 여러 애플리케이션을 처리하는 것처럼 보이게 된다. 그러나 실제로는 CPU 코어가 매우 빠른 속도로 각 애플리케이션의 작업을 전환하면서 이루어지고, 이를 컨텍스트 스위칭이라 한다. 이러한 방식으로, 단일 CPU 코어는 1초 동안 수천 개의 작업을 처리할 수 있다. 이 때문에 cpu

wanny328

포스팅 이유 Kubernetes Cluster를 운영하며 발생하는 문제 상황들(ex. Pod Down, Node Down, Resource 과다 등..)을 보다 빠르게 확인하기 위해 Alertmanager 사용 Kubernetes Cluster 운영에 필수적인 모니터링 방안 중 하나이기 때문에 포스팅을 통해 정리 시작하며 Kubernetes Cluster를 안정적으로 운영하기 위해 가장 중요한 것을 두 가지 뽑자면 백업과 모니터링이라 생각합니다. 이 두 분야를 실무에서 담당한 경험이 있고 이런 경험에서 사용하고 공부한 내용을 포스팅을 통해 정리하고자 합니다. 1. Prometheus Rule 설정 > #### 환경정보 > Prometheus와 Alertmanager를 Operator를 통해 설치한 환경 일단 Alert을 위한 Rule을 생성해야합니다. 실제 환경에 구성되어 있는 Rule을 예시로 먼저 보면 <im

jhyoo9727

Java Spring API 모니터링 Dependencies 추가 application.yml 추가 actuator만 port변경을 원할 땐, managerment:server:port=3333 으로 하면 localhost:3333/actuator/prometheu로 port가 변경됨. localhost:8080/actuator/prometheus /junghun 이라는 endpoint의 접속 횟수와 접속하는데 걸린 최대 시간, 합을 출력 Prometheus Target Node js (express) API 모니터링 Exp