배포판 자체 관측 가능성 활성화¶
개요¶
이 문서의 목적은 사설 배포판 사용자가 배포판에 대해 관측 가능성을 구현하여 전체 Guance 서비스의 운영 안정성을 향상시키는 데 도움을 주는 것입니다. 이 문서에서는 2가지 주요 관측 가능성 모드와 Kubernetes 환경에서 Datakit 데이터 수집, 로그 및 파싱, APM, 신서틱 모니터링, RUM 등을 배포하는 방법을 설명합니다. 또한 인프라 및 미들웨어 관측과 애플리케이션 서비스 관측을 위한 원클릭 가져오기 템플릿 파일을 제공하여 자체 환경 관측을 더 쉽게 사용할 수 있도록 합니다.
배포판 관측 가능성 모드¶
이 모드는 자신이 자신을 관측하는 것을 의미합니다. 즉, 데이터를 자신의 워크스페이스로 전송합니다. 이는 환경이 다운되면 자신의 정보 데이터를 관측할 수 없고 추가로 원인을 파악할 수 없음을 의미합니다. 이 방식의 장점은 배포가 편리하다는 것입니다. 단점은 데이터가 지속적으로 생성되어 데이터 자체 반복이 발생하여 무한 루프가 발생할 수 있고, 클러스터가 충돌할 때 자체 문제를 관측할 수 없다는 것입니다.
이 모드는 고객의 여러 Guance이 동일한 노드로 데이터를 전송하는 것을 의미합니다. 장점: 데이터 전송 루프가 발생하지 않으며 자체 클러스터 상태를 실시간으로 모니터링할 수 있습니다.
계정 정보 준비¶
| 이름 | 유형 | 설명 | 생성 구문 (비밀번호 수정에 주의) | 중요도 |
|---|---|---|---|---|
| 사설 FUNC 데이터베이스 계정 | DB & USER | FUNC 서비스 연결 계정 | CREATE DATABASE private_func; create user 'private_func'@'%' identified by 'V4KySbFhzDkxxxx'; GRANT ALL PRIVILEGES ON private_func.* TO private_func; FLUSH PRIVILEGES; |
선택 |
| MySQL 자체 관측 계정 | USER | 자체 관측 계정, MySQL 메트릭 수집 | CREATE USER 'datakit'@'%' IDENTIFIED BY 'SFGS&DFxxxx32!'; -- MySQL 8.0+ create the datakit user with the caching_sha2_password method CREATE USER 'datakit'@'%' IDENTIFIED WITH caching_sha2_password by 'SFGS&DFxxxx32!'; GRANT PROCESS ON . TO 'datakit'@'%'; GRANT SELECT ON . TO 'datakit'@'%'; show databases like 'performance_schema'; GRANT SELECT ON performance_schema.* TO 'datakit'@'%'; GRANT SELECT ON mysql.user TO 'datakit'@'%'; GRANT replication client on . to 'datakit'@'%'; |
중요 |
| 비즈니스 데이터 수집 계정 | USER | FUNC를 사용하여 비즈니스 데이터 수집 시 사용 | CREATE USER 'read'@'%' IDENTIFIED BY 'u19e0LmkL8Fxxxx'; GRANT SELECT ON df_core.* TO 'read'@'%'; FLUSH PRIVILEGES; |
선택 |
| PostgreSQL 자체 관측 계정 | USER | GuanceDB 3.0 모니터링 사용 | CREATE USER datakit WITH PASSWORD 'Z7ZdQ326EeexxxxP'; GRANT pg_monitor TO datakit; GRANT CONNECT ON DATABASE scopedb_meta TO datakit; GRANT SELECT ON pg_stat_database TO datakit; |
선택 |
데이터 수집 구성¶
DataKit 배포¶
참고
참고: 위 DataKit의 기본 미들웨어 구성은 모두 완료되었으므로 약간만 수정하면 사용할 수 있습니다.
2) datakit.yaml DaemonSet 템플릿 파일 수정
- name: ENV_DATAWAY
value: https://openway.guance.com?token=tkn_a624xxxxxxxxxxxxxxxxxxxxxxxx74 ## 실제 dataway 주소 입력
- name: ENV_GLOBAL_TAGS
value: host=__datakit_hostname,host_ip=__datakit_ip,guance_site=guance,cluster_name_k8s=guance # 대시보드 변수는 실제 상황에 맞게 수정
- name: ENV_GLOBAL_ELECTION_TAGS
value: guance_site=guance,cluster_name_k8s=guance # 대시보드 변수에 따라 실제 상황에 맞게 수정
image: pubrepo.guance.com/datakit/datakit:1.65.2 ## 최신 이미지 버전으로 변경
3) datakit.yaml에서 ConfigMap 관련 구성 수정
apiVersion: v1
kind: ConfigMap
metadata:
name: datakit-conf
namespace: datakit
data:
mysql.conf: |-
[[inputs.mysql]]
host = "xxxxxxxxxxxxxxx" ## 해당 MySQL 연결 주소 수정
user = "ste3" ## MySQL 사용자 이름 수정
pass = "Test1234" ## MySQL 비밀번호 수정
......
redis.conf: |-
[[inputs.redis]]
host = "r-xxxxxxxxx.redis.rds.ops.ste3.com" ## Redis 연결 주소 수정
port = 6379
# unix_socket_path = "/var/run/redis/redis.sock"
# 여러 db 구성, dbs를 구성하면 db도 수집 목록에 포함됩니다. dbs=[] 또는 구성하지 않으면 redis의 모든 비어 있지 않은 db를 수집합니다.
# dbs=[]
# username = "<USERNAME>"
password = "Test1234" ## Redis 비밀번호 수정
......
openes.conf: |-
[[inputs.elasticsearch]]
## Elasticsearch 서버 구성
# Basic 인증 지원:
# servers = ["http://user:pass@localhost:9200"]
servers = ["http://guance:123.com@opensearch-cluster-client.middleware:9200"] ## 사용자 이름, 비밀번호 등 수정
......
4) 마운트 작업
- mountPath: /usr/local/datakit/conf.d/db/mysql.conf
name: datakit-conf
subPath: mysql.conf
readOnly: false
참고: 여러 구성도 동일합니다. 순서대로 추가하면 됩니다.
6) 수정 후 DataKit 배포 시작
환경 변수 설명¶
| 변수 이름 | 설명 |
|---|---|
| ENV_DEFAULT_ENABLED_INPUTS | 기본 수집 구성: self,cpu,disk,diskio,mem,swap,system,hostobject,net,host_processes,container,zipkin |
| ENV_ENABLE_ELECTION | 선출 메커니즘 활성화 후 Prometheus 수집(또는 다른 구성 요소)이 마스터 노드 또는 후보 노드 방식으로 작동합니다. |
| ENV_GLOBAL_ELECTION_TAGS | 선출 구성 요소에 추가 태그 차원을 추가하여 Prometheus 수집 시 태그 지정에 사용합니다(선출 활성화 시 유효). |
| ENV_INPUT_DDTRACE_COMPATIBLE_OTEL | otel Trace와 DDTrace Trace 호환 활성화 |
| ENV_INPUT_DISK_USE_NSENTER | nsenter 방식을 사용하여 디스크 사용량 정보를 수집합니다. 클러스터 동적 스토리지 블록 정보를 수집합니다. 동적 스토리지 블록을 사용하는 경우 반드시 설정해야 합니다. |
| ENV_INPUT_HOSTOBJECT_USE_NSENTER | nsenter 방식을 사용하여 디스크 사용량 정보를 수집합니다. 클러스터 동적 스토리지 블록 정보를 수집합니다. 동적 스토리지 블록을 사용하는 경우 반드시 설정해야 합니다. |
| ENV_INPUT_CONTAINER_ENABLE_CONTAINER_METRIC | 컨테이너 메트릭 수집 활성화 |
| ENV_INPUT_CONTAINER_ENABLE_POD_METRIC | Pod 메트릭 수집 활성화 (CPU 및 메모리 사용량) |
| ENV_INPUT_CONTAINER_ENABLE_K8S_METRIC | k8s 메트릭 수집 활성화 |
뷰, 모니터 템플릿 및 Pipelines 가져오기¶
참고
모니터 템플릿을 가져온 후에는 알림 정책 및 알림 대상을 수동으로 설정해야 합니다.
뷰, 모니터 템플릿 가져오기¶
「관리」-「워크스페이스 설정」-「가져오기」
참고
가져온 후 모니터의 해당 점프 링크 구성을 수정해야 합니다. url의 dsbd_xxxx를 해당 대시보드로 변경하고, wksp_xxxx를 모니터링할 워크스페이스로 변경해야 합니다.
Pipelines 가져오기¶
guance-self-observing-latest.zip 파일 압축 풀기, 경로: guance-self-observing-latest/pipeline
「관리」-「Pipelines」-「가져오기」
애플리케이션 서비스 관측¶
서비스 Prom 수집 구성¶
guance-self-observing-prom-latest.zip 압축 풀기 후 다음 명령 실행:
cd guance-self-observing-prom-latest
kubectl patch deploy kodo-x -n forethought-kodo --type merge --patch "$(cat kodo-x-prom.yaml)"
kubectl patch deploy kodo -n forethought-kodo --type merge --patch "$(cat kodo-prom.yaml)"
kubectl patch deploy kodo-inner -n forethought-kodo --type merge --patch "$(cat kodo-inner-prom.yaml)"
kubectl patch sts kodo-servicemap -n forethought-kodo --type merge --patch "$(cat kodo-servicemap-prom.yaml)"
kubectl patch sts kodo-x-backuplog -n forethought-kodo --type merge --patch "$(cat kodo-x-backuplog-prom.yaml)"
kubectl patch deploy inner -n forethought-core --type merge --patch "$(cat core-inner-prom.yaml)"
APM 구성¶
forethought-core 주입 구성¶
#!/bin/bash
set -euo pipefail
# 네임스페이스
NAMESPACE="${NAMESPACE:-forethought-core}"
# —— 각 deployment의 전용 KV를 여기에 작성 (스크립트 내, 외부 파일 불필요) ——
# 한 줄에 하나: "<deploy> KEY=VAL KEY=VAL ..."
DEPLOY_ENV_CONFIG=(
'front-backend DD_PATCH_MODULES=redis:true,urllib3:true,httplib:true,sqlalchemy:true,httpx:true DD_AGENT_PORT=9529 DD_GEVENT_PATCH_ALL=true DD_SERVICE=front-backend DD_TAGS=pod_name:$(POD_NAME),project:dataflux'
'inner DD_PATCH_MODULES=redis:true,urllib3:true,httplib:true,sqlalchemy:true,httpx:true DD_AGENT_PORT=9529 DD_GEVENT_PATCH_ALL=true DD_SERVICE=inner DD_TAGS=pod_name:$(POD_NAME),project:dataflux'
'management-backend DD_PATCH_MODULES=redis:true,urllib3:true,httplib:true,sqlalchemy:true,httpx:true DD_AGENT_PORT=9529 DD_GEVENT_PATCH_ALL=true DD_SERVICE=management-backend DD_TAGS=pod_name:$(POD_NAME),project:dataflux'
'open-api DD_PATCH_MODULES=redis:true,urllib3:true,httplib:true,sqlalchemy:true,httpx:true DD_AGENT_PORT=9529 DD_GEVENT_PATCH_ALL=true DD_SERVICE=open-api DD_TAGS=pod_name:$(POD_NAME),project:dataflux'
'sse DD_PATCH_MODULES=redis:true,urllib3:true,httplib:true,sqlalchemy:true,httpx:true DD_AGENT_PORT=9529 DD_GEVENT_PATCH_ALL=true DD_SERVICE=sse DD_TAGS=pod_name:$(POD_NAME),project:dataflux'
'core-worker DD_TRACE_ENABLED=false'
'core-worker-0 DD_TRACE_ENABLED=false'
'core-worker-beat DD_TRACE_ENABLED=false'
'core-worker-correlation DD_TRACE_ENABLED=false'
)
# —— args[0]에만 ddtrace-run 접두사 추가 (command는 수정하지 않음)——
prefix_ddtrace_run_args_only() { # $1 deploy
local d="$1"
# 명시적으로 tracing 비활성화 시 추가하지 않음
local trace_enabled
trace_enabled="$(kubectl get deploy "$d" -n "$NAMESPACE" \
-o jsonpath='{.spec.template.spec.containers[0].env[?(@.name=="DD_TRACE_ENABLED")].value}' 2>/dev/null || true)"
if [[ "$trace_enabled" == "false" ]]; then
echo " • DD_TRACE_ENABLED=false, ddtrace-run 건너뜁니다."
return 0
fi
# args[0] 읽기
local first_arg
first_arg="$(kubectl get deploy "$d" -n "$NAMESPACE" \
-o jsonpath='{.spec.template.spec.containers[0].args[0]}' 2>/dev/null || true)"
# 이미 ddtrace-run으로 시작하면 건너뜀
if [[ "$first_arg" == "ddtrace-run" ]]; then
echo " • args가 이미 ddtrace-run으로 시작하므로 건너뜁니다."
return 0
fi
# args 배열이 있는지 확인
local has_args
has_args="$(kubectl get deploy "$d" -n "$NAMESPACE" \
-o jsonpath='{.spec.template.spec.containers[0].args}' 2>/dev/null || true)"
if [[ -n "$has_args" ]]; then
# 기존 args 앞에 ddtrace-run 삽입
kubectl patch deploy "$d" -n "$NAMESPACE" --type='json' -p='[
{"op":"add","path":"/spec/template/spec/containers/0/args/0","value":"ddtrace-run"}
]' >/dev/null
echo " • args[0]에 ddtrace-run을 삽입했습니다."
else
# args가 없으면 args를 생성하고 ddtrace-run을 첫 번째 요소로 추가
kubectl patch deploy "$d" -n "$NAMESPACE" --type='json' -p='[
{"op":"add","path":"/spec/template/spec/containers/0/args","value":["ddtrace-run"]}
]' >/dev/null
echo " • args 없음: args=[\"ddtrace-run\"]을 생성했습니다."
fi
}
# —— 유틸리티 함수 —— #
has_env() { # $1 deploy $2 KEY
kubectl get deploy "$1" -n "$NAMESPACE" \
-o jsonpath="{.spec.template.spec.containers[0].env[?(@.name=='$2')].name}" 2>/dev/null | grep -qx "$2"
}
ensure_env_array() { # $1 deploy
local has_array
has_array="$(kubectl get deploy "$1" -n "$NAMESPACE" -o jsonpath="{.spec.template.spec.containers[0].env}" 2>/dev/null || true)"
if [[ -z "${has_array}" ]]; then
kubectl patch deploy "$1" -n "$NAMESPACE" --type='json' -p="[
{\"op\":\"add\",\"path\":\"/spec/template/spec/containers/0/env\",\"value\":[]}
]" >/dev/null
fi
}
for item in "${DEPLOY_ENV_CONFIG[@]}"; do
deploy="${item%% *}"
# 해당 행에 배포 이름만 있으면 건너뜀
rest="${item#* }"; [[ "$rest" == "$deploy" ]] && rest=""
echo "→ 처리 중: $deploy"
# 존재 여부 확인
if ! kubectl get deploy "$deploy" -n "$NAMESPACE" >/dev/null 2>&1; then
echo " - 찾을 수 없음, 건너뜁니다."
continue
fi
# env 배열이 있는지 확인 (없으면 /env/- 추가 실패)
ensure_env_array "$deploy"
# Downward API 추가 (없으면): DD_AGENT_HOST=status.hostIP, POD_NAME=metadata.name
if ! has_env "$deploy" "DD_AGENT_HOST"; then
kubectl patch deploy "$deploy" -n "$NAMESPACE" --type='json' -p='[
{"op":"add","path":"/spec/template/spec/containers/0/env/-",
"value":{"name":"DD_AGENT_HOST","valueFrom":{"fieldRef":{"apiVersion":"v1","fieldPath":"status.hostIP"}}}}
]' >/dev/null
echo " • DD_AGENT_HOST 추가 (status.hostIP)"
else
echo " • DD_AGENT_HOST 존재, 건너뜁니다."
fi
if ! has_env "$deploy" "POD_NAME"; then
kubectl patch deploy "$deploy" -n "$NAMESPACE" --type='json' -p='[
{"op":"add","path":"/spec/template/spec/containers/0/env/-",
"value":{"name":"POD_NAME","valueFrom":{"fieldRef":{"apiVersion":"v1","fieldPath":"metadata.name"}}}}
]' >/dev/null
echo " • POD_NAME 추가 (metadata.name)"
else
echo " • POD_NAME 존재, 건너뜁니다."
fi
# 개별 정적 KEY=VAL (없으면 추가, 있으면 건너뜀)
for kv in $rest; do
key="${kv%%=*}"
val="${kv#*=}"
if has_env "$deploy" "$key"; then
echo " • $key 존재, 건너뜁니다."
else
kubectl set env deploy/"$deploy" -n "$NAMESPACE" "$key=$val" >/dev/null
echo " • $key=$val 추가"
fi
done
# 시작 명령 앞에 ddtrace-run이 있는지 확인
prefix_ddtrace_run_args_only "$deploy"
echo " -> 완료: $deploy"
done
forethought-kodo 주입 구성¶
#!/bin/bash
set -euo pipefail
# 네임스페이스
NAMESPACE="${NAMESPACE:-forethought-kodo}"
# —— 각 deployment의 전용 KV를 여기에 작성 (스크립트 내, 외부 파일 불필요) ——
# 한 줄에 하나: "<deploy> KEY=VAL KEY=VAL ..."
DEPLOY_ENV_CONFIG=(
'kodo DD_TRACE_ENABLED=true DD_TRACE_AGENT_PORT=9529 DD_TRACE_SAMPLE_RATE=0 DD_SERVICE=kodo DD_TAGS=pod_name:$(POD_NAME),project:dataflux'
'kodo-inner DD_TRACE_ENABLED=true DD_TRACE_AGENT_PORT=9529 DD_SERVICE=kodo-inner DD_TAGS=pod_name:$(POD_NAME),project:dataflux'
)
# —— 유틸리티 함수 —— #
has_env() { # $1 deploy $2 KEY
kubectl get deploy "$1" -n "$NAMESPACE" \
-o jsonpath="{.spec.template.spec.containers[0].env[?(@.name=='$2')].name}" 2>/dev/null | grep -qx "$2"
}
ensure_env_array() { # $1 deploy
local has_array
has_array="$(kubectl get deploy "$1" -n "$NAMESPACE" -o jsonpath="{.spec.template.spec.containers[0].env}" 2>/dev/null || true)"
if [[ -z "${has_array}" ]]; then
kubectl patch deploy "$1" -n "$NAMESPACE" --type='json' -p="[
{\"op\":\"add\",\"path\":\"/spec/template/spec/containers/0/env\",\"value\":[]}
]" >/dev/null
fi
}
for item in "${DEPLOY_ENV_CONFIG[@]}"; do
deploy="${item%% *}"
# 해당 행에 배포 이름만 있으면 건너뜀
rest="${item#* }"; [[ "$rest" == "$deploy" ]] && rest=""
echo "→ 처리 중: $deploy"
# 존재 여부 확인
if ! kubectl get deploy "$deploy" -n "$NAMESPACE" >/dev/null 2>&1; then
echo " - 찾을 수 없음, 건너뜁니다."
continue
fi
# env 배열이 있는지 확인 (없으면 /env/- 추가 실패)
ensure_env_array "$deploy"
# Downward API 추가 (없으면): DD_AGENT_HOST=status.hostIP, POD_NAME=metadata.name
if ! has_env "$deploy" "DD_AGENT_HOST"; then
kubectl patch deploy "$deploy" -n "$NAMESPACE" --type='json' -p='[
{"op":"add","path":"/spec/template/spec/containers/0/env/-",
"value":{"name":"DD_AGENT_HOST","valueFrom":{"fieldRef":{"apiVersion":"v1","fieldPath":"status.hostIP"}}}}
]' >/dev/null
echo " • DD_AGENT_HOST 추가 (status.hostIP)"
else
echo " • DD_AGENT_HOST 존재, 건너뜁니다."
fi
if ! has_env "$deploy" "POD_NAME"; then
kubectl patch deploy "$deploy" -n "$NAMESPACE" --type='json' -p='[
{"op":"add","path":"/spec/template/spec/containers/0/env/-",
"value":{"name":"POD_NAME","valueFrom":{"fieldRef":{"apiVersion":"v1","fieldPath":"metadata.name"}}}}
]' >/dev/null
echo " • POD_NAME 추가 (metadata.name)"
else
echo " • POD_NAME 존재, 건너뜁니다."
fi
# 개별 정적 KEY=VAL (없으면 추가, 있으면 건너뜀)
for kv in $rest; do
key="${kv%%=*}"
val="${kv#*=}"
if has_env "$deploy" "$key"; then
echo " • $key 존재, 건너뜁니다."
else
kubectl set env deploy/"$deploy" -n "$NAMESPACE" "$key=$val" >/dev/null
echo " • $key=$val 추가"
fi
done
echo " -> 완료: $deploy"
done
신서틱 모니터링 구성¶
1) 모니터링할 웹사이트 새로 생성
2) 신서틱 테스트 구성
참고
실제 설정된 도메인에 따라 수정
| 이름 | 테스트 주소 | 유형 | 작업 상태 | 작업 |
|---|---|---|---|---|
| xx-dataflux-api | https://xx-console-api.guance.com | HTTP | 시작 |  |
| xx-open-api | https://xx-open-api.guance.com | HTTP | 시작 | |
| xx-dataway | https://xx-dataway.guance.com | HTTP | 시작 | |
| xx-static-res | https://xx-static-res.guance.com/dataflux-template/README.md | HTTP | 시작 | |
| xx-dataflux | https://xx-dataflux.guance.com | HTTP | 시작 | |
| xx-management-api | https://xx-management-api.guance.com | HTTP | 시작 | |
| xx-management | https://xx-management.guance.com | HTTP | 시작 | |
RUM 구성¶
참고
"공용 네트워크 DataWay 사용"을 찾을 수 없으면 namespace「forethought-webclient」- configmap「front-web-config」를 수정하고 rumDatawayUrl:<https://<Dataway 주소>를 추가한 후 front-webclient 서비스를 재시작합니다.
1) RUM 구성 가져오기
자체 관측 워크스페이스에 로그인하여 RUM 앱 생성
- App Name: Guance
- App ID: xxx_guance_com
- site 가져오기
- clientToken 가져오기
2) forethought-webclient namespace의 front-web-config ConfigMap 구성 수정 (매개변수가 없으면 추가)
- rumEnable: 1 (1은 활성화)
- rumOpenwayUrl: 「가져온 site」
- rumClientToken: 「가져온 clientToken」
- rumApplicationId: 「App ID」
- rumAllowedDdtracingOrigins: ["https://xxx-console-api.guance.com", "https://xxx-console.guance.com"]
- rumJsUrl: "https://static.guance.com/browser-sdk/v3/dataflux-rum.js", ## Guance 버전 1.123.216 이전에는 v2를 v3로 변경
window.DEPLOYCONFIG = {
cookieDomain: '.guance.com',
apiUrl: 'https://cn4-console-api.guance.com',
wsUrl: 'wss://.guance.com',
innerAppDisabled: 0,
innerAppLogin: 'https://cn4-auth.guance.com/redirectpage/login',
innerAppRegister: 'https://cn4-auth.guance.com/redirectpage/register',
innerAppProfile: 'https://cn4-auth.guance.com/redirectpage/profile',
innerAppCreateworkspace: 'https://cn4-auth.guance.com/redirectpage/createworkspace',
staticFileUrl: 'https://cn4-static-res.guance.com',
staticDatakit: 'https://static.guance.com',
cloudDatawayUrl: '',
isSaas: '1',
showHelp: 1,
rumEnable: 1, ## 0은 비활성화, 1은 활성화, 여기서는 활성화
rumOpenwayUrl: "", ## openway 주소
rumApplicationId: "", ## 실제 appid로 변경
rumJsUrl: "https://static.guance.com/browser-sdk/v3/dataflux-rum.js", ## Guance 버전 1.123.216 이전에는 v2를 v3로 변경
rumDataEnv: 'prod',
알림 정책 설명¶
| 알림 정책 이름 | 알림 수준 | 알림 설명 | 비고 |
|---|---|---|---|
| P0 알림 - Lark 그룹 & 전화 알림 | 심각 | 이 정책은 최고 수준 알림으로, 이벤트 발생 후 즉시 처리해야 합니다. 트리거 조건: 1. 사이트 페이지에 접근할 수 없음 2. 데이터 업로드 실패 또는 쓰기 실패로 데이터 손실 발생 3. 모니터 중단으로 사용자 모니터링 실패 4. 자동 트리거 작업 중단 또는 실패로 데이터 손실 발생 5. 미들웨어 장애로 시스템 사용 불가 또는 데이터 손실 발생 |
알림 대상 권장: 전화 |
| 인프라 알림 - Lark 그룹 알림 | 심각, 중요 | 이 정책은 P0 알림보다 낮은 수준으로, 이벤트 발생 후 지속적인 관찰 및 조사가 필요합니다. 트리거 조건: 1. 서비스 비정상 재시작 2. 노드 메모리 이상 3. 노드 부하 과다 또는 기타 시스템 리소스 이상 |
알림 대상 권장: 일반 (이메일, Lark 등) |
| 비즈니스 알림 - Lark 그룹 알림 | 심각, 중요, 경고 | 이 정책은 일반 수준 알림으로, 이벤트 발생 후 지속적인 관찰을 권장합니다. 트리거 조건: 1. 서비스 로그 오류 2. 비즈니스 로직 관련 이상 |
알림 대상 권장: 일반 (이메일, Lark 등) |
| ScopeDB 관련 서비스 알림 | 전체 | 이 정책은 일반 수준 알림으로, 이벤트 발생 후 지속적인 관찰을 권장합니다. 트리거 조건: 1. ScopeDB 서비스 로그 오류 2. ScopeDB 성능 알림 |
알림 대상 권장: 일반 (이메일, Lark 등) |
알림 설정 단계¶
알림 대상 생성¶
-
자체 관측 워크스페이스에 로그인하여 「모니터」-「알림 대상 관리」 방문
-
3개의 다른 알림 대상 생성 (알림 대상 유형 제한 없음, 다른 알림 그룹 권장)
- 비즈니스 알림
- 인프라 알림
- P0 알림
알림 정책 구성¶
「모니터」- 「알림 정책 관리」에서 알림 구성 설정
| 알림 정책 이름 | 알림 구성-수준 | 알림 구성-대상 | 반복 알림 주기 |
|---|---|---|---|
| 인프라 알림 -Lark 그룹 | 심각, 중요 | 인프라 알림 | 30분 |
| P0 알림 - Lark 그룹 & 전화 알림 | 심각 | P0 알림 | 6시간 |
| 비즈니스 알림 - Lark 그룹 알림 | 심각, 중요, 경고 | 비즈니스 알림 | 30분 |
| ScopeDB 관련 서비스 알림 | 전체 | 비즈니스 알림 | 30분 |
Func 자체 관측 (선택 사항)¶
Func 작업 로그 데이터 보고¶
DataFlux Func의 함수 실행 로그, 자동 트리거 구성 등의 정보를 Guance에 직접 보고할 수 있습니다. 단계는 아래 그림과 같습니다.
Guance 데이터 보고에서 DataWay / OpenWay 주소와 Token 정보를 입력하면 됩니다. 형식은 다음과 같습니다.
참고: Func 데이터 보고가 실패하면 DataFlux Func 문서를 확인하세요.
비즈니스 모니터링 수집 (선택 사항)¶
사설 Func 배포¶
참고, storageClass, MYSQL_HOST, MYSQL_USER, MYSQL_PASSWORD, MYSQL_DATABASE 등의 매개변수
helm install func func --repo https://pubrepo.guance.com/chartrepo/func -n datakit --create-namespace \
--set storage.pvc.enabled=true,storage.pvc.storageClass="xxxxxxxx" \
--set mysql.enabled=false,func.MYSQL_HOST='xxxxxx' \
--set func.MYSQL_USER=private_func,func.MYSQL_PASSWORD=xxxxx,func.MYSQL_DATABASE=private_func
Ingress 설정¶
사전에 인증서 설정
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: xxx-private-func
namespace: datakit
spec:
ingressClassName: nginx
rules:
- host: xxx-private-func.guance.com
http:
paths:
- backend:
service:
name: func-server
port:
number: 8088
path: /
pathType: ImplementationSpecific
tls:
- hosts:
- xxx-private-func.guance.com
secretName: guance.com
초기화¶
브라우저에서 도메인으로 접속, 다음 단계
스크립트 가져오기¶
「스크립트 세트 가져오기」-「스크립트 가져오기」 방문
데이터베이스 환경 변수 구성 수정¶
【비즈니스 데이터 수집 계정】 정보 입력
검증 방법¶
guance_site 매개변수 전환 필요
| 이름 | 검증 방식 | 검증 작업 | |
|---|---|---|---|
| MySQL | DQL | M::mysql:(avg(max_connections)) { guance_site = 'xxx' } BY host |
|
| Redis | DQL | M::redis_info:(avg(maxmemory)) { guance_site = 'xxx' } BY host |
|
| PostgreSQL | DQL | M::postgresql_connection:(max(percent_usage_connections)) { guance_site = 'xxx' } |
|
| NSQD | DQL | M::nsq_topics:(max(message_count)) { guance_site = 'xxx' } BY topic |
|
| DataWay | DQL | M::dw:(max(dataway_cpu_cores)) { guance_site = 'xxx' } BY guance_site |
|
| Studio 트레이스 | DQL | T::front-backend:(count(*)) { guance_site = 'xxx' } BY guance_site |
|
| Kodo-inner 트레이스 | DQL | T::kodo-inner:(count(*)) { guance_site = 'xxx' } BY guance_site |
|
| Kodo 메트릭 | DQL | M::kodo_workers:(count(job_point_bytes_total), count(write_byte_total)) BY guance_site |