测验：时间戳、导数、埋点 API、Span

PromQL 의 time() 함수가 돌려주는 값을 문서대로 설명한 것은?

• Prometheus 서버의 현재 벽시계 시각이라 과거 구간 쿼리에서도 항상 지금 시각이 나온다
• 표현식이 평가되는 시각의 Unix 초이므로 범위 쿼리에서는 각 평가 지점의 시각이 들어간다
• 가장 최근에 스크레이프한 샘플의 시각이라 대상이 사라지면 값이 멈춘다
• 시리즈가 처음 생긴 시각이라 재시작을 감지하는 데 그대로 쓸 수 있다

최근 1시간 안에 재시작한 인스턴스를 찾는 식으로 가장 알맞은 것은?

• rate(process_start_time_seconds[1h]) > 0
• time() - process_start_time_seconds > 3600
• changes(process_start_time_seconds[1h]) > 0
• predict_linear(process_start_time_seconds[1h], 0) < time()

deriv() 와 predict_linear() 에 공통으로 적용되는 문서상의 조건은?

• 게이지에만 쓰며 범위 안에 float 샘플이 둘 이상 있어야 계산된다
• 카운터에만 쓰며 범위 안에 리셋이 있으면 자동으로 보정한다
• 히스토그램 샘플에서만 동작하며 le 라벨이 있는 시리즈만 입력으로 받는다
• 인스턴트 벡터를 입력으로 받으며 샘플이 하나만 있어도 기울기를 0 으로 돌려준다

Python prometheus_client 의 Histogram 생성자에 대한 설명으로 옳은 것은?

• buckets 는 내림차순으로 적어야 하며 +Inf 버킷은 사용자가 마지막에 직접 넣어야 한다
• labelnames 에 le 를 넣으면 버킷 경계를 라벨로 직접 제어할 수 있다
• registry=None 을 주면 기본 REGISTRY 에 자동 등록되어 start_http_server 가 바로 노출한다
• buckets 는 오름차순이어야 하고 +Inf 는 항상 자동으로 붙으며, le 는 예약된 라벨이라 labelnames 에 쓸 수 없다

Go 클라이언트의 DefBuckets 에 대해 문서가 하는 설명은?

• 네트워크 서비스의 응답 시간을 넓게 재도록 맞춘 값이라 대부분은 자기 용도에 맞는 버킷을 따로 정의해야 한다
• 모든 워크로드에 최적화된 값이라 바꾸면 histogram_quantile 의 정확도가 떨어진다
• 네이티브 히스토그램 전용 값이라 고전 히스토그램에서는 무시된다
• 밀리초 단위로 정의되어 있어 초 단위 관측값에는 쓸 수 없다

한 트레이스에 속한 스팬들이 트리를 이루는 방식과 서비스 경계를 넘는 전파 형식으로 옳은 것은?

• 각 스팬이 서로 다른 trace_id 를 갖고 링크로 이어지며, 전파는 X-Request-Id 헤더 하나로 한다
• 루트 스팬만 trace_id 를 갖고 자식은 span_id 만 가지며, 전파는 gRPC 메타데이터로만 가능하다
• 스팬은 시작 시각 순으로만 정렬되어 부모 관계가 없고, 전파는 로그의 trace_id 를 검색해 사후에 맞춘다
• 모든 스팬이 같은 trace_id 를 공유하고 자식의 parent_id 가 부모의 span_id 이며, 기본 전파는 W3C traceparent 헤더로 한다