tbot 프로세스는 선택적으로 진단 서비스를 노출할 수 있습니다. 기본적으로 비활성화되어 있지만, 활성화하면 HTTP를 통해 실행 중인 tbot 프로세스에 대한 유용한 정보를 쿼리할 수 있습니다.

구성#

진단 서비스를 활성화하려면 리스닝할 주소와 포트를 지정해야 합니다.

보안상의 이유로, 이 리스너에 대한 접근이 제한되어야 합니다. 대부분의 경우, 가장 안전한 방법은 리스너를 127.0.0.1에 바인딩하여 로컬 머신에서만 접근할 수 있도록 하는 것입니다.

--diag-addr CLI 매개변수를 사용하여 진단 서비스를 구성할 수 있습니다:

$ tbot start -c my-config.yaml --diag-addr 127.0.0.1:3001

또는 diag_addr을 사용하여 구성 파일 내에서 직접 설정할 수 있습니다:

diag_addr: 127.0.0.1:3001

엔드포인트#

진단 서비스는 다음 HTTP 엔드포인트를 노출합니다.

/livez#

/livez 엔드포인트는 항상 200 상태 코드로 응답합니다. 이를 사용하여 tbot 프로세스가 실행 중이며 충돌하거나 멈추지 않았는지 확인할 수 있습니다.

Kubernetes에 배포하는 경우 이 엔드포인트를 Liveness Probe에 사용하는 것을 권장합니다.

/readyz 및 /readyz/{service}#

/readyz 엔드포인트는 내부 서비스와 사용자 정의 서비스를 포함하여 tbot의 전반적인 상태를 반환합니다. 모든 서비스가 정상이면 200 상태 코드로 응답합니다. 서비스가 비정상이면 503 상태 코드로 응답합니다.

$ curl -v http://127.0.0.1:3001/readyz

HTTP/1.1 503 Service Unavailable
Content-Type: application/json

{
  "status": "unhealthy",
  "services": {
    "ca-rotation": {
      "status": "healthy"
    },
    "heartbeat": {
      "status": "healthy"
    },
    "identity": {
      "status": "healthy"
    },
    "aws-roles-anywhere": {
      "status": "unhealthy",
      "reason": "access denied to perform action \"read\" on \"workload_identity\""
    }
  },
  "pid": 42344
}

Kubernetes에 배포하는 경우 이 엔드포인트를 Readiness Probe에 사용하는 것을 권장합니다.

/readyz/{service} 엔드포인트를 사용하여 특정 서비스의 상태를 쿼리할 수도 있습니다.

$ curl -v http://127.0.0.1:3001/readyz/aws-roles-anywhere

HTTP/1.1 200 OK
Content-Type: application/json

{
  "status": "healthy"
}

기본적으로 tbot은 서비스 유형을 기반으로 서비스 이름을 생성합니다(예: application-output-1). tbot 구성 파일에서 사용자 지정 이름을 제공하여 이를 재정의할 수 있습니다.

services:
  - type: identity
    name: my-service-123

/metrics#

/metrics 엔드포인트는 Prometheus 호환 메트릭 스냅샷을 반환합니다.

자세한 내용은 아래의 Prometheus 메트릭을 참조하세요.

/debug/pprof#

이 엔드포인트는 디버깅 목적으로 pprof 프로파일을 수집할 수 있게 합니다. 성능 문제가 발생하는 경우 Teleport 엔지니어가 이를 수집하도록 요청할 수 있습니다.

tbot을 시작할 때 -d/--debug 플래그가 제공된 경우에만 활성화됩니다. 이를 디버그 모드라고 합니다.

/wait 및 /wait/{service}#

/wait 엔드포인트는 /readyz와 동일한 내용을 반환하지만, 정상 또는 비정상 여부에 관계없이 bot 또는 서비스가 초기 상태를 보고할 때까지 응답을 지연합니다. /readyz와 마찬가지로 bot 또는 서비스가 정상적이지 않은 경우 503 상태 코드로 응답합니다. 초기 준비 상태 보고를 기다리며 무기한 지연될 수 있으므로, 클라이언트는 필요한 경우 합리적인 시간 초과를 구성해야 합니다.

이 엔드포인트는 bot 출력이나 서비스에 의존하는 워크플로가 실제로 요청을 처리할 준비가 되었는지 확인하기 위해 앱에서 직접 준비 상태 확인 루프를 구현할 필요 없이 bot과 동기적으로 통합할 때 유용합니다. CI/CD 환경이나 tbot이 완전히 초기화되었는지 확인해야 하는 다른 상황에서 유용합니다.

tbot wait 헬퍼 명령은 내부적으로 이 엔드포인트를 사용하지만, 추가 오류 케이스(tbot이 아직 시작되지 않은 경우, 서비스가 정상이 될 때까지 명시적으로 기다림)를 처리합니다. 가능한 경우 대부분의 사용자는 CLI 헬퍼를 사용하는 것이 좋습니다.

$ curl -v http://127.0.0.1:3001/wait

HTTP/1.1 503 Service Unavailable
Content-Type: application/json

{
  "status": "unhealthy",
  "services": {
    "ca-rotation": {
      "status": "healthy"
    },
    "heartbeat": {
      "status": "healthy"
    },
    "identity": {
      "status": "healthy"
    },
    "aws-roles-anywhere": {
      "status": "unhealthy",
      "reason": "access denied to perform action \"read\" on \"workload_identity\""
    }
  },
  "pid": 42344
}

/wait/{service} 엔드포인트를 사용하여 특정 서비스가 초기 상태를 보고할 때까지 기다릴 수도 있습니다.

$ curl -v http://127.0.0.1:3001/wait/aws-roles-anywhere

HTTP/1.1 200 OK
Content-Type: application/json

{
  "status": "healthy"
}

Prometheus 메트릭#

tbot 프로세스는 진단 서비스의 /metrics 엔드포인트를 통해 다수의 Prometheus 메트릭을 노출합니다.

표준 Go 런타임 메트릭을 내보내는 것 외에도, tbot은 구성 가능한 다양한 서비스의 상태와 성능을 반영하는 커스텀 메트릭도 내보냅니다.

조언#

tbot의 상태를 모니터링할 때 고려해야 할 세 가지 메트릭 범주가 있습니다:

• tbot 프로세스 자체의 상태. 예를 들어, CPU 시간과 메모리를 얼마나 사용하고 있나요? 이는 전반적인 상태를 나타내는 강력한 지표이며 잠재적인 문제(예: 메모리 누수)의 조기 경고 신호를 제공합니다.
• tbot이 의존하는 내부 서비스의 상태. 예를 들어, tbot이 내부 신원을 성공적으로 갱신할 수 있었나요? 이러한 내부 서비스가 비정상이 되면 tbot 내의 사용자 정의 서비스도 비정상이 될 가능성이 높습니다.
• tbot 내에서 구성한 서비스의 상태. 이는 tbot이 의도한 기능을 성공적으로 수행할 수 있었는지 나타냅니다.

tbot 프로세스 자체의 상태 모니터링을 위해 Go 런타임에서 많은 메트릭이 제공됩니다.

내부 서비스와 사용자 정의 서비스의 상태 모니터링을 위해 두 가지 핵심 메트릭이 있습니다:

• tbot_task_iterations_failed: 실패한 총 작업 반복 수. tbot 프로세스 내에서 작업이 속하는 서비스를 나타내는 service 레이블이 있습니다.
• tbot_task_iterations_successful: 성공한 총 작업 반복 수. 이 메트릭도 service 레이블이 있습니다. 이 메트릭은 히스토그램이며, 작업이 성공하기 전에 필요한 재시도 횟수도 나타냅니다. 완벽하게 정상적인 서비스의 경우 이 재시도 횟수는 0이거나 0에 가까울 것으로 예상됩니다.

메트릭#

일반#

이 메트릭은 tbot 내의 여러 서비스에서 생성되거나 tbot 자체의 코어 수퍼바이저에서 생성될 수 있습니다.

ssh-multiplexer#

이 메트릭은 SSH 멀티플렉서 서비스에서 생성됩니다.