Bản dịch của bài viết được chuẩn bị riêng cho các học viên của khóa học .
là một nhà phát triển phần mềm, một người đam mê Go và là người giải quyết vấn đề. Ông cũng là người bảo trì Prometheus và đồng sáng lập công cụ Kubernetes SIG. Trước đây, anh từng là kỹ sư sản xuất tại SoundCloud và lãnh đạo nhóm giám sát tại CoreOS. Hiện đang làm việc tại Google.
- Kỹ sư cơ sở hạ tầng tại Improbable. Ông quan tâm đến các công nghệ mới và các vấn đề của hệ thống phân tán. Anh ấy có kinh nghiệm lập trình cấp thấp tại Intel, kinh nghiệm đóng góp tại Mesos và kinh nghiệm sản xuất SRE đẳng cấp thế giới tại Improbable. Dành riêng cho việc cải thiện thế giới của microservice. Ba tình yêu của anh: Golang, mã nguồn mở và bóng chuyền.
Nhìn vào sản phẩm chủ lực của chúng tôi SpatialOS, bạn có thể đoán rằng Improbable yêu cầu cơ sở hạ tầng đám mây có quy mô toàn cầu, rất năng động với hàng chục cụm Kubernetes. Chúng tôi là một trong những người đầu tiên sử dụng hệ thống giám sát . Prometheus có khả năng theo dõi hàng triệu số liệu trong thời gian thực và đi kèm với ngôn ngữ truy vấn mạnh mẽ cho phép bạn trích xuất thông tin bạn cần.
Sự đơn giản và độ tin cậy của Prometheus là một trong những ưu điểm chính của nó. Tuy nhiên, khi vượt qua một quy mô nhất định, chúng tôi gặp phải một số hạn chế. Để giải quyết những vấn đề này chúng tôi đã phát triển là một dự án nguồn mở do Improbable tạo ra để chuyển đổi liền mạch các cụm Prometheus hiện có thành một hệ thống giám sát duy nhất với khả năng lưu trữ dữ liệu lịch sử không giới hạn. Thanos có sẵn trên Github .
Mục tiêu của chúng tôi với Thanos
Ở một quy mô nhất định, các vấn đề nảy sinh vượt quá khả năng của Prometheus vani. Làm thế nào để lưu trữ hàng petabyte dữ liệu lịch sử một cách đáng tin cậy và tiết kiệm? Điều này có thể được thực hiện mà không ảnh hưởng đến thời gian phản hồi? Có thể truy cập tất cả số liệu nằm trên các máy chủ Prometheus khác nhau bằng một yêu cầu API không? Có cách nào để kết hợp dữ liệu sao chép được thu thập bằng Prometheus HA không?
Để giải quyết những vấn đề này, chúng tôi đã tạo ra Thanos. Các phần sau đây mô tả cách chúng tôi tiếp cận những vấn đề này và giải thích các mục tiêu của chúng tôi.
Truy vấn dữ liệu từ nhiều phiên bản Prometheus (truy vấn chung)
Prometheus cung cấp một phương pháp tiếp cận chức năng cho sharding. Ngay cả một máy chủ Prometheus cũng cung cấp đủ khả năng mở rộng để giải phóng người dùng khỏi sự phức tạp của phân vùng theo chiều ngang trong hầu hết các trường hợp sử dụng.
Mặc dù đây là một mô hình triển khai tuyệt vời nhưng thường cần phải truy cập dữ liệu trên các máy chủ Prometheus khác nhau thông qua một API hoặc giao diện người dùng duy nhất - một chế độ xem toàn cầu. Tất nhiên, có thể hiển thị nhiều truy vấn trong một bảng Grafana, nhưng mỗi truy vấn chỉ có thể được thực thi trên một máy chủ Prometheus. Mặt khác, với Thanos, bạn có thể truy vấn và tổng hợp dữ liệu từ nhiều máy chủ Prometheus vì tất cả chúng đều có thể truy cập được từ một điểm cuối duy nhất.
Trước đây, để có được cái nhìn toàn cầu về Không thể cải thiện, chúng tôi đã tổ chức các phiên bản Prometheus của mình thành một mô hình đa cấp . Điều này có nghĩa là tạo một máy chủ meta Prometheus thu thập một số số liệu từ mỗi máy chủ lá.
Cách tiếp cận này tỏ ra có vấn đề. Điều này dẫn đến cấu hình phức tạp hơn, bổ sung thêm một điểm lỗi tiềm ẩn và áp dụng các quy tắc phức tạp để đảm bảo rằng điểm cuối liên kết chỉ nhận được dữ liệu cần thiết. Ngoài ra, loại liên kết này không cho phép bạn có được chế độ xem toàn cầu thực sự vì không phải tất cả dữ liệu đều có sẵn từ một yêu cầu API.
Liên quan chặt chẽ đến điều này là chế độ xem thống nhất về dữ liệu được thu thập trên các máy chủ Prometheus có tính sẵn sàng cao (HA). Mô hình HA của Prometheus thu thập dữ liệu hai lần một cách độc lập, đơn giản đến mức không thể đơn giản hơn. Tuy nhiên, việc sử dụng chế độ xem kết hợp và loại bỏ trùng lặp của cả hai luồng sẽ thuận tiện hơn nhiều.
Tất nhiên, cần có máy chủ Prometheus có tính sẵn sàng cao. Tại Improbable, chúng tôi thực sự coi trọng việc giám sát dữ liệu từng phút, nhưng việc có một phiên bản Prometheus trên mỗi cụm là một điểm thất bại duy nhất. Bất kỳ lỗi cấu hình hoặc lỗi phần cứng nào cũng có thể dẫn đến mất dữ liệu quan trọng. Ngay cả việc triển khai đơn giản cũng có thể gây ra sự gián đoạn nhỏ trong việc thu thập số liệu vì quá trình khởi động lại có thể dài hơn đáng kể so với khoảng thời gian thu thập dữ liệu.
Lưu trữ dữ liệu lịch sử đáng tin cậy
Lưu trữ số liệu giá rẻ, nhanh chóng, lâu dài là ước mơ của chúng tôi (được chia sẻ bởi hầu hết người dùng Prometheus). Trong Không thể cải thiện, chúng tôi buộc phải định cấu hình khoảng thời gian lưu giữ số liệu thành chín ngày (đối với Prometheus 1.8). Điều này bổ sung thêm những giới hạn rõ ràng về khoảng cách chúng ta có thể nhìn lại.
Prometheus 2.0 đã được cải thiện về mặt này vì số lượng chuỗi thời gian không còn ảnh hưởng đến hiệu suất tổng thể của máy chủ (xem phần XNUMX). ). Tuy nhiên, Prometheus lưu trữ dữ liệu trên đĩa cục bộ. Mặc dù tính năng nén dữ liệu hiệu quả cao có thể giảm đáng kể mức sử dụng SSD cục bộ nhưng cuối cùng vẫn có giới hạn về lượng dữ liệu lịch sử có thể được lưu trữ.
Ngoài ra, tại Improbable, chúng tôi quan tâm đến độ tin cậy, tính đơn giản và chi phí. Các đĩa cục bộ lớn khó vận hành và sao lưu hơn. Chúng có giá cao hơn và yêu cầu nhiều công cụ sao lưu hơn, dẫn đến sự phức tạp không cần thiết.
Lấy mẫu xuống
Khi bắt đầu làm việc với dữ liệu lịch sử, chúng tôi nhận ra rằng có những khó khăn cơ bản với big-O khiến các truy vấn ngày càng chậm hơn khi chúng tôi làm việc với dữ liệu theo tuần, tháng và năm.
Giải pháp tiêu chuẩn cho vấn đề này sẽ là (downsampling) - giảm tần số lấy mẫu tín hiệu. Với việc lấy mẫu xuống, chúng tôi có thể “giảm quy mô” xuống phạm vi thời gian lớn hơn và duy trì cùng số lượng mẫu, giúp truy vấn luôn phản hồi.
Việc lấy mẫu dữ liệu cũ là yêu cầu tất yếu của bất kỳ giải pháp lưu trữ dài hạn nào và nằm ngoài phạm vi của Prometheus thông thường.
Mục tiêu bổ sung
Một trong những mục tiêu ban đầu của dự án Thanos là tích hợp liền mạch với mọi bản cài đặt Prometheus hiện có. Mục tiêu thứ hai là dễ vận hành với các rào cản gia nhập tối thiểu. Bất kỳ sự phụ thuộc nào cũng phải dễ dàng được đáp ứng cho cả người dùng nhỏ và lớn, điều này cũng có nghĩa là chi phí cơ bản thấp.
Kiến trúc của Thanos
Sau khi liệt kê các mục tiêu của chúng ta ở phần trước, chúng ta hãy cùng tìm hiểu chúng và xem Thanos giải quyết những vấn đề này như thế nào.
Tầm nhìn toàn cầu
Để có được cái nhìn toàn cầu về các phiên bản Prometheus hiện có, chúng tôi cần liên kết một điểm nhập yêu cầu duy nhất với tất cả các máy chủ. Đây chính xác là những gì thành phần Thanos làm. . Nó được triển khai bên cạnh mỗi máy chủ Prometheus và hoạt động như một proxy, phục vụ dữ liệu Prometheus cục bộ thông qua API gRPC Store, cho phép truy xuất dữ liệu chuỗi thời gian theo thẻ và phạm vi thời gian.
Mặt khác là thành phần Querier không trạng thái, mở rộng quy mô, thực hiện nhiều nhiệm vụ hơn là chỉ trả lời các truy vấn PromQL thông qua API HTTP Prometheus tiêu chuẩn. Querier, Sidecar và các thành phần khác của Thanos giao tiếp qua .
- Querier, khi nhận được yêu cầu, sẽ kết nối với máy chủ API Store tương ứng, tức là với Sidecar của chúng tôi và nhận dữ liệu chuỗi thời gian từ các máy chủ Prometheus tương ứng.
- Sau đó, nó kết hợp các phản hồi và thực hiện truy vấn PromQL trên chúng. Querier có thể hợp nhất cả dữ liệu rời rạc và dữ liệu trùng lặp từ máy chủ Prometheus HA.
Điều này giải quyết được phần lớn câu đố của chúng tôi - kết hợp dữ liệu từ các máy chủ Prometheus bị cô lập vào một chế độ xem duy nhất. Trên thực tế, Thanos chỉ có thể sử dụng được tính năng này. Không cần thực hiện thay đổi nào đối với các máy chủ Prometheus hiện có!
Thời hạn sử dụng không giới hạn!
Tuy nhiên, sớm hay muộn chúng ta cũng sẽ muốn lưu trữ dữ liệu vượt quá thời gian lưu giữ thông thường của Prometheus. Chúng tôi đã chọn lưu trữ đối tượng để lưu trữ dữ liệu lịch sử. Nó có sẵn rộng rãi trong mọi đám mây cũng như các trung tâm dữ liệu tại chỗ và rất hiệu quả về mặt chi phí. Ngoài ra, hầu hết mọi bộ lưu trữ đối tượng đều có sẵn thông qua API S3 nổi tiếng.
Prometheus ghi dữ liệu từ RAM vào đĩa khoảng hai giờ một lần. Khối dữ liệu được lưu trữ chứa tất cả dữ liệu trong một khoảng thời gian cố định và không thể thay đổi. Điều này rất thuận tiện vì Thanos Sidecar có thể chỉ cần xem thư mục dữ liệu của Prometheus và khi có các khối mới, hãy tải chúng vào thùng lưu trữ đối tượng.
Việc tải vào bộ lưu trữ đối tượng ngay sau khi ghi vào đĩa cũng cho phép bạn duy trì tính đơn giản của trình quét (Prometheus và Thanos Sidecar). Giúp đơn giản hóa việc hỗ trợ, chi phí và thiết kế hệ thống.
Như bạn có thể thấy, sao lưu dữ liệu rất đơn giản. Nhưng còn việc truy vấn dữ liệu trong bộ lưu trữ đối tượng thì sao?
Thành phần Thanos Store hoạt động như một proxy để lấy dữ liệu từ bộ lưu trữ đối tượng. Giống như Thanos Sidecar, nó tham gia vào nhóm tin đồn và triển khai API Store. Bằng cách này, Querier hiện tại có thể coi nó giống như một Sidecar, như một nguồn dữ liệu chuỗi thời gian khác - không cần cấu hình đặc biệt.
Khối dữ liệu chuỗi thời gian bao gồm một số tệp lớn. Việc tải chúng theo yêu cầu sẽ khá kém hiệu quả và việc lưu chúng vào bộ nhớ đệm cục bộ sẽ yêu cầu một lượng lớn bộ nhớ và dung lượng ổ đĩa.
Thay vào đó, Store Gateway biết cách xử lý định dạng lưu trữ Prometheus. Nhờ bộ lập lịch truy vấn thông minh và chỉ lưu vào bộ đệm các phần chỉ mục cần thiết của các khối, có thể giảm các truy vấn phức tạp xuống số lượng yêu cầu HTTP tối thiểu đối với các tệp lưu trữ đối tượng. Bằng cách này, bạn có thể giảm số lượng yêu cầu từ bốn đến sáu bậc độ lớn và đạt được thời gian phản hồi thường khó phân biệt với các yêu cầu đối với dữ liệu trên ổ SSD cục bộ.
Như được hiển thị trong sơ đồ trên, Thanos Querier giảm đáng kể chi phí cho mỗi truy vấn dữ liệu lưu trữ đối tượng bằng cách tận dụng định dạng lưu trữ Prometheus và đặt dữ liệu liên quan cạnh nhau. Bằng cách sử dụng phương pháp này, chúng tôi có thể kết hợp nhiều yêu cầu đơn lẻ thành một số lượng hoạt động hàng loạt tối thiểu.
Nén và lấy mẫu xuống
Khi một khối dữ liệu chuỗi thời gian mới được tải thành công vào bộ lưu trữ đối tượng, chúng tôi sẽ coi nó là dữ liệu “lịch sử”, dữ liệu này có sẵn ngay lập tức thông qua Store Gateway.
Tuy nhiên, sau một thời gian, các khối từ một nguồn (Prometheus với Sidecar) sẽ tích lũy và không còn sử dụng toàn bộ tiềm năng lập chỉ mục nữa. Để giải quyết vấn đề này, chúng tôi đã giới thiệu một thành phần khác có tên là Compactor. Nó chỉ đơn giản áp dụng công cụ nén cục bộ của Prometheus cho dữ liệu lịch sử trong bộ lưu trữ đối tượng và có thể chạy như một công việc hàng loạt định kỳ đơn giản.
Nhờ nén hiệu quả, việc truy vấn bộ nhớ trong thời gian dài không gây ra vấn đề gì về kích thước dữ liệu. Tuy nhiên, chi phí tiềm tàng của việc giải nén một tỷ giá trị và chạy chúng thông qua bộ xử lý truy vấn chắc chắn sẽ dẫn đến thời gian thực hiện truy vấn tăng lên đáng kể. Mặt khác, vì có hàng trăm điểm dữ liệu trên mỗi pixel trên màn hình nên thậm chí không thể hiển thị dữ liệu ở độ phân giải đầy đủ. Do đó, việc lấy mẫu xuống không những có thể thực hiện được mà còn không dẫn đến sự mất đi độ chính xác đáng chú ý.
Để lấy mẫu dữ liệu xuống, Compactor liên tục tổng hợp dữ liệu ở độ phân giải năm phút và một giờ. Đối với mỗi đoạn thô được mã hóa bằng cách nén TSDB XOR, các loại dữ liệu tổng hợp khác nhau sẽ được lưu trữ, chẳng hạn như tối thiểu, tối đa hoặc tổng cho một khối. Điều này cho phép Querier tự động chọn một tập hợp phù hợp cho một truy vấn PromQL nhất định.
Không cần cấu hình đặc biệt để người dùng sử dụng dữ liệu có độ chính xác thấp hơn. Querier tự động chuyển đổi giữa các độ phân giải và dữ liệu thô khác nhau khi người dùng phóng to và thu nhỏ. Nếu muốn, người dùng có thể kiểm soát điều này trực tiếp thông qua tham số “bước” trong yêu cầu.
Vì chi phí lưu trữ một GB thấp nên theo mặc định, Thanos lưu trữ dữ liệu thô, dữ liệu có độ phân giải năm phút và một giờ. Không cần phải xóa dữ liệu gốc.
Quy tắc ghi
Ngay cả với Thanos, các quy tắc ghi lại vẫn là một phần thiết yếu của quy trình giám sát. Chúng làm giảm độ phức tạp, độ trễ và chi phí truy vấn. Chúng cũng thuận tiện cho người dùng lấy dữ liệu tổng hợp theo số liệu. Thanos dựa trên các phiên bản Prometheus thông thường, do đó việc lưu trữ các quy tắc ghi và quy tắc cảnh báo trên máy chủ Prometheus hiện có là hoàn toàn có thể chấp nhận được. Tuy nhiên, trong một số trường hợp điều này có thể không đủ:
- Cảnh báo và quy tắc chung (ví dụ: cảnh báo khi một dịch vụ không hoạt động trên nhiều hơn hai trong số ba cụm).
- Quy tắc cho dữ liệu bên ngoài bộ nhớ cục bộ.
- Mong muốn lưu trữ tất cả các quy tắc và cảnh báo ở một nơi.
Đối với tất cả các trường hợp này, Thanos bao gồm một thành phần riêng biệt gọi là Ruler, tính toán quy tắc và cảnh báo thông qua Thanos Queries. Bằng cách cung cấp StoreAPI nổi tiếng, nút Truy vấn có thể truy cập các số liệu mới được tính toán. Sau đó, chúng cũng được lưu trữ trong bộ lưu trữ đối tượng và được cung cấp thông qua Store Gateway.
Sức mạnh của Thanos
Thanos đủ linh hoạt để có thể tùy chỉnh cho phù hợp với nhu cầu của bạn. Điều này đặc biệt hữu ích khi di chuyển từ Prometheus đơn giản. Hãy tóm tắt nhanh những gì chúng ta đã học được về các thành phần của Thanos bằng một ví dụ nhanh. Dưới đây là cách đưa Prometheus nguyên bản của bạn vào thế giới “lưu trữ số liệu không giới hạn”:
- Thêm Thanos Sidecar vào máy chủ Prometheus của bạn - ví dụ: thùng chứa sidecar trong nhóm Kubernetes.
- Triển khai nhiều bản sao Thanos Querier để có thể xem dữ liệu. Ở giai đoạn này rất dễ nảy sinh tin đồn giữa Scraper và Querier. Để kiểm tra sự tương tác của các thành phần, hãy sử dụng chỉ số 'thanos_cluster_members'.
Chỉ cần hai bước này là đủ để cung cấp chế độ xem toàn cầu và khả năng chống trùng lặp dữ liệu liền mạch từ các bản sao Prometheus HA tiềm năng! Chỉ cần kết nối bảng thông tin của bạn với điểm cuối HTTP Querier hoặc sử dụng trực tiếp giao diện người dùng Thanos.
Tuy nhiên, nếu yêu cầu sao lưu số liệu và lưu trữ lâu dài, bạn sẽ cần phải hoàn thành thêm ba bước:
- Tạo nhóm AWS S3 hoặc GCS. Định cấu hình Sidecar để sao chép dữ liệu vào các nhóm này. Lưu trữ dữ liệu cục bộ bây giờ có thể được giảm thiểu.
- Triển khai Store Gateway và kết nối nó với cụm tin đồn hiện có của bạn. Bây giờ bạn có thể truy vấn dữ liệu đã sao lưu!
- Triển khai Compactor để cải thiện hiệu quả truy vấn trong thời gian dài bằng cách sử dụng tính năng nén và lấy mẫu xuống.
Nếu bạn muốn biết thêm, đừng ngần ngại xem qua của chúng tôi и !
Chỉ trong năm bước, chúng tôi đã biến Prometheus thành một hệ thống giám sát đáng tin cậy với chế độ xem toàn cầu, thời gian lưu trữ không giới hạn và khả năng sẵn sàng cao của các số liệu.
Kéo yêu cầu: chúng tôi cần bạn!
đã là một dự án nguồn mở ngay từ đầu. Khả năng tích hợp liền mạch với Prometheus và khả năng chỉ sử dụng một phần của Thanos khiến nó trở thành lựa chọn tuyệt vời để mở rộng hệ thống giám sát của bạn một cách dễ dàng.
Chúng tôi luôn hoan nghênh các Yêu cầu và Sự cố kéo GitHub. Trong thời gian chờ đợi, vui lòng liên hệ với chúng tôi qua Github Issues hoặc Slacknếu bạn có câu hỏi hoặc phản hồi hoặc muốn chia sẻ trải nghiệm của mình khi sử dụng nó! Nếu bạn thích những gì chúng tôi làm tại Improbable, đừng ngần ngại liên hệ với chúng tôi - !
Nguồn: www.habr.com