paint-brush
OpenTelemetry Collector'ı İncelemekile@nfrankel
1,352 okumalar
1,352 okumalar

OpenTelemetry Collector'ı İncelemek

ile Nicolas Fränkel18m2023/11/18
Read on Terminal Reader

Çok uzun; Okumak

OTEL mimarisinin zorunlu bir parçası olmasa da OTEL Collector, tüm veri işleme ihtiyaçlarınız için kullanışlı bir İsviçre bıçağıdır.
featured image - OpenTelemetry Collector'ı İncelemek
Nicolas Fränkel HackerNoon profile picture
0-item
1-item


OpenTelemetry Collector, OpenTelemetry mimarisinin merkezinde yer alır ancak W3C İzleme Bağlamı ile ilgisi yoktur. İzleme demomda Collector yerine Jaeger kullanıyorum. Ancak OpenTelemetry ile ilgili her gönderide olduğu gibi her yerde mevcuttur. Daha da keşfetmek istedim.


Bu yazıda Koleksiyoncunun farklı yönlerini araştırıyorum:


  • Veri türü: günlükler, ölçümler ve izler
  • İtme ve çekme modelleri
  • İşlemler: okuma, dönüştürme ve yazma

İlk adım

Uzun zaman önce, bildiğimiz şekliyle gözlemlenebilirlik mevcut değildi; bunun yerine yaptığımız şey izlemekti . O zamanlar izleme, kontrol panellerini gösteren ekranlara bakan bir grup insandan ibaretti. Gösterge tablolarının kendisi metriklerden ve yalnızca sistem metriklerinden oluşuyordu: esas olarak CPU, bellek ve disk kullanımı. Bu nedenle metriklerle başlayacağız.


Prometheus birincil izleme çözümlerinden biridir. Çekme tabanlı bir model üzerinde çalışır: Prometheus, uygulamanızın/uygulamalarınızın uyumlu uç noktalarını sıyırır ve bunları dahili olarak saklar.


Prometheus uyumlu bir uç nokta kazımak ve sonucu konsola yazdırmak için OTEL Collector'ı kullanacağız. Grafana Labs, oynanacak rastgele ölçümler üreten bir proje sunuyor. Basitlik açısından Docker Compose'u kullanacağım; kurulum aşağıdakine benzer:


 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. Sahte metrik projesi için Docker görüntüsü mevcut değil; dolayısıyla onu inşa etmemiz gerekiyor
  2. Bu yazının yazıldığı sırada OTEL Collector'ın en son sürümü
  3. Aşağıdaki yapılandırma dosyasını parametrelendirin
  4. Her şey burada olur


Yukarıda da belirttiğim gibi OTEL Koleksiyoncusu çok şey yapabilir. Dolayısıyla konfigürasyon her şeydir.


 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. Alıcıların listesi. Bir alıcı verileri okur; itme tabanlı veya çekme tabanlı olabilir.
  2. prometheus önceden tanımlanmış alıcısını kullanıyoruz
  3. Çekme işlerini tanımlayın
  4. İşin yapılandırması
  5. İhracatçıların listesi. Alıcıların aksine, ihracatçı veri yazar.
  6. En basit ihracatçı standart çıkışa veri yazmaktır
  7. Boru hatları alıcıları ve ihracatçıları bir araya getiriyor
  8. Metrikle ilgili bir ardışık düzen tanımlayın
  9. Boru hattı, önceden tanımlanmış prometheus alıcısından verileri alır ve bunu logging aktarıcısına gönderir, yani bunları yazdırır.


İşte sonucun bir örneği:


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

Yazdırmanın ötesinde

Yukarıdakiler mükemmel bir ilk adımdır ancak konsola yazdırmaktan daha fazlası vardır. Normal bir Prometheus örneği tarafından kazınacak metrikleri açığa çıkaracağız; bunları görselleştirmek için bir Grafana kontrol paneli ekleyebiliriz. Her ne kadar anlamsız görünse de buna katlanın çünkü bu sadece bir basamak taşıdır.


Yukarıdakileri başarmak için yalnızca OTEL Collector yapılandırmasını değiştiriyoruz:


 exporters: prometheus: #1 endpoint: ":${env:PROMETHEUS_PORT}" #2 service: pipelines: metrics: receivers: [ "prometheus" ] exporters: [ "prometheus" ] #3
  1. prometheus ihracatçısı ekleyin
  2. Prometheus uyumlu bir uç noktayı ortaya çıkarın
  3. Yazdırmayı pozlamayla değiştirin


Bu kadar. OTEL Toplayıcı çok esnektir.


Kollektörün çok girişli, çok çıkışlı olduğunu unutmayın. Verileri hem yazdırmak hem de uç nokta aracılığıyla kullanıma sunmak için bunları ardışık düzene ekliyoruz:


 exporters: prometheus: #1 endpoint: ":${env:PROMETHEUS_PORT}" logging: #2 loglevel: debug service: pipelines: metrics: receivers: [ "prometheus" ] exporters: [ "prometheus", "logging" ] #3
  1. Verileri kullanıma sunma
  2. Verileri yazdır
  3. Boru hattı hem verileri yazdıracak hem de bunları açığa çıkaracak


Prometheus ihracatçısı yapılandırıldığında Grafana'da metrikleri görselleştirebiliyoruz.


Metrikleri görselleştirme


Alıcıların ve ihracatçıların türlerini belirlediklerini ve her birinin benzersiz olması gerektiğini unutmayın. Son gereksinime uymak için, bunları birbirinden ayırmak için bir niteleyici ekleyebiliriz, yani prometheus/foo ve prometheus/bar.

Aracı veri işleme

Geçerli bir soru, genel tasarımı daha kırılgan hale getirdiği için OTEL Collector'ın neden kaynak ile Prometheus arasında yer aldığı olabilir. Bu aşamada OTEL Toplayıcının gerçek gücünden yararlanabiliriz: veri işleme. Şu ana kadar ham metrikleri aldık ancak kaynak formatı, verileri görselleştirmek istediğimiz şekle uyarlanmamış olabilir. Örneğin, kurulumumuzdaki ölçümler, sahte oluşturucumuz olan "işletme"den ve temeldeki NodeJS platformu olan "teknik"ten gelir. Bu, metriklerin adına yansıtılır. Daha verimli filtreleme yapmak için özel bir kaynak etiketi ekleyebilir ve gereksiz öneki kaldırabiliriz.


Veri işlemcilerini yapılandırma dosyasının processors bölümünde bildirirsiniz. Koleksiyoncu bunları bildirildiği sıraya göre yürütür. Yukarıdaki dönüşümü uygulayalım.


Hedefimize doğru ilk adım, koleksiyoncunun iki tadı olduğunu anlamaktır: "çıplak" olan ve bunun üzerine inşa edilen katkıda bulunan. İlkine dahil olan işlemciler hem sayı hem de yetenek bakımından sınırlıdır; bu nedenle katkı sürümünü değiştirmemiz gerekiyor.


 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 aromasını kullanın
  2. Daha fazla eğlence için yapılandırma dosyası başka bir yoldadır


Bu noktada işlemcinin kendisini ekleyebiliriz:


 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. Metrik dönüştürme işlemcisini çağırın
  2. Sırayla uygulanan dönüşümlerin listesi
  3. Tüm metrikleri tanımlanan normal ifadeyle eşleştirir
  4. Sırasıyla uygulanan işlemlerin listesi
  5. Etiketi ekleyin
  6. Normal ifade grubu önekini kaldırarak metriği yeniden adlandırın
  7. Eğlenceli şeyler: sözdizimi $${x}


Son olarak tanımlanan işlemciyi işlem hattına ekliyoruz:


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


Sonuçlar burada:


Sonuçlar

Alıcıları ve ihracatçıları birbirine bağlama

Konektör hem alıcı hem de ihracatçıdır ve iki boru hattını birbirine bağlar. Dokümantasyondaki örnek, yayılma sayısını (izleme) alır ve bir metriğe sahip olan sayımı dışa aktarır. Aynısını 500 hatayla başarmaya çalıştım - spoiler: amaçlandığı gibi çalışmıyor.


Önce bir günlük alıcısı ekleyelim:


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


Ardından bir bağlayıcı ekliyoruz:


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


Son olarak, günlük alıcısını ve metrik aktarıcısını bağlarız:


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


Metriğin adı log_record_count_total ancak değeri 1'de kalır.

Günlük manipülasyonu

İşlemciler veri manipülasyonuna izin verir; operatörler günlükler üzerinde çalışan özel işlemcilerdir. Elasticsearch Logstash Kibana yığınına aşina iseniz, bunlar Logstash'ın eşdeğeridir.


Şu an itibariyle günlük zaman damgası, besleme zaman damgasıdır. Bunu, yaratılma zaman damgasına göre değiştireceğiz.


 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. Günlük JSON biçimindedir; sağlanan JSON ayrıştırıcısını kullanabiliriz
  2. Ayarlanacak meta veri nitelikleri
  3. Okunacak alanlar
  4. Ayrıştırma deseni
  5. Eşleme tablosu
  6. Bir aralığı kabul edin, örneğin 501-599 . Operatörün HTTP durumları için özel olarak yorumlanmış bir değeri 5xx (ve benzeri) vardır.
  7. Yinelenen verileri kaldır

Kütükler

Bu noktada logları herhangi bir log toplama bileşenine gönderebiliriz. Grafana Laboratuvarları alanında kalıp Loki'yi kullanacağız.


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


Günlükleri toplayıcının kendisinden de kullanabiliriz:


 service: telemetry: logs:


Son olarak başka bir işlem hattı ekleyelim:


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


Grafana ayrıca günlükleri görselleştirebilir. Veri kaynağı olarak Loki'yi seçin.

Çözüm

Bu yazıda OpenTelemetry toplayıcıyı inceledik. OTEL mimarisinin zorunlu bir parçası olmasa da, tüm veri işleme ihtiyaçlarınız için kullanışlı bir İsviçre bıçağıdır. Belirli bir yığına bağlı kalmamanız veya bunu istemiyorsanız, bu çok büyük bir yardımdır.


Bu yazının kaynak kodunun tamamı GitHub'da bulunabilir.


Daha ileri gitmek için:


İlk olarak 12 Kasım 2023'te A Java Geek'te yayınlandı