Guance에서 TAG 모범 사례¶

이 문서는 기초적인 가이드로, 이를 바탕으로 창의력을 발휘하여 자신만의 TAG 활용 방법을 만들 수 있기를 바랍니다.

개요¶

Opentelemetry 프로토콜은 CNCF(Cloud Native Computing Foundation)가 정의한 최신 관측 가능성 표준(현재 인큐베이팅 단계)이며, 이 표준은 관측 가능성의 세 가지 기둥인 메트릭, 트레이스, 로그를 정의합니다. 그러나 이 세 가지 기둥의 데이터를 수집만 하고 연관시키지 않는다면, 소위 관측 가능성은 기존의 모니터링 도구(APM, 로그, Zabbix 등)와有何区别, 단순한 모니터링 도구 모음에 불과할 것입니다. 따라서 여기서 중요한 개념이 등장합니다: TAG(태그). 예를 들어 프론트엔드와 백엔드를 연결하는 traceID도 어느 정도 태그로 볼 수 있고, 메트릭, 트레이스, 로그를初步적으로 연결하는 host도 태그로 볼 수 있습니다. 그 외에도 프로젝트, 환경, 버전 번호 등 모두 태그입니다!
요약하면, TAG를 통해 데이터를 연관시키고 더 많은 사용자 정의 관측 가능성 활용이 가능하다는 점이 매우 중요합니다. Guance의 현재 아키텍처에서는 모든 관측 가능 항목이 태그 설정을 지원하며, 이론적으로 태그 수에는 제한이 없습니다.

예를 들어, 일상 생활에서 흔히 볼 수 있는 현상으로 구직 또는 HR 채용이 있습니다. 채용 공고에는 일반적으로 구체적인 요구 사항이 있습니다. 예: xx 직무, 프로그래밍 기술, 컴퓨터 지식, 학사 학위, n년 경력 등. 이러한 요구 사항은 각각 태그와 같습니다. 태그를 충족하는 사람만이 해당 직무를 얻을 가능성이 있습니다. IT 시스템에서도 마찬가지입니다. xx 서버에서 xx 애플리케이션, xx 데이터베이스, xx Nginx가 실행 중이고, 환경은 xx, 담당자는 xxx인 경우, 문제가 발생했을 때 태그가 충분히 많으면 어떤 서버에 문제가 있는지, 구체적으로 어떤 비즈니스와 애플리케이션 구성 요소가 영향을 받았는지, 누가 관련 구성 요소를 담당하고 있는지 빠르게 파악할 수 있습니다. 이를 통해 적절한 담당자를 신속하게 찾아 수정 및 복구를 진행하여 문제 해결 효율성을 높일 수 있습니다.

이 문서에서는 Guance을 사용하여 네 가지 예제를 통해 TAG의 확장성과 활용 가능성을 실험합니다.

실험 1: 서버 그룹화¶

배경: 기업 내부에는 종종 여러 프로젝트 팀 또는 사업부가 존재합니다. 서로 다른 프로젝트 팀이나 사업부는 자체 비즈니스 개발을 위해 전용 인프라를 사용하는 경우가 많습니다. 인프라에서 애플리케이션까지 Guance에 연결하여 관측 가능성을 확보한 경우, 워크스페이스를 분리하는 것 외에 프로젝트 리소스를 구분할 수 있는 다른 방법이 있을까요?
물론 있습니다. Guance은 설계 초기부터 이러한 상황을 고려했습니다. 기본 DataKit 메인 설정 파일에는 global_tag 태그가 있으며, 이 태그는 인프라 수준에서 태그를 설정합니다. 해당 인프라의 다른 구성 요소(예: 애플리케이션, 데이터베이스)는 기본적으로 이 태그를 상속합니다.

1. datakit-inputs 수정 및 global_tag 구성¶

$ vim /usr/local/datakit/conf.d/datakit.conf

# global_tags에 태그를 추가합니다. 기본 3개 외에도 다른 태그를 추가할 수 있습니다.

$ [global_tags]
$  cluster = ""
$  project = "solution"
$  site = ""

마찬가지로, 관련된 모든 호스트의 DataKit에 이 태그를 추가할 수 있습니다.

2. Guance - 서버 그룹 확인¶

실험 2: DataKit이 인식하는 hostname 변경¶

배경: DataKit은 기본적으로 호스트 수준의 hostname을 수집하여 인식된 hostname을 글로벌 태그로 사용하여 모든 메트릭, 트레이스, 로그, 객체 등의 데이터를 연관시킵니다. 그러나 많은 기업의 실제 환경에서 hostname은 규칙 없이 생성된 문자열로 실질적인 의미가 없습니다. 또한 hostname이 애플리케이션 연결이나 데이터베이스 관리 등 다른 용도로 사용될 수 있기 때문에 기업 내부에서는 hostname을 변경(인식 가능한 문자열로 변경)할 때 발생할 수 있는 위험을 평가하기 어려워 변경을 꺼립니다. 이러한 위험을 방지하기 위해 DataKit에 내장된 ENV_HOSTNAME을 사용할 수 있습니다.

Warning

참고: 이 방법이 적용되면 새 hostname의 호스트 데이터가 다시 업로드되고, 기존 hostname의 호스트 데이터는 더 이상 업데이트되지 않습니다.
권장 사항: hostname 변경이 필요한 경우, DataKit을 처음 설치할 때 수정하는 것이 좋습니다.

1. datakit-inputs 수정 및 [environments] 구성¶

$ vim /usr/local/datakit/conf.d/datakit.conf

# [environments]에서 ENV_HOSTNAME을 수정하여 인식하기 쉬운 hostname으로 변경

[environments]
  ENV_HOSTNAME = "118.178.57.79"

2. Guance - 변경 전후 데이터 비교¶

실험 3: Nginx 로그 통계를 서비스별로 데이터 표시¶

배경: 기업 내부의 Nginx는 일반적으로 도메인 포워딩 또는 서비스 포워딩 역할을 담당합니다. Nginx가 처리하는 도메인은 프론트엔드 요청을 백엔드의 여러 다른 하위 도메인이나 여러 다른 포트의 서비스로 전달하는 경우가 많으며, Nginx가 직접 여러 도메인 서비스를 처리할 수도 있습니다. 이러한 상황에서 통합된 Nginx 모니터링으로는 요구사항을 충족할 수 없습니다. Guance은 이 문제를 어떻게 해결할까요?

시나리오: Nginx가 외부에 18889와 80 포트를 노출하고, 각각 내부 서버 118.178.57.79의 8999 및 18999 포트로 전달합니다.

요구사항: Nginx 18889 및 80 포트에 해당하는 서비스의 데이터(PV, UV, 요청 오류 수 등)를 각각 통계합니다.

전제 조건: Nginx의 80 및 18889 액세스 로그가 각각 다른 디렉토리(또는 다른 로그 파일 이름)로 구성되어 있습니다.

80 포트 로그 디렉토리	/var/log/nginx/80/
18889 포트 로그 디렉토리	/var/log/nginx/18999/

1. Nginx 자체 메트릭 모니터링 구성¶

자세한 구성은 통합 문서 <Nginx>를 참조하세요.

nginx.conf 자체 성능 메트릭 통계 모듈 활성화

Nginx의 http_stub_status_module 모듈이 활성화되어 있는지 확인합니다.

(이 예제에서는 활성화되어 있습니다.)

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;
                             }

          }

nginx -s reload를 실행하여 Nginx를 다시 로드합니다.
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

nginx.conf 파일을 저장한 후 DataKit 재시작

$ service datakit restart

2. 80 및 18889 서비스에 해당하는 로그 모니터링 각각 구성¶

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

$ vim nginx80.conf

## 로그 경로를 올바른 애플리케이션 로그 경로로 수정
## source, service, pipeline은 필수 필드입니다. 애플리케이션 이름을 직접 사용하여 로그 이름을 구분할 수 있습니다.
## domainname 태그 추가

## 다음과 같이 수정:
[[inputs.logging]]

  logfiles = ["/var/log/nginx/80/access.log","/var/log/nginx/80/error.log" ]

  source = "nginx"

  service = "nginx"

  pipeline = "nginx.p"

  [inputs.logging.tags]

  domainname = "118.178.226.149:80"

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

## 로그 경로를 올바른 애플리케이션 로그 경로로 수정
## source, service, pipeline은 필수 필드입니다. 애플리케이션 이름을 직접 사용하여 로그 이름을 구분할 수 있습니다.
## domainname 태그 추가

## 다음과 같이 수정:
[[inputs.logging]]

  logfiles = ["/var/log/nginx/18889/access.log","/var/log/nginx/18889/error.log" ]

  source = "nginx"

  service = "nginx"

  pipeline = "nginx.p"

  [inputs.logging.tags]

  domainname = "118.178.226.149:18889"

3. 사용자 정의 뷰 구성 (태그를 통해 도메인 구분)¶

단계: Guance - 「시나리오」 - 「시나리오 생성」 - 「빈 시나리오 생성」 - 「시스템 뷰」(NGINX 생성)에 로그인합니다.

중요: 시스템 템플릿에서 nginx 뷰 관련 구성을 수정합니다.

뷰 편집 상태로 들어가서 「뷰 변수 수정」 - 「뷰 변수 추가」를 클릭합니다.

L::nginx:(distinct(`domainname`)){host='#{host}'}

의미 설명: nginx 메트릭의 host를 상속받아 L(로그)에서 nginx 로그의 서로 다른 domainname을 조회합니다.

특정 뷰의 매개변수 수정

4. Guance - 서비스별 데이터 표시¶

마찬가지로, 다른 태그를 추가하여 프로젝트, 담당자, 비즈니스 모듈, 환경 등을 구분할 수 있습니다. 태그의 활용 범위는 상상력에 따라 달라집니다.

실험 4: 태그를 통해 서비스 담당자(owner) 확인 및 알림 전송¶

배경: 기업 비즈니스가 발전함에 따라 마이크로서비스와 컨테이너가 많이 사용되고, 서비스 구성 요소가 증가하며, 관련 개발 및 운영 인력도 늘어나고 각자의 역할이 더 세분화됩니다. 비즈니스 시스템이나 IT 시스템에 장애가 발생했을 때 가장 효과적인 알림 사례는 관련 담당자를 직접 지정하여 알림 종료 효율을 높이는 것입니다. 일반적인 방법은 알림을 관련 담당자에게만 보내거나 Jira에 티켓을 할당하는 것입니다. Guance에서는 어떻게 할까요? Guance에서는 특정 관측 가능 inputs에 태그를 추가하면 됩니다(이론적으로 태그 수에 제한이 없습니다). 예를 들어 nginx-inputs에 사용자 정의 태그 owner = "xxx"를 추가한 다음, 이상 탐지에서 owner를 변수로 설정하면 이상 탐지가 자동으로 해당 필드를 인식하여 DingTalk 또는 WeCom 그룹으로 전송합니다. 결과는 다음과 같습니다.

예를 들어 위의 Nginx 사용자 정의 로그에 추가하는 경우:

Guance에서 TAG 모범 사례¶

개요¶

실험 1: 서버 그룹화¶

1. datakit-inputs 수정 및 global_tag 구성¶

2. Guance - 서버 그룹 확인¶

실험 2: DataKit이 인식하는 hostname 변경¶

1. datakit-inputs 수정 및 [environments] 구성¶

2. Guance - 변경 전후 데이터 비교¶

실험 3: Nginx 로그 통계를 서비스별로 데이터 표시¶

1. Nginx 자체 메트릭 모니터링 구성¶

2. 80 및 18889 서비스에 해당하는 로그 모니터링 각각 구성¶

3. 사용자 정의 뷰 구성 (태그를 통해 도메인 구분)¶

4. Guance - 서비스별 데이터 표시¶

실험 4: 태그를 통해 서비스 담당자(owner) 확인 및 알림 전송¶

1. inputs에 태그 추가¶

2. 이상 탐지 구성¶

3. 알림 트리거 및 알림 이벤트 확인¶

이 페이지가 도움이 되었나요?

Guance에서 TAG 모범 사례¶

개요¶

실험 1: 서버 그룹화¶

1. datakit-inputs 수정 및 global_tag 구성¶

2. Guance - 서버 그룹 확인¶

실험 2: DataKit이 인식하는 hostname 변경¶

1. datakit-inputs 수정 및 [environments] 구성¶

2. Guance - 변경 전후 데이터 비교¶

실험 3: Nginx 로그 통계를 서비스별로 데이터 표시¶

1. Nginx 자체 메트릭 모니터링 구성¶

2. 80 및 18889 서비스에 해당하는 로그 모니터링 각각 구성¶

3. 사용자 정의 뷰 구성 (태그를 통해 도메인 구분)¶

4. Guance - 서비스별 데이터 표시¶

실험 4: 태그를 통해 서비스 담당자(owner) 확인 및 알림 전송¶

1. inputs에 태그 추가¶

2. 이상 탐지 구성¶

3. 알림 트리거 및 알림 이벤트 확인¶

이 페이지가 도움이 되었나요? ×

이 페이지가 도움이 되었나요?