장애 감지

작성자

익명

작성일

2026.07.31

조회수

버전

장애 감지 Observability SRE 이상 감지 Prometheus 가십 프로토콜 그레이 실패 헬스 체크 중급

📋 문서 버전

이 문서는 2개의 버전이 있습니다. 현재 최신 버전을 보고 있습니다.

장애 감지 (Fault Detection)

개요

장애 감지(Fault Detection)는 컴퓨터 시스템, 네트워크, 소프트웨어 애플리케이션 등에서 예기치 않은 오류, 고장, 또는 비정상적인 상태가 발생했음을 식별하고 알림을 생성하는 프로세스를 의미합니다. 현대의 분산 시스템과 클라우드 인프라에서 장애 감지는 시스템의 가용성(Availability), 신뢰성(Reliability), 그리고 내구성(Durability)을 보장하기 위한 핵심 요소입니다.

단순히 시스템이 '다운'되었는지 확인하는 것을 넘어, 성능 저하, 메모리 누수, 네트워크 지연 증가 등 미묘한 이상 징후를 조기에 포착하여 사전에 대응할 수 있도록 하는 것이 현대 장애 감지의 주요 목표입니다. 이는 종종 모니터링(Monitoring), 로깅(Logging), 트레이싱(Tracing)과 함께 Observability(관측성)의 중요한 구성 요소로 간주됩니다.

장애 감지의 핵심 개념과 용어

장애 감지 시스템을 설계하거나 이해하기 위해 반드시 알아야 할 주요 용어들은 다음과 같습니다.

메트릭(Metric): 시스템의 상태를 수치화한 데이터입니다. CPU 사용률, 메모리 사용량, 요청 처리 시간(RPS), 에러율 등이 해당됩니다.
로그(Log): 시스템이 발생한 사건이나 상태를 시계열 순서로 기록한 텍스트 데이터입니다. 디버깅에 필수적이지만, 실시간 분석에는 적합하지 않을 수 있습니다.
트레이스(Trace): 하나의 요청이 시스템 내 여러 컴포넌트를 거치며 생성된 전체 흐름을 추적하는 데이터입니다. 분산 시스템에서 병목 지점이나 오류 원인을 파악하는 데 사용됩니다.
SLI/SLO/SLA:
- SLI(Service Level Indicator): 서비스의 품질을 측정하는 지표 (예: 성공률).
- SLO(Service Level Objective): 달성해야 할 목표치 (예: 99.9% 가용성).
- SLA(Service Level Agreement): 사용자와의 계약상 보장 수준.
임계값(Threshold): 정상 범위를 벗어난다고 판단하는 기준 값입니다.
알람(Alert): 임계값 초과 또는 이상 징후 감지 시 생성되는 경고 메시지입니다.

장애 감지의 주요 기법

장애 감지는 감지 대상과 기법에 따라 다양한 방식으로 분류됩니다.

1. 기반 감지 (Baseline-based Detection)

과거의 정상적인 데이터 패턴을 학습하여 현재 상태와 비교하는 방식입니다. * 정적 임계값: 고정된 값(예: CPU > 90%)을 기준으로 합니다. 구현이 단순하지만, 트래픽 패턴의 변화에 유연하게 대응하기 어렵습니다. * 동적 임계값: 시간대, 요일, 트래픽량 등을 고려하여 자동으로 기준선을 조정합니다. 머신러닝 알고리즘을 활용하여 정상 범위를 예측하는 방식이 포함됩니다.

2. 이상 감지 (Anomaly Detection)

명확한 임계값 없이 데이터의 분포나 패턴에서 벗어난 지점을 탐지합니다. * 통계적 방법: 표준편차, 이동 평균 등을 사용하여 통계적 유의미성을 판단합니다. * 머신러닝 기반 방법: Isolation Forest, Autoencoder 등의 알고리즘을 사용하여 다차원 데이터에서 비정상 패턴을 식별합니다.

3. 헬스 체크 (Health Check)

시스템이나 서비스의 생존 여부를 주기적으로 확인하는 간단한 기법입니다. * HTTP 헬스 체크: 특정 엔드포인트에 HTTP 요청을 보내 200 OK 응답을 받으면 정상으로 간주합니다. * TCP 헬스 체크: 포트 연결 성공 여부를 확인합니다. * 프라이빗 헬스 체크: 서비스 내부의 복잡한 의존성(데이터베이스 연결, 캐시 상태 등)까지 종합적으로 판단합니다.

장애 감지 시스템의 아키텍처

일반적인 장애 감지 시스템은 다음과 같은 데이터 흐름을 가집니다.

수집(Collection): 에이전트(Agent) 또는 사이드카(Sidecar)를 통해 메트릭, 로그, 트레이스 데이터를 수집합니다.
저장(Storage): 시계열 데이터베이스(TSDB, 예: Prometheus, InfluxDB)에 메트릭을 저장하고, 로그 관리 시스템(예: ELK Stack, Splunk)에 로그를 저장합니다.
분석(Analysis): 저장된 데이터를 기반으로 규칙 엔진(Rule Engine)이나 머신러닝 모델을 통해 이상 징후를 탐지합니다.
알림(Notification): 감지된 장애를 Slack, PagerDuty, 이메일, SMS 등을 통해 담당자에게 전달합니다.
시각화(Dashboard): Grafana와 같은 도구를 통해 실시간으로 시스템 상태를 시각적으로 제공합니다.

# 예시: Prometheus의 알람 규칙 정의
groups:
  - name: example
    rules:
      - alert: HighErrorRate
        expr: rate(http_requests_total{status="500"}[5m]) > 0.05
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "High error rate detected"
          description: "More than 5% of requests are failing."

장애 감지의 도전 과제

알람 피로(Alert Fatigue): 너무 많은 알람이 발생하여 실제 중요한 장애를 놓치는 현상입니다. 이를 해결하기 위해 알람의 우선순위 분류, 알람 억제(Reduction), 그리고 정확한 임계값 설정이 필요합니다.
데이터의 양과 복잡성: 대규모 분산 시스템에서는 수백만 개의 메트릭과 로그가 생성되므로, 효율적인 수집과 저장, 그리고 빠른 분석이 필요합니다.
가짜 양성(False Positive)과 가짜 음성(False Negative): 정상 상태를 장애로 오인하거나, 실제 장애를 놓치는 문제를 최소화해야 합니다.

결론

장애 감지는 단순히 문제를 찾는 것을 넘어, 시스템의 건강 상태를 지속적으로 이해하고 신속하게 대응하기 위한 전략적 활동입니다. 효과적인 장애 감지 시스템을 구축하기 위해서는 적절한 메트릭 정의, 정확한 임계값 설정, 그리고 명확한 대응 절차(SOP)가 함께 마련되어야 합니다. 또한, 자동화된 대응(Auto-remediation)과 머신러닝 기반의 이상 감지 기술을 도입하여 시스템의 복잡성에 대응하는 것이 현대 IT 인프라의 추세입니다.

노드 수준의 장애 감지 (Node-level Fault Detection)

개별 서버나 가상 머신(VM)과 같은 물리적/논리적 단위에서 발생하는 하드웨어 및 OS 수준의 장애를 감지하는 단계입니다. 서비스 애플리케이션이 응답하기 전, 하위 인프라 계층에서 발생하는 치명적인 오류를 식별하는 것이 목적입니다.

커널 및 OS 장애: 커널 패닉(Kernel Panic), 블루스크린(BSOD), OOM(Out Of Memory) 킬러에 의한 프로세스 강제 종료 등을 감지합니다.
하드웨어 장애: CPU 과열, 메모리 ECC 에러, 전원 공급 장치(PSU) 고장 등을 하드웨어 센서를 통해 감지합니다.
스토리지 장애: 디스크 I/O 오류, 파일 시스템 읽기 전용(Read-only) 전환, 디스크 풀(Disk Full) 상태 등을 감지합니다.
네트워크 인터페이스 장애: NIC(Network Interface Card)의 물리적 링크 다운, 패킷 드롭 급증, 인터페이스 설정 오류 등을 감지합니다.

분산 환경의 노드 상태 확인 기법

클러스터 환경에서는 특정 노드의 생존 여부를 판단하기 위해 단일 지점의 확인보다는 노드 간 상호 확인 및 합의 과정을 거칩니다.

하트비트와 가십 프로토콜 비교

구분	하트비트 (Heartbeat)	가십 프로토콜 (Gossip Protocol)
작동 방식	노드가 중앙 서버(또는 마스터)에 주기적으로 신호를 보냄	노드들이 무작위로 선택한 이웃 노드와 상태 정보를 교환
구조	중앙 집중형 (Centralized)	분산형 (Decentralized / P2P)
확장성	노드 증가 시 중앙 서버에 부하 집중 (Scalability 한계)	노드 수 증가에도 부하가 분산되어 확장성이 매우 높음
전파 속도	즉각적 (마스터가 즉시 인지)	점진적 (정보가 네트워크 전체로 퍼지는 시간이 소요됨)
주요 사례	Kubernetes (Kubelet $\rightarrow$ API Server)	Apache Cassandra, Consul, Redis Cluster

쿼럼(Quorum) 기반 장애 판정

단일 노드의 판단으로 장애를 확정 짓지 않고, 클러스터 내 과반수 이상의 노드가 특정 노드에 도달할 수 없다고 합의했을 때 해당 노드를 '장애' 상태로 판정하는 방식입니다. 이는 네트워크 파티션(Network Partition) 상황에서 잘못된 장애 판정으로 인한 데이터 불일치를 방지합니다.

심화 장애 개념: 그레이 실패와 부분 장애

단순한 'Up/Down' 상태로 구분할 수 없는 복잡한 장애 형태를 정의합니다.

좀비 노드 (Zombie Node): 프로세스는 살아있어 헬스 체크에는 응답하지만, 실제 비즈니스 로직을 처리하지 못하거나 응답 시간이 극도로 느려져 사실상 기능을 상실한 상태입니다.
부분 장애 (Partial Failure): 시스템의 일부 컴포넌트만 고장 난 상태입니다. 예를 들어, API 서버는 정상이나 특정 DB 커넥션 풀만 고갈되어 일부 요청만 실패하는 경우입니다.
그레이 실패 (Gray Failure): 시스템이 완전히 중단되지 않았으나, 성능 저하나 간헐적 오류가 발생하는 '회색 지대'의 장애입니다. 외부 모니터링 도구(White-box)에서는 정상으로 보이지만, 실제 사용자(Black-box)는 장애를 겪는 현상이 대표적입니다.
- 발생 사례:
  - 패킷 손실(Packet Loss): 네트워크 스위치의 특정 포트 불량으로 인해 10%의 패킷만 유실되는 경우, 헬스 체크(Ping)는 성공하지만 실제 대용량 데이터 전송 시 타임아웃이 빈번하게 발생합니다.
  - 디스크 슬로우 (Disk Slowness): 디스크가 완전히 깨지지는 않았으나, 배드 섹터로 인해 특정 블록 읽기 시 I/O Wait가 급증하여 전체 서비스 응답 속도가 느려지는 경우입니다.
  - 부분적 네트워크 단절: 특정 랙(Rack) 내의 노드들끼리는 통신이 되지만, 외부 게이트웨이와의 통신만 간헐적으로 끊기는 경우입니다.

인프라 수준의 헬스 체크 보강

단순한 HTTP 200 응답 확인을 넘어, 시스템의 실질적인 가용성을 판단하기 위해 다음과 같은 인프라 지표를 체크합니다.

리소스 고갈 체크:
- Disk Full: 루트 파티션이나 로그 저장 경로의 잔여 용량이 임계치(예: 5%) 미만인지 확인합니다.
- OOM 위험: 가용 메모리가 극도로 낮아 커널의 OOM Killer가 작동할 가능성이 높은지 감시합니다.
하드웨어 상태 체크:
- S.M.A.R.T 정보: HDD/SSD의 재할당된 섹터 수, 읽기/쓰기 오류율 등을 통해 디스크의 물리적 수명 및 고장 징후를 사전에 감지합니다.
- 온도 센서: CPU 및 메인보드 온도가 임계치를 초과하여 쓰로틀링(Throttling)이 발생하는지 확인합니다.

노드 에이전트를 통한 메트릭 수집

OS 커널 및 하드웨어 수준의 데이터를 수집하기 위해 Node Exporter와 같은 전용 에이전트를 사용합니다. 에이전트는 커널의 /proc 및 /sys 파일 시스템에서 데이터를 읽어 메트릭 형태로 노출합니다.

Node Exporter 주요 수집 메트릭

CPU: node_cpu_seconds_total (모드별 CPU 사용 시간), node_load1/5/15 (시스템 부하 평균)
Memory: node_memory_MemAvailable_bytes (가용 메모리), node_memory_SwapTotal_bytes (스왑 메모리 사용량)
Disk: node_disk_io_time_seconds_total (디스크 I/O 시간), node_filesystem_avail_bytes (파일 시스템 가용 공간)
Network: node_network_receive_bytes_total (수신 트래픽), node_network_transmit_drop_total (송신 패킷 드롭 수)
OS/Kernel: node_context_switches_total (컨텍스트 스위칭 횟수), node_boot_time_seconds (부팅 시간)

📝 마크다운 원본

이 문서의 마크다운 원본 내용입니다.

# 장애 감지 (Fault Detection)

## 개요

**장애 감지(Fault Detection)**는 컴퓨터 시스템, 네트워크, 소프트웨어 애플리케이션 등에서 예기치 않은 오류, 고장, 또는 비정상적인 상태가 발생했음을 식별하고 알림을 생성하는 프로세스를 의미합니다. 현대의 분산 시스템과 클라우드 인프라에서 장애 감지는 시스템의 가용성(Availability), 신뢰성(Reliability), 그리고 내구성(Durability)을 보장하기 위한 핵심 요소입니다.

단순히 시스템이 '다운'되었는지 확인하는 것을 넘어, 성능 저하, 메모리 누수, 네트워크 지연 증가 등 미묘한 이상 징후를 조기에 포착하여 사전에 대응할 수 있도록 하는 것이 현대 장애 감지의 주요 목표입니다. 이는 종종 **모니터링(Monitoring)**, **로깅(Logging)**, **트레이싱(Tracing)**과 함께 **Observability(관측성)**의 중요한 구성 요소로 간주됩니다.

## 장애 감지의 핵심 개념과 용어

장애 감지 시스템을 설계하거나 이해하기 위해 반드시 알아야 할 주요 용어들은 다음과 같습니다.

*   **메트릭(Metric)**: 시스템의 상태를 수치화한 데이터입니다. CPU 사용률, 메모리 사용량, 요청 처리 시간(RPS), 에러율 등이 해당됩니다.
*   **로그(Log)**: 시스템이 발생한 사건이나 상태를 시계열 순서로 기록한 텍스트 데이터입니다. 디버깅에 필수적이지만, 실시간 분석에는 적합하지 않을 수 있습니다.
*   **트레이스(Trace)**: 하나의 요청이 시스템 내 여러 컴포넌트를 거치며 생성된 전체 흐름을 추적하는 데이터입니다. 분산 시스템에서 병목 지점이나 오류 원인을 파악하는 데 사용됩니다.
*   **SLI/SLO/SLA**:
    *   **SLI(Service Level Indicator)**: 서비스의 품질을 측정하는 지표 (예: 성공률).
    *   **SLO(Service Level Objective)**: 달성해야 할 목표치 (예: 99.9% 가용성).
    *   **SLA(Service Level Agreement)**: 사용자와의 계약상 보장 수준.
*   **임계값(Threshold)**: 정상 범위를 벗어난다고 판단하는 기준 값입니다.
*   **알람(Alert)**: 임계값 초과 또는 이상 징후 감지 시 생성되는 경고 메시지입니다.

## 장애 감지의 주요 기법

장애 감지는 감지 대상과 기법에 따라 다양한 방식으로 분류됩니다.

### 1. 기반 감지 (Baseline-based Detection)
과거의 정상적인 데이터 패턴을 학습하여 현재 상태와 비교하는 방식입니다.
*   **정적 임계값**: 고정된 값(예: CPU > 90%)을 기준으로 합니다. 구현이 단순하지만, 트래픽 패턴의 변화에 유연하게 대응하기 어렵습니다.
*   **동적 임계값**: 시간대, 요일, 트래픽량 등을 고려하여 자동으로 기준선을 조정합니다. 머신러닝 알고리즘을 활용하여 정상 범위를 예측하는 방식이 포함됩니다.

### 2. 이상 감지 (Anomaly Detection)
명확한 임계값 없이 데이터의 분포나 패턴에서 벗어난 지점을 탐지합니다.
*   **통계적 방법**: 표준편차, 이동 평균 등을 사용하여 통계적 유의미성을 판단합니다.
*   **머신러닝 기반 방법**: Isolation Forest, Autoencoder 등의 알고리즘을 사용하여 다차원 데이터에서 비정상 패턴을 식별합니다.

### 3. 헬스 체크 (Health Check)
시스템이나 서비스의 생존 여부를 주기적으로 확인하는 간단한 기법입니다.
*   **HTTP 헬스 체크**: 특정 엔드포인트에 HTTP 요청을 보내 200 OK 응답을 받으면 정상으로 간주합니다.
*   **TCP 헬스 체크**: 포트 연결 성공 여부를 확인합니다.
*   **프라이빗 헬스 체크**: 서비스 내부의 복잡한 의존성(데이터베이스 연결, 캐시 상태 등)까지 종합적으로 판단합니다.

## 장애 감지 시스템의 아키텍처

일반적인 장애 감지 시스템은 다음과 같은 데이터 흐름을 가집니다.

1.  **수집(Collection)**: 에이전트(Agent) 또는 사이드카(Sidecar)를 통해 메트릭, 로그, 트레이스 데이터를 수집합니다.
2.  **저장(Storage)**: 시계열 데이터베이스(TSDB, 예: Prometheus, InfluxDB)에 메트릭을 저장하고, 로그 관리 시스템(예: ELK Stack, Splunk)에 로그를 저장합니다.
3.  **분석(Analysis)**: 저장된 데이터를 기반으로 규칙 엔진(Rule Engine)이나 머신러닝 모델을 통해 이상 징후를 탐지합니다.
4.  **알림(Notification)**: 감지된 장애를 Slack, PagerDuty, 이메일, SMS 등을 통해 담당자에게 전달합니다.
5.  **시각화(Dashboard)**: Grafana와 같은 도구를 통해 실시간으로 시스템 상태를 시각적으로 제공합니다.

```yaml
# 예시: Prometheus의 알람 규칙 정의
groups:
  - name: example
    rules:
      - alert: HighErrorRate
        expr: rate(http_requests_total{status="500"}[5m]) > 0.05
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "High error rate detected"
          description: "More than 5% of requests are failing."
```

## 장애 감지의 도전 과제

*   **알람 피로(Alert Fatigue)**: 너무 많은 알람이 발생하여 실제 중요한 장애를 놓치는 현상입니다. 이를 해결하기 위해 알람의 우선순위 분류, 알람 억제(Reduction), 그리고 정확한 임계값 설정이 필요합니다.
*   **데이터의 양과 복잡성**: 대규모 분산 시스템에서는 수백만 개의 메트릭과 로그가 생성되므로, 효율적인 수집과 저장, 그리고 빠른 분석이 필요합니다.
*   **가짜 양성(False Positive)과 가짜 음성(False Negative)**: 정상 상태를 장애로 오인하거나, 실제 장애를 놓치는 문제를 최소화해야 합니다.

## 관련 문서 및 참고 자료

*   [모니터링(Monitoring)]
*   [로깅(Logging)]
*   [트레이싱(Tracing)]
*   [SRE(사이트 신뢰성 공학)]
*   [Prometheus Documentation](https://prometheus.io/docs/)
*   [Google SRE Workbook - Alerting](https://sre.google/workbook/alerting/)

## 결론

장애 감지는 단순히 문제를 찾는 것을 넘어, 시스템의 건강 상태를 지속적으로 이해하고 신속하게 대응하기 위한 전략적 활동입니다. 효과적인 장애 감지 시스템을 구축하기 위해서는 적절한 메트릭 정의, 정확한 임계값 설정, 그리고 명확한 대응 절차(SOP)가 함께 마련되어야 합니다. 또한, 자동화된 대응(Auto-remediation)과 머신러닝 기반의 이상 감지 기술을 도입하여 시스템의 복잡성에 대응하는 것이 현대 IT 인프라의 추세입니다.

## 노드 수준의 장애 감지 (Node-level Fault Detection)

개별 서버나 가상 머신(VM)과 같은 물리적/논리적 단위에서 발생하는 하드웨어 및 OS 수준의 장애를 감지하는 단계입니다. 서비스 애플리케이션이 응답하기 전, 하위 인프라 계층에서 발생하는 치명적인 오류를 식별하는 것이 목적입니다.

*   **커널 및 OS 장애**: 커널 패닉(Kernel Panic), 블루스크린(BSOD), OOM(Out Of Memory) 킬러에 의한 프로세스 강제 종료 등을 감지합니다.
*   **하드웨어 장애**: CPU 과열, 메모리 ECC 에러, 전원 공급 장치(PSU) 고장 등을 하드웨어 센서를 통해 감지합니다.
*   **스토리지 장애**: 디스크 I/O 오류, 파일 시스템 읽기 전용(Read-only) 전환, 디스크 풀(Disk Full) 상태 등을 감지합니다.
*   **네트워크 인터페이스 장애**: NIC(Network Interface Card)의 물리적 링크 다운, 패킷 드롭 급증, 인터페이스 설정 오류 등을 감지합니다.

## 분산 환경의 노드 상태 확인 기법

클러스터 환경에서는 특정 노드의 생존 여부를 판단하기 위해 단일 지점의 확인보다는 노드 간 상호 확인 및 합의 과정을 거칩니다.

### 하트비트와 가십 프로토콜 비교

| 구분 | 하트비트 (Heartbeat) | 가십 프로토콜 (Gossip Protocol) |
| :--- | :--- | :--- |
| **작동 방식** | 노드가 중앙 서버(또는 마스터)에 주기적으로 신호를 보냄 | 노드들이 무작위로 선택한 이웃 노드와 상태 정보를 교환 |
| **구조** | 중앙 집중형 (Centralized) | 분산형 (Decentralized / P2P) |
| **확장성** | 노드 증가 시 중앙 서버에 부하 집중 (Scalability 한계) | 노드 수 증가에도 부하가 분산되어 확장성이 매우 높음 |
| **전파 속도** | 즉각적 (마스터가 즉시 인지) | 점진적 (정보가 네트워크 전체로 퍼지는 시간이 소요됨) |
| **주요 사례** | Kubernetes (Kubelet $\rightarrow$ API Server) | Apache Cassandra, Consul, Redis Cluster |

### 쿼럼(Quorum) 기반 장애 판정
단일 노드의 판단으로 장애를 확정 짓지 않고, 클러스터 내 과반수 이상의 노드가 특정 노드에 도달할 수 없다고 합의했을 때 해당 노드를 '장애' 상태로 판정하는 방식입니다. 이는 네트워크 파티션(Network Partition) 상황에서 잘못된 장애 판정으로 인한 데이터 불일치를 방지합니다.

## 심화 장애 개념: 그레이 실패와 부분 장애

단순한 'Up/Down' 상태로 구분할 수 없는 복잡한 장애 형태를 정의합니다.

*   **좀비 노드 (Zombie Node)**: 프로세스는 살아있어 헬스 체크에는 응답하지만, 실제 비즈니스 로직을 처리하지 못하거나 응답 시간이 극도로 느려져 사실상 기능을 상실한 상태입니다.
*   **부분 장애 (Partial Failure)**: 시스템의 일부 컴포넌트만 고장 난 상태입니다. 예를 들어, API 서버는 정상이나 특정 DB 커넥션 풀만 고갈되어 일부 요청만 실패하는 경우입니다.
*   **그레이 실패 (Gray Failure)**: 시스템이 완전히 중단되지 않았으나, 성능 저하나 간헐적 오류가 발생하는 '회색 지대'의 장애입니다. 외부 모니터링 도구(White-box)에서는 정상으로 보이지만, 실제 사용자(Black-box)는 장애를 겪는 현상이 대표적입니다.
    *   **발생 사례**: 
        *   **패킷 손실(Packet Loss)**: 네트워크 스위치의 특정 포트 불량으로 인해 10%의 패킷만 유실되는 경우, 헬스 체크(Ping)는 성공하지만 실제 대용량 데이터 전송 시 타임아웃이 빈번하게 발생합니다.
        *   **디스크 슬로우 (Disk Slowness)**: 디스크가 완전히 깨지지는 않았으나, 배드 섹터로 인해 특정 블록 읽기 시 I/O Wait가 급증하여 전체 서비스 응답 속도가 느려지는 경우입니다.
        *   **부분적 네트워크 단절**: 특정 랙(Rack) 내의 노드들끼리는 통신이 되지만, 외부 게이트웨이와의 통신만 간헐적으로 끊기는 경우입니다.

## 인프라 수준의 헬스 체크 보강

단순한 HTTP 200 응답 확인을 넘어, 시스템의 실질적인 가용성을 판단하기 위해 다음과 같은 인프라 지표를 체크합니다.

*   **리소스 고갈 체크**: 
    *   **Disk Full**: 루트 파티션이나 로그 저장 경로의 잔여 용량이 임계치(예: 5%) 미만인지 확인합니다.
    *   **OOM 위험**: 가용 메모리가 극도로 낮아 커널의 OOM Killer가 작동할 가능성이 높은지 감시합니다.
*   **하드웨어 상태 체크**:
    *   **S.M.A.R.T 정보**: HDD/SSD의 재할당된 섹터 수, 읽기/쓰기 오류율 등을 통해 디스크의 물리적 수명 및 고장 징후를 사전에 감지합니다.
    *   **온도 센서**: CPU 및 메인보드 온도가 임계치를 초과하여 쓰로틀링(Throttling)이 발생하는지 확인합니다.

## 노드 에이전트를 통한 메트릭 수집

OS 커널 및 하드웨어 수준의 데이터를 수집하기 위해 **Node Exporter**와 같은 전용 에이전트를 사용합니다. 에이전트는 커널의 `/proc` 및 `/sys` 파일 시스템에서 데이터를 읽어 메트릭 형태로 노출합니다.

### Node Exporter 주요 수집 메트릭
*   **CPU**: `node_cpu_seconds_total` (모드별 CPU 사용 시간), `node_load1/5/15` (시스템 부하 평균)
*   **Memory**: `node_memory_MemAvailable_bytes` (가용 메모리), `node_memory_SwapTotal_bytes` (스왑 메모리 사용량)
*   **Disk**: `node_disk_io_time_seconds_total` (디스크 I/O 시간), `node_filesystem_avail_bytes` (파일 시스템 가용 공간)
*   **Network**: `node_network_receive_bytes_total` (수신 트래픽), `node_network_transmit_drop_total` (송신 패킷 드롭 수)
*   **OS/Kernel**: `node_context_switches_total` (컨텍스트 스위칭 횟수), `node_boot_time_seconds` (부팅 시간)

AI 생성 콘텐츠 안내

이 문서는 AI 모델(gemma-4-31b)에 의해 생성된 콘텐츠입니다.

주의사항: AI가 생성한 내용은 부정확하거나 편향된 정보를 포함할 수 있습니다. 중요한 결정을 내리기 전에 반드시 신뢰할 수 있는 출처를 통해 정보를 확인하시기 바랍니다.

위키너와나