OpenTelemetry Collector 살펴보기

OpenTelemetry Collector는 OpenTelemetry 아키텍처의 중심에 있지만 W3C 추적 컨텍스트와 관련이 없습니다. 내 에서는 Collector 대신 Jaeger를 사용합니다. 그러나 모든 OpenTelemetry 관련 게시물과 마찬가지로 어디에나 존재합니다. 나는 그것을 더 탐구하고 싶었습니다.

이 게시물에서는 Collector의 다양한 측면을 살펴봅니다.

• 데이터 종류: 로그, 측정항목, 추적
• 푸시 및 풀 모델
• 작업: 읽기, 변환 및 쓰기

첫 번째 단계

오래 전에는 우리가 알고 있는 관측 가능성이 존재하지 않았습니다. 대신 우리가 가진 것은 모니터링 이었습니다. 그 당시 모니터링은 대시보드가 표시된 화면을 여러 사람이 보는 일이었습니다. 대시보드 자체는 지표와 시스템 지표(주로 CPU, 메모리, 디스크 사용량)로만 구성되었습니다. 이러한 이유로 측정항목부터 시작하겠습니다.

는 주요 모니터링 솔루션 중 하나입니다. 풀 기반 모델에서 작동합니다. Prometheus는 애플리케이션의 호환 가능한 엔드포인트를 스크랩하여 내부에 저장합니다.

OTEL Collector를 사용하여 Prometheus 호환 엔드포인트를 스크랩하고 콘솔에 결과를 인쇄해 보겠습니다. Grafana Labs는 사용할 무작위 측정항목을 생성하는 제공합니다. 단순화를 위해 Docker Compose를 사용하겠습니다. 설정은 다음과 같습니다.

 version: "3" services: fake-metrics: build: ./fake-metrics-generator #1 collector: image: otel/opentelemetry-collector:0.87.0 #2 environment: #3 - METRICS_HOST=fake-metrics - METRICS_PORT=5000 volumes: - ./config/collector/config.yml:/etc/otelcol/config.yaml:ro #4

1. 가짜 지표 프로젝트에는 Docker 이미지를 사용할 수 없습니다. 그러므로 우리는 그것을 구축해야 합니다
2. 이 글을 쓰는 시점의 OTEL Collector 최신 버전
3. 다음 구성 파일을 매개변수화합니다.
4. 모든 일은 여기서 일어난다

위에서 언급했듯이 OTEL Collector는 많은 일을 할 수 있습니다. 따라서 구성이 전부입니다.

 receivers: #1 prometheus: #2 config: scrape_configs: #3 - job_name: fake-metrics #4 scrape_interval: 3s static_configs: - targets: [ "${env:METRICS_HOST}:${env:METRICS_PORT}" ] exporters: #5 logging: #6 loglevel: debug service: pipelines: #7 metrics: #8 receivers: [ "prometheus" ] #9 exporters: [ "logging" ] #9

1. 수신자 목록입니다. 수신기는 데이터를 읽습니다. 푸시 기반이거나 풀 기반일 수 있습니다.
2. 우리는 사전 정의된 prometheus 수신기를 사용합니다.
3. 풀 작업 정의
4. 작업 구성
5. 수출업체 목록. 수신자와 달리 수출자는 데이터를 씁니다.
6. 가장 간단한 내보내기는 표준 출력에 데이터를 쓰는 것입니다.
7. 파이프라인은 수신자와 수출자를 조립합니다.
8. 측정항목 관련 파이프라인 정의
9. 파이프라인은 이전에 정의된 prometheus 수신기로부터 데이터를 가져와 logging 내보내기 도구로 보냅니다. 즉 , 이를 인쇄합니다.

결과 샘플은 다음과 같습니다.

 2024-11-11 08:28:54 otel-collector-collector-1 | StartTimestamp: 1971-01-01 00:00:00 +0000 UTC 2024-11-11 08:28:54 otel-collector-collector-1 | Timestamp: 2024-11-11 07:28:54.14 +0000 UTC 2024-11-11 08:28:54 otel-collector-collector-1 | Value: 83.090000 2024-11-11 08:28:54 otel-collector-collector-1 | NumberDataPoints #1 2024-11-11 08:28:54 otel-collector-collector-1 | Data point attributes: 2024-11-11 08:28:54 otel-collector-collector-1 | -> fake__embrace_world_class_systems: Str(concept) 2024-11-11 08:28:54 otel-collector-collector-1 | -> fake__exploit_magnetic_applications: Str(concept) 2024-11-11 08:28:54 otel-collector-collector-1 | -> fake__facilitate_wireless_architectures: Str(extranet) 2024-11-11 08:28:54 otel-collector-collector-1 | -> fake__grow_magnetic_communities: Str(challenge) 2024-11-11 08:28:54 otel-collector-collector-1 | -> fake__reinvent_revolutionary_applications: Str(support) 2024-11-11 08:28:54 otel-collector-collector-1 | -> fake__strategize_strategic_initiatives: Str(internet_solution) 2024-11-11 08:28:54 otel-collector-collector-1 | -> fake__target_customized_eyeballs: Str(concept) 2024-11-11 08:28:54 otel-collector-collector-1 | -> fake__transform_turn_key_technologies: Str(framework) 2024-11-11 08:28:54 otel-collector-collector-1 | -> fake__whiteboard_innovative_partnerships: Str(matrices) 2024-11-11 08:28:54 otel-collector-collector-1 | StartTimestamp: 1971-01-01 00:00:00 +0000 UTC 2024-11-11 08:28:54 otel-collector-collector-1 | Timestamp: 2024-11-11 07:28:54.14 +0000 UTC 2024-11-11 08:28:54 otel-collector-collector-1 | Value: 53.090000 2024-11-11 08:28:54 otel-collector-collector-1 | NumberDataPoints #2 2024-11-11 08:28:54 otel-collector-collector-1 | Data point attributes: 2024-11-11 08:28:54 otel-collector-collector-1 | -> fake__expedite_distributed_partnerships: Str(approach) 2024-11-11 08:28:54 otel-collector-collector-1 | -> fake__facilitate_wireless_architectures: Str(graphical_user_interface) 2024-11-11 08:28:54 otel-collector-collector-1 | -> fake__grow_magnetic_communities: Str(policy) 2024-11-11 08:28:54 otel-collector-collector-1 | -> fake__reinvent_revolutionary_applications: Str(algorithm) 2024-11-11 08:28:54 otel-collector-collector-1 | -> fake__transform_turn_key_technologies: Str(framework) 2024-11-11 08:28:54 otel-collector-collector-1 | StartTimestamp: 1971-01-01 00:00:00 +0000 UTC 2024-11-11 08:28:54 otel-collector-collector-1 | Timestamp: 2024-11-11 07:28:54.14 +0000 UTC 2024-11-11 08:28:54 otel-collector-collector-1 | Value: 16.440000 2024-11-11 08:28:54 otel-collector-collector-1 | NumberDataPoints #3 2024-11-11 08:28:54 otel-collector-collector-1 | Data point attributes: 2024-11-11 08:28:54 otel-collector-collector-1 | -> fake__exploit_magnetic_applications: Str(concept) 2024-11-11 08:28:54 otel-collector-collector-1 | -> fake__grow_magnetic_communities: Str(graphical_user_interface) 2024-11-11 08:28:54 otel-collector-collector-1 | -> fake__target_customized_eyeballs: Str(extranet)

인쇄를 넘어

위의 내용은 훌륭한 첫 번째 단계이지만 콘솔에 인쇄하는 것 이상의 작업이 있습니다. 일반 Prometheus 인스턴스에서 스크랩할 측정항목을 노출합니다. 추가하여 시각화할 수 있습니다. 무의미해 보일 수도 있지만, 단지 디딤돌일 뿐이므로 참아주세요.

위의 목적을 달성하기 위해 OTEL Collector 구성만 변경합니다.

 exporters: prometheus: #1 endpoint: ":${env:PROMETHEUS_PORT}" #2 service: pipelines: metrics: receivers: [ "prometheus" ] exporters: [ "prometheus" ] #3

1. prometheus 내보내기 추가
2. Prometheus 호환 엔드포인트 노출
3. 인쇄를 노출로 대체

그게 다야. OTEL Collector는 매우 유연합니다.

Collector는 다중 입력, 다중 출력입니다. 데이터를 인쇄하고 엔드포인트를 통해 노출하려면 데이터를 파이프라인에 추가합니다.

 exporters: prometheus: #1 endpoint: ":${env:PROMETHEUS_PORT}" logging: #2 loglevel: debug service: pipelines: metrics: receivers: [ "prometheus" ] exporters: [ "prometheus", "logging" ] #3

1. 데이터 노출
2. 데이터 인쇄
3. 파이프라인은 데이터를 인쇄하고 노출합니다.

Prometheus 내보내기 도구를 구성하면 Grafana에서 측정항목을 시각화할 수 있습니다.

수신자와 수출자는 자신의 유형을 지정 하며 각각은 고유해야 합니다. 마지막 요구 사항을 준수하기 위해 prometheus/foo 및 prometheus/bar. 를 구별하는 한정자를 추가할 수 있습니다 .

중개 데이터 처리

유효한 질문은 OTEL Collector가 소스와 Prometheus 사이에 설정되는 이유입니다. 이는 전체 디자인을 더욱 취약하게 만들기 때문입니다. 이 단계에서는 OTEL Collector의 진정한 기능인 데이터 처리를 활용할 수 있습니다. 지금까지 원시 측정항목을 수집했지만 소스 형식이 데이터 시각화 방식에 적합하지 않을 수 있습니다. 예를 들어, 우리 설정에서 메트릭은 가짜 생성기인 "비즈니스"와 기본 NodeJS 플랫폼인 "기술"에서 나옵니다. 이는 측정항목 이름에 반영됩니다. 전용 소스 레이블을 추가하고 불필요한 접두사를 제거하여 보다 효율적으로 필터링할 수 있습니다.

구성 파일의 processors 섹션에서 데이터 프로세서를 선언합니다. 컬렉터는 선언된 순서대로 실행합니다. 위의 변환을 구현해 보겠습니다.

우리의 목표를 향한 첫 번째 단계는 컬렉터가 두 가지 특징을 가지고 있다는 것을 이해하는 것입니다. 하나는 "기본" 하나이고 다른 하나는 이를 기반으로 하는 기여형입니다. 전자에 포함된 프로세서는 수와 기능면에서 제한되어 있습니다. 따라서 contrib 버전을 전환해야 합니다.

 collector: image: otel/opentelemetry-collector-contrib:0.87.0 #1 environment: - METRICS_HOST=fake-metrics - METRICS_PORT=5000 - PROMETHEUS_PORT=8889 volumes: - ./config/collector/config.yml:/etc/otelcol-contrib/config.yaml:ro #2

1. contrib 플레이버를 사용하세요
2. 재미를 더하기 위해 구성 파일은 다른 경로에 있습니다.

이 시점에서 프로세서 자체를 추가할 수 있습니다.

 processors: metricstransform: #1 transforms: #2 - include: ^fake_(.*)$ #3 match_type: regexp #3 action: update operations: #4 - action: add_label #5 new_label: origin new_value: fake - include: ^fake_(.*)$ match_type: regexp action: update #6 new_name: $${1} #6-7 # Do the same with metrics generated by NodeJS

1. 메트릭 변환 프로세서 호출
2. 순서대로 적용된 변환 목록
3. 정의된 정규 표현식과 모든 측정항목을 일치시킵니다.
4. 순서대로 적용되는 작업 목록
5. 라벨 추가
6. 정규 표현식 그룹 접두사를 제거하여 측정항목 이름을 바꿉니다.
7. 재미있는 점: 구문은 $${x} 입니다.

마지막으로 정의된 프로세서를 파이프라인에 추가합니다.

 service: pipelines: metrics: receivers: [ "prometheus" ] processors: [ "metricstransform" ] exporters: [ "prometheus" ]

결과는 다음과 같습니다.

수신기와 내보내기 연결

커넥터는 수신자이자 내보내기 이며 두 파이프라인을 연결합니다. 문서의 예는 범위 수(추적)를 수신하고 측정항목이 있는 개수를 내보냅니다. 나는 500개의 오류로 동일한 결과를 얻으려고 노력했습니다. 스포일러: 의도한 대로 작동하지 않습니다.

먼저 로그 수신기를 추가해 보겠습니다.

 receivers: filelog: include: [ "/var/logs/generated.log" ]

그런 다음 커넥터를 추가합니다.

 connectors: count: requests.errors: description: Number of 500 errors condition: [ "status == 500 " ]

마지막으로 로그 수신기와 측정항목 내보내기를 연결합니다.

 service: pipelines: logs: receivers: [ "filelog" ] exporters: [ "count" ] metrics: receivers: [ "prometheus", "count" ]

측정항목 이름은 log_record_count_total 이지만 값은 1로 유지됩니다.

로그 조작

프로세서는 데이터 조작을 허용합니다. 연산자는 로그에서 작동하는 특수 프로세서입니다. Elasticsearch Logstash Kibana 스택에 익숙하다면 이는 Logstash와 동일합니다.

현재로서는 로그 타임스탬프가 수집 타임스탬프입니다. 이를 생성된 타임스탬프로 변경하겠습니다.

 receivers: filelog: include: [ "/var/logs/generated.log" ] operators: - type: json_parser #1 timestamp: #2 parse_from: attributes.datetime #3 layout: "%d/%b/%Y:%H:%M:%S %z" #4 severity: #2 parse_from: attributes.status #3 mapping: #5 error: 5xx #6 warn: 4xx info: 3xx debug: 2xx - id: remove_body #7 type: remove field: body - id: remove_datetime #7 type: remove field: attributes.datetime - id: remove_status #7 type: remove field: attributes.status

1. 로그는 JSON 형식입니다. 제공된 JSON 파서를 사용할 수 있습니다
2. 설정할 메타데이터 속성
3. 읽을 필드
4. 파싱 패턴
5. 매핑 테이블
6. 범위를 허용합니다( 예 : 501-599 . 연산자에는 HTTP 상태에 대해 특수하게 해석된 값 5xx (및 유사)가 있습니다.
7. 중복된 데이터 제거

로그

이 시점에서 로그를 모든 로그 집계 구성 요소로 보낼 수 있습니다. 우리는 Grafana Labs 영역에 머물면서 Loki를 사용할 것입니다.

 exporters: loki: endpoint: "//loki:3100/loki/api/v1/push"

수집기 자체의 로그를 사용할 수도 있습니다.

 service: telemetry: logs:

마지막으로 다른 파이프라인을 추가해 보겠습니다.

 service: pipelines: logs: receivers: [ "filelog" ] exporters: [ "loki" ]

Grafana는 로그를 시각화할 수도 있습니다. Loki를 데이터 소스로 선택합니다.

결론

이 게시물에서는 OpenTelemetry 수집기에 대해 자세히 살펴보았습니다. OTEL 아키텍처의 필수 부분은 아니지만 모든 데이터 처리 요구 사항에 유용한 유용한 도구입니다. 특정 스택에 얽매이지 않거나 원하지 않는 경우 이는 엄청난 도움이 됩니다.

이 게시물의 전체 소스 코드는 에서 찾을 수 있습니다.

더 나아가려면:

---