PCA模擬試験A

메트릭이 로그에 비해 갖는 강점으로 가장 정확한 것은?

• 개별 요청의 전체 맥락을 그대로 담아 사후 조사가 쉽다
• 시간에 따라 집계된 수치라 저장 비용이 낮고 장기 추세와 알림에 적합하다
• 서비스 사이의 호출 관계를 그대로 보여 준다
• 샘플링 없이 모든 이벤트를 개별적으로 보존한다

가용성이 아니라 지연으로 사용자 경험이 나빠지는 상황을 잡으려면 SLI 를 어떻게 정의해야 하는가?

• 성공 응답의 비율만 본다
• 정해진 기준 시간 안에 성공한 요청의 비율을 본다
• 요청 수의 총합을 본다
• 응답 시간의 산술 평균을 본다

화이트박스 모니터링과 블랙박스 모니터링의 차이로 올바른 것은?

• 화이트박스는 시스템 내부가 노출한 지표를 보고, 블랙박스는 밖에서 관찰 가능한 증상을 본다
• 화이트박스는 외부 프로브로 확인하고, 블랙박스는 코드 계측으로 확인한다
• 화이트박스는 로그만 쓰고, 블랙박스는 메트릭만 쓴다
• 화이트박스는 운영 환경에서만, 블랙박스는 개발 환경에서만 쓸 수 있다

관측 가능성(observability)과 모니터링의 관계로 가장 적절한 것은?

• 모니터링은 미리 정한 질문에 답하고, 관측 가능성은 예상하지 못한 질문에도 답할 수 있는 성질이다
• 관측 가능성은 모니터링의 옛 이름이라 둘은 같은 말이다
• 모니터링은 메트릭만, 관측 가능성은 트레이스만 다룬다
• 관측 가능성은 도구의 이름이고 모니터링은 절차의 이름이다

네 가지 골든 시그널에 해당하지 않는 것은?

• 지연(latency)
• 트래픽(traffic)
• 배포 빈도(deployment frequency)
• 포화도(saturation)

카디널리티가 높은 레이블이 문제가 되는 이유는?

• 레이블 값의 조합마다 별도의 시계열이 만들어져 메모리와 저장 공간이 급격히 늘기 때문
• 레이블 값이 길면 스크레이프 요청이 실패하기 때문
• 레이블이 많으면 PromQL 문법 오류가 나기 때문
• 레이블 값이 많으면 알림 규칙을 만들 수 없기 때문

SLO 를 정할 때 100% 를 목표로 삼지 않는 이유로 가장 적절한 것은?

• 100% 는 측정 자체가 불가능하기 때문
• 마지막 몇 자릿수의 비용이 급격히 커지고 변경을 감당할 여유가 사라지기 때문
• 고객이 100% 를 요구하지 않기 때문
• 프로메테우스가 100% 를 표현하지 못하기 때문

에러 버짓이 소진되었을 때의 조치로 가장 적절한 것은?

• SLO 목표치를 낮춰 버짓을 다시 확보한다
• 새 기능 배포를 늦추고 안정성 개선에 힘을 옮긴다
• 알림 임계값을 올려 알림이 덜 오게 한다
• 측정 창을 늘려 위반이 희석되게 한다

분산 추적이 메트릭으로는 답하기 어려운 질문에 답해 주는 예로 가장 적절한 것은?

• 지난 30일 동안 오류율이 어떻게 변했는가
• 이 느린 요청 하나가 어느 서비스 구간에서 시간을 썼는가
• 현재 클러스터의 총 요청 처리량은 얼마인가
• 노드의 메모리 사용률이 임계값을 넘었는가

USE 방법론에서 보는 세 가지로 올바른 것은?

• 사용률(Utilization), 포화도(Saturation), 에러(Errors)
• 요청률(Rate), 에러(Errors), 지속시간(Duration)
• 사용률(Utilization), 속도(Speed), 규모(Extent)
• 가용성(Uptime), 서비스(Service), 경험(Experience)

대시보드를 만들 때 흔히 저지르는 실수로 가장 적절한 것은?

• 패널을 잘게 나누지 않고 몇 개의 핵심 지표만 크게 배치하는 것
• 가능한 모든 지표를 한 화면에 늘어놓아 어디를 봐야 할지 알 수 없게 만드는 것
• 패널마다 단위를 명시하는 것
• 사용자 관점의 지표를 맨 위에 두는 것

프로메테우스의 데이터 모델에서 하나의 시계열을 유일하게 식별하는 것은?

• 메트릭 이름과 레이블 이름·값 집합의 조합
• 메트릭 이름 하나
• 스크레이프한 타깃의 IP 주소
• 샘플의 타임스탬프

프로메테우스의 네 가지 메트릭 타입에 해당하지 않는 것은?

• Counter
• Gauge
• Timer
• Histogram

Counter 타입에 대한 설명으로 올바른 것은?

• 오르내릴 수 있으므로 현재 온도나 큐 길이에 적합하다
• 단조 증가하며 프로세스가 재시작하면 0 으로 되돌아간다
• 값이 자동으로 초당 비율로 변환되어 저장된다
• 최근 값 하나만 저장되고 과거 값은 버려진다

프로메테우스가 pull 방식을 기본으로 택한 이유로 가장 적절한 것은?

• 타깃 목록을 서버가 알고 있어 대상이 살아 있는지 스크레이프 자체로 판단할 수 있기 때문
• push 방식보다 네트워크 대역폭을 항상 적게 쓰기 때문
• 타깃이 자기 지표를 저장하지 않아도 되기 때문
• 방화벽 설정이 전혀 필요 없기 때문

타깃의 up 메트릭이 0 이라는 것의 의미로 가장 정확한 것은?

• 타깃의 애플리케이션이 오류 응답을 반환했다
• 직전 스크레이프가 실패했다
• 타깃이 서비스 디스커버리에서 사라졌다
• 타깃의 지표 값이 모두 0 이다

서비스 디스커버리를 쓰지 않고 static_configs 로만 타깃을 관리할 때의 문제는?

• 타깃이 늘거나 줄 때마다 설정을 고치고 다시 읽어야 한다
• 레이블을 붙일 수 없어 쿼리에서 구분할 수 없다
• 스크레이프 간격을 지정할 수 없다
• TLS 로 스크레이프할 수 없다

scrape_interval 을 지나치게 짧게 잡을 때 생기는 대가로 가장 적절한 것은?

• 샘플 수가 늘어 저장 용량과 쿼리 비용이 함께 증가한다
• 레이블 카디널리티가 자동으로 늘어난다
• 타깃이 스크레이프를 거부하게 된다
• 알림 규칙이 평가되지 않는다

프로메테우스 TSDB 의 head 블록이 하는 역할은?

• 가장 오래된 데이터를 압축해 오브젝트 스토리지로 옮겨 장기 보관한다
• 최근 샘플을 메모리에 두고 WAL 에 기록했다가 주기적으로 디스크 블록으로 내린다
• 쿼리 결과를 캐시해 같은 요청이 반복될 때 빠르게 응답한다
• 알림 규칙의 상태를 저장해 재시작한 뒤에도 그대로 유지되게 한다

프로메테우스의 데이터 보존 기간을 늘리는 대신 장기 저장소를 붙이는 이유로 가장 적절한 것은?

• 단일 인스턴스의 디스크와 메모리로는 감당하기 어렵고 이중화도 되지 않기 때문
• 프로메테우스가 30일을 넘는 보존을 지원하지 않기 때문
• 장기 저장소가 PromQL 을 더 빠르게 실행하기 때문
• 장기 저장소를 붙이면 카디널리티 제한이 사라지기 때문

honor_labels: true 를 설정하면 어떻게 되는가?

• 스크레이프한 데이터의 레이블이 프로메테우스가 붙이는 레이블보다 우선한다
• 모든 레이블이 소문자로 변환된다
• 타깃의 레이블이 무시되고 job 레이블만 남는다
• 레이블 값의 길이 제한이 해제된다

프로메테우스 페더레이션(federation)의 적절한 사용법은?

• 하위 서버의 모든 시계열을 상위로 복제해 단일 저장소를 만든다
• 하위 서버에서 이미 집계한 소수의 시계열만 상위로 가져와 전역 관점을 만든다
• 상위 서버가 하위 서버 대신 타깃을 직접 스크레이프하게 한다
• 하위 서버의 알림 규칙을 상위로 옮겨 중앙에서 평가한다

프로메테우스가 고가용성을 위해 쓰는 일반적인 방식은?

• 여러 인스턴스가 리더를 선출해 하나만 스크레이프한다
• 동일한 설정의 인스턴스 두 대가 같은 타깃을 각각 독립적으로 스크레이프한다
• 인스턴스끼리 데이터를 실시간 복제해 동일한 블록을 유지한다
• 하나의 인스턴스가 다른 인스턴스의 WAL 을 공유 볼륨으로 읽는다

PromQL 에서 http_requests_total[5m] 의 결과 타입은?

• 즉시 벡터
• 구간 벡터
• 스칼라
• 문자열

Counter 에 rate() 를 쓸 때 구간 길이를 스크레이프 간격의 최소 몇 배 이상으로 잡으라고 하는가?

• 1배
• 2배
• 4배
• 10배

rate() 와 irate() 의 차이로 올바른 것은?

• rate 는 구간 전체에 대한 평균 증가율이고, irate 는 마지막 두 샘플만 보는 순간 증가율이다
• rate 는 Gauge 에, irate 는 Counter 에 쓴다
• rate 는 리셋을 보정하지 않고 irate 만 보정한다
• irate 는 구간 전체를 보고 rate 는 마지막 샘플만 본다

increase(http_requests_total[1h]) 를 가장 정확히 설명한 것은?

• 지난 1시간 동안 관측된 마지막 값에서 첫 값을 뺀 정수 차이다
• rate 에 구간 길이를 곱한 값이라 외삽 때문에 소수가 나올 수 있다
• 지난 1시간의 평균값이다
• 지난 1시간 중 가장 큰 값이다

Gauge 의 변화 추세를 보려 할 때 rate() 대신 써야 하는 함수는?

• delta()
• increase()
• resets()
• idelta()와 rate()의 조합

sum(rate(http_requests_total[5m])) by (job) 과 sum(rate(...)) without (instance) 의 차이로 올바른 것은?

• by 는 나열한 레이블만 남기고, without 은 나열한 레이블만 버리고 나머지를 남긴다
• by 는 합계를, without 은 평균을 계산한다
• by 는 즉시 벡터를, without 은 구간 벡터를 돌려준다
• 둘은 완전히 같은 표현이라 어느 쪽을 써도 결과가 같다

sum(rate(http_request_duration_seconds_sum[5m])) / sum(rate(http_request_duration_seconds_count[5m])) 가 계산하는 값은?

• 구간 동안의 평균 응답 시간
• 구간 동안의 95 분위 응답 시간
• 구간 동안의 최대 응답 시간
• 구간 동안의 초당 요청 수

histogram_quantile(0.95, sum(rate(x_bucket[5m])) by (le)) 에서 by (le) 를 빠뜨리면?

• 버킷 경계 정보가 사라져 분위수를 계산할 수 없고 결과가 비거나 잘못된다
• 결과가 항상 0 이 된다
• 모든 분위수가 같은 값으로 나온다
• 쿼리는 정상 동작하고 성능만 느려진다

히스토그램 분위수 값이 실제와 다를 수 있는 근본적인 이유는?

• 프로메테우스가 샘플을 무작위로 버리기 때문
• 분위수 계산이 부동소수점 오차를 누적하기 때문
• 버킷이 누적이 아니라 배타적으로 저장되기 때문
• 버킷 안에서 값이 고르게 분포한다고 가정하고 보간하기 때문

Summary 로는 서비스 전체의 분위수를 구할 수 없는 이유는?

• Summary 가 레이블을 지원하지 않기 때문
• Summary 의 값이 문자열로 저장되기 때문
• Summary 는 프로메테우스가 스크레이프하지 못하기 때문
• Summary 는 인스턴스 안에서 이미 계산된 분위수 값을 노출하므로 인스턴스끼리 더하거나 평균 낼 수 없기 때문

벡터 매칭에서 on(job) 과 ignoring(instance) 의 관계로 올바른 것은?

• on 은 왼쪽 벡터에만, ignoring 은 오른쪽 벡터에만 적용된다
• on 은 일대일 매칭에만, ignoring 은 다대일 매칭에만 쓸 수 있다
• 둘은 결과가 항상 같아 취향의 문제다
• on 은 나열한 레이블로만 짝을 맞추고, ignoring 은 나열한 레이블을 뺀 나머지로 짝을 맞춘다

group_left 를 쓰는 상황으로 가장 적절한 것은?

• 왼쪽 벡터의 시계열을 오른쪽 벡터의 순서에 맞춰 정렬하려고
• 연산 결과에서 왼쪽 벡터가 가진 레이블을 모두 지우려고
• 왼쪽의 여러 시계열이 오른쪽 한 시계열에 대응할 때 오른쪽 레이블을 끌어오려고
• 왼쪽 벡터의 값을 오른쪽 벡터의 값으로 대체하려고

absent(up{job="payments"}) 가 유용한 경우는?

• 해당 시계열의 값이 0 일 때 알림을 띄우려는 경우
• 해당 시계열의 증가율을 구하려는 경우
• 여러 시계열의 평균을 구하려는 경우
• 해당 시계열이 아예 존재하지 않을 때 알림을 띄우려는 경우

offset 1h 를 쓰는 목적으로 가장 적절한 것은?

• 쿼리 실행을 한 시간 뒤로 미루려고
• 구간 길이를 한 시간으로 늘리려고
• 한 시간 전 시점의 값을 가져와 현재와 비교하려고
• 알림 평가 주기를 한 시간으로 바꾸려고

topk(5, sum(rate(errors_total[5m])) by (service)) 의 결과로 올바른 것은?

• 오류율 상위 다섯 개의 값을 합한 스칼라 하나
• 무작위로 고른 다섯 개의 서비스
• 오류율이 가장 낮은 서비스 다섯 개
• 오류율이 가장 높은 서비스 다섯 개의 시계열

avg_over_time(node_memory_usage_bytes[1h]) 와 avg(node_memory_usage_bytes) 의 차이는?

• 앞은 Gauge 에만, 뒤는 Counter 에만 쓸 수 있다
• 앞은 즉시 벡터를, 뒤는 구간 벡터를 돌려준다
• 앞은 시계열마다 시간 축으로 평균을 내고, 뒤는 한 시점에서 시계열들 사이의 평균을 낸다
• 두 표현은 항상 같은 값을 돌려준다

PromQL 쿼리가 느릴 때 가장 먼저 점검할 것으로 적절한 것은?

• 프로메테우스의 로그 레벨 설정
• 알림 규칙의 for 값
• Alertmanager 의 그룹 설정
• 선택되는 시계열 수와 조회 구간의 길이

프로메테우스 명명 규약에 맞는 메트릭 이름은?

• httpRequestsTotal
• http_requests_total
• http.requests.count
• HTTP-Requests

익스포터를 쓰는 이유로 가장 정확한 것은?

• 프로메테우스가 저장할 수 없는 데이터를 대신 저장하려고
• 여러 프로메테우스 인스턴스 사이의 데이터를 동기화하려고
• 직접 계측할 수 없는 서드파티 시스템의 상태를 프로메테우스 형식으로 변환해 노출하려고
• 알림을 수신자에게 전달하려고

node_exporter 가 제공하는 지표로 가장 적절한 것은?

• 쿠버네티스 오브젝트의 상태
• 애플리케이션의 HTTP 요청 지연
• 컨테이너별 자원 사용량
• 호스트의 CPU·메모리·디스크·네트워크 같은 운영체제 수준 지표

blackbox_exporter 의 동작 방식으로 올바른 것은?

• 대상 시스템 안에 설치되어 내부 상태를 직접 읽는다
• 프로메테우스 대신 알림을 평가해 Alertmanager 로 보낸다
• 프로메테우스가 대상 주소를 파라미터로 넘겨 프로브를 요청하면 결과를 지표로 돌려준다
• 여러 익스포터의 지표를 모아 한곳에 캐시한다

Pushgateway 를 상시 워크로드에 쓰면 안 되는 이유는?

• Pushgateway 가 Counter 타입을 지원하지 않기 때문
• Pushgateway 가 레이블을 지원하지 않기 때문
• Pushgateway 를 쓰면 스크레이프 간격을 지정할 수 없기 때문
• 값이 계속 남아 있어 인스턴스가 죽어도 지표가 살아 있는 것처럼 보이고 up 으로 생존을 판단할 수 없기 때문

kube-state-metrics 와 metrics-server 의 차이로 올바른 것은?

• 둘은 같은 기능을 하며 이름만 다르다
• kube-state-metrics 는 자원 사용량을, metrics-server 는 오브젝트 상태를 다룬다
• kube-state-metrics 는 오브젝트의 선언과 상태를 지표로 내고, metrics-server 는 오토스케일링용 자원 사용량을 API 로 제공한다
• metrics-server 가 프로메테우스 형식으로 장기 저장을 제공한다

레코딩 룰을 쓰는 주된 목적은?

• 조건이 참인 동안 알림을 발생시켜 Alertmanager 로 보낸다
• 보존 기간이 지난 오래된 시계열을 찾아 자동으로 삭제한다
• 레이블 값의 가짓수를 감시해 카디널리티를 자동으로 낮춘다
• 자주 쓰는 무거운 표현식을 미리 계산해 새 시계열로 저장해 둔다

레코딩 룰 이름의 관례로 권장되는 형태는?

• 원본 메트릭과 같은 이름을 쓰되 레이블만 다르게 한다
• 규칙 파일 이름을 그대로 메트릭 이름으로 쓴다
• level:metric:operations 형태로 집계 수준과 연산을 이름에 담는다
• 접두사 없이 임의의 짧은 이름을 쓴다

애플리케이션을 계측할 때 레이블 값으로 쓰기에 가장 위험한 것은?

• HTTP 상태 코드
• 요청 경로의 라우트 템플릿
• 요청마다 달라지는 사용자 식별자
• 서비스 이름

알림 규칙의 for 절이 하는 일은?

• 알림이 발생한 뒤 그 기간 동안 재발송을 막는다
• 그 기간이 지나면 알림을 자동으로 해제한다
• 그 기간마다 규칙을 한 번씩 평가한다
• 조건이 그 기간 동안 계속 참이어야 firing 으로 바뀌게 한다

알림 규칙에서 labels 와 annotations 의 역할 차이로 올바른 것은?

• labels 는 사람이 읽을 설명을, annotations 는 라우팅 정보를 담는다
• 둘 다 라우팅에 쓰이며 차이는 이름뿐이다
• labels 는 알림의 신원과 라우팅에 쓰이고, annotations 는 사람이 읽을 설명을 담는다
• labels 는 Alertmanager 가, annotations 는 프로메테우스가 각각 생성한다

Alertmanager 의 그룹핑(grouping)이 해결하는 문제는?

• 알림의 심각도를 자동으로 판정한다
• 중복 수신자를 제거해 비용을 줄인다
• 알림 조건을 다시 평가해 오탐을 걸러 낸다
• 같은 원인으로 한꺼번에 터진 알림들을 하나의 알림으로 묶어 보내 폭주를 막는다

Alertmanager 의 억제(inhibition) 규칙을 쓰는 상황으로 가장 적절한 것은?

• 같은 알림이 반복될 때 두 번째부터 무시한다
• 야간에는 모든 알림을 보내지 않게 한다
• 클러스터 전체가 죽었다는 알림이 있을 때 그 하위 서비스의 알림을 보내지 않게 한다
• 알림을 심각도 순으로 정렬한다

사일런스(silence)와 억제(inhibition)의 차이로 올바른 것은?

• 사일런스는 설정 파일로만, 억제는 UI 로만 만들 수 있다
• 사일런스는 알림 평가 자체를 멈추고 억제는 전송만 막는다
• 둘은 같은 기능이며 이름만 다르다
• 사일런스는 사람이 기간을 정해 거는 일시적 조치이고, 억제는 설정으로 정의한 알림 사이의 관계다

알림 피로(alert fatigue)를 줄이는 방법으로 가장 적절한 것은?

• 임계값을 모두 높여 알림 수를 줄인다
• 알림 수신자를 늘려 부담을 나눈다
• 사람이 즉시 행동해야 하는 것만 호출로 보내고 나머지는 티켓이나 대시보드로 돌린다
• 알림 규칙의 for 값을 일괄적으로 크게 늘린다

증상 기반 알림(symptom-based alerting)을 권하는 이유로 가장 적절한 것은?

• 원인 기반 알림보다 항상 더 빨리 발생하기 때문
• 알림 규칙을 더 적게 쓸 수 있어 설정이 짧아지기 때문
• 증상 지표가 원인 지표보다 카디널리티가 낮기 때문
• 사용자가 겪는 문제를 직접 감지하므로 예상하지 못한 원인으로 생긴 장애도 잡을 수 있기 때문

번 레이트(burn rate) 기반 알림에서 긴 창과 짧은 창을 함께 쓰는 이유는?

• 두 창의 평균을 내어 정확도를 높이려고
• 긴 창은 낮에, 짧은 창은 밤에 쓰려고
• 긴 창으로 오탐을 줄이고 짧은 창으로 이미 회복된 상황에서 알림이 계속 남는 것을 막는다
• 짧은 창이 실패했을 때를 대비한 예비 조건이라서

Alertmanager 의 group_wait 가 하는 일은?

• 이미 보낸 그룹에 새 알림이 추가됐을 때 다음 전송까지 기다린다
• 같은 내용의 알림을 다시 보내기까지 기다린다
• 수신자가 응답하지 않을 때 다음 수신자로 넘어가기까지 기다린다
• 새 그룹의 첫 알림을 보내기 전에 같은 그룹의 다른 알림이 더 오는지 잠시 기다린다

알림 라우팅 트리에서 하위 라우트가 상위와 다른 값을 지정하지 않았을 때의 동작은?

• 기본값으로 되돌아간다
• 설정 검증에서 오류가 난다
• 상위 라우트의 설정을 물려받는다
• 그 라우트가 무시된다

대시보드에서 알림 임계선을 함께 그려 두는 것이 도움이 되는 이유는?

• 임계선을 그리면 알림이 더 빨리 발생하기 때문
• 임계선이 있어야 PromQL 이 정확한 값을 돌려주기 때문
• 임계선을 그리면 시계열 저장 용량이 줄기 때문
• 지금 값이 알림 기준에서 얼마나 떨어져 있는지 한눈에 보여 대응 여유를 판단할 수 있기 때문