OTCA — 오픈텔레메트리 인증 어소시에이트 · 모의고사 · 퀴즈

OTCA 모의고사 A

LabHub 에서 이어서 보기

문항 60개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

모니터링과 관측가능성의 관계를 가장 정확하게 설명한 것은?
1. 모니터링은 온프레미스에서 쓰고 관측가능성은 클라우드에서 쓰는 말입니다
2. 모니터링은 사람이 화면을 보는 일이고 관측가능성은 자동화가 대신 보는 일입니다
3. 모니터링은 미리 정해 둔 실패 조건을 감시하고, 관측가능성은 예상하지 못한 실패까지 데이터로 되짚을 수 있는 성질입니다
4. 관측가능성을 갖추면 알림 규칙이 필요 없어지므로 모니터링을 걷어내야 합니다
메트릭 라벨에 요청 ID 나 사용자 ID 같은 값을 넣으면 생기는 문제는?
1. 라벨 조합마다 별도의 시계열이 생겨 카디널리티가 폭발하고 저장소와 질의가 함께 무너집니다
2. 메트릭 값이 정수가 아니게 되어 집계 함수가 동작하지 않습니다
3. OTLP 가 문자열 라벨을 지원하지 않으므로 전송 단계에서 거부됩니다
4. SDK 가 라벨을 해시로 바꾸므로 값을 되읽을 수 없게 됩니다
메트릭 그래프에서 지연이 튄 구간을 찾은 뒤 그 구간의 실제 트레이스로 바로 넘어가게 해 주는 것은?
1. 히스토그램 버킷 경계
2. 리소스 속성
3. Baggage 항목
4. Exemplar
RED 방법과 USE 방법의 차이로 옳은 것은?
1. RED 는 로그를 보고 USE 는 메트릭을 보는 차이입니다
2. RED 는 요청을 처리하는 서비스를, USE 는 자원을 보는 관점이라 대상이 다릅니다
3. RED 는 개발 환경에, USE 는 운영 환경에 쓰도록 정해져 있습니다
4. RED 는 CNCF 표준이고 USE 는 폐기된 방법론입니다
구조화 로그를 쓰는 가장 실질적인 이유는?
1. 필드가 이름과 타입을 가지므로 정규식 없이 질의하고 다른 시그널과 상관 지을 수 있습니다
2. 평문 로그보다 저장 용량을 항상 절반 이하로 줄여 줍니다
3. 로그 수집기가 없어도 백엔드가 알아서 로그를 가져갑니다
4. 구조화 로그만 OpenTelemetry 로그 시그널로 보낼 수 있습니다
SLO 와 에러 버짓의 관계로 옳은 것은?
1. 에러 버짓은 SLO 를 달성한 달에만 다음 달로 이월되어 누적됩니다
2. 에러 버짓이 남아 있으면 SLI 측정을 중단해도 됩니다
3. 에러 버짓은 SLO 목표치와 100% 사이의 여유분이며, 이것이 남아 있는지가 배포 속도를 조절하는 근거가 됩니다
4. SLO 를 100% 로 잡으면 에러 버짓이 무한해집니다
특정 요청 하나가 어느 서비스에서 시간을 썼는지 알아야 합니다. 가장 적합한 시그널과 그 이유는?
1. 메트릭입니다. 집계값이 가장 정확하기 때문입니다
2. 트레이스입니다. 요청 하나가 거친 구간을 부모 자식 관계로 이어 붙여 보여 주기 때문입니다
3. 로그입니다. 모든 서비스가 이미 로그를 남기고 있기 때문입니다
4. 프로파일입니다. 함수 단위 시간까지 볼 수 있기 때문입니다
OpenTelemetry 프로젝트가 제공하지 않는 것은?
1. 텔레메트리 생성용 API 와 SDK
2. 텔레메트리 전송 규약인 OTLP
3. 텔레메트리를 장기 보관하고 질의하는 저장소
4. 텔레메트리를 수집하고 가공하는 컬렉터
관측 데이터 비용을 줄이려 합니다. 정보 손실이 가장 적은 순서로 먼저 손대야 할 것은?
1. 모든 서비스의 로그 수준을 ERROR 로 올립니다
2. 트레이스 수집을 전면 중단하고 메트릭만 남깁니다
3. 보관 기간을 하루로 줄입니다
4. 헬스체크처럼 가치 없는 트래픽을 걸러 내고 반복되는 이벤트를 집계로 바꿉니다
OpenTelemetry 스펙에서 시그널마다 안정성 등급이 따로 붙어 있는 이유는?
1. 언어별 SDK 성능 차이를 표시하기 위해서입니다
2. 시그널마다 설계가 굳은 시점이 달라서, 안정 등급이면 호환을 깨는 변경을 하지 않겠다는 약속이 붙기 때문입니다
3. 유료 지원 범위를 구분하기 위해서입니다
4. 등급이 낮은 시그널은 컬렉터가 처리하지 못하기 때문입니다
장애 조사 중 '어떤 코드가 CPU 를 쓰고 있는가'를 알아야 합니다. 이 질문에 답하는 시그널은?
1. 메트릭
2. 로그
3. 프로파일
4. 트레이스
TracerProvider 의 역할로 옳은 것은?
1. 스팬을 백엔드로 직접 전송하는 HTTP 클라이언트입니다
2. Tracer 를 만들어 주고 샘플러와 스팬 프로세서와 리소스 같은 SDK 설정을 보유합니다
3. 컬렉터에서 파이프라인을 정의하는 설정 블록입니다
4. 트레이스 컨텍스트를 헤더로 직렬화하는 구성 요소입니다
HTTP 요청을 받아 처리하는 서버 쪽 진입 스팬에 붙여야 할 SpanKind 는?
1. INTERNAL
2. CLIENT
3. PRODUCER
4. SERVER
스팬에서 예외를 기록할 때 상태 코드까지 함께 다뤄야 하는 이유는?
1. 예외를 기록하면 스팬이 자동으로 종료되기 때문입니다
2. 예외 기록은 이벤트를 추가할 뿐이므로, 이 구간이 실패했다고 표시하려면 상태를 ERROR 로 따로 설정해야 합니다
3. 상태를 설정하지 않으면 스팬이 익스포터에서 버려지기 때문입니다
4. 예외 기록과 상태 설정은 같은 동작이라 둘 중 하나만 부르면 되기 때문입니다
스팬 속성과 스팬 이벤트를 나누어 쓰는 기준으로 옳은 것은?
1. 속성은 구간 전체를 설명하는 키값이고, 이벤트는 구간 안의 특정 시각에 일어난 일입니다
2. 속성은 문자열만 담고 이벤트는 숫자만 담습니다
3. 속성은 SDK 가 붙이고 이벤트는 컬렉터가 붙입니다
4. 속성은 검색이 되고 이벤트는 검색이 되지 않습니다
메시지 100건을 한 배치로 처리하는 컨슈머 스팬에서 Span Link 가 필요한 이유는?
1. 링크를 걸면 부모 스팬의 샘플링 결정이 그대로 상속되기 때문입니다
2. 링크가 없으면 스팬이 생성되지 않기 때문입니다
3. 배치 처리는 트레이스를 만들 수 없으므로 링크로 대신하기 때문입니다
4. 부모는 하나만 가질 수 있는데 원인이 되는 트레이스는 여럿이므로, 나머지를 링크로 가리켜야 하기 때문입니다
W3C Trace Context 의 tracestate 헤더가 담는 것은?
1. 벤더별 추가 상태 정보이며, traceparent 로는 표현할 수 없는 값을 키값 목록으로 실어 나릅니다
2. 그 요청이 거쳐 온 스팬의 속성 전체를 직렬화해 담은 값입니다
3. 샘플링 여부를 나타내는 한 비트입니다
4. 요청 본문의 해시값입니다
Baggage 를 쓸 때 반드시 주의해야 할 점은?
1. Baggage 는 트레이스가 샘플링된 경우에만 전파됩니다
2. Baggage 는 스팬 속성으로 자동 승격되므로 별도 설정이 필요 없습니다
3. Baggage 는 모든 하위 호출의 HTTP 헤더에 그대로 실려 나가므로, 민감 정보를 넣으면 외부 서비스까지 새어 나가고 헤더 크기도 커집니다
4. Baggage 는 프로세스 안에서만 유효하고 네트워크로는 전파되지 않습니다
OTEL_PROPAGATORS 를 별도로 지정하지 않은 SDK 의 기본 전파기 조합은?
1. b3 와 jaeger
2. 아무 전파기도 등록되지 않습니다
3. tracecontext 와 baggage
4. xray 와 ottrace
구형 서비스는 B3 헤더만 보내는데 신규 서비스는 tracecontext 만 읽습니다. 나타나는 증상은?
1. 두 서비스 사이의 호출이 연결 자체에 실패합니다
2. 신규 서비스가 부모를 찾지 못해 새 트레이스를 시작하고, 트레이스가 경계에서 끊깁니다
3. trace ID 가 뒤섞여 서로 다른 요청이 한 트레이스로 합쳐집니다
4. SDK 가 두 형식을 자동으로 변환해 문제가 생기지 않습니다
현재 활성 연결 수처럼 늘고 줄기를 반복하는 값을 동기 계측기로 기록할 때 알맞은 것은?
1. Counter
2. Histogram
3. UpDownCounter
4. Observable Counter
요청 지연을 기록할 때 Gauge 가 아니라 Histogram 을 쓰는 이유는?
1. Histogram 이 Gauge 보다 전송 데이터가 항상 작기 때문입니다
2. Gauge 는 정수만 담을 수 있기 때문입니다
3. Gauge 는 관측 시점의 한 값만 남겨 분포와 백분위를 잃지만, Histogram 은 버킷별 개수를 유지해 p95 같은 값을 낼 수 있기 때문입니다
4. Gauge 는 OTLP 로 전송되지 않기 때문입니다
Observable(비동기) 계측기의 콜백을 작성할 때 지켜야 할 규칙은?
1. 콜백은 수집 주기마다 호출되므로 빠르게 끝나야 하고, 블로킹 작업이나 예외를 발생시키는 코드를 넣으면 안 됩니다
2. 콜백 안에서 반드시 다른 계측기를 하나 이상 호출해야 합니다
3. 콜백은 애플리케이션이 직접 원하는 시점에 호출해야 합니다
4. 콜백은 프로세스 시작 시 한 번만 실행됩니다
메트릭의 delta 시간성과 cumulative 시간성의 차이로 옳은 것은?
1. delta 는 트레이스에만, cumulative 는 메트릭에만 쓰입니다
2. delta 는 직전 수집 이후의 변화량을, cumulative 는 시작 시점부터의 누적값을 보냅니다
3. delta 는 정수만, cumulative 는 실수만 담을 수 있습니다
4. delta 는 SDK 에서만, cumulative 는 컬렉터에서만 만들 수 있습니다
특정 히스토그램의 버킷 경계를 바꾸고 불필요한 속성 하나를 떨어뜨리려 합니다. SDK 에서 쓸 것은?
1. Sampler
2. Resource Detector
3. Propagator
4. View
OpenTelemetry 로그 시그널이 트레이스나 메트릭과 다른 방식으로 설계된 점은?
1. 기존 로깅 프레임워크를 그대로 두고 브리지(appender)로 연결하는 것을 기본 도입 경로로 삼습니다
2. 로그는 OTLP 로 전송할 수 없어 파일로만 남기고 수집기가 따로 읽어 갑니다
3. 로그는 API 가 없고 컬렉터에서만 생성됩니다
4. 로그는 리소스 속성을 갖지 않습니다
로그에서 trace_id 를 얻어 트레이스와 이어 붙이려면 무엇이 필요합니까?
1. 컬렉터의 batch 프로세서를 켜면 자동으로 붙습니다
2. 로그를 남기는 시점의 활성 컨텍스트에서 스팬 컨텍스트를 읽어 필드로 넣어 주는 계측이 필요합니다
3. 백엔드에서 타임스탬프가 가까운 로그와 스팬을 짝지어 줍니다
4. 로그 수준을 DEBUG 로 올리면 SDK 가 자동으로 넣습니다
코드에서 만든 Resource 와 OTEL_RESOURCE_ATTRIBUTES 환경변수에 같은 키가 있을 때의 처리로 옳은 것은?
1. SDK 가 충돌을 감지하고 시작을 중단합니다
2. 두 값이 쉼표로 이어진 하나의 문자열이 됩니다
3. 환경변수 값이 언제나 우선하며 코드 설정은 무시됩니다
4. 리소스는 병합되며, 명시적으로 만든 리소스 쪽이 환경변수에서 온 기본 리소스를 덮어씁니다
쿠버네티스에서 파드 이름과 네임스페이스를 리소스 속성으로 넣는 방법 중 애플리케이션 코드를 고치지 않는 것은?
1. Downward API 로 값을 환경변수에 넣고 OTEL_RESOURCE_ATTRIBUTES 로 전달하거나, 컬렉터의 k8sattributes 프로세서로 붙입니다
2. kubelet 이 OTLP 페이로드를 가로채 파드 이름과 네임스페이스를 자동으로 삽입해 줍니다
3. SDK 가 API 서버에 직접 질의해 채웁니다
4. OTLP 헤더에 파드 정보가 기본 포함됩니다
BatchSpanProcessor 의 큐가 가득 찼을 때 일어나는 일은?
1. 애플리케이션 스레드가 큐에 자리가 날 때까지 대기합니다
2. 새로 들어오는 스팬이 조용히 버려지고 드롭 카운터만 올라갑니다
3. 프로세서가 자동으로 큐 크기를 두 배로 늘립니다
4. 익스포터가 동기 모드로 전환됩니다
SimpleSpanProcessor 를 운영 환경에서 쓰지 말라고 하는 이유는?
1. 샘플링 결정을 무시하고 모든 스팬을 내보내기 때문입니다
2. 리소스 속성을 붙이지 않기 때문입니다
3. 스팬이 끝날 때마다 즉시 익스포트해 호출 경로에 네트워크 지연이 그대로 실리기 때문입니다
4. OTLP 를 지원하지 않고 콘솔 출력만 가능하기 때문입니다
짧게 끝나는 배치 잡이나 서버리스 함수에서 텔레메트리가 유실될 때 코드에서 해야 할 일은?
1. 프로세스를 끝내기 전에 강제 플러시와 종료를 호출해 큐에 남은 데이터를 내보냅니다
2. 익스포트 간격을 더 길게 잡아 배치를 크게 만듭니다
3. 샘플링 비율을 0 으로 낮춰 데이터 양을 줄입니다
4. SimpleSpanProcessor 대신 BatchSpanProcessor 로 반드시 바꿉니다
기본 샘플러인 parentbased_always_on 의 동작으로 옳은 것은?
1. 부모의 샘플링 결정이 있으면 그것을 따르고, 부모가 없는 루트 스팬만 항상 샘플링합니다
2. 부모 여부와 관계없이 모든 스팬을 개별적으로 다시 판정합니다
3. 부모가 샘플링되지 않았어도 자식은 항상 샘플링합니다
4. trace ID 해시를 계산해 고정 비율만 남깁니다
헤드 샘플링 결정이 하위 서비스로 전달되는 방식은?
1. 컬렉터가 서비스 목록을 보고 각 서비스에 결정을 통보합니다
2. 각 서비스가 같은 샘플링 비율을 설정해 두면 판정 결과가 저절로 일치하게 됩니다
3. SDK 가 백엔드에 질의해 이미 샘플링된 트레이스인지 확인합니다
4. traceparent 헤더의 sampled 플래그 비트에 실려 전파되고, 하위 서비스의 parentbased 샘플러가 이를 따릅니다
자동 계측(zero-code instrumentation)의 한계로 옳은 것은?
1. 자동 계측을 켜면 수동 계측 API 를 함께 쓸 수 없습니다
2. 자동 계측은 메트릭만 만들고 트레이스는 만들지 않습니다
3. 지원되는 라이브러리의 경계는 잡아 주지만 사업 로직의 의미 있는 구간과 도메인 속성은 만들지 못합니다
4. 자동 계측은 컬렉터가 있어야만 동작합니다
성능 문제를 조사하려고 특정 파드에서만 SDK 를 잠시 꺼야 합니다. 코드 변경 없이 쓸 수 있는 방법은?
1. OTEL_SDK_DISABLED 를 true 로 두어 SDK 를 no-op 로 만듭니다
2. OTEL_EXPORTER_OTLP_ENDPOINT 를 빈 문자열로 둡니다
3. OTEL_LOG_LEVEL 을 none 으로 둡니다
4. OTEL_SERVICE_NAME 을 지워 리소스를 비웁니다
OTEL_EXPORTER_OTLP_TRACES_ENDPOINT 를 쓸 때 주의할 점은?
1. 이 변수는 gRPC 에서만 유효합니다
2. 시그널별 변수이므로 HTTP 에서는 SDK 가 경로를 덧붙이지 않고, 값에 /v1/traces 까지 전부 적어야 합니다
3. 이 변수를 쓰면 메트릭과 로그까지 모두 같은 주소로 함께 전송됩니다
4. 공통 변수보다 우선순위가 낮아 함께 쓰면 무시됩니다
스팬 속성 이름을 임의로 짓지 않고 시맨틱 컨벤션을 따르는 이유로 가장 적절한 것은?
1. 임의 속성은 OTLP 로 전송되지 않기 때문입니다
2. SDK 의 속성 개수 제한이 컨벤션 속성에는 적용되지 않아 더 많이 넣을 수 있기 때문입니다
3. 컨벤션 속성만 인덱싱되어 검색이 가능하기 때문입니다
4. 백엔드와 대시보드와 컬렉터 프로세서가 약속된 키를 전제로 동작하므로, 이름이 어긋나면 기존 도구가 데이터를 알아보지 못하기 때문입니다
스팬을 만들었지만 종료 호출을 빠뜨린 코드가 있습니다. 나타나는 결과는?
1. SDK 가 프로세스 종료 시 자동으로 닫아 정상 전송됩니다
2. 부모 스팬이 대신 종료시켜 지속 시간이 0 으로 기록됩니다
3. 다음 스팬 생성 시 이전 스팬이 자동으로 닫힙니다
4. 그 스팬은 익스포트되지 않고, 자식 스팬만 도착해 트레이스가 비어 보이거나 불완전해집니다
컬렉터를 에이전트로 배포할 때와 게이트웨이로 배포할 때의 차이로 옳은 것은?
1. 에이전트는 트레이스만, 게이트웨이는 메트릭만 다룹니다
2. 에이전트는 노드나 사이드카에 붙어 로컬 데이터를 모으고, 게이트웨이는 별도 서비스로 모아 중앙에서 가공하고 라우팅합니다
3. 에이전트는 Core 배포판만, 게이트웨이는 Contrib 배포판만 쓸 수 있습니다
4. 게이트웨이는 상태를 갖지 않고 에이전트는 상태를 가집니다
컴포넌트를 receivers 와 exporters 에 정의만 하고 service.pipelines 에는 넣지 않았습니다. 결과는?
1. 정의만 되고 실제로는 인스턴스화되지 않아 아무 일도 하지 않습니다
2. 컬렉터가 설정 오류로 기동에 실패합니다
3. 기본 파이프라인에 자동으로 편입되어 동작합니다
4. 경고 로그를 남긴 뒤 첫 데이터 수신 시 자동 활성화됩니다
컨테이너에서 otlp 리시버를 켰는데 외부에서 접속이 되지 않습니다. 가장 가능성 높은 원인은?
1. gRPC 는 컨테이너 안에서 동작하지 않습니다
2. 리시버가 TLS 를 요구하는데 클라이언트가 평문으로 보내고 있습니다
3. 컬렉터가 프로세서 없이는 리시버를 열지 않습니다
4. 엔드포인트가 localhost 로 바인딩되어 있어 컨테이너 밖에서 오는 연결을 받지 못합니다
memory_limiter 프로세서의 동작으로 옳은 것은?
1. 메모리를 초과하면 컬렉터를 재시작해 자원을 회수합니다
2. 메모리 사용량이 임계에 닿으면 데이터를 거부해 리시버가 클라이언트에 오류를 돌려주고, 이를 통해 배압을 앞으로 전달합니다
3. 메모리 사용량이 임계에 닿으면 오래된 데이터부터 조용히 버립니다
4. 익스포터 큐 크기를 자동으로 줄여 줍니다
attributes 프로세서와 resource 프로세서의 차이는?
1. attributes 는 트레이스에만, resource 는 메트릭에만 적용됩니다
2. attributes 는 값을 추가만 하고 resource 는 삭제만 합니다
3. attributes 는 스팬이나 데이터포인트 각각의 속성을, resource 는 그 데이터를 만든 주체를 설명하는 리소스 속성을 다룹니다
4. attributes 는 컬렉터에서, resource 는 SDK 에서만 쓸 수 있습니다
속성 값의 일부만 마스킹하는 것처럼 조건과 변환이 함께 필요한 가공에 적합한 컬렉터 컴포넌트는?
1. OTTL 문법을 쓰는 transform 프로세서
2. batch 프로세서
3. memory_limiter 프로세서
4. probabilistic_sampler 프로세서
컬렉터 파이프라인에서 memory_limiter 와 batch 를 함께 쓸 때 권장되는 순서와 이유는?
1. batch 를 먼저 두어야 memory_limiter 가 정확한 크기를 알 수 있습니다
2. 순서는 성능에만 영향을 주고 동작에는 차이가 없습니다
3. 두 프로세서는 함께 쓸 수 없습니다
4. memory_limiter 를 먼저 두어야 과부하 시 데이터를 배치로 쌓기 전에 거부해 메모리를 지킬 수 있습니다
한 파이프라인의 출력을 다른 파이프라인의 입력으로 넘겨 스팬에서 메트릭을 만들려 합니다. 필요한 것은?
1. extension
2. receiver 두 개를 같은 포트에 바인딩
3. connector
4. exporter 의 routing 옵션
테일 샘플링을 쓰는 게이트웨이를 여러 대로 늘릴 때 앞단에 필요한 것은?
1. trace ID 를 기준으로 분배하는 loadbalancing 익스포터 계층
2. 라운드로빈 방식의 일반 L4 로드밸런서
3. 각 게이트웨이에 동일한 정적 IP 를 부여하는 설정
4. 게이트웨이 사이의 공유 파일 스토리지
익스포터의 sending_queue 와 retry_on_failure 의 역할 구분으로 옳은 것은?
1. sending_queue 는 재시도 간격을, retry_on_failure 는 큐 크기를 정합니다
2. sending_queue 는 전송 대기 데이터를 버퍼링하고, retry_on_failure 는 실패한 요청을 백오프로 다시 보냅니다
3. 둘 다 같은 기능이며 하나만 켜면 됩니다
4. sending_queue 는 메모리에, retry_on_failure 는 디스크에 데이터를 씁니다
컬렉터가 재시작해도 큐에 남아 있던 데이터를 잃지 않게 하려면?
1. sending_queue 의 크기를 최대로 키웁니다
2. batch 프로세서의 타임아웃을 0 으로 둡니다
3. memory_limiter 의 임계를 100% 로 올립니다
4. file_storage 확장을 붙이고 익스포터 큐가 그 스토리지를 쓰도록 지정해 큐를 디스크에 영속화합니다
컬렉터 자체의 상태를 확인하는 extension 과 그 용도로 올바르게 짝지은 것은?
1. health_check 는 컬렉터의 기동 상태를 HTTP 로 노출해 쿠버네티스 프로브에 씁니다
2. zpages 는 익스포터 큐를 디스크에 저장합니다
3. pprof 는 파이프라인 설정을 검증합니다
4. health_check 는 백엔드의 응답 시간을 측정합니다
k8sattributes 프로세서가 파드 정보를 붙이지 못하고 있습니다. 가장 먼저 확인할 것은?
1. 컬렉터를 사이드카가 아니라 DaemonSet 으로 바꿉니다
2. batch 프로세서를 앞으로 옮깁니다
3. 컬렉터 ServiceAccount 가 파드와 네임스페이스를 조회할 RBAC 권한을 갖고 있는지 봅니다
4. OTLP 전송 방식을 gRPC 로 바꿉니다
Prometheus 형식 지표를 컬렉터가 가져오게 하려면 어떤 컴포넌트를 씁니까?
1. prometheusremotewrite 익스포터
2. prometheus 리시버
3. prometheus 커넥터
4. prometheus 확장
문서에서 본 컴포넌트를 설정에 넣었더니 컬렉터가 알 수 없는 타입이라며 기동에 실패합니다. 배포판을 확인하는 명령은?
1. otelcol validate --config 로 문법을 검사합니다
2. otelcol --version 으로 버전만 확인합니다
3. kubectl describe 로 파드 이벤트를 봅니다
4. otelcol components 로 이 바이너리에 포함된 컴포넌트 목록과 안정성 등급을 확인합니다
컬렉터에 데이터가 실제로 들어오는지 눈으로 확인하려 합니다. 최신 배포판에서 쓸 익스포터는?
1. logging 익스포터
2. nop 익스포터
3. debug 익스포터
4. file 익스포터
otelcol_exporter_send_failed_spans 가 꾸준히 증가하고 있습니다. 이 지표가 가리키는 지점은?
1. 애플리케이션 SDK 가 스팬 생성에 실패하고 있습니다
2. 리시버가 잘못된 형식의 페이로드를 받고 있습니다
3. 프로세서가 스팬을 정책에 따라 걸러 내고 있습니다
4. 컬렉터에서 백엔드로 나가는 구간이 실패하고 있으므로 백엔드 상태와 인증과 네트워크를 봐야 합니다
데이터가 백엔드까지 도달하지 않을 때 파이프라인을 구간별로 좁히는 순서로 가장 합리적인 것은?
1. 리시버 수신 지표를 먼저 보고, 프로세서 드롭 지표를 본 뒤, 익스포터 전송 실패 지표를 봅니다
2. 백엔드 대시보드를 먼저 보고 없으면 컬렉터를 재시작합니다
3. 익스포터 설정을 먼저 지우고 하나씩 다시 넣습니다
4. 모든 서비스의 샘플링 비율을 100% 로 올려 재현합니다
컬렉터 자체 텔레메트리를 확보해 두어야 하는 이유로 가장 적절한 것은?
1. 컬렉터 자체 지표는 백엔드의 과금 대상에서 제외되어 비용이 들지 않기 때문입니다
2. 관측 파이프라인 자신이 장애 지점이 될 수 있으므로, 파이프라인이 죽었는지 밀렸는지를 알려 줄 독립적인 신호가 필요하기 때문입니다
3. 설정 파일 문법 오류를 자동으로 고쳐 주기 때문입니다
4. 자체 텔레메트리를 켜야 프로세서가 활성화되기 때문입니다
컬렉터를 새 버전으로 올린 뒤 기동에 실패했습니다. 릴리스 노트에서 먼저 확인할 것은?
1. 컨테이너 이미지의 압축 크기 변화
2. 지원 쿠버네티스 버전 목록
3. 새로 추가된 익스포터 종류
4. 폐기되거나 이름이 바뀐 컴포넌트와 설정 키가 있는지
백엔드에서 메트릭 시계열 수가 갑자기 몇 배로 늘었습니다. 컬렉터 계층에서 취할 조치로 가장 적절한 것은?
1. 익스포터 큐 크기를 늘려 전송 실패를 줄입니다
2. batch 프로세서의 배치 크기를 키워 백엔드로 가는 요청 수를 줄입니다
3. 원인이 된 고카디널리티 속성을 찾아 transform 이나 attributes 프로세서로 제거하거나 값을 묶습니다
4. 메트릭 파이프라인을 중단하고 트레이스만 남깁니다