Consul 모니터링 개요

Consul 모니터링 개요

Consul 컨트롤 플레인과 데이터 플레인을 모니터링하는 방법의 개요를 설명해 드릴게요. 구성 요소를 추적하고 알림을 설정하면 서비스 메시의 전반적인 상태와 복원력을 유지할 수 있어요.

출처: 문서

본문

이 문서는 Consul 컨트롤 및 데이터 플레인을 모니터링하는 방법에 대한 개요를 제공해요. 이러한 구성 요소를 추적하고 알림을 설정함으로써 서비스 메시의 전반적인 상태와 복원력을 더 잘 유지할 수 있어요.

배경

Consul 데이터센터는 서비스 디스커버리나 서비스 메시 같은 기본 Consul 작업을 수행할 수 있는 가장 작은 단위의 Consul 인프라예요. 데이터센터에는 최소 하나의 Consul 서버 에이전트가 포함되지만, 실제 배포에는 3개 또는 5개의 서버 에이전트와 여러 Consul 클라이언트 에이전트가 포함돼요.

Consul 컨트롤 플레인은 서비스 및 노드 IP 주소, 헬스 체크, 구성을 포함한 모든 상태 정보를 저장하는 서버 에이전트로 구성돼요. 또한 컨트롤 플레인은 메시 보안, 서비스 디스커버리 지원, 헬스 체크, 정책 적용 및 기타 유사한 운영 문제를 담당해요. 또한 컨트롤 플레인은 노드 및 서비스 헬스 상태를 Consul 클러스터에 보고하는 클라이언트 에이전트를 포함해요. 일반적인 배포에서는 데이터센터의 모든 컴퓨트 노드에서 클라이언트 에이전트를 실행해야 해요.

Consul 데이터 플레인은 각 서비스 인스턴스 옆에 로컬로 배포된 프록시로 구성돼요. 사이드카 프록시라고 하는 이러한 프록시는 컨트롤 플레인에서 메시 구성 데이터를 받고, 로컬 서비스 인스턴스와 네트워크의 다른 서비스 간의 네트워크 통신을 제어해요. 사이드카 프록시는 인바운드 및 아웃바운드 서비스 연결을 처리하고 서비스 간 TLS 연결이 확인되고 암호화되도록 보장해요.

Kubernetes 워크로드가 있다면 클라이언트 에이전트 대신 Envoy 프록시를 배포하는 대체 서비스 메시 구성으로 Consul을 실행할 수도 있어요. 자세한 내용은 Consul dataplanes로 간소화된 서비스 메시를 참고해 주세요.

Consul 컨트롤 플레인 모니터링

Consul 컨트롤 플레인은 다음 구성 요소로 구성돼요:

  • Consul 서버와 클라이언트 간의 RPC 통신.
  • Envoy Layer 7 프록시에 대한 데이터 플레인 라우팅 지침.
  • Serf 트래픽: LAN 및 WAN
  • Consul 클러스터 피어링 및 서버 연합

비정상 동작 감지를 위해 컨트롤 플레인 구성 요소에 대한 기준선과 알림 임계값을 설정하고 모니터링하는 것이 중요해요. 이러한 알림은 Consul 클러스터 업그레이드, 구성 변경, 리더십 변경 같은 계획된 이벤트에 의해 트리거될 수도 있다는 점에 유의해 주세요.

Consul 컨트롤 플레인을 모니터링하는 데 도움을 주기 위해 다음에 대한 기준선과 표준 편차를 설정할 것을 권장해요:

  • 서버 상태
  • 리더십 변경
  • 핵심 지표
  • Autopilot
  • 네트워크 활동
  • 인증 기관 만료

낮은 네트워크 지연의 고성능 네트워크를 갖는 것이 중요해요. 모든 데이터센터의 gossip 네트워크 지연이 모든 Consul 에이전트에 대해 8ms 지연 예산 내에 있는지 확인해 주세요. 자세한 내용은 프로덕션 서버 요구 사항을 참고해 주세요.

Raft 권장 사항

Consul은 컨센서스 프로토콜에 Raft를 사용해요. Raft goroutine의 높은 포화는 나머지 시스템의 지연 상승으로 이어질 수 있고 Consul 클러스터가 불안정해질 수 있어요. 결과적으로 컨트롤 플레인 상태를 추적하기 위해 Raft를 모니터링하는 것이 중요해요. 컨트롤 플레인을 정상으로 유지하기 위해 다음 작업을 권장해요:

  • Raft 스레드 포화가 50%를 초과할 때 알림을 보내는 경보를 만들어요.
  • Consul이 많은 양의 데이터와 높은 쓰기 처리량을 처리할 때 Raft 복제 용량을 모니터링해요.
  • Consul 클러스터를 안정적으로 유지하려면 raft_multiplier를 낮춰 주세요. raft_multiplier 값은 Consul의 확장 계수를 정의해요. raft_multiplier의 기본값은 5예요.

짧은 승수는 실패 감지와 선거 시간을 최소화하지만 고지연 상황에서는 자주 트리거될 수 있어요. 이는 지속적인 리더십 교체와 관련된 가용성 부족을 일으킬 수 있어요. 높은 승수는 가짜 실패가 리더십 교체를 일으킬 가능성을 줄이지만, 실제 실패를 감지하는 데 더 오래 걸리고 따라서 Consul 클러스터 가용성 복구에 더 오래 걸려요.

더 높은 지연의 넓은 네트워크는 더 큰 raft_multiplier 값으로 더 잘 작동해요.

Raft는 데이터 저장과 자체 상태 유지에 BoltDB를 사용해요. Raft 성능 문제를 해결할 때는 Bolt DB 성능 지표를 참고해 주세요.

Consul 데이터 플레인 모니터링

Consul의 데이터 플레인은 서비스 간 통신을 통해 서로 상호 작용하는 Consul 클라이언트 또는 Connect 프록시로 구성돼요. 서비스 간 트래픽은 항상 데이터 플레인 내에 유지되며, 컨트롤 플레인은 트래픽 규칙만 적용해요. 서비스 간 통신을 모니터링하는 것은 중요하지만, 메시, 인그레스, 터미네이팅 게이트웨이를 통해 연합된 Consul 클러스터 간에 서로 통신하는 여러 서비스가 있는 엔터프라이즈 설정에서는 매우 복잡해질 수 있어요.

서비스 모니터링

다음 서비스 관련 정보를 추출할 수 있어요:

  • catalog 명령 또는 Consul UI를 사용하여 Consul 데이터센터의 모든 등록된 서비스를 쿼리해요.
  • /agent/service/:service_id API 엔드포인트를 사용하여 개별 서비스를 쿼리해요. Connect 프록시는 이 엔드포인트를 사용하여 내장 구성을 발견해요.

프록시 모니터링

Envoy는 Consul 서비스 메시에 대한 지원되는 Connect 프록시예요. 가상 머신(VM)의 경우 Envoy는 사이드카 서비스 프로세스로 시작해요. Kubernetes의 경우 Envoy는 Kubernetes 서비스 pod의 사이드카 컨테이너로 시작해요. Consul 버전과 호환되는 Envoy 버전을 찾으려면 지원되는 Envoy 버전 문서를 참고해 주세요.

서비스 메시 문제를 해결할 때는 Consul 로그를 trace 또는 debug로 설정해 주세요. 다음 예시 어노테이션은 Envoy 로깅을 debug로 설정해요.

annotations:
  consul.hashicorp.com/envoy-extra-args: '--log-level debug --disable-hot-restart'

자세한 내용은 Envoy 사이드카 pod에서 로깅 활성화 문서를 참고해 주세요.

Envoy 관리 인터페이스

서비스 간 통신 문제를 해결하려면 Envoy 호스트 통계를 모니터링해 주세요. Envoy는 기본적으로 포트 19000에서 서버의 다양한 측면을 쿼리하고 수정하는 데 사용할 수 있는 로컬 관리 인터페이스를 노출해요. Envoy는 또한 기본적으로 포트 20000에서 메시의 다른 프록시로부터 mTLS 연결을 받는 공개 리스너 포트를 노출해요.

Envoy가 노출하는 모든 엔드포인트는 Envoy가 실행되는 노드의 포트 19000에서 사용할 수 있어요. 노드는 Kubernetes의 pod이거나 Consul Service Mesh를 실행하는 VM일 수 있어요. 예를 들어 Envoy 포트를 로컬 머신으로 포워딩하면 http://localhost:19000/에서 Envoy 관리 인터페이스에 접근할 수 있어요.

다음 Envoy 관리 인터페이스 엔드포인트가 특히 유용해요:

  • listeners 엔드포인트는 localhost에서 실행되는 모든 리스너를 나열해요. 이를 통해 업스트림 서비스가 Envoy에 올바르게 바인딩되고 있는지 확인할 수 있어요.
$ curl http://localhost:19000/listeners
public_listener:192.168.19.168:20000::192.168.19.168:20000
Outbound_listener:127.0.0.1:15001::127.0.0.1:15001
  • /clusters 엔드포인트는 서비스 요청 및 mTLS 관련 데이터 같은 xDS 클러스터에 대한 정보를 표시해요. 다음 예시는 잘린 출력을 보여줘요.
$ http://localhost:19000/clusters
`local_app::observability_name::local_app
local_app::default_priority::max_connections::1024
local_app::default_priority::max_pending_requests::1024
local_app::default_priority::max_requests::1024
local_app::default_priority::max_retries::3
local_app::high_priority::max_connections::1024
local_app::high_priority::max_pending_requests::1024
local_app::high_priority::max_requests::1024
local_app::high_priority::max_retries::3
local_app::added_via_api::true
## ...

가능한 Consul 관리 엔드포인트의 전체 목록을 찾으려면 기본 관리 인터페이스(http://localhost:19000)를 방문해 주세요. 자세한 내용은 Envoy 문서를 참고해 주세요.

다음 단계

이 가이드에서는 Consul 컨트롤 및 데이터 플레인을 모니터링하기 위한 권장 사항을 배웠어요.

Consul 호스트 및 인스턴스 리소스 모니터링에 대해 알아보려면 모니터링 모범 사례 문서를 방문해 주세요.

더 알아보기 (Learn more)