InfoGrab Docs

자체 호스팅 클러스터의 주요 메트릭

요약

이 가이드는 Auth 서비스와 Proxy 서비스가 보고하는 메트릭을 중심으로 자체 호스팅 Teleport 클러스터 모니터링을 시작하는 데 사용해야 할 메트릭을 설명합니다. 사용 가능한 모든 메트릭의 참조는 Teleport 메트릭 참조를 참조하세요.

이 가이드는 Auth 서비스와 Proxy 서비스가 보고하는 메트릭을 중심으로 자체 호스팅 Teleport 클러스터 모니터링을 시작하는 데 사용해야 할 메트릭을 설명합니다. Teleport Enterprise (Cloud)를 사용하는 경우 Teleport 팀이 이러한 메트릭을 모니터링하고 대응합니다.

사용 가능한 모든 메트릭의 참조는 Teleport 메트릭 참조를 참조하세요.

이 가이드는 Teleport Auth 서비스와 Proxy 서비스를 실행하는 모든 인스턴스의 컴퓨팅 리소스(예: CPU, 메모리, 디스크, 대역폭, 열린 파일 디스크립터)를 이미 모니터링하고 있다고 가정합니다.

메트릭 활성화#

Teleport's diagnostic HTTP endpoints are disabled by default. You can enable them via:

Ensure you can connect to the diagnostic endpoint 
Verify that Teleport is now serving the diagnostics endpoint:

```code
$ curl http://127.0.0.1:3000/healthz
```

이렇게 하면 http://127.0.0.1:3000/metrics 엔드포인트가 활성화되어 Teleport가 추적하는 메트릭을 제공합니다. Prometheus 수집기와 호환됩니다.

Grafana 대시보드

Grafana 대시보드 템플릿은 examples/grafana/teleport-dashboard.json에서 찾을 수 있습니다.

백엔드 작업#

Auth 서비스에 정상적인 클러스터 상태 백엔드가 없으면 Teleport 클러스터는 작동할 수 없습니다. Auth 서비스가 백엔드에서 읽고 쓰는 능력을 추적해야 합니다.

Auth 서비스는 여러 가능한 백엔드에 연결할 수 있습니다. Teleport 백엔드 메트릭 외에도, 이러한 메트릭이 문제가 있는 값을 보여줄 경우 백엔드 인프라의 메트릭과 연관 지을 수 있도록 선택한 백엔드에 대한 모니터링도 설정해야 합니다.

백엔드 작업 처리량 및 가용성#

각 백엔드 작업에서 Auth 서비스는 메트릭을 증가시킵니다. 백엔드 작업 메트릭의 형식은 다음과 같습니다:

teleport_backend_[_failed]_total

작업이 오류를 초래하면 Auth 서비스는 메트릭 이름에 _failed 세그먼트를 추가합니다. 예를 들어, 레코드 생성에 성공하면 teleport_backend_write_requests_total 메트릭이 증가합니다. 생성 작업이 실패하면 Auth 서비스는 대신 teleport_backend_write_requests_failed_total을 증가시킵니다.

다음 백엔드 작업 메트릭을 사용할 수 있습니다:

작업 증가되는 메트릭 이름
항목 생성 write_requests
항목 수정, 없으면 생성 write_requests
항목 업데이트 write_requests
버전이 일치하면 항목을 조건부 업데이트 write_requests
항목 범위 나열 batch_read_requests
단일 항목 가져오기 read_requests
항목 비교 및 교환 write_requests
항목 삭제 write_requests
버전이 일치하면 항목을 조건부 삭제 write_requests
업데이트가 실패하면 쓰기가 실패하는 업데이트 배치를 원자적으로 작성 write_requests와 atomic_write_requests 모두
항목 범위 삭제 batch_write_requests
항목의 keepalive 상태 업데이트 write_requests

백엔드 쓰기가 실패하는 동안, Teleport 프로세스는 실패 원인이 예상된 경우 backend_write_requests_failed_precondition_total 메트릭도 증가시킵니다. 예를 들어, 레코드가 이미 존재하면 생성 작업 중에, 레코드를 찾을 수 없으면 업데이트 또는 삭제 작업 중에, 리소스가 동시에 수정된 경우 원자 쓰기 중에 메트릭이 증가합니다. 이러한 조건들은 모두 정상적으로 작동하는 Teleport 클러스터에서 유지될 수 있습니다.

backend_write_requests_failed_precondition_total은 backend_write_requests_failed_total이 증가할 때마다 증가하며, 잠재적으로 예상된 쓰기 실패와 예상치 못한 문제가 있는 실패를 구별하는 데 사용할 수 있습니다.

백엔드 작업 메트릭을 사용하여 가용성 공식, 즉 성공한 읽기 또는 쓰기의 비율을 정의할 수 있습니다. 예를 들어 Prometheus에서 다음과 유사한 쿼리를 정의할 수 있습니다. 이는 예상치 못한 이유로 실패한 쓰기 요청의 비율을 가져와 1에서 빼서 성공한 쓰기 비율을 구합니다:

1- (sum(rate(backend_write_requests_failed_total -sum(rate(teleport_backend_write_requests_failed_precondition_total)) / sum(rate(backend_write_requests_total))

백엔드가 사용할 수 없게 보이기 시작하면 백엔드 인프라를 조사할 수 있습니다.

백엔드 작업 성능#

백엔드 작업 성능 추적을 돕기 위해 Auth 서비스는 읽기 및 쓰기 작업에 대한 Prometheus 히스토그램 메트릭도 노출합니다:

  • teleport_backend_read_seconds_bucket
  • teleport_backend_write_seconds_bucket
  • teleport_backend_batch_write_seconds_bucket
  • teleport_backend_batch_read_seconds_bucket
  • teleport_backend_atomic_write_seconds_bucket

이전 섹션에서 논의한 백엔드 처리량 메트릭은 지연 시간 메트릭에 매핑됩니다. Auth 서비스가 처리량 메트릭 중 하나를 증가시킬 때마다 해당 지연 시간 메트릭 중 하나를 보고합니다. 처리량 메트릭이 지연 시간 메트릭에 매핑되는 방식은 아래 표를 참조하세요. 각 메트릭 이름에는 표준 접두사와 접미사가 제외됩니다.

처리량 지연 시간
read_requests read_seconds_bucket
read_requests write_seconds_bucket
batch_read_requests batch_write_seconds_bucket
batch_write_requests batch_read_seconds_bucket
atomic_write_requests atomic_write_seconds_bucket

에이전트 및 연결된 리소스#

Teleport를 사용하여 대부분의 인프라에 사용자가 접근할 수 있도록 하려면 Teleport 에이전트를 Teleport 클러스터에 참여시키고 인프라를 프록시하도록 구성해야 합니다. 일반적인 설정에서 에이전트는 Proxy 서비스와 SSH 역방향 터널을 설정합니다. Teleport 보호 리소스에 대한 사용자 트래픽은 Proxy 서비스, 에이전트, 그리고 최종적으로 에이전트가 프록시하는 인프라 리소스를 통해 흐릅니다. 리소스에서의 반환 트래픽은 이 경로를 역순으로 따릅니다.

유형별 연결된 리소스 수#

Teleport에 연결된 리소스는 주기적으로 Auth 서비스에 하트비트(keepalive) 메시지를 보냅니다. Auth 서비스는 이러한 하트비트를 사용하여 teleport_connected_resources 메트릭으로 유형별 Teleport 보호 리소스 수를 추적합니다.

Auth 서비스는 다음 리소스에 대해 이 메트릭을 추적합니다:

  • SSH 서버
  • Kubernetes 클러스터
  • 애플리케이션
  • 데이터베이스
  • Teleport Database 서비스 인스턴스
  • Windows 데스크톱

이 메트릭을 사용하여 다음을 수행할 수 있습니다:

  • Teleport로 보호되는 리소스 수와 보호되지 않는 리소스 수를 비교하여 자동 검색을 구성하는 등 Teleport 롤아웃을 계획합니다.
  • Teleport 사용 변화를 Auth 서비스 및 Proxy 서비스 컴퓨팅 인스턴스의 리소스 활용도와 연관 지어 확장 요구를 결정합니다.

이 쿼리를 Grafana 구성에 포함하여 리소스 유형별로 이 메트릭을 분류할 수 있습니다:

sum(teleport_connected_resources) by (type)

유형별 역방향 터널#

시작되는 모든 Teleport 서비스는 Proxy 서비스에 SSH 역방향 터널을 설정합니다. (자체 호스팅 클러스터는 역방향 터널을 설정하지 않고 에이전트 서비스가 Auth 서비스에 직접 연결하도록 구성할 수 있습니다.) Proxy 서비스는 teleport_reverse_tunnels_connected 메트릭을 사용하여 역방향 터널 수를 추적합니다.

Proxy 서비스 풀이 적절하게 확장되지 않으면 Proxy 서비스가 Teleport 보호 리소스에 대한 트래픽의 병목이 될 수 있습니다. Proxy 서비스 인스턴스에서 컴퓨팅 리소스 활용도가 높으면서 연결된 인프라 리소스 수가 많으면 Proxy 서비스 풀을 확장하고 Proxy Peering을 사용하는 것을 고려할 수 있습니다.

다음 Grafana 쿼리를 사용하여 특정 간격 동안 유형별 역방향 터널의 최대 수를 추적합니다:

max(teleport_reverse_tunnels_connected) by (type))

Teleport 인스턴스 버전#

정기적인 간격(지터가 있는 약 7초)으로 Auth 서비스는 등록된 Teleport 인스턴스 수를 갱신합니다. 여기에는 에이전트와 Auth 서비스 및 Proxy 서비스를 실행하는 Teleport 프로세스가 포함됩니다. teleport_registered_servers 메트릭으로 이 수를 측정할 수 있습니다. 버전별 등록된 인스턴스 수를 구하려면 Grafana에서 이 쿼리를 사용할 수 있습니다:

sum by (version)(teleport_registered_servers)

이 메트릭을 사용하여 등록된 Teleport 인스턴스 중 Auth 서비스와 Proxy 서비스 버전보다 낮은 버전이 있는지 확인할 수 있습니다. 이는 Teleport 버전 호환성 보장을 위반할 위험이 있는 인스턴스를 식별하는 데 도움이 됩니다.

자체 호스팅 Teleport 사용자는 에이전트를 자동 업데이트에 등록하는 것을 강력히 권장합니다. 자동 업데이트에 등록되지 않은 Teleport 에이전트 수는 teleport_enrolled_in_upgrades 메트릭을 사용하여 추적할 수 있습니다. 에이전트를 자동 업데이트에 등록하는 방법은 문서를 참조하세요.

자체 호스팅 클러스터의 주요 메트릭

원문 보기
요약

이 가이드는 Auth 서비스와 Proxy 서비스가 보고하는 메트릭을 중심으로 자체 호스팅 Teleport 클러스터 모니터링을 시작하는 데 사용해야 할 메트릭을 설명합니다. 사용 가능한 모든 메트릭의 참조는 Teleport 메트릭 참조를 참조하세요.

이 가이드는 Auth 서비스와 Proxy 서비스가 보고하는 메트릭을 중심으로 자체 호스팅 Teleport 클러스터 모니터링을 시작하는 데 사용해야 할 메트릭을 설명합니다. Teleport Enterprise (Cloud)를 사용하는 경우 Teleport 팀이 이러한 메트릭을 모니터링하고 대응합니다.

사용 가능한 모든 메트릭의 참조는 Teleport 메트릭 참조를 참조하세요.

이 가이드는 Teleport Auth 서비스와 Proxy 서비스를 실행하는 모든 인스턴스의 컴퓨팅 리소스(예: CPU, 메모리, 디스크, 대역폭, 열린 파일 디스크립터)를 이미 모니터링하고 있다고 가정합니다.

메트릭 활성화#

Teleport's diagnostic HTTP endpoints are disabled by default. You can enable them via:

Ensure you can connect to the diagnostic endpoint 
Verify that Teleport is now serving the diagnostics endpoint:

```code
$ curl http://127.0.0.1:3000/healthz
```

이렇게 하면 http://127.0.0.1:3000/metrics 엔드포인트가 활성화되어 Teleport가 추적하는 메트릭을 제공합니다. Prometheus 수집기와 호환됩니다.

Grafana 대시보드

Grafana 대시보드 템플릿은 examples/grafana/teleport-dashboard.json에서 찾을 수 있습니다.

백엔드 작업#

Auth 서비스에 정상적인 클러스터 상태 백엔드가 없으면 Teleport 클러스터는 작동할 수 없습니다. Auth 서비스가 백엔드에서 읽고 쓰는 능력을 추적해야 합니다.

Auth 서비스는 여러 가능한 백엔드에 연결할 수 있습니다. Teleport 백엔드 메트릭 외에도, 이러한 메트릭이 문제가 있는 값을 보여줄 경우 백엔드 인프라의 메트릭과 연관 지을 수 있도록 선택한 백엔드에 대한 모니터링도 설정해야 합니다.

백엔드 작업 처리량 및 가용성#

각 백엔드 작업에서 Auth 서비스는 메트릭을 증가시킵니다. 백엔드 작업 메트릭의 형식은 다음과 같습니다:

teleport_backend_[_failed]_total

작업이 오류를 초래하면 Auth 서비스는 메트릭 이름에 _failed 세그먼트를 추가합니다. 예를 들어, 레코드 생성에 성공하면 teleport_backend_write_requests_total 메트릭이 증가합니다. 생성 작업이 실패하면 Auth 서비스는 대신 teleport_backend_write_requests_failed_total을 증가시킵니다.

다음 백엔드 작업 메트릭을 사용할 수 있습니다:

작업 증가되는 메트릭 이름
항목 생성 write_requests
항목 수정, 없으면 생성 write_requests
항목 업데이트 write_requests
버전이 일치하면 항목을 조건부 업데이트 write_requests
항목 범위 나열 batch_read_requests
단일 항목 가져오기 read_requests
항목 비교 및 교환 write_requests
항목 삭제 write_requests
버전이 일치하면 항목을 조건부 삭제 write_requests
업데이트가 실패하면 쓰기가 실패하는 업데이트 배치를 원자적으로 작성 write_requests와 atomic_write_requests 모두
항목 범위 삭제 batch_write_requests
항목의 keepalive 상태 업데이트 write_requests

백엔드 쓰기가 실패하는 동안, Teleport 프로세스는 실패 원인이 예상된 경우 backend_write_requests_failed_precondition_total 메트릭도 증가시킵니다. 예를 들어, 레코드가 이미 존재하면 생성 작업 중에, 레코드를 찾을 수 없으면 업데이트 또는 삭제 작업 중에, 리소스가 동시에 수정된 경우 원자 쓰기 중에 메트릭이 증가합니다. 이러한 조건들은 모두 정상적으로 작동하는 Teleport 클러스터에서 유지될 수 있습니다.

backend_write_requests_failed_precondition_total은 backend_write_requests_failed_total이 증가할 때마다 증가하며, 잠재적으로 예상된 쓰기 실패와 예상치 못한 문제가 있는 실패를 구별하는 데 사용할 수 있습니다.

백엔드 작업 메트릭을 사용하여 가용성 공식, 즉 성공한 읽기 또는 쓰기의 비율을 정의할 수 있습니다. 예를 들어 Prometheus에서 다음과 유사한 쿼리를 정의할 수 있습니다. 이는 예상치 못한 이유로 실패한 쓰기 요청의 비율을 가져와 1에서 빼서 성공한 쓰기 비율을 구합니다:

1- (sum(rate(backend_write_requests_failed_total -sum(rate(teleport_backend_write_requests_failed_precondition_total)) / sum(rate(backend_write_requests_total))

백엔드가 사용할 수 없게 보이기 시작하면 백엔드 인프라를 조사할 수 있습니다.

백엔드 작업 성능#

백엔드 작업 성능 추적을 돕기 위해 Auth 서비스는 읽기 및 쓰기 작업에 대한 Prometheus 히스토그램 메트릭도 노출합니다:

  • teleport_backend_read_seconds_bucket
  • teleport_backend_write_seconds_bucket
  • teleport_backend_batch_write_seconds_bucket
  • teleport_backend_batch_read_seconds_bucket
  • teleport_backend_atomic_write_seconds_bucket

이전 섹션에서 논의한 백엔드 처리량 메트릭은 지연 시간 메트릭에 매핑됩니다. Auth 서비스가 처리량 메트릭 중 하나를 증가시킬 때마다 해당 지연 시간 메트릭 중 하나를 보고합니다. 처리량 메트릭이 지연 시간 메트릭에 매핑되는 방식은 아래 표를 참조하세요. 각 메트릭 이름에는 표준 접두사와 접미사가 제외됩니다.

처리량 지연 시간
read_requests read_seconds_bucket
read_requests write_seconds_bucket
batch_read_requests batch_write_seconds_bucket
batch_write_requests batch_read_seconds_bucket
atomic_write_requests atomic_write_seconds_bucket

에이전트 및 연결된 리소스#

Teleport를 사용하여 대부분의 인프라에 사용자가 접근할 수 있도록 하려면 Teleport 에이전트를 Teleport 클러스터에 참여시키고 인프라를 프록시하도록 구성해야 합니다. 일반적인 설정에서 에이전트는 Proxy 서비스와 SSH 역방향 터널을 설정합니다. Teleport 보호 리소스에 대한 사용자 트래픽은 Proxy 서비스, 에이전트, 그리고 최종적으로 에이전트가 프록시하는 인프라 리소스를 통해 흐릅니다. 리소스에서의 반환 트래픽은 이 경로를 역순으로 따릅니다.

유형별 연결된 리소스 수#

Teleport에 연결된 리소스는 주기적으로 Auth 서비스에 하트비트(keepalive) 메시지를 보냅니다. Auth 서비스는 이러한 하트비트를 사용하여 teleport_connected_resources 메트릭으로 유형별 Teleport 보호 리소스 수를 추적합니다.

Auth 서비스는 다음 리소스에 대해 이 메트릭을 추적합니다:

  • SSH 서버
  • Kubernetes 클러스터
  • 애플리케이션
  • 데이터베이스
  • Teleport Database 서비스 인스턴스
  • Windows 데스크톱

이 메트릭을 사용하여 다음을 수행할 수 있습니다:

  • Teleport로 보호되는 리소스 수와 보호되지 않는 리소스 수를 비교하여 자동 검색을 구성하는 등 Teleport 롤아웃을 계획합니다.
  • Teleport 사용 변화를 Auth 서비스 및 Proxy 서비스 컴퓨팅 인스턴스의 리소스 활용도와 연관 지어 확장 요구를 결정합니다.

이 쿼리를 Grafana 구성에 포함하여 리소스 유형별로 이 메트릭을 분류할 수 있습니다:

sum(teleport_connected_resources) by (type)

유형별 역방향 터널#

시작되는 모든 Teleport 서비스는 Proxy 서비스에 SSH 역방향 터널을 설정합니다. (자체 호스팅 클러스터는 역방향 터널을 설정하지 않고 에이전트 서비스가 Auth 서비스에 직접 연결하도록 구성할 수 있습니다.) Proxy 서비스는 teleport_reverse_tunnels_connected 메트릭을 사용하여 역방향 터널 수를 추적합니다.

Proxy 서비스 풀이 적절하게 확장되지 않으면 Proxy 서비스가 Teleport 보호 리소스에 대한 트래픽의 병목이 될 수 있습니다. Proxy 서비스 인스턴스에서 컴퓨팅 리소스 활용도가 높으면서 연결된 인프라 리소스 수가 많으면 Proxy 서비스 풀을 확장하고 Proxy Peering을 사용하는 것을 고려할 수 있습니다.

다음 Grafana 쿼리를 사용하여 특정 간격 동안 유형별 역방향 터널의 최대 수를 추적합니다:

max(teleport_reverse_tunnels_connected) by (type))

Teleport 인스턴스 버전#

정기적인 간격(지터가 있는 약 7초)으로 Auth 서비스는 등록된 Teleport 인스턴스 수를 갱신합니다. 여기에는 에이전트와 Auth 서비스 및 Proxy 서비스를 실행하는 Teleport 프로세스가 포함됩니다. teleport_registered_servers 메트릭으로 이 수를 측정할 수 있습니다. 버전별 등록된 인스턴스 수를 구하려면 Grafana에서 이 쿼리를 사용할 수 있습니다:

sum by (version)(teleport_registered_servers)

이 메트릭을 사용하여 등록된 Teleport 인스턴스 중 Auth 서비스와 Proxy 서비스 버전보다 낮은 버전이 있는지 확인할 수 있습니다. 이는 Teleport 버전 호환성 보장을 위반할 위험이 있는 인스턴스를 식별하는 데 도움이 됩니다.

자체 호스팅 Teleport 사용자는 에이전트를 자동 업데이트에 등록하는 것을 강력히 권장합니다. 자동 업데이트에 등록되지 않은 Teleport 에이전트 수는 teleport_enrolled_in_upgrades 메트릭을 사용하여 추적할 수 있습니다. 에이전트를 자동 업데이트에 등록하는 방법은 문서를 참조하세요.