VictoriaMetrics - tạo bộ nhớ từ xa tốt nhất cho Prometheus

Chào mọi người! Người sáng lập VictoriaMetrics tại đây:

  • valyala
  • hagen1778
  • mười triệu

Chúng tôi rất vui khi làm sáng tỏ về VictoriaMetrics.

Một chút về lịch sử

Chúng tôi bắt đầu sử dụng Prometheus và Grafana hai năm trước. Đây là một luồng không khí trong lành so với Zabbix. Bây giờ các nhà phát triển có thể phân tán các số liệu tùy ý xung quanh mã của họ, xây dựng bảng điều khiển tùy chỉnh trong Grafana và giám sát các ứng dụng của họ mà không cần sysadmins / DevOps chuyên dụng.

Số lượng các số liệu duy nhất được quét bởi ví dụ Prometheus của chúng tôi đã nhanh chóng tăng từ vài trăm đến hơn 300 nghìn trong nửa năm. Chúng tôi đã chuyển sang Prometheus 2.0 trong quá trình tăng trưởng, vì Prometheus trước 2.0 trở nên quá chậm so với khối lượng số liệu của chúng tôi. Nhưng Prometheus mới có một vài vấn đề:

  • Nó không quá nhanh trên phạm vi truy vấn vượt quá một vài ngày. Chúng tôi đã sử dụng phạm vi như vậy cho xu hướng dài hạn và bảng điều khiển lập kế hoạch năng lực.
  • Nó bắt đầu ăn rất nhiều không gian lưu trữ sau khi tăng dần giữ lại từ mặc định 15 ngày đến một năm.
  • Không rõ làm thế nào để ngăn chặn mất dữ liệu Prometheus trong trường hợp sự cố lưu trữ. Chúng tôi kết thúc với hai trường hợp Prometheus riêng biệt cào cùng một bộ mục tiêu (còn gọi là cặp HA). Điều này tăng gấp đôi chi phí giám sát của chúng tôi.

Chúng tôi bắt đầu khám phá các giải pháp khả thi và phát hiện ra rằng Prometheus hỗ trợ lưu trữ từ xa. Nhưng tất cả các giải pháp hiện tại đều không thỏa mãn vì nhiều lý do:

  • Thiết lập phức tạp và hoạt động dễ vỡ.
  • Báo cáo sự cố và mất dữ liệu.
  • Chậm.
  • Không hoặc khả năng mở rộng tối ưu.

Đồng thời, chúng tôi đã sử dụng thành công ClickHouse để lưu trữ và phân tích các luồng sự kiện lớn - lên tới 300 tỷ sự kiện mỗi ngày. Chúng tôi đã rất ngạc nhiên với sự đơn giản trong vận hành, tốc độ truy vấn và mức độ nén của công cụ bảng MergeTree của nó.

Trải nghiệm của chúng tôi với ClickHouse rất tuyệt vời, vì vậy chúng tôi đã mở các dự án sau cho nó:

  • clickhouse-grafana - Nguồn dữ liệu Grafana cho ClickHouse.
  • chproxy - bộ cân bằng tải và proxy lưu trữ cho ClickHouse.
  • chclient - khách hàng nhanh chóng cho ClickHouse.

Chúng tôi đã thử sử dụng ClickHouse làm nơi lưu trữ từ xa cho Prometheus. Kết quả ban đầu rất tuyệt - ClickHouse có thể quét hàng tỷ điểm dữ liệu mỗi giây trên một máy chủ. Thật không may, chúng tôi không thể tìm thấy một giải pháp tốt để xây dựng chỉ số hiệu quả cho các nhãn Prometheus.

Sau đó, một ý tưởng điên rồ đã xuất hiện - hãy để tạo ra TSDB của riêng chúng tôi với các yêu cầu sau:

  • Chỉ mục hiệu quả cho các nhãn Prometheus hay còn gọi là thẻ Metrics 2.0, dễ dàng lưu trữ và truy vấn hàng tỷ nhãn khác nhau.
  • Tốc độ nhanh cho các truy vấn trên phạm vi ngày lớn, số lượng lớn các số liệu duy nhất và số lượng điểm dữ liệu khổng lồ.
  • Nén lưu trữ tốt, do đó, nhiều dữ liệu có thể được lưu trữ trên không gian đĩa hạn chế.
  • Sao lưu trực tuyến dễ dàng và nhanh chóng tương tự như PHẦN MỀM MIỄN PHÍ trong ClickHouse.

Nguyên mẫu của TSDB này rất hứa hẹn, vì vậy tôi (valyala) đã rời bỏ công việc của mình tại VertaMedia và bắt đầu làm việc trên TSDB toàn thời gian. Sau đó, TSDB có tên đẹp - VictoriaMetrics.

Chi tiết kỹ thuật

VictoriaMetrics được viết bằng Go. Go đã được chọn vì những lý do sau:

  • Nhiều giải pháp TSDB hiện có được viết bằng Go - Prometheus, InfluxDB, Thanos, M3, Cortex, v.v ... Gợi ý này khá tốt cho việc viết TSDB.
  • Tôi có kinh nghiệm tốt trong Go. Xem repos của tôi trên GitHub.
  • Tôi là tác giả của fasthttp, vì vậy tôi biết cách viết các ứng dụng hiệu quả trong Go.

Bộ lưu trữ VictoriaMetrics, được xây dựng từ đầu bằng cách sử dụng các ý tưởng từ công cụ bảng Clickhouse của MergeTree:

  • Lưu trữ riêng thời gian tên, dấu thời gian và giá trị (còn gọi là lưu trữ cột). Điều này tăng tốc truy vấn bằng cách chỉ quét các cột cần thiết.
  • Lưu trữ mỗi cột trong cơ sở hạ tầng tương tự như cây hợp nhất có cấu trúc log (LSM). Điều này làm giảm I / O ngẫu nhiên khi thêm / quét các giá trị được sắp xếp so với các cấu trúc dữ liệu giống như cây B. Điều này tăng tốc độ lưu trữ trên ổ cứng. Các tập tin LSM là bất biến. Điều này giúp đơn giản hóa việc chụp nhanh và sao lưu. LSM có một nhược điểm so với B-tree - dữ liệu được lưu trữ được viết lại nhiều lần khi các tệp nhỏ hơn được hợp nhất thành các tệp lớn hơn. Điều này làm lãng phí băng thông đĩa, nhưng thực tế ClickHouse cho thấy đây là sự đánh đổi khá tốt.
  • Xử lý dữ liệu trong khối phù hợp với bộ đệm CPU. Điều này tối đa hóa hiệu suất của CPU, vì nó không chờ dữ liệu từ RAM chậm. Xem số độ trễ Mỗi lập trình viên nên biết để biết chi tiết.

Ban đầu chỉ mục cho các nhãn Prometheus đã được xây dựng trên đỉnh của LevelDB trong Go. Sau đó tôi đã thử thay thế nó bằng giải pháp thay thế hiệu quả hơn - RocksDB. Nhưng nó đã không thành công vì có chi phí cao, phải được trả cho mỗi nhãn được quét. Cuối cùng, LevelDB đã được thay thế bằng cấu trúc dữ liệu tùy chỉnh - mergeset. Cấu trúc dữ liệu này được tối ưu hóa đặc biệt cho chỉ mục của nhãn Prometheus.

mergeset có những khác biệt sau so với LevelDB:

  • Nó chỉ hoạt động trên các phím. Đó là nhận thức về các giá trị.
  • Nó có khuếch đại ghi thấp hơn.
  • Nó có tìm kiếm nhanh hơn cho nhiều phím được đặt hàng.
  • Nó nén các phím tốt hơn, vì vậy chúng đòi hỏi ít không gian lưu trữ hơn.
  • Nó cung cấp ảnh chụp nhanh dữ liệu ngay lập tức và sao lưu dễ dàng.
  • Nó sử dụng các ý tưởng từ công cụ bảng ClickHouse sườn MergeTree.

Chúng tôi dự định hợp nhất nguồn mở trong tương lai gần, vì vậy những người khác có thể được hưởng lợi từ nó.

Ban đầu VictoriaMetrics là một giải pháp máy chủ đơn. Sau đó, nó đã được chuyển thành một giải pháp cụm. Một dịch vụ duy nhất đã được chia thành ba dịch vụ trong quá trình chuyển đổi:

  • vmst Storage - lưu trữ các giá trị số liệu nhận được từ vminsert, trả về giá trị số liệu thô cho các truy vấn từ vmselect.
  • vminsert - chấp nhận các giá trị số liệu thông qua API Prometheus remote_write và gửi chúng đến vmst Storage.
  • vmselect - thực hiện API truy vấn Prometheus. Lấy dữ liệu thô từ vmst Storage.

Việc chia tách mang lại những lợi ích sau:

  • Mỗi dịch vụ có thể mở rộng độc lập.
  • Mỗi dịch vụ có thể chạy trên phần cứng được tối ưu hóa lý tưởng cho nhu cầu dịch vụ.
  • Chèn nặng don don can thiệp vào các lựa chọn nặng.
  • Lỗi trong vminsert không phá vỡ vmselect và ngược lại.
  • Độ bền của vmst Storage tốt hơn, vì nó giảm logic truy vấn phức tạp cho vmselect.

Bây giờ VictoriaMetrics chạy trong Google Cloud. Chúng tôi sử dụng Cơ sở hạ tầng làm cách tiếp cận Mã để quản lý và cung cấp tài nguyên thông qua Trình quản lý triển khai.

Công cụ truy vấn

Ban đầu vmselect cung cấp API đọc từ xa Prometheus. Nhưng điều này là không tối ưu, vì API yêu cầu chuyển tất cả các điểm dữ liệu thô sang Prometheus cho mỗi truy vấn. Chẳng hạn, nếu Prometheus xây dựng phản hồi trên 1K số liệu với 10K điểm dữ liệu mỗi điểm, thì vmselect sẽ gửi 1K * 10K = 10M điểm dữ liệu cho Prometheus trên mỗi truy vấn. Đây là một sự lãng phí lưu lượng truy cập và tiền. Vì vậy, sau đó API đọc từ xa đã được thay thế bởi công cụ truy vấn tương thích hoàn toàn với PromQL.

Công cụ truy vấn hỗ trợ các tính năng bổ sung nhằm hướng tới các truy vấn phức tạp Đơn giản hóa. Dưới đây là một vài ví dụ:

  • VỚI các mẫu tương tự như các biểu thức bảng phổ biến:
VỚI (
      commonFilters = {job = ~ "$ job", instance = ~ "$ dụ"}
  ) node_filesystem_size_bytes {commonFilters} / node_filesystem_avail_bytes {commonFilters}

Đọc thêm về các mẫu VỚI và chơi với chúng trên sân chơi mẫu VỚI.

  • Nhiều chức năng hữu ích. Ví dụ: hàm union để kết hợp các kết quả truy vấn:
liên hiệp(
    node_filesystem_size_bytes,
    node_filesystem_avail_bytes,
)

Danh sách đầy đủ các chức năng bổ sung có sẵn ở đây.

Hiệu suất thực tế

  • Các thử nghiệm ban đầu cho thấy VictoriaMetrics sử dụng không gian lưu trữ ít hơn 10 lần so với Prometheus 2.0, 0,4 byte cho mỗi điểm dữ liệu so với 4 byte cho mỗi điểm dữ liệu trong trường hợp của chúng tôi. Điểm dữ liệu là (dấu thời gian, số liệu) giá trị.
  • Một dịch vụ vmst Storage duy nhất chấp nhận tới 4 triệu điểm dữ liệu mỗi giây trên máy chủ 8xCPU.
  • Một dịch vụ vmselect duy nhất quét tới 500 triệu điểm dữ liệu mỗi giây trên máy chủ 8xCPU.
  • VictoriaMetrics sử dụng không gian lưu trữ ít hơn 70 lần so với TimescaleDB trên dữ liệu thử nghiệm từ Time Series Benchmark Suite - 250MB so với 18GB. Dữ liệu thử nghiệm bao gồm các điểm dữ liệu 1B - xem mô tả TSBS trên GitHub.
  • Có một phòng để cải thiện hiệu suất. Tất cả các dịch vụ VictoriaMetrics đều được trang bị trình xử lý pprof, vì vậy chúng tôi sẵn sàng điều chỉnh hiệu suất của chúng trên khối lượng công việc sản xuất.

Các tính năng của VictoriaMetrics

  • Hỗ trợ PromQL đầy đủ cộng với PromQL mở rộng với các mẫu CÓ. PromQL mở rộng có thể được thử trên sân chơi Grafana.
  • Dễ dàng thiết lập - chỉ cần sao chép-n-dán URL remote_write được cung cấp vào cấu hình Prometheus.
  • Giảm chi phí hoạt động. Prometheus có thể được chuyển đổi thành dịch vụ không trạng thái sau khi cho phép ghi từ xa vào VictoriaMetrics.
  • Có nhiều loại thời gian duy trì - từ 1 tháng đến 5 năm.
  • Chèn tỷ lệ hiệu suất lên hàng triệu giá trị số liệu mỗi giây.
  • Chọn thang đo hiệu suất đến hàng tỷ giá trị số liệu mỗi giây.
  • Lưu trữ quy mô đến hàng nghìn tỷ giá trị số liệu và hàng triệu số liệu duy nhất (còn gọi là cardinality cao).
  • Cung cấp chế độ xem truy vấn toàn cầu trên số lượng phiên bản Prometheus khác nhau nếu chúng sử dụng cùng một URL remote_write.

Ai có thể hưởng lợi từ VictoriaMetrics?

  • Bất cứ ai sử dụng Prometheus. Chỉ cần thiết lập VictoriaMetrics như một bộ lưu trữ từ xa và ngừng bận tâm về các vấn đề vận hành lưu trữ cục bộ như sao lưu, sao chép, lập kế hoạch dung lượng và các gánh nặng bảo trì khác.
  • Người dùng triển khai Prometheus trong Kubernetes. Hiện tại, những người dùng như vậy nên cẩn thận quản lý khối lượng liên tục cho bộ nhớ cục bộ Prometheus. Thông thường, họ thiết lập Prometheus như một ứng dụng có trạng thái, có thể hạn chế Kubernetes trong các quyết định lập lịch. Chỉ cần sử dụng VictoriaMetrics như một bộ lưu trữ từ xa và chạy Prometheus như một ứng dụng không trạng thái.
  • Người dùng có nhiều phiên bản Prometheus riêng biệt nằm trong các mạng / trung tâm dữ liệu riêng biệt. VictoriaMetrics cung cấp chế độ xem truy vấn toàn cầu trên tất cả các phiên bản Prometheus.

Các tính năng trong tương lai

Chúng tôi dự định thực hiện các tính năng sau trong tương lai:

  • Tự động lấy mẫu dữ liệu cũ.
  • Giá trị cuối cùng cho các bộ lọc nhãn nhất định.
  • Cửa sổ thời gian.

Phần kết luận

Chúng tôi chắc chắn VictoriaMetrics sẽ trở thành nơi lưu trữ từ xa tốt nhất cho Prometheus.

Tiếp tục khám phá nó. Đọc FAQ. Đăng ký tại sân chơi VictoriaMetrics, sử dụng nó như một bộ lưu trữ từ xa thử nghiệm cho các phiên bản Prometheus của bạn. Nó hoàn toàn an toàn, vì Prometheus tiếp tục ghi dữ liệu vào bộ nhớ cục bộ cùng với bộ lưu trữ từ xa, do đó dữ liệu cục bộ của bạn không bị mất khi bật lưu trữ từ xa. Xem Bắt đầu nhanh để biết thêm chi tiết.

Chỉnh sửa bảng điều khiển và đồ thị trên sân chơi Grafana. Sân chơi này sử dụng nguồn dữ liệu VictoriaMetrics chỉ vào số liệu nội bộ của sân chơi VictoriaMetrics, vì vậy tất cả các tính năng từ Extended PromQL đều có sẵn ở đó.

Sản xuất VictoriaMetrics sẽ sớm được cung cấp. Hãy theo dõi và truyền bá về nó!

Cập nhật: Hình ảnh Docker với VictoriaMetrics một máy chủ có sẵn tại đây. Nếu bạn không giống như Docker, thì chỉ cần sử dụng các nhị phân tĩnh.

Update2: Đọc bài đăng mới của chúng tôi - Điểm chuẩn TSDB cao cấp: VictoriaMetrics vs TimescaleDB vs InfluxDB.

Update3: VictoriaMetrics là nguồn mở ngay bây giờ!

Tham gia cộng đồng Slack của chúng tôi và đọc các chủ đề Faun hàng tuần của chúng tôi

Nếu bài đăng này hữu ích, vui lòng nhấp vào nút vỗ tay bên dưới một vài lần để thể hiện sự hỗ trợ của bạn cho tác giả! ⬇