이 가이드는 자가 호스팅 Teleport 클러스터를 모니터링하기 위해 사용할 지표를 설명하며, Auth Service와 Proxy Service에서 보고된 지표에 초점을 맞춥니다. Teleport Enterprise (Cloud)를 사용하는 경우, Teleport 팀이 이러한 지표를 모니터링하고 대응합니다.

사용 가능한 모든 지표의 참조는 Teleport Metrics Reference를 참조하십시오.

이 가이드는 Teleport Auth Service와 Proxy Service를 실행하는 모든 인스턴스에서 컴퓨팅 자원을 모니터링하고 있다고 가정합니다 (예: CPU, 메모리, 디스크, 대역폭 및 열린 파일 설명자).

지표 활성화

Teleport의 진단 HTTP 엔드포인트는 기본적으로 비활성화되어 있습니다. 이를 활성화하려면 다음 방법을 사용하십시오:

sudo teleport start  --diag-addr=127.0.0.1:3000

teleport:
    diag_addr: 127.0.0.1:3000

log:
    severity: DEBUG

curl http://127.0.0.1:3000/healthz

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

백엔드 작업

Auth Service가 건강한 클러스터 상태 백엔드 없이 Teleport 클러스터가 기능할 수 없습니다. Auth Service의 읽기 및 쓰기 기능을 추적해야 합니다.

Auth Service는 여러 가능한 백엔드에 연결할 수 있습니다. Teleport 백엔드 지표 외에도 선택한 백엔드에 대한 모니터링을 설정해야 합니다. 이러한 지표에 문제가 있는 값을 보여줄 경우, 이를 기반으로 인프라에 대한 지표와 상관관계를 파악할 수 있습니다.

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

각 백엔드 작업에서 Auth Service는 지표를 증가시킵니다. 백엔드 작업 지표는 다음 형식을 가집니다:

teleport_backend_<METRIC_NAME>[_failed]_total

작업이 오류로 끝나는 경우, Auth Service는 지표 이름에 _failed 구문을 추가합니다. 예를 들어, 레코드를 성공적으로 생성하면 teleport_backend_write_requests_total 지표가 증가합니다. 생성 작업이 실패하면, Auth Service는 대신 teleport_backend_write_requests_failed_total 을 증가시킵니다.

다음의 백엔드 작업 지표가 제공됩니다:

실패한 백엔드 쓰기 중 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 Service는 읽기 및 쓰기 작업에 대한 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 Service가 처리량 메트릭 중 하나를 증가시킬 때마다, 해당 지연 메트릭 중 하나를 보고합니다. 아래 표를 참조하여 어떤 처리량 메트릭이 어떤 지연 메트릭에 매핑되는지 확인하세요. 각 메트릭 이름은 표준 접두사 및 접미사를 제외합니다.

에이전트 및 연결된 리소스

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

유형별 연결된 리소스 수

Teleport에 연결된 리소스는 주기적으로 Auth Service에 하트비트(유지 활성) 메시지를 전송합니다. Auth Service는 이 하트비트를 사용하여 teleport_connected_resources 메트릭으로 유형별로 Teleport로 보호된 리소스의 수를 추적합니다.

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

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

이 메트릭을 사용하여:

• Teleport로 보호된 리소스 수와 보호되지 않은 리소스 수를 비교하여 Teleport 롤아웃 계획을 수립할 수 있습니다. 예를 들어, 자동 검색을 구성하여 계획할 수 있습니다.
• Teleport 사용 변화와 Auth Service 및 Proxy Service 계산 인스턴스의 리소스 활용도를 상관관계 지어 스케일링 필요성을 판단할 수 있습니다.

다음과 같은 쿼리를 Grafana 구성에 포함하여 이 메트릭을 리소스 유형별로 나누어 볼 수 있습니다:

sum(teleport_connected_resources) by (type)

유형별 역 터널

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

부적절하게 스케일링된 Proxy Service 풀에서는 Proxy Service가 Teleport로 보호된 리소스에 대한 트래픽의 병목 현상이 될 수 있습니다. Proxy Service 인스턴스가 계산 리소스를 과도하게 사용하면서 연결된 인프라 리소스의 수가 많을 경우, Proxy Service 풀을 확장하고 프록시 피어링을 사용하는 것을 고려할 수 있습니다.

다음 Grafana 쿼리를 사용하여 주어진 시간 간격 동안 유형별로 최대 역 터널 수를 추적하세요:

max(teleport_reverse_tunnels_connected) by (type))

Teleport 인스턴스 버전

Auth 서비스는 정기적으로 (7초 정도의 불규칙한 간격으로) 등록된 Teleport 인스턴스의 수를 새로 고칩니다. 여기에는 Auth 서비스와 Proxy 서비스가 실행되는 에이전트 및 Teleport 프로세스가 포함됩니다. 이 수치는 teleport_registered_servers 메트릭으로 측정할 수 있습니다. 등록된 인스턴스를 버전별로 확인하려면 Grafana에서 다음 쿼리를 사용할 수 있습니다:

sum by (version)(teleport_registered_servers)

이 메트릭을 사용하면 등록된 Teleport 인스턴스 중 Auth 서비스와 Proxy 서비스의 버전보다 구버전인 인스턴스 수를 확인할 수 있으며, 이는 Teleport의 버전 호환성 보장을 위반할 위험이 있는 경우 식별하는 데 도움이 됩니다.

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