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:
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
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
prometheus
önceden tanımlanmış alıcısını kullanıyoruzprometheus
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)
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
prometheus
ihracatçısı ekleyin
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
Prometheus ihracatçısı yapılandırıldığında Grafana'da metrikleri görselleştirebiliyoruz.
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.
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
contrib
aromasını kullanın
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
$${x}
Son olarak tanımlanan işlemciyi işlem hattına ekliyoruz:
service: pipelines: metrics: receivers: [ "prometheus" ] processors: [ "metricstransform" ] exporters: [ "prometheus" ]
Sonuçlar burada:
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.
İş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
501-599
. Operatörün HTTP durumları için özel olarak yorumlanmış bir değeri 5xx
(ve benzeri) vardır.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.
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ı