Airbnb chuyển đổi hệ thống xử lý chỉ số quy mô lớn sang OpenTelemetry

Airbnb chuyển đổi hệ thống xử lý chỉ số quy mô lớn sang OpenTelemetry

Đội ngũ kỹ thuật chịu trách nhiệm về tính khả quan (observability) của Airbnb vừa công bố chi tiết về một dự án di chuyển quy mô lớn: chuyển từ hệ thống StatsD và đường ống tổng hợp dựa trên Veneur sang một stack chỉ số mã nguồn mở hiện đại. Hệ thống mới được xây dựng dựa trên OpenTelemetry Protocol (OTLP), OpenTelemetry Collector và vmagent của VictoriaMetrics. Kết quả là hệ thống hiện tại có khả năng tiếp nhận hơn 100 triệu mẫu dữ liệu mỗi giây trong môi trường sản xuất.

Kiến trúc hệ thống mới của Airbnb

Chiến lược di chuyển và tối ưu hóa hiệu năng

Thay vì thực hiện di chuyển từng tính năng một cách từng bước, nhóm kỹ thuật đã chọn cách tiếp cận "ưu tiên thu thập": đảm bảo tất cả các chỉ số đều chảy vào hệ thống mới trước, sau đó mới xử lý các bảng điều khiển (dashboard), cảnh báo và công cụ dành cho người dùng dựa trên dữ liệu thực tế.

Thách thức lớn nhất là kết nối ba thế giới công cụ giám sát đang cùng tồn tại: các thư viện StatsD, sự gia tăng áp dụng OTLP và một backend lưu trữ tương thích Prometheus mới dựa trên Grafana Mimir.

Khoảng 40% dịch vụ của Airbnb sử dụng thư viện chỉ số được duy trì bởi nền tảng. Đội ngũ quan sát đã cập nhật thư viện này để phát song song (dual-emit) các chỉ số: gửi StatsD đến đường ống cũ đồng thời phát OTLP đến OpenTelemetry Collector mới, cho phép tiến độ di chuyển rộng rãi với ma sát tối thiểu trên toàn bộ đội dịch vụ.

Việc chuyển đổi sang OTLP mang lại những lợi ích đo lường được: thời gian CPU dành cho xử lý chỉ số trong các dịch vụ JVM đã giảm từ 10% xuống dưới 1% tổng mẫu CPU. Ngoài hiệu suất, việc sử dụng TCP của OTLP đã loại bỏ rủi ro mất gói tin vốn có trong giao thức vận chuyển UDP của StatsD. Hơn nữa, hỗ trợ biểu đồ hàm mũ (exponential histograms) tích hợp của OTLP đã loại bỏ nhu cầu về một lớp dịch chuyển trung gian bên trong bộ thu thập.

Tuy nhiên, các dịch vụ có độ truy cập cao (high-cardinality), phát ra tới 10.000 mẫu mỗi giây cho mỗi phiên bản, đã gặp phải áp lực bộ nhớ và tăng cường thu gom rác (garbage collection) sau khi bật OTLP. Giải pháp là chuyển các dịch vụ cụ thể này sang tính thời gian delta thông qua AggregationTemporalitySelector.deltaPreferred(), giúp tránh việc giữ lại trạng thái đầy đủ của tất cả các kết hợp nhãn chỉ số giữa các lần xuất. Sự đánh đổi được chấp nhận là các lỗi thất bại bất ngờ sẽ hiện ra dưới dạng khoảng trống dữ liệu thay vì các bước nhảy bất thường.

Giải quyết bài toán tổng hợp và chi phí

Đường ống cũ của Airbnb đã tổng hợp các nhãn cấp độ phiên bản (như pod và hostname) bằng cách sử dụng một bản phân nhánh nội bộ của Veneur trước khi chuyển tiếp cho nhà cung cấp chỉ số. Stack mới dựa trên Prometheus yêu cầu một bước tổng hợp tương đương để giữ chi phí lưu trữ ở mức quản lý được.

Đội ngũ đã đánh giá nhiều giải pháp thay thế: tiếp tục với Veneur sẽ yêu cầu viết lại mã đáng kể để hỗ trợ mô hình dữ liệu Prometheus. Các quy tắc ghi (recording rules) bị loại bỏ vì chúng yêu cầu lưu trữ dữ liệu thô trong TSDB trước khi tổng hợp, làm mất mục tiêu tiết kiệm chi phí. OpenTelemetry Collector thiếu hỗ trợ tổng hợp chỉ số tích hợp mặc dù có các đề xuất mở. Vector bị loại bỏ do thiếu khả năng mở rộng tích hợp và việc áp dụng Rust tại Airbnb còn hạn chế. Cuối cùng, m3aggregator được coi là phức tạp về mặt kiến trúc hơn mức cần thiết.

Cuối cùng, vmagent được chọn nhờ khả năng tổng hợp luồng tích hợp cho các chỉ số Prometheus, hỗ trợ phân mảnh ngang (horizontal sharding), tài liệu dễ tiếp cận và cơ sở mã nhỏ khoảng 10.000 dòng, giúp việc tùy chỉnh nội bộ trở nên khả thi.

Kiến trúc sản xuất và xử lý sự cố Counter

Kiến trúc sản xuất sử dụng hai lớp vmagent: các pod router không trạng thái phân mảnh các chỉ số bằng cách băm nhất quán tất cả các nhãn ngoại trừ những nhãn cần loại bỏ, và các pod tổng hợp có trạng thái duy trì tổng số chạy trong bộ nhớ. Các router được cấu hình với danh sách tên máy chủ tổng hợp tĩnh, tận dụng danh tính mạng ổn định của Kubernetes StatefulSet để tránh các phụ thuộc khám phá dịch vụ bổ sung. Cụm sản xuất đã mở rộng lên hàng trăm tổng hợp. Nhiều cải thiện chung đã được đóng góp lại cho dự án nguồn mở VictoriaMetrics.

Sau khi hoàn tất việc di chuyển thu thập, nhóm nhận thấy rằng các truy vấn PromQL trên một số bộ đếm (counter) nhất quán báo cáo thấp hơn so với nhà cung cấp cũ. Nguyên nhân gốc rễ là một trường hợp cạnh trong cách Prometheus xử lý việc đặt lại bộ đếm ở tốc độ phát thấp. Trong StatsD, mỗi điểm dữ liệu đại diện cho một delta tương đối với cửa sổ xả. Trong Prometheus, các điểm dữ liệu đại diện cho số lượng tích lũy, và hàm rate() suy ra các delta — nhưng nếu một bộ đếm tăng lên một lần và pod của nó khởi động lại trước khi nó có thể tăng thêm lần nữa, lần tăng đó sẽ bị mất trước khi rate() có thể tính toán một delta có ý nghĩa.

Tại Airbnb, trường hợp cạnh này chứng tỏ tác động lớn hơn dự kiến. Nhiều bộ đếm theo dõi các sự kiện tần suất thấp, nhiều chiều, ví dụ như yêu cầu theo từng loại tiền tệ cho từng người dùng ở từng khu vực, nơi bất kỳ kết hợp nhãn cụ thể nào có thể chỉ tăng vài lần một ngày. Đây thường là các chỉ số quan trọng về mặt kinh doanh, và việc thiếu hụt có hệ thống các chỉ số này đã làm đình trệ việc di chuyển người dùng.

Giải pháp được chọn là kỹ thuật "tiêm số không" (zero injection) trong suốt được triển khai bên trong tầng tổng hợp vmagent: lần đầu tiên một bộ đếm tổng hợp được xả, bộ tổng hợp phát ra một số không tổng hợp thay vì tổng số chạy thực tế. Giá trị tích lũy thực tế được xả trong khoảng thời gian tiếp theo. Điều này ngầm định khởi tạo mọi bộ đếm về số không, phù hợp với ngữ nghĩa của Prometheus, trong khi việc xóa lần đầu bị trì hoãn đảm bảo dấu thời gian của số không tổng hợp không va chạm với bất kỳ mẫu nào trước đó. Sự đánh đổi là độ trễ một khoảng xả trên lần tăng đầu tiên được ghi lại.

Kết quả và xu hướng ngành

Đường ống hoàn chỉnh xử lý hơn 100 triệu mẫu mỗi giây trong một cụm sản xuất duy nhất, với chi phí giảm khoảng một cấp độ lớn so với kiến trúc nhà cung cấp trước đó. Tầng tổng hợp tập trung cũng trở thành một lớp chuyển đổi mục đích chung: các nhà khai thác có thể loại bỏ các chỉ số gây rối do các thay đổi công cụ đo lường kém mà không cần chạm vào mã ứng dụng, hoặc tạm thời phát song song các chỉ số thô cho mục đích gỡ lỗi.

Flipkart và Shopify cũng đã giải quyết phiên bản của cùng một vấn đề cơ bản từ các góc độ khác. Flipkart sử dụng liên kết Prometheus phân cấp, trong khi Shopify xây dựng lại từ đầu lên Prometheus, Loki, Tempo và Grafana dưới một nền tảng nội bộ gọi là Observe. Cả hai bài đăng đều xác nhận rằng việc thoát khỏi StatsD, sự tính toán lại chi phí nhà cung cấp và sự chuyển dịch sang stack mã nguồn mở dựa trên Prometheus không phải là những lựa chọn ngẫu nhiên. Đây là một mô hình đang diễn ra trên các tổ chức kỹ thuật siêu quy mô, nơi mô hình giám sát dựa trên đẩy (push-based) cũ đã đạt đến giới hạn.