0부터 1까지 Guance를 활용한 Springcloud 서비스의 관측 가능성 구축¶

본 프로젝트 비즈니스 시스템 개요:¶

본 사례는 기업 내부에서 사용하는 사무용 시스템을 시뮬레이션하며, 0부터 1까지 Guance를 활용하여 시스템의 관측 가능성을 구축합니다.

이번 관측 가능성 구축은 단일 JAR 패키지 버전 애플리케이션을 선택했습니다.

프로젝트 오픈소스 주소: https://gitee.com/y_project/RuoYi-Cloud

프로젝트 데모 주소: http://demo.ruoyi.vip/login

시스템 소개:

이 시스템은 오픈소스 백엔드 관리 시스템으로, 동시에 Java EE 엔터프라이즈 급 빠른 개발 플랫폼이며, 다양한 고전적인 기술 조합(Spring Boot, Apache Shiro, MyBatis, Thymeleaf, Bootstrap 등)을 기반으로 합니다. 부서 관리, 역할 및 사용자, 메뉴 및 버튼 권한, 데이터 권한, 시스템 파라미터, 로그 관리, 공지사항 등 많은 내장 모듈을 갖추고 있어, 개발자가 비즈니스에 집중하고 기술적 난이도를 낮추어 인건비를 절감하며 프로젝트 기간을 단축하고 소프트웨어 보안 품질을 향상시키는 것을 주요 목표로 합니다. 이 프로젝트는 웹 애플리케이션(예: 웹사이트 관리 백엔드, 웹사이트 회원 센터, CMS, CRM, OA 등)에 모두 사용할 수 있으며, 동시에 사용자 정의 심층 커스터마이징을 지원하여 기업이 더 강력한 시스템을 만들 수 있습니다. 모든 프론트엔드 및 백엔드 코드는 캡슐화되어 매우 간결하고 사용하기 쉬우며 오류 발생률이 낮습니다. 또한 모바일 클라이언트 접근을 지원합니다.

프로젝트 기능 모듈:

• 사용자 관리: 사용자는 시스템 운영자이며, 이 기능은 주로 시스템 사용자 구성을 수행합니다.
• 부서 관리: 시스템 조직 구조(회사, 부서, 팀)를 구성하며, 트리 구조로 표시되어 데이터 권한을 지원합니다.
• 직무 관리: 시스템 사용자가 소속된 직무를 구성합니다.
• 메뉴 관리: 시스템 메뉴, 운영 권한, 버튼 권한 식별자 등을 구성합니다.
• 역할 관리: 역할 메뉴 권한 할당, 역할별 기관에 따른 데이터 범위 권한 구분을 설정합니다.
• 사전 관리: 시스템에서 자주 사용되는 비교적 고정적인 데이터를 유지 관리합니다.
• 파라미터 관리: 시스템 동적 구성에 사용되는 일반 파라미터를 관리합니다.
• 공지사항: 시스템 공지사항 정보를 게시 및 유지 관리합니다.
• 운영 로그: 시스템 정상 운영 로그 기록 및 조회, 시스템 예외 정보 로그 기록 및 조회.
• 로그인 로그: 시스템 로그인 로그 기록 및 조회에는 로그인 예외가 포함됩니다.
• 온라인 사용자: 현재 시스템의 활성 사용자 상태를 모니터링합니다.
• 예약 작업: 온라인 작업 스케줄러(추가, 수정, 삭제) 및 실행 결과 로그를 포함합니다.
• 코드 생성: 프론트엔드 및 백엔드 코드 생성(java, html, xml, sql) 및 CRUD 다운로드를 지원합니다.
• 시스템 인터페이스: 비즈니스 코드를 기반으로 관련 API 인터페이스 문서를 자동으로 생성합니다.
• 서비스 모니터링: 현재 시스템의 CPU, 메모리, 디스크, 스택 등 관련 정보를 모니터링합니다.
• 캐시 모니터링: 시스템 캐시 조회, 보기, 정리 등 작업을 수행합니다.
• 온라인 빌더: 폼 요소를 드래그하여 해당 HTML 코드를 생성합니다.

사무 시스템에 사용된 기술 스택:

사무 시스템 아키텍처:

• 웹 페이지: Nginx에 배치
• 레지스트리: Nacos
• 게이트웨이: Gateway
• 서비스 모듈: Auth, System
• 데이터베이스: Mysql
• 캐시: Redis

참고: 이 데모는 모든 서비스 모듈을 동일한 서버에 배포하고, 서로 다른 포트를 사용하여 서비스에 접근합니다.

Guance 소개:¶

소개: [Guance 공식 소개]

Guance는 클라우드 컴퓨팅 및 클라우드 네이티브 시대에 시스템이 모든 완전한 애플리케이션을 위해 전체 링크의 관측 가능성을 구축할 수 있도록 설계된 클라우드 서비스 플랫폼으로, 기존의 모니터링 시스템과는 근본적인 차이가 있습니다.

기존 모니터링 시스템은 종종 단일 영역의 모니터링 시스템으로, 마치 기업 내부에 구축된 많은 굴뚝(예: APM(애플리케이션 성능 모니터링), RUM(실제 사용자 모니터링), 로그, NPM, zabbix 등)과 같습니다. 이는 애플리케이션, 로그, 인프라 등 각각 단일하고 분리된 모니터링 체계이며, 굴뚝이 즐비하게 서 있는 현상이 나타납니다. 또한 모니터링 시스템의 분리는 모니터링 데이터의 분리로 이어져 기업 내부에 데이터 사일로를 만듭니다. 기업 내부에서 문제를 해결할 때는 일반적으로 부서 간, 플랫폼 간에 많은 인력과 자원을 투입하여 이상을 찾아야 합니다.

관측 가능성의 개념은 완전한 체계를 통해 비즈니스 시스템을 호스팅하는 IT 체계를 관측 가능하게 만드는 것입니다. 이는 메트릭, 로그, 분산 추적의 세 가지 주요 구성 요소를 포함하며, 통합 데이터 수집, 통합 저장, 통합 쿼리, 통합 표시를 실현하고 메트릭, 분산 추적, 로그의 모든 관측 가능한 데이터를 연결하여 IT 체계의 완전한 관측 가능성을 구현합니다.

Guance는 이 개념을 기반으로 개발된 관측 가능성 솔루션으로, 기업 내부 IT 서비스 품질을 향상시키고 최종 사용자 경험을 개선하는 데 전념합니다.

Guance 데이터 흐름:

참고: DQL은 Dataflux가 특별히 개발한 QL 언어로, ES 및 InfluxDB의 데이터를 연결하여 쿼리하는 데 사용됩니다.

Datakit 설치:¶

1. console.guance.com에 로그인합니다.

2. 새 워크스페이스를 생성합니다.

3. 통합 페이지에서 datakit을 선택하고, 자신의 환경에 맞는 설치 명령어를 선택하여 복사합니다.

4. 서버에 datakit을 설치합니다.

5. service datakit status (또는 systemctl status datakit)를 실행하여 datakit 상태를 확인합니다.

Datakit 설치 후, 기본적으로 다음 항목을 수집하며, Dataflux - 인프라 - 호스트에서 관련 데이터를 직접 확인할 수 있습니다.

다른 통합 inputs 이름을 선택하면 해당 모니터링 뷰를 확인할 수 있으며, 모니터링 뷰 아래에서 로그, 프로세스, 컨테이너 등 다른 데이터도 확인할 수 있습니다.

특정 inputs 활성화:¶

참고:

Nginx:¶

자세한 단계는 문서 <Nginx 관측 가능성 모범 사례>를 참조하세요.
전제 조건: 먼저 nginx의 http_stub_status_module 모듈이 활성화되어 있는지 확인해야 합니다. 이미 모듈이 설치되어 있는 경우 1단계를 건너뛰십시오.

1. with-http_stub_status_module 모듈 설치(linux):
   이 모듈을 활성화하려면 nginx를 다시 컴파일해야 합니다. 구체적인 명령은 다음과 같습니다.
   ./configure --with-http_stub_status_module
   configure 파일 위치 확인 방법:
   find /| grep configure |grep nginx

$ find /| grep configure |grep nginx

$ cd /usr/local/src/nginx-1.20.0/
$ ./configure --with-http_stub_status_module

1. Nginx.conf에 nginx_status의 location 전달 추가

$ cd /etc/nginx   
   ## nginx 경로는 실제 상황에 따라 다름
$ vim nginx.conf

$  server{
     listen 80;   
     server_name localhost;
     ## 포트는 사용자 정의 가능

      location /nginx_status {
          stub_status  on;
          allow 127.0.0.1;
          deny all;
                             }

          }

1. Datakit에서 nginx의 inputs 수정

$ cd /usr/local/datakit/conf.d/nginx/
$ cp nginx.conf.sample nginx.conf
$ vim  nginx.conf

#다음 내용 수정
[[inputs.nginx]]
        url = http://localhost/nginx_status
[inputs.nginx.log]
        files = ["/var/log/nginx/access.log","/var/log/nginx /error.log"]

#파일 저장 후 datakit 재시작    
$ service datakit restart

데이터 확인: curl 127.0.0.1/nginx_status

1. Guance 플랫폼에서 Nginx 뷰 생성 및 데이터 확인 생성 단계는 [시나리오 및 뷰 생성]을 참조하세요.** 단계: 시나리오 -> 새 시나리오 -> 새 빈 시나리오 -> 시스템 뷰 (Nginx 생성) 뷰 예시 (이 뷰를 통해 Nginx 관련 지표 및 로그 정보를 빠르게 확인하여 Nginx의 상태를 판단할 수 있음):

Mysql:¶

자세한 단계는 문서 <Mysql DataKit 연동>를 참조하세요.

# mysql 로그인 
$ mysql -uroot -p  
# 비밀번호 입력: Solution****

# 모니터링 계정 생성
$ CREATE USER 'datakit'@'localhost' IDENTIFIED BY 'Datakit_1234';

# 모니터링 계정 권한 부여
$ grant process,select,replication client on *.* to 'datakit'@'%' identified by 'Datakit_1234';

# 권한 새로고침
flush privileges;

1. Datakit에서 mysql의 inputs 수정¶

$ cd /usr/local/datakit/conf.d/db/
$ cp mysql.conf.sample mysql.conf
$ vim mysql.conf

# 다음 내용 수정 
## mysql 읽기 전용 계정을 생성하여 사용하는 것을 권장합니다.
[[inputs.mysql]]
     user ="datakit"
     pass ="Datakit_1234“

#파일 저장 후 datakit 재시작    
$ service datakit restart

2. Guance 플랫폼에서 Mysql 뷰 생성 및 데이터 확인¶

생성 단계는 [시나리오 및 뷰 생성]을 참조하세요.** 단계: 시나리오 -> 새 시나리오 -> 새 빈 시나리오 -> 시스템 뷰 (Mysql 생성) 뷰 예시 (이 뷰를 통해 Mysql 관련 지표 및 로그 정보를 빠르게 확인하여 Mysql의 상태를 판단할 수 있음):

Redis:¶

자세한 단계는 문서 <Redis DataKit 연동>를 참조하세요.

1. Datakit에서 redis의 inputs 수정¶

$ cd /usr/local/datakit/conf.d/db/
$ cp redis.conf.sample redis.conf
$ vim redis.conf

#다음 내용 수정
## redis 읽기 전용 계정을 생성하여 사용하는 것을 권장합니다.
[[inputs.redis]]
     pass ="Solution******“
#pass 앞의 주석 문자 #을 해제해야 합니다.
[inputs.redis.log]
    files = ["/var/log/redis/redis.log"]

#파일 저장 후 datakit 재시작    
$ service datakit restart

2. Guance 플랫폼에서 Redis 뷰 생성 및 데이터 확인¶

생성 단계는 [시나리오 및 뷰 생성]을 참조하세요.** 단계: 시나리오 -> 새 시나리오 -> 새 빈 시나리오 -> 시스템 뷰 (Redis 생성) 뷰 예시 (이 뷰를 통해 Redis 관련 지표 및 로그 정보를 빠르게 확인하여 Redis의 상태를 판단할 수 있음):

JVM:¶

자세한 단계는 문서 <jvm DataKit 연동>를 참조하세요.

1. Datakit에서 jvm의 inputs 수정¶

jvm의 inputs는 기본적으로 수정할 필요가 없으며, conf 파일을 복사하여 생성하기만 하면 됩니다.

$ cd /usr/local/datakit/conf.d/statsd/
$ cp statsd.conf.sample ddtrace-jvm-statsd.conf 
$ vim ddtrace-jvm-statsd.conf

# 기본적으로 수정 불필요

2. Java 애플리케이션 시작 스크립트 수정¶

### JVM과 APM(애플리케이션 성능 모니터링)은 모두 ddtrace-agent를 통해 데이터를 수집하므로, 애플리케이션 시작 스크립트는 APM(애플리케이션 성능 모니터링) 관련 내용 [APM(애플리케이션 성능 모니터링)]을 참조하세요. ###

3. Guance 플랫폼에서 JVM 뷰 생성 및 데이터 확인¶

생성 단계는 [시나리오 및 뷰 생성]을 참조하세요.** 단계: 시나리오 -> 새 시나리오 -> 새 빈 시나리오 -> 시스템 뷰 (JVM 생성) 뷰 예시 (이 뷰를 통해 JVM 관련 지표 및 로그 정보를 빠르게 확인하여 JVM의 상태를 판단할 수 있음):

APM(애플리케이션 성능 모니터링):¶

자세한 단계는 문서 분산 추적(APM(애플리케이션 성능 모니터링)) 모범 사례를 참조하세요. Guance 지원하는 APM(애플리케이션 성능 모니터링) 연동 방식은 ddtrace, skywalking, zipkin, jaeger 등 다양한 opentracing 프로토콜을 지원하는 APM(애플리케이션 성능 모니터링) 도구를 포함하며, 여기서는 ddtrace를 사용하여 APM(애플리케이션 성능 모니터링) 측면의 관측 가능성을 구현하는 예시를 보여줍니다.

1. Datakit에서 APM(애플리케이션 성능 모니터링)(ddtrace)의 inputs 수정¶

jvm의 inputs는 기본적으로 수정할 필요가 없으며, conf 파일을 복사하여 생성하기만 하면 됩니다.

$ cd /usr/local/datakit/conf.d/ddtrace/
$ cp ddtrace.conf.sample ddtrace.conf
$ vim ddtrace.conf

# 기본적으로 수정 불필요

2. Java 애플리케이션 시작 스크립트 수정¶

APM(애플리케이션 성능 모니터링) 관측 가능성을 위해 Java 애플리케이션에 에이전트를 추가해야 합니다. 이 에이전트는 애플리케이션 시작 시 바이트코드 인젝션 기술을 통해 애플리케이션 내부 메서드 호출, SQL 호출, 외부 시스템 호출 등 관련 성능 데이터를 수집하여 애플리케이션 시스템 코드 품질에 대한 관측 가능성을 구현합니다.

#원본 애플리케이션 시작 스크립트
$ cd /usr/local/ruoyi/
$ nohup java -Dfile.encoding=utf-8   -jar ruoyi-gateway.jar > logs/gateway.log  2>&1 & 
$ nohup java -Dfile.encoding=utf-8   -jar ruoyi-auth.jar > logs/auth.log  2>&1 & 
$ nohup java -Dfile.encoding=utf-8   -jar ruoyi-modules-system.jar > logs/system.log  2>&1 &

기존 애플리케이션 시작 프로세스를 종료하고, ddtrace 파라미터를 추가한 후 애플리케이션을 재시작해야 합니다. 구체적인 종료 방법은 아래 그림을 참조하세요.

#ddtrace-agent 추가 후 애플리케이션 시작 스크립트

$ cd /usr/local/ruoyi/

$ nohup java -Dfile.encoding=utf-8 -javaagent:dd-java-agent-0.80.0.jar -XX:FlightRecorderOptions=stackdepth=256 -Ddd.logs.injection=true -Ddd.service.name=ruoyi-gateway -Ddd.service.mapping=redis:redis_ruoyi -Ddd.agent.port=9529 -Ddd.jmxfetch.enabled=true -Ddd.jmxfetch.check-period=1000  -Ddd.jmxfetch.statsd.port=8125 -Ddd.version=1.0 -jar ruoyi-gateway.jar > logs/gateway.log  2>&1 &

$ nohup java -Dfile.encoding=utf-8 -javaagent:dd-java-agent-0.80.0.jar  -XX:FlightRecorderOptions=stackdepth=256 -Ddd.logs.injection=true -Ddd.service.name=ruoyi-auth -Ddd.service.mapping=redis:redis_ruoyi -Ddd.env=staging -Ddd.agent.port=9529 -Ddd.jmxfetch.enabled=true -Ddd.jmxfetch.check-period=1000 -Ddd.jmxfetch.statsd.port=8125 -Ddd.version=1.0 -jar ruoyi-auth.jar > logs/auth.log  2>&1 & 

$ nohup java -Dfile.encoding=utf-8 -javaagent:dd-java-agent-0.80.0.jar -XX:FlightRecorderOptions=stackdepth=256 -Ddd.logs.injection=true -Ddd.service.name=ruoyi-modules-system -Ddd.service.mapping=redis:redis_ruoyi,mysql:mysql_ruoyi -Ddd.env=dev -Ddd.agent.port=9529 -Ddd.jmxfetch.enabled=true -Ddd.jmxfetch.check-period=1000 -Ddd.jmxfetch.statsd.port=8125 -Ddd.version=1.0 -jar ruoyi-modules-system.jar > logs/system.log  2>&1 & 

! Guance 플랫폼에서 APM(애플리케이션 성능 모니터링) 관련 데이터가 보이지 않으면 datakit 로그를 확인하세요. cat /var/log/datakit/gin.log 정상 로그:

오류 로그:

이러한 오류는 /usr/local/datakit/con.d/ddtrace/ddtrace.conf 를 아래 그림과 같이 수정해야 합니다. ddtrace.conf 설정의 path 경로가 datakit/gin.log 로그의 경로와 일치하는지 확인하세요.

ddtrace 관련 환경 변수(시작 파라미터) 설명:

• Ddd.env: 사용자 정의 환경 유형, 선택 사항입니다.
• Ddd.tags: 사용자 정의 애플리케이션 태그, 선택 사항입니다.
• Ddd.service.name: 사용자 정의 애플리케이션 이름, 필수 항목입니다.
• Ddd.agent.port: 데이터 업로드 포트(기본값 9529), 필수 항목입니다.
• Ddd.version: 애플리케이션 버전, 선택 사항입니다.
• Ddd.trace.sample.rate: 샘플링 비율 설정(기본값은 전체 샘플링), 선택 사항입니다. 샘플링이 필요한 경우 0~1 사이의 값(예: 0.6, 즉 60% 샘플링)을 설정할 수 있습니다.
• Ddd.service.mapping: 현재 애플리케이션이 호출하는 redis, mysql 등에 이 파라미터를 통해 별칭을 추가하여 다른 애플리케이션이 호출하는 redis, mysql과 구분할 수 있습니다. 선택 사항입니다. 사용 사례: 예를 들어 프로젝트 A와 프로젝트 B가 모두 mysql을 호출하고 각각 mysql-a, mysql-b를 호출하는 경우, mapping 설정 항목을 추가하지 않으면 Guance 플랫폼에 프로젝트 A와 프로젝트 B가 동일한 이름의 mysql 데이터베이스를 호출한 것으로 표시됩니다. mapping 설정 항목을 추가하여 mysql-a, mysql-b로 구성하면 Guance 플랫폼에 프로젝트 A가 mysql-a를 호출하고 프로젝트 B가 mysql-b를 호출한 것으로 표시됩니다.
• Ddd.agent.host: 데이터 전송 대상 IP, 기본값은 localhost, 선택 사항입니다.

3. Guance 플랫폼에서 APM(애플리케이션 성능 모니터링) 데이터 확인¶

APM(애플리케이션 성능 모니터링)은 Guance의 기본 내장 모듈이므로 시나리오나 뷰를 생성하지 않고도 확인할 수 있습니다. 경로: Guance 플랫폼 -> 애플리케이션 성능 모니터링(APM) 뷰 예시: (이 뷰를 통해 애플리케이션 호출 상황, 토폴로지 뷰, 이상 데이터 등 기타 APM(애플리케이션 성능 모니터링) 관련 데이터를 빠르게 확인할 수 있습니다.)

RUM(실제 사용자 모니터링):¶

자세한 단계는 문서 [사용자 접근(RUM(실제 사용자 모니터링)) 관측 가능성 모범 사례]를 참조하세요.

1. Dataflux 플랫폼에 로그인¶

2. 사용자 접근 모니터링(RUM) 선택 -> 새 애플리케이션 -> 웹 유형 선택 -> 동시 로드¶

3. 프론트엔드 페이지 index.html에 Guance RUM(실제 사용자 모니터링) 관측 가능성 js 파일 연동¶

$ cd /usr/local/ruoyi/dist/

// 백업을 잊지 마세요.
$ cp index.html index.html.bkd

// index.html에 df-js 추가
// DF 플랫폼의 js 내용을 복사하여 index.html의 </head> 앞에 붙여넣고 파일을 저장합니다. 예시는 다음과 같습니다.

$ vim index.html

<script src="https://static.guance.com/browser-sdk/v2/dataflux-rum.js" type="text/javascript"></script>
<script>
  window.DATAFLUX_RUM &&
    window.DATAFLUX_RUM.init({
      applicationId: 'xxxxxxxxxxxxxxxxxxxxxxxxxx',
      datakitOrigin: 'xxx.xxx.xxx.xxx:9529',
      env: 'test',
      version: '1.0.0',
      trackInteractions: true,
      allowedTracingOrigins:["xxx.xxx.xxx.xxx"]
      })
</script></head> 

# xxx는 모두 실제 상황에 따라 변경해야 합니다. 자세한 변경 내용은 다음을 참조하세요.

datakitOrigin: datakit 주소(datakit이 설치된 서버의 IP 또는 도메인), Guance에서 RUM(실제 사용자 모니터링) 데이터 흐름은 rum.js 파일 -> datakit -> dataway -> Guance 플랫폼입니다. 프로덕션 환경인 경우 이 IP를 도메인 또는 SLB 주소로 설정해야 하며, 테스트 환경에서는 내부 IP를 입력해야 합니다. datakit 서버의 9529 포트에 해당합니다.

trackInteractions: 사용자 행동 수집 설정 항목으로, 페이지 수준의 사용자 작업 행동 통계를 구현할 수 있습니다.

allowedTracingOrigins: 프론트엔드와 백엔드(RUM(실제 사용자 모니터링)과 APM(애플리케이션 성능 모니터링))를 연결하는 설정 항목으로, 필요에 따라 설정할 수 있습니다. 프론트엔드 페이지와 상호 작용하는 백엔드 서버에 해당하는 도메인 또는 IP를 여기에 입력해야 합니다.

주의 사항:

• datakitOrigin: 데이터 전송 주소입니다. 프로덕션 환경에서 도메인으로 구성된 경우 도메인 요청을 datakit-9529 포트가 설치된 특정 서버로 전달할 수 있습니다. 프론트엔드 접근량이 너무 많으면 도메인과 datakit이 설치된 서버 사이에 SLB 계층을 추가할 수 있습니다. 프론트엔드 js는 SLB로 데이터를 보내고, SLB도 9529 포트를 열어야 합니다. SLB는 요청을 datakit-9529가 설치된 여러 서버로 전달합니다. 여러 datakit이 RUM(실제 사용자 모니터링) 데이터를 처리하며, 프론트엔드 요청 재사용으로 인해 세션 데이터가 중단되지 않고 RUM(실제 사용자 모니터링) 데이터 표시에도 영향을 미치지 않습니다.

예시:

• allowedTracingOrigins: 프론트엔드와 백엔드(APM(애플리케이션 성능 모니터링)과 RUM(실제 사용자 모니터링))를 연결합니다. 이 시나리오는 프론트엔드에 RUM(실제 사용자 모니터링)이 배포되고 백엔드에 APM(애플리케이션 성능 모니터링)이 배포된 경우에만 적용됩니다. 프론트엔드 페이지와 상호 작용하는 백엔드 애플리케이션 서버에 해당하는 도메인(프로덕션 환경) 또는 IP(테스트 환경)를 입력해야 합니다. 사용 사례: 프론트엔드 사용자 접근 속도 저하가 백엔드 코드 로직 이상으로 인해 발생하는 경우, 프론트엔드 RUM(실제 사용자 모니터링) 느린 요청 데이터에서 직접 APM(애플리케이션 성능 모니터링) 데이터로 이동하여 해당 백엔드 코드 호출 상황을 확인하고 느린 속도의 근본 원인을 파악할 수 있습니다. 구현 원리: 사용자가 프론트엔드 애플리케이션에 접근하면 프론트엔드 애플리케이션이 리소스 및 요청을 호출하고 rum-js 성능 데이터 수집을 트리거합니다. rum-js는 trace-id를 생성하여 요청의 request_header에 기록합니다. 요청이 백엔드에 도달하면 백엔드의 ddtrace가 이 trace_id를 읽어 자신의 trace 데이터에 기록하여 동일한 trace_id를 통해 애플리케이션 성능 모니터링(APM)과 실제 사용자 모니터링(RUM) 데이터를 연결합니다.
• env: 필수, 애플리케이션이 속한 환경(test, product 또는 기타 필드).
• version: 필수, 애플리케이션 버전 번호.
• trackInteractions: 사용자 행동 통계(예: 버튼 클릭, 정보 제출 등).

4. 페이지 저장, 확인 및 게시¶

브라우저를 열고 대상 페이지에 접근한 후, F12 개발자 도구를 통해 페이지 네트워크 요청에 rum 관련 요청이 있는지, 상태 코드가 200인지 확인합니다.

주의!! : F12 개발자 도구에서 데이터를 업로드할 수 없고 포트 refused가 표시되면 telnet IP:9529를 통해 포트가 열려 있는지 확인하십시오. 열려 있지 않은 경우 /usr/local/datakit/conf.d/datakit.conf를 수정하여 http_listen의 localhost를 0.0.0.0으로 변경해야 합니다.

5. 사용자 접근 모니터링(RUM)에서 rum 관련 데이터 확인¶

6. RUM(실제 사용자 모니터링)과 APM(애플리케이션 성능 모니터링) 데이터 연동 데모¶

구성 방법: [java 예시]

사용 사례: 프론트엔드와 백엔드 연결, 프론트엔드 요청과 백엔드 메서드 실행 성능 데이터를 일대일로 바인딩하여 프론트엔드와 백엔드 관련 문제를 더 쉽게 찾을 수 있습니다. 예를 들어 프론트엔드 사용자 접근 속도 저하가 백엔드 서비스 호출 이상으로 인한 경우, 팀과 부서를 넘어 신속하게 문제를 파악할 수 있습니다. 예시는 다음과 같습니다.

Security Checker(보안 점검):¶

Security Checker 소개: [Guance 공식 소개**]

참고: 현재 linux만 지원합니다. 자세한 단계는 문서 [Security Checker 설치 및 구성]를 참조하세요.

1. Security Checker 설치¶

##  설치
$ bash -c "$(curl https://static.guance.com/security-checker/install.sh)"
## 또는 다음 명령어 실행   sudo datakit --install scheck
## 업데이트
$ bash -c "$(curl https://static.guance.com/security-checker/install.sh) --upgrade"
## 시작/중지 명령어
$ systemctl start/stop/restart/status scheck
## 또는
$ service scheck start/stop/restart/status
## 설치 디렉터리  /usr/local/scheck

2. Security Checker를 Datakit에 연결¶

Security Checker 데이터를 datakit으로 전송한 후 dataflux 플랫폼으로 전달합니다.

$ cd /usr/local/scheck/
$ vim scheck.conf


    # ##(필수) 스크립트가 포함된 디렉터리
    rule_dir='/usr/local/scheck/rules.d'

    # ##(필수) 검사 결과 출력, 로컬 파일 또는 원격 http 서버 지원
    # ##로컬 파일: file:///your/file/path
    # ##원격:  http(s)://your.url
    output='http://127.0.0.1:9529/v1/write/security'


    # ##(선택 사항) 글로벌 cron, 기본값은 10초마다
    #cron='*/10 * * * *'

    log='/usr/local/scheck/log'
    log_level='info'
    #disable_log=false

3. Security Checker 관련 데이터 확인¶

로그:¶

자세한 단계는 문서 로그 수집을 참조하세요.

1. 표준 로그 수집 (Nginx, Mysql, Redis 등)¶

DataKit에 내장된 다양한 inputs을 활성화하여 관련 로그 수집을 직접 시작합니다. 예를 들어 Nginx, Redis, 컨테이너, ES 등이 있습니다.

예시: Nginx

$ cd /usr/local/datakit/conf.d/nginx/
$ cp nginx.conf.sample nginx.conf
$ vim nginx.conf

## log 경로를 올바른 nginx 경로로 수정
$ [inputs.nginx.log]
$     files = ["/usr/local/nginx/logs/access.log","/usr/local/nginx/logs/error.log"]
$     pipeline = "nginx.p"

## pipeline은 grok 문으로, 텍스트 로그를 파싱하는 데 사용됩니다. datakit은 nginx, mysql 등을 포함한 다양한 pipeline을 내장하고 있습니다. pipeline 기본 디렉터리는 /usr/local/datakit/pipeline/ 입니다. 여기서 pipeline 경로를 수정할 필요는 없으며, datakit이 기본적으로 자동으로 읽습니다.

뷰 표시:

2. 사용자 정의 로그 수집 (애플리케이션 로그, 비즈니스 로그 등)¶

예시: 애플리케이션 로그

pipeline (로그 grok 파싱) [Guance 공식 문서**]

$ cd /usr/local/datakit/conf.d/log/
$ cp logging.conf.sample logging.conf
$ vim logging.conf

## log 경로를 올바른 애플리케이션 로그 경로로 수정

## source와 service는 필수 필드이며, 애플리케이션 이름을 직접 사용하여 로그 이름을 구분할 수 있습니다.

$  [inputs.nginx.log]
$    logfiles = [
      "/usr/local/ruoyi/logs/ruoyi-system/error.log",
      "/usr/local/ruoyi/logs/ruoyi-system/info.log",]
$    source = "ruoyi-system"
$    service = "ruoyi-system"
#    pipeline = "ruoyi-system.p"

## pipeline은 grok 문으로, 텍스트 로그를 파싱하는 데 사용됩니다. 이 설정을 활성화하지 않으면 기본적으로 DF 플랫폼에 로그 원본 텍스트 내용이 표시됩니다. 입력하면 해당 로그에 대해 grok 파싱을 수행합니다. 여기에 입력하는 .p 파일은 직접 작성해야 합니다.

$ cd /usr/local/datakit/pipeline/
$ vim ruoyi_system.p

##예시:
#로그 스타일 
#2021-06-25 14:27:51.952 [http-nio-9201-exec-7] INFO  c.r.s.c.SysUserController - [list,70] ruoyi-08-system 5430221015886118174 6503455222153372731 - 사용자 조회

##예시 grok, 다음 내용을 ruoyi_system.p에 복사

grok(_, "%{TIMESTAMP_ISO8601:time} %{NOTSPACE:thread_name} %{LOGLEVEL:level} \\s+%{NOTSPACE:class_name} - \\[%{NOTSPACE:method_name},%{NUMBER:line}\\] %{DATA:service} %{DATA:trace_id} %{DATA:span_id} - %{GREEDYDATA:msg}")

default_time(time)

뷰 표시:

Nginx 로그 이상 탐지 생성:¶

1. Guance 플랫폼 열기 -> 이상 탐지 라이브러리 -> 새 탐지 라이브러리 -> 사용자 정의 모니터링

2. 새로 생성된 탐지 라이브러리 이름 클릭 -> 새 탐지 규칙 -> 새 로그 탐지

3. 구체적인 탐지 규칙 내용을 작성하고 저장합니다. 규칙 이름: Nginx 로그 ERROR 횟수 과다 이상 탐지 탐지 지표: 그림 참조 트리거 조건: Result >= 5 이벤트 이름: Nginx 로그 ERROR 횟수 과다 이상 알림 이벤트 내용:

   등급: {{status}} 호스트: {{host}} 내용: 로그 ERROR 횟수가 너무 많습니다. 오류 수는 {{ Result }}입니다. 제안: 로그 ERROR 횟수가 너무 많으면 애플리케이션에 이상이 있을 수 있습니다. 애플리케이션 상태를 확인하는 것이 좋습니다. 탐지 빈도: 1분

이상 탐지 메커니즘 확인:¶

1. 서버에서 ruoyi-gateway 관련 프로세스를 찾아 종료합니다. 2.

   $ ps -ef|grep ruoyi-gateway
   $ kill -9 xxxxx
   

1. ruoyi 웹사이트에 접근합니다 (여러 번 새로고침, 최소 5회 이상).

1. Guance 플랫폼 이벤트 관련 내용 확인

1. nginx 로그 관련 내용 및 관련 뷰 확인

inputs 활성화 과정 중 문제 해결 방법:¶

1. inputs 오류 정보 확인 Guance는 기본적으로 inputs의 상태 정보를 일정 빈도로 Guance 플랫폼에 업로드하므로, 인프라 -> 특정 호스트에서 통합 상황을 직접 확인할 수 있습니다. 예시: apache 서비스 다운, inputs 오류 표시

1. 데이터 업로드 정보 확인

방법 1: 브라우저 또는 콘솔에서 curl 127.0.0.1:9529/monitor 입력하여 확인 방법 2: 브라우저 또는 콘솔에서 curl 127.0.0.1:9529/stats 입력하여 확인

1. datakit 로그 확인

datakit 로그 디렉터리: cd /var/log/datakit

시나리오 및 뷰 생성:¶

시스템 뷰 템플릿을 사용하여 생성 (Nginx 예시)¶

1. 시나리오 -> 새 시나리오

1. 새 빈 시나리오

1. 시나리오 이름 입력 -> 확인

1. 시스템 뷰 -> Nginx 뷰 (생성)

1. Nginx 뷰 확인

1. 기타

다른 뷰 생성 방법도 유사합니다. 사용자 정의 뷰 내용 및 레이아웃이 필요한 경우 빈 뷰를 생성하여 직접 구성할 수 있습니다.

요약:¶

이로써 이번 데모 사무 시스템의 분산 추적, 지표, 로그, 인프라 등에 대한 전방위적인 관측 가능성을 구축했습니다.

전반적으로 Guance를 사용해 본 결과, 구성이 편리하고 관리가 용이하며, 통합된 조회 뷰를 제공합니다. 모든 지표, 분산 추적, 로그가 동일한 태그(host)를 통해 데이터를 연결하므로 플랫폼에서 쉽게 연계하여 IT 시스템 전체의 관측 가능성을 구현할 수 있습니다.

마지막으로 이상 탐지를 결합하면 시스템 통합 관리가 가능해져 운영 및 개발 효율성을 높이고 IT 의사 결정 능력을 향상시킬 수 있습니다!

이 제품은 계속해서 발전 중이며, 앞으로 기능이 더욱 강력해지고 사용하기 쉬워지며 UI도 더욱 아름다워질 것입니다.

Guance, 관측 가능성의 대변인이 되겠습니다!