모래성 말고 철옹성

Elastic APM 이란Elastic 플랫폼 위에 구축된 APM(Application Performance Monitoring) 시스템소프트웨어 서비스를 실시간으로 모니터링할 수 있게 함응답 시간에 대한 자세한 성능 정보를 수집예: 데이터베이스 쿼리, 캐시 호출, HTTP 요청 등처리되지 않은 오류 및 예외를 자동으로 수집오류는 주로 stacktrace를 기반으로 그룹화새로운 오류가 발생했을 때 쉽게 식별하고, 발생 횟수도 파악할 수 있음호스트 수준의 기본 메트릭과 에이전트 별 메트릭 모니터링도 지원Elastic APM 의 구성요소Elastic APM 은 네 가지 요소로 구성APM agentsElastic APM integrationElasticsearchKibana일반적으로 이 네 가지 구성 요소로 ..

Log 란?로그(log)는 시스템, 애플리케이션, 장치, 또는 심지어 사람의 활동을 기록한 것근본적으로는 사실 timestamp + data로그의 생애 주기 (ELK Stack)Elastic Agent가 로그를 수집하고 Elasticsearch 클러스터로 전송Hot-Warm 아키텍처로 로그 수명 주기 관리처음엔 Hot 노드에 저장시간이 지나면 Warm 노드로 이동이후에는 삭제되거나 Cold/Frozen 티어로 이동 가능로그가 클러스터 내에 있는 동안에는 어느 티어에 있든지 검색 및 분석이 가능Timestamp에 대해타임스탬프 처리의 어려움 존재다양한 포맷 존재시간대 처리 복잡Elasticsearch 권장 포맷기본적으로 ISO 8601 형식여러 시간 포맷도 설정을 통해 수집 가능ISO 8601의 장점명확하..

Elastic Agent 란?에이전트(Agent)는 Integrations를 호스트 서버에 전송정책(Policy)은 각 호스트에서 어떤 Integrations 기능을 사용할지를 정의Integraions 기능은 다양한 데이터 소스를 어떻게 추출하고 전송할지에 대한 정보를 포함]IntegrationsIntegrations는 외부 서비스와 시스템을 Elastic과 연동함빠르게 시스템에 대한 인사이트와 대응을 보조새로운 데이터 소스 수집 가능Integrations는 종종 기본으로 제공되는 기능(out-of-the-box assets)과 함께 제공되며, 여기에는 대시보드, 시각화 도구, 파이프라인 등이 포함Elastic Agent policies어떤 integration을 실행할지, 어떤 호스트에서 실행할지를 지..

Uptime 가동시간시스템이 살아있지 않으면 관측할 수 없음따라서 Observability는 보통 "시스템이 살아있나?" 부터 시작HeartbeatUptime 데이터를 수집하고 ship하는 agentICMPv4 and v6 (echo requests)requires root accessTCP사용자 정의 페이로드를 보내고 받음으로써 엔드포인트 확인HTTP호스트가 예상한 응답을 반환하는지 확인e.g. 상태 코드, 응답 헤더 또는 콘텐츠 등TCP와 HTTP 모니터는 모두 SSL/TLS를 지원일부 프록시 설정도 지원용어 정리ICMP (Internet Control Message Protocol)인터넷 제어 메시지 프로토콜IP 동작에서 진단이나 제어로 사용되거나 오류에 대한 응답으로 만들어진 메시지인터넷/통신 상..

Observability가 필요한 이유현대화된 시스템들분산 시스템MSA데이터 사일로이런 현대화된 시스템들에서 우리는 운영하는데 있어 어려움이 있음장애의 원인 파악SLA 충족 여부Observability 란?가용성, 확장성 등과 같은 소스트웨어에서 비기능적 요구사항Monitoring과 다른점Monitoring은 알고있는 장애 상황에 대해 알게해줌 (CPU XX% 이상 시 장애 등)Observability는 이전에 없었던 예상치 못했던 장애에 대해 알게해줌 (이전에 없던 장애인데, 특수한 조건에서 장애 발생)Elastic Observability모든 Obserrvability data를 하나의 스택에 저장통합 관측 알림 솔루션

쿠버네티스 아키텍처 톺아보기쿠버네티스(Kubernetes)는 컨테이너 오케스트레이션을 위한 플랫폼이다. 컨트롤 플레인(Control Plane), 워커 노드(Worker Node), 애드온(Add-ons) 이렇게 세 가지 부분으로 나누어 알아보자. 🏗 컨트롤 플레인 (Control Plane)쿠버네티스 클러스터의 두뇌 역할. API 서버: 쿠버네티스의 모든 요청을 처리하는 중심 허브컨트롤러 매니저: 클러스터 상태를 원하는 상태로 유지스케줄러: 워커 노드에 적절한 파드를 배치etcd: 클러스터의 상태 정보를 저장하는 키-값 저장소🏭 워커 노드 (Worker Node)컨테이너가 실제로 실행되는 곳 Kubelet: 컨트롤 플레인의 명령을 받아 컨테이너를 관리Kube Proxy: 네트워크 통신을 담당컨테이너..

Service의 역할쿠버네티스에서 Service는 파드(Pod)들이 안정적으로 네트워크를 통해 통신할 수 있도록 도와주는 리소스다. 각 파드는 고유한 IP를 가지지만, 동적으로 변경될 수 있기 때문에 직접 접근하는 것이 어렵다. 이를 해결하기 위해 Service가 존재하며, 특정 네트워크 정책을 설정하여 안정적인 접근을 가능하게 한다.네트워크 추상화: 파드가 변경되더라도 동일한 네트워크 주소를 통해 접근할 수 있도록 한다.로드 밸런싱: 여러 개의 파드로 트래픽을 분산시켜 부하를 조절한다.디스커버리: DNS와 연동하여 내부 또는 외부 서비스 탐색이 용이하도록 지원한다.쿠버네티스에서 Service를 생성할 때, spec.type 필드를 통해 동작 방식을 정의할 수 있다. 주요한 세 가지 유형은 다음과 같다...

1분 쿠버네티스QoS (Quality of Service)쿠버네티스에서 QoS는 파드(Pod)의 리소스 우선순위를 결정하는 역할을 한다. 노드에 리소스가 부족할 때 우선순위가 낮은 파드가 먼저 종료되므로, 서비스 안정성을 위해 QoS 설정이 중요하다.QoS 클래스BestEffort: 리소스 request/limit 없음 → 가장 먼저 종료됨Burstable: request보다 더 많이 사용할 수 있음 → 중간 우선순위Guaranteed: request=limit → 가장 높은 우선순위샘플apiVersion: v1kind: Podmetadata: name: qos-examplespec: containers: - name: guaranteed-container image: nginx reso..