반응형

circuit breaker 가 오픈되었는지 닫혀있는지를 확인하려면 대시보드가 필요하다는 생각이 든다.

예전에 histrix 를 이용할때는 turbin 이라는 모니터링이 있던거로 기억하는데, spring cloud gateway 의 circuit breaker 인 

Resilience4j 는 없다.

Resilience4j 에는 모니터링 툴이 존재 하지 않아 micormeter 로 metric 제공하는 내용으로 모니터링을 직접 구성해야 한다.

메트릭을 수집하고 표현하는 대시보드는 prometheus 와 grafana 로 모니터링을 할 수 있다.

 

준비 

1. Prometheus 설치

2. grafana 설치

 

스프링 yml

cloud:
  gateway:
    routes:
      - id: test
        uri: http://localhost:9091
        predicates:
          - Path=/circuit/**
        filters:
          - name: Retry
            args:
              retries: 3
              method: GET
              backoff:
                firstBackoff: 50ms
                maxBackoff: 500ms
          - name: CircuitBreaker
            args:
              name: myCircuitBreaker #서킷브레이커 명.
              fallbackUri: forward:/fallback
              statusCodes:
                - 500

예시로, 요청하려는 서버의 응답코드가 500 이면 서킷브레이커가 가동되고, 서킷브레이커의 네이밍을 지정할 수 있다. 이 네이밍 myCircuitBreaker 는 dashboard 에 찾을 수 있다.

스프링 

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-circuitbreaker-reactor-resilience4j</artifactId>
</dependency>
<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-registry-prometheus</artifactId>
</dependency> <!-- 모니터링 -->

모니터링을 위해 필요한 metric 을 제공하는 라이브러리는 micrometer-registry-prometheus 이다.

 

그리고 actuator 가 있어야, prometheus 가 데이터를 수집해줄 수 있다.

actuator 엔드포인트 /actuator/prometheus 로 데이터 수집한다.

 

http://localhost:포트/actuator/prometheus

과 같이 나온다.

 

프로메테우스 구성법

https://juntcom.tistory.com/188

 

프로메테우스 Prometheus 시작하기(docker)

프로메테우스란 - prometheus 란 오픈소스 모니터링 툴로 지표 수집을 통한 모니터링이 주요 기능이다. 쿠버네티스 뿐만 아니라 애플리케이션이나 서버, OS등 다양한 대상으로부터 지표(Metric)를 수

juntcom.tistory.com

prometheus.yml 

서버에서 실행시

vi /etc/prometheus/prometheus.yml

global:
  scrape_interval: 10s # 10초마다 매트릭을 수집 default 1분
  evaluation_interval: 1m # 1분마다 규칙을 평가 default 1분

  external_labels: # 외부 시스템에 표시할 이 서버의 레이블
    monitor: 'monitor'

rule_files: # 규칙을 로딩하고 evaluation_interval 설정에 따라 정기적으로 평가한다.
# - "first.rules"
# - "second.rules"

scrape_configs:
  - job_name: 'circuit-breaker' 
    metrics_path: '/actuator/prometheus' # 메트릭을 수집할 path 설정
    static_configs:
      - targets: [‘ip:포트’] #로컬도커인 경우 'host.docker.internal:포트'

도커 실행
docker run -d -p 9090:9090 -v /etc/prometheus:/etc/prometheus --name prometheus prom/prometheus

프로메테우스 실행 하면 
http://localhost:9090/targets  에 수집하고 있는 target 들 현황을 볼 수 있다.

 

위의 데이터 수집까지 되었으면 prometheus 로 수집한 데이터를 grafana 로 데이터 보여주면 된다.

grafana 설치까지 하면 인프라 구성은 완료 

grafana 설치했으면 prometheus 를 datasource 추가하자.

다음에

https://resilience4j.readme.io/docs/grafana-1 대시보드 설치해주면된다.

https://github.com/resilience4j/resilience4j/blob/master/grafana_dashboard.json 

 

GitHub - resilience4j/resilience4j: Resilience4j is a fault tolerance library designed for Java8 and functional programming

Resilience4j is a fault tolerance library designed for Java8 and functional programming - GitHub - resilience4j/resilience4j: Resilience4j is a fault tolerance library designed for Java8 and functi...

github.com

위 json 파일을 대시보드로 import 해주면 끝.


혹 데이터가 보이지 않으면, datasource 를 방금 추가해준 prometheus 설정으로 수정 하면 된다.

반응형

'인프라 > 모니터링' 카테고리의 다른 글

[ELK] logstash 설치 및 실행하기  (0) 2022.07.13
telegraf 시작하기  (0) 2022.01.04
Burrow 시작하기  (0) 2021.12.30
ZIPKIN 시작하기  (0) 2021.11.25
프로메테우스 Prometheus 시작하기(docker)  (0) 2021.11.04
반응형

logstasth 로 elasticsearch 에 데이터를 넣어줄 수 있다.

나는 kafka 데이터를 logstash 로 컨슘하고 output 저장소로 elasticsearch 에 넣으려고 한다.

 

https://www.elastic.co/guide/en/logstash/6.6/installing-logstash.html

 

Installing Logstash | Logstash Reference [6.6] | Elastic

Use the echo method described above to add the Logstash repository. Do not use add-apt-repository as it will add a deb-src entry as well, but we do not provide a source package. If you have added the deb-src entry, you will see an error like the following:

www.elastic.co

이거대로만 하면 logstash 설치 가능하다.

 

요약하자면

centos 기준, elasticsearch version 6 기준

1. 퍼블릭키를 다운

rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch

2. 경로 /etc/yum.repos.d/ 에서 logstash.repo 라는 파일 생성 후 아래 코드 작성

[logstash-6.x]
name=Elastic repository for 6.x packages
baseurl=https://artifacts.elastic.co/packages/6.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1
autorefresh=1
type=rpm-md

3. 설치

sudo yum install logstash
 

 

conf 파일 작성.

/etc/logstash/conf.d/ 경로에 logstasth.conf 파일 생성 후 

내용 작성한다.

input 및 output 설정해주면 된다. -> Pipline.yml 에 

path.config: "/etc/logstash/conf.d/*.conf"

과 같이 파이프라인 파일에 conf 파일을 읽는 거로 설정되어 있기 때문에 저 경로에 파일 생성해준다.

input {
    kafka {
        bootstrap_servers =>  "172.11.11.11:9092"
        group_id => "logstash"
        topics => [“test-topic”]
        consumer_threads => 1
    }
}

filter {
}

output {
    stdout {
        codec => rubydebug
    }    
    elasticsearch {
        hosts => "172.11.22.22:9200"
        index => "kafka-test-%{+YYYY-MM-dd}"
        document_type => "_doc"
    }
}

 

 

로그스태시 실행(start, restart, stop)

 systemctl restart logstash

 

- 로그 스테이스 설정 파일의 변경 사항을 적용하려면 재시작을 한다.

로그스테이시 로그

$ tail -f /var/log/logstash/logstash-plain.log

 

https://medium.com/geekculture/data-pipeline-from-kafka-to-elastic-search-using-logstash-5edca8d44d82

filter {
  mutate {
  add_field => {
  "id" => "%{[data][id]}"
  }
  add_field => {
  "firstName" => "%{[data][firstName]}"
  }
  add_field => {
  "lastName" => "%{[data][lastName]}"
  }
  add_field => {
  "city" => "%{[data][city]}"
  }
  add_field => {
  "country" => "%{[data][country]}"
  }
  add_field => {
  "email" => "%{[data][email]}"
  }
  add_field => {
  "phoneNumber" => "%{[data][phoneNumber]}"
  }
  add_field => {
  "createdAt" => "%{[data][createdAt]}"
  }
  remove_field => ["data", "@version", "@timestamp", "message", "event", "globalId"]
  }
  }
 
반응형

'인프라 > 모니터링' 카테고리의 다른 글

spring cloud resilience4j 모니터링  (0) 2022.11.03
telegraf 시작하기  (0) 2022.01.04
Burrow 시작하기  (0) 2021.12.30
ZIPKIN 시작하기  (0) 2021.11.25
프로메테우스 Prometheus 시작하기(docker)  (0) 2021.11.04
반응형

Telegraf 설정

Telegraf는 agent application으로서 burrow의 rest api데이터를 일정주기로 ES에 전달하는 역할을 합니다.

 

설치

centos 다운

# influxdb.key GPG Fingerprint: 05CE15085FC09D18E99EFB22684A14CF2582E0C5
cat <https://repos.influxdata.com/stable/\$basearch/main
enabled = 1
gpgcheck = 1
gpgkey = https://repos.influxdata.com/influxdb.key
EOF
sudo yum install telegraf

위 두 명령어 입력하면 다운된다. os 별 다운로드는 하기 링크에 있다.
https://portal.influxdata.com/downloads/

 

시작하기

systemctl start telegraf <-- 시작하기
sudo systemctl status telegraf  <-- 확인하기 

 

설정확인 후 재시작

systemctl restart telegraf

 

telegraf.conf

[[inputs.burrow]]
  servers = ["http://버로우:8000"]
  topics_exclude = [ "__consumer_offsets" ]
  groups_exclude = ["console-*"]

[[outputs.elasticsearch]]
  urls = [ "http://엘라스틱서치:9200" ] 
  timeout = "5s"
  enable_sniffer = false
  health_check_interval = "10s"
  index_name = "burrow-%Y.%m.%d" 
  manage_template = false

https://runebook.dev/ko/docs/influxdata/telegraf/v1.3/introduction/getting_started/index

 

 

 

반응형

'인프라 > 모니터링' 카테고리의 다른 글

spring cloud resilience4j 모니터링  (0) 2022.11.03
[ELK] logstash 설치 및 실행하기  (0) 2022.07.13
Burrow 시작하기  (0) 2021.12.30
ZIPKIN 시작하기  (0) 2021.11.25
프로메테우스 Prometheus 시작하기(docker)  (0) 2021.11.04
반응형

Burrow 는 또한 링크드인에서 제작한 아파치 카프카용 컨슈머 lag 를 체크하기 위한 api 서비스이다.

 

kafka 에 대한 endpoint 정보를 burrow 에 적용을 하면 카프카 lag 에 대한 정보부터 다양한 정보를 api 로 제공 받을 수 있다.

이 정보들을 활용해서 로그로 적재할 수 도 있다

 

 

공식문서

https://github.com/linkedin/Burrow

 

GitHub - linkedin/Burrow: Kafka Consumer Lag Checking

Kafka Consumer Lag Checking. Contribute to linkedin/Burrow development by creating an account on GitHub.

github.com

 

 

burrow 설치 

먼저 burrow 를 설치전에 go 를 설치해야 한다. burrow 는 go 로 만들어져 있다.

 

go 설치

brew install go

및 go 사이트에서 다운받아서 사용하면 된다.

 

git 레포지토리 clone

$ git clone https://github.com/linkedin/Burrow.git

 

go 실행하여 Burrow.exe 생성

클론 받은 디렉토리로 이동하고 go mod tidy 및 go install 을 해라. 

그러면 go 가 설치면 디렉토리에 go 하위 폴더에 Burrow.exe 가 생겼을 거다.

나 같은 경우 mac 

/Users/사용자명/go/bin 에 생성됐다.

$ cd to the source directory.
$ go mod tidy
$ go install

 

 

설정파일 수정

실행 전에 설정파일을 수정해야 한다.

파일명 burrow.toml 이고 git clone 으로 파일 repo 의 config 폴더에 있다.

[general]

[logging]
level="info"

[zookeeper]
servers=[ "localhost:2181"]

[client-profile.local]
client-id="burrow-local"
kafka-version="2.0.0"

[cluster.local]
class-name="kafka"
servers=[ "localhost:9092" ]
client-profile="local"
topic-refresh=120
offset-refresh=30

[consumer.local]
class-name="kafka"
cluster="local"
servers=[ "localhost:9092" ]
client-profile="local"
group-denylist="^(console-consumer-|python-kafka-consumer-|quick-).*$"
group-allowlist=""

[httpserver.default]
address=":8000"

[storage.default]
class-name="inmemory"
workers=20
intervals=15
expire-group=604800
min-distance=1

설정값들에 대한 정리는 여기 정리가 되어 있다.

https://gunju-ko.github.io/kafka/2018/06/06/Burrow.html

 

Monitoring Consumer LAG - Burrow

Burrow Burrow - Kafka Consumer Lag Checking Burrow는 카프카의 모니터링 툴로 Consumer의 LAG을 모니터링할 때 주로 사용된다. 모든 Consumer의 커밋 오프셋을 모니터링한다. 또한 필요할 때 Consumer의 상태를 계산

gunju-ko.github.io

 

실행

git clone 받은 repo로 이동 후 아래와 같이 Burrow.exe 파일로 수정한 config 파일을 읽어 실행하면 된다.

$ /Users/사용자명/bin/Burrow --config-dir=/config

 

서비스 확인은 

localhost:8000/burrow/admin 을 띄우면 GOOD 이 뜬다.

 

엔드포인트 정리된 문서는

https://github.com/linkedin/Burrow/wiki/HTTP-Endpoint

 

GitHub - linkedin/Burrow: Kafka Consumer Lag Checking

Kafka Consumer Lag Checking. Contribute to linkedin/Burrow development by creating an account on GitHub.

github.com

 

반응형

'인프라 > 모니터링' 카테고리의 다른 글

spring cloud resilience4j 모니터링  (0) 2022.11.03
[ELK] logstash 설치 및 실행하기  (0) 2022.07.13
telegraf 시작하기  (0) 2022.01.04
ZIPKIN 시작하기  (0) 2021.11.25
프로메테우스 Prometheus 시작하기(docker)  (0) 2021.11.04
반응형

Zipkin 설치방법 1(Jar 파일 실행)

curl -sSL https://zipkin.io/quickstart.sh | bash -s
java -jar zipkin.jar

Zipkin Elasitc 저장소로 실행

java -jar zipkin.jar --STORAGE_TYPE=elasticsearch --ES_HOSTS=http://127.0.0.1:9200

 

Zipkin 설치방법 2(도커 이미지 실행)

docker run -d -p 9411:9411 openzipkin/zipkin

docker-compose.yml

version: "3.3" # 파일 규격 버전
services: # 이 항목 밑에 실행하려는 컨테이너 들을 정의

  zipkin:
    image: openzipkin/zipkin
    container_name: zipkin
    # environment:
    #   - STORAGE_TYPE=elasticsearch
    #   - ES_HOSTS=localhost:9200 ## 도커로 엘라스틱 저장소 연결하는거는 다음처럼 했을때 안됐음.
    ports:
      - "9411:9411"

Zipkin 설치방법 3(zipkin-server 용 어플리케이션 생성)

@EnableZipkinServer 추가

 

 

위와 같은 준비가 끝났으면 spring 에서는 

spring cloud slueth 연동

 

<dependency>
	<groupId>org.springframework.cloud</groupId>
	<artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
<dependency>
	<groupId>org.springframework.cloud</groupId>
	<artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>
spring:
  application:
    name: zipkin-client
  sleuth:
    sampler:
      probability: 1.0
  zipkin:
    base-url: http://localhost:9411

 

 

Zipkin 구조도

Zipkin은 크게 Zipkin Client Library와 Zipkin Server로 구성되며, Zipkin Server는 Collector, Storage, API(Query Service), Web UI(Dashboard)로 구성된다.

 

1. Zipkin Client Library : 서비스에서 트레이스 정보를 수집하여 Zipkin Server의 Collector 모듈로 전송하며, 지원하는 언어는 Java, Javascript, Go, C# 등이 있다. Collector로 전송할 때는 다양한 프로토콜을 사용할 수 있지만 일반적으로 HTTP를 사용하고, 시스템이 클 경우 Kafka 큐를 통해서도 전송을 한다.

2. Collector : Zipkin Client Library로부터 전달된 트레이스 정보 유효성을 검증하고 검색 가능하게 저장 및 색인화 한다. 

3. Storage : Zkipkin Collector로 보내진 트레이스 정보는 Storage에 저장된다. Zipkin은 초창기에는 Cassandra에 데이터를 저장하도록 만들어졌지만(Cassandra가 확장 가능하고 유연한 스키마를 가지고 있기 때문에 Twitter 내에서 많이 사용되었음), 그 뒤로 ElasticSearch나 MySQL도 지원 가능하게 구성되었다. 그 외에 In-Memory도 지원 가능하기 때문에 간단히 로컬에서 테스트할 때는 In-Memory, 소규모는 MySQL, 운영환경에 적용은 Cassandra나 ElasticSearch를 저장소로 사용하는 것이 좋다. 

4. API(Zipkin Query Service) : 저장되고 색인화된 트레이스 정보를 검색하기 위한 JSON API이며, 주로 Web UI에서 호출된다.

5. Web UI : 수집된 트레이스 정보를 확인할 수 있는 GUI로 만들어진 대쉬보드이며, 서비스 / 시간 / 어노테이션 기반으로 데이터 확인이 가능하다. Zipkin 서버의 대쉬보드를 사용할 수도 있고, ElasticSearch 백앤드를 이용한 경우는 Kibana 활용도 가능하다.

 

 

Spring Cloud Sleuth란?

MSA환경에서 클라이언트의 호출은 내부적으로 여러 마이크로서비스를 거쳐서 일어나기 때문에 추적이 어렵다. 때문에 이를 추적하기 위해서는 연관된 ID가 필요한데, 이런 ID를 자동으로 생성해주는 것이 Spring Cloud Sleuth이다.

Spring Cloud Sleuth는 Spring에서 공식적으로 지원하는 Zipkin Client Library로 Spring과의 연동이 매우 쉬우며, 호출되는 서비스에 Trace(추적) ID와 Span(구간) ID를 부여한다. Trace ID는 클라이언트 호출의 시작부터 끝날때까지 동일한 ID로 처리되며, Span ID는 마이크로서비스당 1개의 ID가 부여된다. 이 두 ID를 활용하면 클라이언트 호출을 쉽게 추적할 수 있다.


Zipkin 헤더

Zipkin은 B3-Propagation을 통해서 OpenTracing을 구현하고 있습니다. B3 propagation은 간단히 말해 ‘X-B3-‘으로 시작하는 X-B3-TraceId와 X-B3-ParentSpanId, X-B3-SpanId, X-B3-Sampled, 이 4개 값을 전달하는 것을 통해서 트레이스 정보를 관리합니다. 서버에서는 이 값들을 TraceContext에서 관리하는데요. Spring 프레임워크와 SLF4J(Simple Logging Facade for Java)를 사용하고 있었기에 MDC(Mapped Diagnostic Context)에서 해당 값을 꺼내서 사용할 수 있었습니다. HTTP를 통해 다른 서버로 전달하는 경우에는 HTTP 헤더를 통해서 전달하고, Kafka 메시지를 통해 전달하는 경우에는 Kafka 헤더를 통해서 전달합니다.

 

Spring cloud sleuth

Zipkin의 Brave는 B3-propagation의 Java 구현체이고, Spring Cloud Sleuth는 BraveTracer를 Spring 프레임워크에서 쉽게 사용하기 위한 라이브러리입니다. TaskExecutor와 RestTemplate, KafkaTemplate, KafkaListener, RedisTemplate을 사용하는 것만으로 새로운 스팬(span)이 생성됩니다. 다만, BeanPostProcessor를 통해서 동작하기 때문에 아래와 같이 메서드 내부에서 생성된 오브젝트를 사용하는 경우에는 동작하지 않는다.

 

TaskExecutor executor = new TaskExecutor();
-> 
@Bean

 

public TaskExecutor taskExecutor() { return new TaskExecutor();}
반응형

'인프라 > 모니터링' 카테고리의 다른 글

spring cloud resilience4j 모니터링  (0) 2022.11.03
[ELK] logstash 설치 및 실행하기  (0) 2022.07.13
telegraf 시작하기  (0) 2022.01.04
Burrow 시작하기  (0) 2021.12.30
프로메테우스 Prometheus 시작하기(docker)  (0) 2021.11.04
반응형

프로메테우스란 - prometheus 란

오픈소스 모니터링 툴로 지표 수집을 통한 모니터링이 주요 기능이다. 쿠버네티스 뿐만 아니라 애플리케이션이나 서버, OS등 다양한 대상으로부터 지표(Metric)를 수집하여 모니터링 할 수 있다. 기본적으로 Pull 방식으로 데이터를 수집하는데, 이 말은 모니터링 대상이 되는 자원이 지표정보를 프로메테우스로 보내는 것이 아니라, 프로메테우스가 주기적으로 모니터링 대상에서 지표를 읽어온다는 뜻이다(Push 방식으로 지표를 수집하는 모니터링 툴은 ELK스택 또는 Telegraf & InfluxDB 등이 있다). Pull 방식으로 지표정보를 읽어올때는 각 서버에 설치된 Exporter를 통해서 정보를 읽어오며, 배치나 스케쥴 작업의 경우에는 필요한 경우에만 떠 있다가 작업이 끝나면 사라지기 때문에 Pull 방식으로 데이터 수집이 어렵다. 그럴 경우 Push방식을 사용하는 Push gateway를 통해 지표정보를 받아오는 경우도 있다. 서버의 갯수가 정해져 있다면 프로메테우스에서 모니터링 대상을 관리하는데 어려움이 없지만, 오토스케일링이 많이 사용되는 클라우드 환경이나 쿠버네티스 클러스터에서는 모니터링 대상의 IP가 동적으로 변경되기 때문에 이를 일일이 설정파일에 넣는데 한계가 있다. 이러한 문제를 해결하기 위해 프로메테우스는 DNS나 Consul, etcd와 같은 다양한 서비스 디스커버리 서비스와 연동을 통해 모니터링 목록을 가지고 모니터링을 수행한다.

 

 

version: "3.3" # 파일 규격 버전
services: # 이 항목 밑에 실행하려는 컨테이너 들을 정의
  prometheus: # 서비스 명
    image: prom/prometheus      # 사용할 이미지
      # restart: always
    container_name: prometheus # 컨테이너 이름 설정
    ports:
      - "9090:9090" # 접근 포트 설정 (컨테이너 외부:컨테이너 내부)
    volumes:
      - /Users/폴더명/docker_voluems/prometheus/data/prometheus:/prometheus
    command: --web.enable-lifecycle --config.file=/etc/prometheus/prometheus.yml

 

프로메테우스 설정

프로메테우스 도커 접속

docker exec -it 도커명 /bin/sh

프로메테우스 내부 prometheus.yml 설정

# my global config
global:
  scrape_interval:     15s # Set the scrape interval to every 15 seconds. Def
  evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is
  # scrape_timeout is set to the global default (10s).

# Alertmanager configuration
alerting:
  alertmanagers:
  - static_configs:
    - targets:
      # - alertmanager:9093

# Load rules once and periodically evaluate them according to the global 'eva
rule_files:
  # - "first_rules.yml"
  # - "second_rules.yml"

# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
  # The job name is added as a label `job=<job_name>` to any timeseries scrap
  - job_name: 'spring-boot-app'
    metrics_path: '/actuator/prometheus'
    # metrics_path defaults to '/metrics'
    # scheme defaults to 'http'.

    static_configs:
    - targets: ['host.docker.internal:8080']

  - job_name: 'spring-boot-app'
    metrics_path: '/actuator/prometheus' 
이부분은 스프링 actuator 과 연동시킬때 사용.

scrape_configs 는 데이터를 수집할 곳의 job 정보를 작성.

위의 예시는 내부에서 사용하는 8080 포트로 시작하는 spring boot 의 정보를 스크랩한다. 

도커로 프로메테우스를 실행하고 내부 localhost 라면 tarets 을 host.docker.internal 로 설정해야 함.

 

Configuration prometheus.yml 기본 spring boot 와 설정.

targets에 모니터링할 Spring Boot 애플리케이션 IP:Port 추가
Service Discovery를 사용한다면 관련 Service Discovery 설정 추가

global:
  scrape_interval: "15s"
  evaluation_interval: "15s"
scrape_configs:
- job_name: "springboot"
  metrics_path: "/actuator/prometheus"
  static_configs:
  - targets:
    - "<my_spring_boot_app_ip>:<port>"
- job_name: "prometheus"
  static_configs:
  - targets:
    - "localhost:9090"

 

그라파나

바로 promethus 로 실행해서 모니터링 하기 보기가 어렵다.

version: "3.3" # 파일 규격 버전
services: # 이 항목 밑에 실행하려는 컨테이너 들을 정의
  grafana: # 서비스 명
    image: grafana/grafana    # 사용할 이미지\
    # restart: always
    container_name: grafana # 컨테이너 이름 설정
    ports:
      - "3000:3000" # 접근 포트 설정 (컨테이너 외부:컨테이너 내부)
    environment: # -e 옵션
      GF_SECURITY_ADMIN_PASSWORD: secret
    volumes:
      - /Users/폴더명/docker_voluems/grafana/grafana-storage:/var/lib/grafana

Install and Run

  • 기본 포트: 3000
  • 기본 계정 ID/PW: admin/admin
  • GF_SECURITY_ADMIN_PASSWORD 옵션으로 admin 패스워드 변경 가능

 

반응형

'인프라 > 모니터링' 카테고리의 다른 글

spring cloud resilience4j 모니터링  (0) 2022.11.03
[ELK] logstash 설치 및 실행하기  (0) 2022.07.13
telegraf 시작하기  (0) 2022.01.04
Burrow 시작하기  (0) 2021.12.30
ZIPKIN 시작하기  (0) 2021.11.25

+ Recent posts