Clients and tooling

Use Grafana Loki with Object Storage

Grafana Loki là một hệ thống tổng hợp và trực quan hóa nhật ký dành cho môi trường dựa trên nền tảng đám mây. Nó cung cấp giải pháp có thể mở rộng, tiết kiệm chi phí để xử lý khối lượng lớn dữ liệu nhật ký được tạo bởi các ứng dụng và dịch vụ vi mô hiện đại. Với Grafana Loki, người dùng có thể truy vấn và trực quan hóa nhật ký từ khối lượng công việc trên nền tảng đám mây. Loki sử dụng hệ thống lập chỉ mục dựa trên nhãn. Điều này làm cho nó trở thành một lựa chọn lý tưởng cho khả năng quan sát, giám sát, cảnh báo và phân tích dữ liệu.

Trước khi bạn bắt đầu

  • Grafana Loki có thể tích hợp với Object Storage dưới dạng giải pháp lưu trữ phụ trợ sử dụng giao thức S3 và cấu hình lưu trữ S3.
  • Trước khi bạn áp dụng Các phương pháp thực hành tốt nhất cho cấu hình của mình, hãy xem lại các khái niệm cơ bản này để hiểu quy trình lưu trữ và bộ nhớ đệm của Loki.

Kho lưu trữ bộ nhớ đệm Memcached

  • Các ví dụ về phương pháp hay nhất sử dụng Memcached, hệ thống bộ nhớ đệm cục bộ phổ biến nhất. Memcached đóng vai trò là kho lưu trữ bộ nhớ đệm của Loki để cung cấp lớp bộ nhớ đệm phân tán, nhanh chóng.
  • Cấu hình Memcached lưu trữ các khối dữ liệu nhật ký và siêu dữ liệu liên quan trong kho khóa-giá trị của nó.

Lập chỉ mục và bộ nhớ đệm

  • Các nhật ký được đưa vào Loki thường được nhóm thành các khối. Các khối này đại diện cho một phân đoạn dữ liệu nhật ký có giới hạn thời gian. Cấu trúc của các khối cho phép truy vấn hiệu quả dựa trên phạm vi thời gian và nhãn.
  • Trình nhập Loki lập chỉ mục và lưu trữ các khối trong Memcached để truy xuất nhanh chóng.
  • Khi truy vấn Loki xảy ra, trước tiên, công cụ truy vấn sẽ kiểm tra Memcached để tìm các đoạn được yêu cầu.

Bộ nhớ đệm trong khi viết

  • Trong quá trình nhập, các đoạn có thể được lưu vào bộ nhớ đệm trong Memcached ngay sau khi chúng được ghi vào bộ lưu trữ phụ trợ, chẳng hạn như Object Store.
  • Bộ nhớ đệm chủ động này đảm bảo rằng dữ liệu nhật ký được nhập gần đây có sẵn để truy vấn. Nó cũng tránh được độ trễ xảy ra khi tìm nạp nó từ bộ lưu trữ phía sau.
  • Loki quản lý các chỉ mục và khối riêng biệt mặc dù nó có thể sử dụng cùng một bộ lưu trữ phụ trợ cho cả hai.

Bộ nhớ đệm trong khi đọc

  • Khi một truy vấn xảy ra, công cụ truy vấn sẽ kiểm tra Memcached để tìm các đoạn được yêu cầu.
  • Nếu truy vấn tìm thấy các đoạn trong bộ đệm, truy vấn sẽ truy xuất các đoạn đó trực tiếp từ Memcached. Điều này dẫn đến phản hồi truy vấn có độ trễ thấp.
  • Loki tìm nạp các đoạn không có trong bộ đệm hoặc các đoạn bị loại bỏ do chính sách bộ nhớ đệm từ bộ lưu trữ phía sau.

Trục xuất và quản lý

  • Memcached quản lý chính sách trục xuất của riêng mình. Các chính sách này sử dụng các yếu tố như mức sử dụng bộ nhớ, kiểu truy cập và thời gian hết hạn.
  • Các đoạn được truy cập ít thường xuyên nhất hoặc đã vượt quá thời gian tồn tại (TTL) của chúng có thể bị xóa khỏi bộ đệm. Điều này nhường chỗ cho dữ liệu mới.
  • Cấu hình của Loki có thể bao gồm các tham số để điều chỉnh chính sách trục xuất và kích thước bộ đệm để tối ưu hóa hiệu suất và việc sử dụng tài nguyên.

Định cấu hình bộ đệm loki

Loki hỗ trợ một số tham số bộ nhớ đệm có thể định cấu hình. Xem lại các tùy chọn được đề xuất này để tìm hiểu thêm.

Sử dụng kho lưu trữ bộ đệm được tối ưu hóa như memcached

Bộ nhớ đệm trong bộ nhớ được kích hoạt tự động trong Loki. Tuy nhiên, bạn nên sử dụng kho lưu trữ bộ đệm được tối ưu hóa như Memcached. Để định cấu hình Memcached, hãy tham khảo tài liệu Grafana.

Định cấu hình khối chunk_store_config

Khối chunk_store_config cho phép bạn định cấu hình cách các khối được lưu vào bộ đệm và thời gian chờ trước khi lưu chúng vào kho lưu trữ dự phòng.

Một số tham số cấu hình chính bao gồm max_chunk_age và chunk_idle_ Period. Các tham số này xác định khoảng thời gian các khối được lưu vào bộ nhớ đệm trước khi bị xóa.

Sử dụng tham số default_validity để lưu vào bộ đệm kết quả và tham số chunk_target_size để định cấu hình kích thước khối được nén.

Để xác định giá trị phù hợp cho các tham số này cho trường hợp sử dụng của bạn, điều quan trọng là phải xem xét những điều sau:

  • Tải: Lượng dữ liệu nhật ký tính bằng byte được tạo ra mỗi ngày theo khối lượng công việc của đối tượng thuê của bạn. Ví dụ: GB/ngày.
  • Mẫu truy cập nhật ký: Xác định xem mẫu truy cập dữ liệu nhật ký cho trường hợp sử dụng của bạn có thiên về dữ liệu gần đây không, chẳng hạn như dữ liệu cũ <12h hoặc cũ hơn, chẳng hạn như >4-5 ngày.
  • Cân nhắc về dung lượng bộ nhớ đệm: Xác định xem việc triển khai Loki của bạn có đủ tài nguyên như RAM, CPU và dung lượng ổ đĩa cục bộ được phân bổ cho bộ nhớ đệm hay không.
  • Cân nhắc về chi phí: Ước tính chi phí để quản lý bộ nhớ đệm cục bộ cho Loki, dựa trên yêu cầu về dung lượng bộ nhớ và dung lượng ổ đĩa.
  • Để tìm hiểu thêm, bạn có thể đọc bài đăng trên blog Grafana Cloud thảo luận về mức độ ảnh hưởng của kích thước bộ nhớ đệm thích hợp đến hiệu suất và độ tin cậy.

Để tìm hiểu thêm, bạn có thể đọc bài đăng trên blog Grafana Cloud thảo luận về mức độ ảnh hưởng của kích thước bộ nhớ đệm thích hợp đến hiệu suất và độ tin cậy.

Cấu hình lưu trữ Loki

Khối s3_storage_config định cấu hình kết nối đến phần cuối của Bộ lưu trữ đối tượng Linode S3.

Tham số cấu hình lưu trữ tên nhóm cho phép khối lượng công việc của đối tượng thuê Loki chỉ định nhiều nhóm. Điều này cho phép phân chia các khối dữ liệu nhật ký trên nhiều nhóm. Chúng tôi khuyên bạn nên định cấu hình nhiều nhóm và có thể nhiều tùy thuộc vào tải. Điều này giúp tăng khả năng mở rộng và cân bằng tải vì giới hạn tốc độ được thực thi ở cấp độ nhóm.

Các cài đặt dự phòng lưu trữ sau đây cũng rất quan trọng.

Các tham số này xác định cách Loki quản lý các yêu cầu lưu trữ khi Bộ lưu trữ đối tượng thực thi các giới hạn tốc độ. Ví dụ: giới hạn tỷ lệ có thể được thực thi do tỷ lệ yêu cầu cao hơn giới hạn cho phép. Nếu không được định cấu hình đúng cách, có thể có hiệu ứng xếp tầng trong đó số lần thử lại góp phần tăng thêm tỷ lệ yêu cầu. Điều này có thể dẫn đến việc thực thi giới hạn vĩnh viễn hoặc lâu hơn lý tưởng.

Do việc triển khai giới hạn tốc độ Lưu trữ đối tượng, nên sử dụng các giá trị sau:

  • min_period – 2 giây
  • max_period – 5 giây
  • max_retries – 5

Cấu hình kích thước khối Loki

Kích thước khối sau đây và các tham số cấu hình liên quan được hỗ trợ.

Bạn nên định cấu hình kích thước chunk trong khoảng từ 1,5 MB đến 2 MB. chunk_target_size dịch trực tiếp sang kích thước đối tượng trong bộ lưu trữ đối tượng và xác định:

  • Số lượng yêu cầu PUT tổng thể.
  • Số lượng đối tượng được lưu trữ trong các thùng.
  • Cần có băng thông hiệu quả cho các hoạt động Lưu trữ đối tượng.

Xem lại ví dụ sau để tìm hiểu lý do tại sao việc chọn giá trị chunk_target_size một cách cẩn thận lại quan trọng.

  • Nếu khối lượng công việc của bạn tạo ra 5 TB dữ liệu ghi nhật ký mỗi ngày và kích thước khối là 1,5 MB thì trung bình, phân phối đồng đều nó sẽ tạo ra:
  • ~38 yêu cầu PUT mỗi giây.
  • Thông lượng 57 MBps (456 Mbps) được đưa vào bộ lưu trữ.
  • ~ 3,3 triệu đồ vật mỗi ngày.

Thay vào đó, nếu kích thước khối là 2 MB thì trung bình, phân phối đồng đều sẽ tạo ra:

  • ~29 yêu cầu PUT mỗi giây cho cùng một thông lượng tổng hợp vào bộ lưu trữ nhưng với ~2,5 triệu đối tượng mỗi ngày.
  • Số lượng yêu cầu và thông lượng cho các yêu cầu GET mỗi giây phụ thuộc nhiều vào kích thước cửa sổ và khoảng thời gian mà nhật ký được kéo và liệu chúng có nằm trong bộ nhớ đệm hay không. Ví dụ: ~500 yêu cầu GET mỗi giây bị thiếu bộ nhớ đệm với kích thước đoạn 2 MB sẽ dẫn đến thông lượng đầu ra khoảng ~1 GBps (8 Gbps) từ Bộ lưu trữ đối tượng.
  • Ví dụ: ~500 yêu cầu GET mỗi giây bị thiếu bộ nhớ đệm với kích thước đoạn 2 MB sẽ dẫn đến thông lượng đầu ra khoảng ~1 GBps (8 Gbps) từ Bộ lưu trữ đối tượng.

Nguồn: https://techdocs.akamai.com/cloud-computing/docs/using-grafana-loki-with-object-storage