이득:
- 관찰 가능성의 세 가지 요소(메트릭, 로그, 추적)와 4가지 골든 신호를 이해하고 인공 지능이 PromQL 쿼리, 경보 규칙 및 대시보드를 생성하도록 하는 능력
- 경보를 조치 지향적으로, 적절한 긴급 상태로 유지하고 자체 시스템의 기록 데이터에 대한 임계값을 테스트하여 경보 피로를 방지하는 기능
- 로그를 인공지능에 전달하기 전 민감한 부분을 마스킹하여 개인정보 유출 및 개인정보 유출을 방지하는 기능
시스템이 작동하는 것처럼 보이지만 내부적으로는 죽어가고 있을 수 있습니다. 메모리가 천천히 채워지고, 응답 시간이 증가하고, 오류율이 점점 높아지고 있습니다. 이를 알아차리는 유일한 방법은 시스템을 지속적으로 모니터링하는 것입니다. 더 발전된 개념은 관찰성(observability), 즉 외부 신호를 보고 시스템 내부에서 무슨 일이 일어나고 있는지 이해하는 능력입니다. 관찰 가능성에는 세 가지 핵심 요소가 있으며 DevOps 전문가는 세 가지를 모두 사용합니다.
- 지표: 시간 경과에 따라 측정된 숫자 값 — CPU 사용량, 요청 수, 응답 시간, 오류율. "얼마나 많이?" 질문에 대답합니다.
- 로그: 시스템에서 생성된 텍스트 이벤트 기록("사용자 로그인", "데이터베이스 연결 끊김"). "정확히 무슨 일이 일어났나요?" 질문에 대답합니다.
- 추적: 시스템 내에서 서비스 간에 전달되는 동안 요청이 따르는 경로와 각 단계의 기간입니다. "느림은 어디에 있습니까?" 질문에 대답합니다.
가장 일반적인 도구: 메트릭용 Prometheus, 시각화용 Grafana, 로그용 Loki/ELK, 추적용 Jaeger/OpenTelemetry. AI는 이러한 도구에 대한 쿼리 언어(특히 Prometheus의 PromQL), 경보 규칙 및 대시보드 구성을 작성하는 데 매우 능숙합니다. 또한 대량의 로그와 지표를 요약하고 이상 징후를 표시하는 등 AI가 가장 강력한 곳이기도 합니다.
모니터링과 관찰 가능성의 차이점을 한 문장으로 명확하게 설명하겠습니다. 모니터링은 이미 알고 있는 질문(“CPU가 90%를 넘었나요?”)을 묻는 것입니다. 관찰 가능성은 아직 알지 못했던 질문을 할 수 있다는 것입니다("이 이상한 속도 저하가 특정 시간에 특정 고객에게만 발생하는 이유는 무엇입니까?"). 현대 시스템은 너무 복잡해서 모든 실패 모드를 예측할 수 없습니다. 따라서 풍부한 지표, 로그 및 추적을 수집한 다음 심층적으로 쿼리하는 기능, 즉 관찰 가능성이 중요해집니다. AI는 "이전에 알려지지 않은 질문"에 답할 때 AI가 작동하는 곳입니다. 보유한 원시 데이터를 신속하게 스캔하고 패턴과 이상 현상을 제안하며 이러한 단서를 확인하여 근본 원인에 도달합니다.
단계별: 모니터링 대상과 방법은 무엇입니까?
- 올바른 측정항목을 선택하세요. 업계에서는 대기 시간, 트래픽, 오류, 포화도, 즉 리소스가 얼마나 꽉 차 있는지 등 "4가지 골든 신호"를 기준으로 삼습니다. 여기에는 대부분의 서비스 상태가 요약되어 있습니다.
- 측정항목을 수집합니다. 애플리케이션이 Prometheus가 읽을 수 있는 엔드포인트를 제시하도록 하세요.
- 대시보드를 설정합니다. Grafana에서 이러한 측정항목을 시각화하세요.
- 알람 규칙을 작성합니다. 임계값을 초과하면 누가 경고를 받게 됩니까? 어떻게 경고를 받게 됩니까?
- 로그를 중앙 집중화합니다. 모든 서비스 로그를 한 곳에서 검색 가능하게 만드세요.
- 소음을 줄입니다. 알람이 너무 많으면 "경고 피로"가 발생합니다. 중요한 알람이 사라집니다.
팁: 좋은 경보는 실행 가능하고 적절한 긴급성을 갖는다는 두 가지 요건을 충족합니다. 새벽 3시에 누군가를 깨우는 알람은 실제로 야간 개입이 필요한 알람이어야 합니다. "CPU 70%"와 같이 자체적으로 조치가 필요하지 않은 문제 때문에 누구도 깨우지 마세요. 칠판에 표시해 보세요.
알람 규칙을 작성하는 방법은 무엇입니까?
경고는 조건(메트릭이 어떤 임계값을 얼마나 오랫동안 초과하는지), 기간(순간적인 변동을 유발하지 않기 위해 "5분 동안"), 중요도/작업(누구에게, 어떤 채널을 통해)이라는 세 가지 구성 요소로 구성됩니다. AI는 올바른 컨텍스트를 통해 이 세 가지를 능숙하게 설정합니다. 예를 들어, "오류율이 5분 동안 5%를 초과하면 중요 경보"와 같은 규칙을 PromQL로 변환하는 것은 AI의 경우 매우 짧은 작업이지만 임계값이 시스템에 적합한지 여부는 사용자가 결정합니다.
주의: AI가 제안하는 경보 임계값은 일반적인 가정입니다. 시스템의 일반 부하, 허용 오차 및 작업 영향은 다릅니다. 프로덕션에 직접 임계값을 설정하기 전에 기록 데이터를 살펴보고 "과거에 이 임계값이 몇 번이나 트리거되었는지, 그 중 실제 문제는 몇 번이나 발생했습니까?"라고 질문합니다. 질문에 답하십시오.
로그 개인 정보 보호: 심각한 경고
로그는 가장 흔히 간과되는 유출 원인입니다. 로그 라인에는 실수로 비밀번호, 신용 카드 번호 또는 개인 데이터(KVKK/GDPR에 따라)가 포함될 수 있습니다. 분석을 위해 AI에 로그를 붙여넣는 경우:
- 민감한 부위를 가리십시오. 토큰, 비밀번호, 이메일, ID 번호 등의 값을 <REDACTED>로 대체합니다.
- 전부는 아니지만 예를 들어보세요. 백만 개의 라인 대신 수백 개의 대표 라인이면 충분할 때가 많습니다.
- 기관에서 승인한 차량을 선택하세요. 특히 프로덕션 로그의 경우 데이터가 교육에 포함되지 않는 도구를 사용하세요.
4개의 황금 신호 및 경보 테이블
신호
측정한
경보 임계값 예시
긴급함
대기 시간
응답 시간
p95 > 800ms, 5분
높다
교통
요청/초
급격한 300% 증가/감소
중간
오류
실패한 요청 비율
> 5%, 5분
중요한
채도
자원 점유
디스크 > 85%
높다
세 개의 미니 케이스
사례 1 - 400줄의 로그가 30초 안에 요약됩니다. 서비스 속도가 느려졌습니다. 엔지니어는 마스킹된 400줄의 로그를 AI에 넘겨주고 "반복되는 오류 패턴과 시간 강도를 요약하라"고 말했다. AI는 특정 외부 API 호출이 30초마다 시간 초과된다는 것을 보여주었습니다. 30초 안에 근본 원인 발견 로그를 수동으로 스캔하는 데는 30분이 소요됩니다.
사례 2 - 알람 피로가 해결되었습니다. 한 팀은 하루에 200개의 알람을 받고 이를 모두 무시하고 있었습니다. 그러다가 실제 정전 알람도 간과되었습니다. AI에게 모든 경고 규칙을 제공하고 "어떤 것이 실행 가능하지 않고 어떤 것이 결합될 수 있습니까?"라고 질문합니다. 그들은 물었다. 알람 횟수가 하루 12회로 감소했습니다. 이제 모든 경보가 심각하게 받아들여졌습니다.
사례 3 — 잘못된 임계값이 조기에 발견되었습니다. YZ는 디스크에 대해 "95% 찼을 때 경고"를 제안했습니다. 엔지니어는 기록 데이터를 살펴보았습니다. 디스크가 95%에 도달하면 개입할 시간이 거의 없었습니다. 임계값을 80%로 낮추고 '성장률'을 기준으로 두 번째 경보를 추가했습니다. 검증을 통해 실제 자정 정전을 방지했습니다.
복사 가능한 템플릿 4개
1) 로그 요약(마스크됨):
아래 로그 예시를 분석해 보세요(민감한 값은 <REDACTED>로 마스킹했습니다). (1) 반복되는 오류 패턴, (2) 시간 경과에 따른 집중, (3) 가장 가능성이 높은 근본 원인, (4) 확인하기 위해 살펴볼 3가지 측정항목을 알려주세요. 로그: [LINES]
2) 알람 규칙 생성:
Prometheus/Alertmanager에 대한 경보 규칙을 작성합니다. [THRESHOLD]가 [METRIC][DURATION]을 초과하면 [SEVERITY] 경보를 생성합니다. 규칙은 작업 지향적이어야 하며 주석 및 런북 링크 필드를 포함해야 합니다. PromQL을 설명하고 이 임계값이 합리적인 이유를 쓰십시오.
3) PromQL 쿼리 작성/선언:
다음을 측정하는 PromQL 쿼리를 작성합니다. [EX. 5xx지난 5분 동안의 오류율 백분율]. 쿼리를 단계별로 설명하세요. 그런 다음 이 값의 건강한 범위가 어떻게 되어야 하는지 알려주세요.
4) 대시보드 디자인:
[SERVICE]용 Grafana 대시보드 디자인: 어떤 패널을 사용하여 4가지 골든 신호(지연 시간, 트래픽, 오류, 포화도)를 표시해야 합니까? 각 패널에 대한 메트릭, 시각화 유형 및 합리적인 임계값을 제안합니다. 목적: 10초 안에 경비원의 건강 상태를 확인합니다.
약한 프롬프트 / 강한 프롬프트
약함: "그 로그에는 무엇이 들어있나요?" (다음에는 5000줄의 원시 로그와 그 안에 토큰이 옵니다)
결과: 당신은 비밀을 유출하고 AI는 대상이 지정되지 않은 피상적인 요약을 제공합니다.
Strong: "아래 300줄의 마스크된 로그 예에서 반복되는 오류 패턴과 시간 강도를 찾아보세요. 가장 가능성이 높은 근본 원인과 확인하기 위해 살펴볼 측정항목을 알려주세요. 토큰을 <편집됨>으로 만들었습니다."
차이점: 두 번째 프롬프트는 가려지고 집중된 예를 제공하여 명확한 분석 결과를 요구합니다. 안전하고 유용합니다.
일반적인 실수
- 마스킹하지 않고 AI에 로그를 붙여넣습니다. 가장 흔한 비밀/개인 데이터 유출.
- 모든 것에 대한 알람을 설정합니다. 알람 피로는 실제 알람을 묻습니다.
- 조치할 수 없는 경보입니다. 누구도 어찌할 수 없는 경고음이다.
- AI의 한계점을 의심 없이 받아들입니다. 임계값은 시스템 기록에 따라 설정되어야 합니다.
- 측정항목만 보면 됩니다. 로그와 추적이 없으면 근본 원인을 찾을 수 없는 경우가 대부분입니다.
- 알람 시간을 설정하지 않았습니다. 순간적인 변동으로 인해 잘못된 경보가 발생합니다.
요약하면
관찰 가능성; 메트릭, 로그, 트레이스를 통해 외부에서 시스템 내부를 파악하는 능력입니다. 4가지 골든 신호(대기 시간, 트래픽, 오류, 포화)는 대부분의 서비스 상태를 요약합니다. AI는 PromQL 쿼리, 경보 규칙 및 대시보드를 작성하고 대량의 로그를 요약하고 이상 현상을 찾는 데 매우 강력합니다. 그러나 자신의 시스템 기록에 대해 경보 임계값을 확인하고, 경보를 조치 지향적으로 유지하고, 로그를 마스킹하지 않고 공유하지 않는 것은 귀하의 책임입니다.
응용과제
서비스(또는 샘플 서비스)의 경우: (1) "알람 규칙 생성" 템플릿을 사용하여 오류율에 대한 알람 규칙을 생성하고 제안된 임계값을 "과거에 몇 번이나 트리거되었습니까?"로 설정합니다. 질문으로 테스트해 보세요. (2) 보유하고 있는 로그 샘플을 마스크하고 "로그 요약" 템플릿을 사용하여 분석합니다. (3) 가장 가능성이 높은 근본 원인을 확인하기 위해 어떤 지표를 살펴볼 것인지 기록해 두십시오.
체크리스트
- [ ] 저는 4개의 골든 신호를 기반으로 추적할 지표를 선택했습니다.
- [ ] 민감한 부분에 대해서는 AI에게 준 로그를 모두 마스킹했습니다.
- [ ] 각 경보가 조치 지향적이고 긴급성이 정확한지 확인했습니다.
- [ ] 시스템의 기록 데이터를 기준으로 경보 임계값을 테스트했습니다.
- [ ] 알람에 기간(기간)을 추가하여 순간적인 변동을 필터링했습니다.
- [ ] 근본 원인을 찾기 위해 메트릭 + 로그 + 추적을 함께 사용했습니다.