paint-brush
Đi sâu vào Bộ thu thập từ xa mởtừ tác giả@nfrankel
1,349 lượt đọc
1,349 lượt đọc

Đi sâu vào Bộ thu thập từ xa mở

từ tác giả Nicolas Fränkel18m2023/11/18
Read on Terminal Reader

dài quá đọc không nổi

Mặc dù đây không phải là một phần bắt buộc của kiến trúc OTEL, nhưng OTEL Collector là một con dao Thụy Sĩ hữu ích đáp ứng mọi nhu cầu xử lý dữ liệu của bạn.
featured image - Đi sâu vào Bộ thu thập từ xa mở
Nicolas Fränkel HackerNoon profile picture
0-item
1-item


OpenTelemetry Collector nằm ở trung tâm của kiến trúc OpenTelemetry nhưng không liên quan đến Bối cảnh theo dõi W3C. Trong bản demo truy tìm của mình, tôi sử dụng Jaeger thay vì Collector. Tuy nhiên, nó có mặt khắp nơi, như trong mọi bài đăng liên quan đến OpenTelemetry. Tôi muốn khám phá nó sâu hơn.


Trong bài đăng này, tôi khám phá các khía cạnh khác nhau của Collector:


  • Loại dữ liệu: nhật ký, số liệu và dấu vết
  • Mô hình đẩy và kéo
  • Hoạt động: đọc, chuyển đổi và ghi

Những bước đầu tiên

Cách đây rất lâu, khả năng quan sát như chúng ta biết đã không tồn tại; thay vào đó những gì chúng tôi có là giám sát . Hồi đó, việc giám sát là một nhóm người nhìn vào màn hình hiển thị trang tổng quan. Bản thân bảng điều khiển bao gồm các số liệu và chỉ số liệu hệ thống: chủ yếu là mức sử dụng CPU, bộ nhớ và ổ đĩa. Vì lý do này, chúng tôi sẽ bắt đầu với số liệu.


Prometheus là một trong những giải pháp giám sát chính. Nó hoạt động trên mô hình dựa trên kéo: Prometheus loại bỏ các điểm cuối tương thích của (các) ứng dụng của bạn và lưu trữ chúng trong nội bộ.


Chúng tôi sẽ sử dụng OTEL Collector để trích xuất điểm cuối tương thích với Prometheus và in kết quả ra bảng điều khiển. Grafana Labs cung cấp một dự án tạo ra các số liệu ngẫu nhiên để thử nghiệm. Để đơn giản, tôi sẽ sử dụng Docker Compose; thiết lập trông giống như sau:


 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. Không có hình ảnh Docker nào cho dự án số liệu giả mạo; do đó, chúng ta cần xây dựng nó
  2. Phiên bản mới nhất của OTEL Collector tại thời điểm viết bài này
  3. Tham số hóa tệp cấu hình sau
  4. Mọi thứ diễn ra ở đây


Như tôi đã đề cập ở trên, OTEL Collector có thể làm được rất nhiều việc. Do đó, cấu hình là tất cả.


 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. Danh sách người nhận. Một người nhận đọc dữ liệu; nó có thể dựa trên lực đẩy hoặc dựa trên lực kéo.
  2. Chúng tôi sử dụng máy thu được xác định trước prometheus
  3. Xác định công việc kéo
  4. Cấu hình công việc
  5. Danh sách các nhà xuất khẩu Ngược lại với người nhận, người xuất ghi dữ liệu.
  6. Việc xuất đơn giản nhất là ghi dữ liệu ra tiêu chuẩn
  7. Đường ống lắp ráp người nhận và người xuất khẩu
  8. Xác định quy trình liên quan đến số liệu
  9. Đường dẫn lấy dữ liệu từ bộ thu prometheus đã xác định trước đó và gửi nó đến nhà xuất bản logging , tức là in chúng


Đây là một mẫu của kết quả:


 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)

Ngoài việc in ấn

Trên đây là bước đầu tiên tuyệt vời, nhưng còn có nhiều điều hơn là in ra bảng điều khiển. Chúng tôi sẽ hiển thị các số liệu được thu thập bởi phiên bản Prometheus thông thường; chúng ta có thể thêm bảng điều khiển Grafana để trực quan hóa chúng. Mặc dù điều này có vẻ vô nghĩa nhưng hãy chấp nhận vì nó chỉ là bước đệm.


Để đạt được điều trên, chúng tôi chỉ thay đổi cấu hình OTEL Collector:


 exporters: prometheus: #1 endpoint: ":${env:PROMETHEUS_PORT}" #2 service: pipelines: metrics: receivers: [ "prometheus" ] exporters: [ "prometheus" ] #3
  1. Thêm nhà xuất khẩu prometheus
  2. Hiển thị điểm cuối tuân thủ Prometheus
  3. Thay thế in bằng phơi sáng


Đó là nó. OTEL Collector rất linh hoạt.


Lưu ý Collector có nhiều đầu vào, nhiều đầu ra. Để vừa in dữ liệu vừa hiển thị chúng qua điểm cuối, chúng tôi thêm chúng vào quy trình:


 exporters: prometheus: #1 endpoint: ":${env:PROMETHEUS_PORT}" logging: #2 loglevel: debug service: pipelines: metrics: receivers: [ "prometheus" ] exporters: [ "prometheus", "logging" ] #3
  1. Hiển thị dữ liệu
  2. In dữ liệu
  3. Đường ống sẽ vừa in dữ liệu vừa hiển thị chúng


Với trình xuất Prometheus được định cấu hình, chúng tôi có thể trực quan hóa các số liệu trong Grafana.


Trực quan hóa số liệu


Lưu ý rằng người nhận và người xuất chỉ định loại của họ mỗi loại trong số đó phải là duy nhất. Để tuân thủ yêu cầu cuối cùng, chúng ta có thể thêm một từ hạn định để phân biệt giữa chúng, tức là prometheus/fooprometheus/bar.

Xử lý dữ liệu trung gian

Một câu hỏi hợp lệ sẽ là tại sao OTEL Collector lại được đặt giữa nguồn và Prometheus, vì nó làm cho thiết kế tổng thể trở nên mỏng manh hơn. Ở giai đoạn này, chúng ta có thể tận dụng sức mạnh thực sự của OTEL Collector: xử lý dữ liệu. Cho đến nay, chúng tôi đã nhập số liệu thô nhưng định dạng nguồn có thể không được điều chỉnh theo cách chúng tôi muốn trực quan hóa dữ liệu. Ví dụ: trong quá trình thiết lập của chúng tôi, các số liệu đến từ trình tạo giả mạo của chúng tôi, "kinh doanh" và nền tảng NodeJS cơ bản, "kỹ thuật". Nó được phản ánh trong tên của số liệu. Chúng tôi có thể thêm nhãn nguồn chuyên dụng và xóa tiền tố không cần thiết để lọc hiệu quả hơn.


Bạn khai báo bộ xử lý dữ liệu trong phần bộ processors của file cấu hình. Collector thực hiện chúng theo thứ tự chúng được khai báo. Hãy thực hiện phép biến đổi trên.


Bước đầu tiên hướng tới mục tiêu của chúng ta là hiểu rằng bộ sưu tập có hai loại: một loại "trần trụi" và một loại đóng góp được xây dựng dựa trên nó. Các bộ xử lý trước đây bị hạn chế cả về số lượng và khả năng; do đó, chúng ta cần chuyển đổi phiên bản đóng góp.


 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. Sử dụng hương vị contrib
  2. Để thêm phần thú vị, tệp cấu hình nằm trên một đường dẫn khác


Tại thời điểm này, chúng ta có thể thêm bộ xử lý:


 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. Gọi bộ xử lý chuyển đổi số liệu
  2. Danh sách các phép biến đổi được áp dụng theo thứ tự
  3. Khớp tất cả các số liệu với biểu thức chính quy được xác định
  4. Danh sách các thao tác được áp dụng theo thứ tự
  5. Thêm nhãn
  6. Đổi tên số liệu bằng cách xóa tiền tố nhóm biểu thức chính quy
  7. Điều thú vị: cú pháp là $${x}


Cuối cùng, chúng tôi thêm bộ xử lý đã xác định vào quy trình:


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


Dưới đây là kết quả:


Kết quả

Kết nối người nhận và người xuất

Bộ kết nối vừa là bộ thu vừa là bộ xuất và kết nối hai đường ống. Ví dụ từ tài liệu nhận số lượng nhịp (theo dõi) và xuất số lượng có số liệu. Tôi đã cố gắng đạt được điều tương tự với 500 lỗi - spoiler: nó không hoạt động như dự định.


Trước tiên hãy thêm một trình nhận nhật ký:


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


Sau đó, chúng tôi thêm một trình kết nối:


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


Cuối cùng, chúng tôi kết nối trình nhận nhật ký và trình xuất số liệu:


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


Số liệu được đặt tên là log_record_count_total nhưng giá trị của nó vẫn ở mức 1.

Thao tác nhật ký

Bộ xử lý cho phép thao tác dữ liệu; toán tử là các bộ xử lý chuyên dụng hoạt động trên nhật ký. Nếu bạn đã quen thuộc với ngăn xếp Elaticsearch Logstash Kibana thì chúng tương đương với Logstash.


Tính đến thời điểm hiện tại, dấu thời gian nhật ký là dấu thời gian nhập. Chúng ta sẽ thay đổi nó thành dấu thời gian tạo ra nó.


 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. Nhật ký có định dạng JSON; chúng ta có thể sử dụng trình phân tích cú pháp JSON được cung cấp
  2. Thuộc tính siêu dữ liệu cần đặt
  3. Các trường để đọc từ
  4. Mẫu phân tích cú pháp
  5. Bảng ánh xạ
  6. Chấp nhận một phạm vi, ví dụ : 501-599 . Toán tử có giá trị được diễn giải đặc biệt 5xx (và tương tự) cho các trạng thái HTTP.
  7. Xóa dữ liệu trùng lặp

Nhật ký

Tại thời điểm này, chúng tôi có thể gửi nhật ký đến bất kỳ thành phần tổng hợp nhật ký nào. Chúng ta sẽ ở trong quả cầu của Phòng thí nghiệm Grafana và sử dụng Loki.


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


Chúng tôi cũng có thể sử dụng nhật ký từ chính bộ sưu tập:


 service: telemetry: logs:


Cuối cùng, hãy thêm một đường dẫn khác:


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


Grafana cũng có thể trực quan hóa nhật ký. Chọn Loki làm nguồn dữ liệu.

Phần kết luận

Trong bài đăng này, chúng tôi đã đi sâu vào bộ sưu tập OpenTelemetry. Mặc dù đây không phải là một phần bắt buộc của kiến trúc OTEL nhưng đây là con dao Thụy Sĩ hữu ích cho mọi nhu cầu xử lý dữ liệu của bạn. Trong trường hợp bạn không bị mắc kẹt trong một ngăn xếp cụ thể hoặc không muốn, đó là một sự trợ giúp to lớn.


Mã nguồn hoàn chỉnh cho bài đăng này có thể được tìm thấy trên GitHub .


Để đi xa hơn:


Được xuất bản lần đầu tại A Java Geek vào ngày 12 tháng 11 năm 2023