ClusterControl 1.7.0 giới thiệu một tính năng mới táo bạo - tích hợp với Prometheus để giám sát dựa trên tác nhân. Chúng tôi gọi đây là SCUMM (Quản lý và Giám sát hợp nhất của Somenines ClusterControl). Trong các phiên bản trước, các nhiệm vụ giám sát chỉ được thực hiện một cách không tác động. Nếu bạn thắc mắc cách ClusterControl thực hiện các chức năng giám sát của nó, hãy xem trang tài liệu này.
ProxySQL, một proxy ngược hiệu suất cao hiểu các giao thức MySQL, thường nằm trên MySQL Replication và Galera Cluster để hoạt động như một cổng vào dịch vụ MySQL phụ trợ. Nó có thể được định cấu hình như một bộ định tuyến truy vấn, tường lửa truy vấn, bộ nhớ đệm truy vấn, bộ điều phối lưu lượng và nhiều hơn nữa. ProxySQL cũng thu thập và hiển thị các số liệu chính thông qua lược đồ STATS của nó, rất hữu ích để phân tích hiệu suất và hiểu những gì thực sự xảy ra đằng sau hậu trường. Truy cập hướng dẫn toàn diện của chúng tôi về ProxySQL để tìm hiểu thêm về nó.
Trong bài đăng trên blog này, chúng ta sẽ xem xét chuyên sâu theo dõi các phiên bản ProxySQL với cách tiếp cận mới này. Trong ví dụ này, chúng ta có một phiên bản ProxySQL trên cùng của MySQL Replication hai nút (1 cái chính, 1 cái phụ), được triển khai thông qua ClusterControl. Kiến trúc cấp cao của chúng tôi trông giống như sau:
Chúng tôi cũng có các quy tắc truy vấn sau được xác định trong phiên bản ProxySQL (chỉ để tham khảo, để hiểu sâu hơn về các chỉ số giám sát được thu thập):
Kích hoạt Prometheus
Giám sát dựa trên tác nhân của ClusterControl được bật trên mỗi cụm. ClusterControl có thể triển khai một máy chủ Prometheus mới cho bạn hoặc sử dụng một máy chủ Prometheus hiện có (được ClusterControl triển khai cho cụm khác). Việc kích hoạt Prometheus khá đơn giản. Chỉ cần đi tới ClusterControl -> chọn cụm -> Bảng điều khiển -> Bật Giám sát Dựa trên Tác nhân:
Sau đó, chỉ định địa chỉ IP hoặc tên máy chủ của máy chủ Prometheus mới hoặc chỉ cần chọn máy chủ Prometheus hiện có từ trình đơn thả xuống:
ClusterControl sẽ cài đặt và định cấu hình các gói cần thiết (Prometheus trên máy chủ Prometheus, trình xuất trên cơ sở dữ liệu và các nút ProxySQL), kết nối với Prometheus làm nguồn dữ liệu và bắt đầu trực quan hóa dữ liệu giám sát trong giao diện người dùng.
Sau khi công việc triển khai kết thúc, bạn sẽ có thể truy cập vào tab Trang tổng quan như được hiển thị trong phần tiếp theo.
Trang tổng quan ProxySQL
Bạn có thể truy cập Trang tổng quan ProxySQL bằng cách đi tới cụm tương ứng trong tab Trang tổng quan. Nhấp vào trình đơn thả xuống Bảng điều khiển sẽ liệt kê ra các bảng điều khiển liên quan đến cụm của chúng tôi (Bản sao MySQL). Bạn có thể tìm thấy bảng điều khiển Tổng quan về ProxySQL trong phần "Bộ cân bằng tải":
Có một số bảng dành cho ProxySQL, một số bảng trong số đó là tự giải thích. Tuy nhiên, hãy đến thăm từng người một.
Kích thước nhóm máy chủ
Kích thước nhóm máy chủ chỉ là tổng số máy chủ trên tất cả các nhóm máy chủ:
Trong trường hợp này, chúng ta có hai nhóm máy chủ - 10 (người viết) và 20 (người đọc). Nhóm máy chủ 10 bao gồm một máy chủ (chính) trong khi nhóm máy chủ 20 có hai máy chủ (chính và máy chủ phụ), tổng cộng tối đa là ba máy chủ.
Trừ khi bạn thay đổi cấu hình nhóm máy chủ (giới thiệu máy chủ mới, xóa máy chủ hiện có) khỏi ProxySQL, bạn sẽ không có gì thay đổi trong biểu đồ này.
Kết nối máy khách
Số lượng kết nối máy khách đang được ProxySQL xử lý cho tất cả các nhóm máy chủ:
Biểu đồ trên chỉ đơn giản cho chúng ta biết rằng luôn có 8 máy khách MySQL được kết nối với phiên bản ProxySQL của chúng tôi trên cổng 6033 trong 45 phút qua (bạn có thể thay đổi điều này trong tùy chọn "Lựa chọn phạm vi"). Nếu bạn ngừng kết nối ứng dụng của mình với ProxySQL (hoặc bỏ qua nó), giá trị cuối cùng sẽ giảm xuống 0.
Câu hỏi của Khách hàng
Biểu đồ hiển thị số lượng Câu hỏi đang được ProxySQL xử lý cho tất cả các nhóm máy chủ:
Theo tài liệu MySQL, Câu hỏi chỉ đơn giản là số lượng câu lệnh được thực thi bởi máy chủ. Điều này chỉ bao gồm các câu lệnh do máy khách gửi đến máy chủ chứ không phải các câu lệnh được thực thi trong các chương trình được lưu trữ, không giống như biến Truy vấn. Biến này không tính các lệnh COM_PING, COM_STATISTICS, COM_STMT_PREPARE, COM_STMT_CLOSE hoặc COM_STMT_RESET. Một lần nữa, nếu bạn ngừng kết nối ứng dụng của mình với ProxySQL (hoặc bỏ qua nó), giá trị sẽ giảm xuống 0.
Kết nối phụ trợ đang hoạt động
Số lượng kết nối mà ProxySQL duy trì với các máy chủ MySQL phụ trợ trên mỗi máy chủ:
Nó chỉ đơn giản cho chúng ta biết có bao nhiêu kết nối hiện đang được ProxySQL sử dụng để gửi các truy vấn đến máy chủ phụ trợ. Miễn là giá trị tối đa không gần với giới hạn kết nối cho máy chủ cụ thể (đặt qua max_connections khi máy chủ được thêm vào nhóm máy chủ ProxySQL), chúng tôi đang ở trong tình trạng tốt.
Kết nối phụ trợ không thành công
Số lượng kết nối không được thiết lập thành công bởi ProxySQL:
Ví dụ trên chỉ đơn giản cho thấy rằng không có lỗi kết nối phụ trợ nào xảy ra trong 45 phút qua.
Truy vấn được định tuyến
Biểu đồ này cung cấp thông tin chi tiết về việc phân phối các câu lệnh đến máy chủ phụ trợ:
Như bạn có thể thấy, hầu hết các lần đọc sẽ được chuyển đến nhóm máy chủ của trình đọc (HG20). Từ đây, chúng ta có thể hiểu mẫu cân bằng đang được ProxySQL thực hiện phù hợp với các quy tắc truy vấn của chúng ta trong khối lượng công việc cần đọc nhiều này.
Kết nối miễn phí
Biểu đồ cho thấy có bao nhiêu kết nối hiện đang miễn phí:
Các kết nối được giữ ở trạng thái mở để giảm thiểu chi phí thời gian gửi truy vấn đến máy chủ phụ trợ.
Độ trễ
Thời gian ping hiện tại tính bằng micro giây, như được báo cáo từ chuỗi giám sát ProxySQL:
Điều này chỉ đơn giản cho chúng ta biết kết nối ổn định như thế nào từ ProxySQL đến các máy chủ MySQL phụ trợ. Giá trị cao trong một thời gian dài nhất quán hầu hết chỉ ra sự cố mạng giữa chúng.
Bộ nhớ Cache Truy vấn
Biểu đồ này hiển thị mức tiêu thụ bộ nhớ của các truy vấn đang được lưu trong bộ đệm bởi ProxySQL:
Từ biểu đồ trên, chúng ta có thể biết rằng ProxySQL tiêu thụ tổng cộng 8MB bộ nhớ bởi bộ đệm truy vấn. Sau khi đạt đến giới hạn 8MB (có thể định cấu hình qua mysql-query_cache_size_MB biến), bộ nhớ sẽ bị xóa bởi chuỗi thanh lọc của ProxySQL. Biểu đồ này sẽ không được điền nếu bạn không xác định quy tắc bộ nhớ đệm truy vấn.
Nhân tiện, bộ đệm ẩn một truy vấn trong ProxySQL có thể được thực hiện chỉ trong hai cú nhấp chuột với ClusterControl. Đi tới trang Truy vấn hàng đầu của ProxySQL, di chuột qua một truy vấn, nhấp vào Bộ đệm truy vấn và nhấp vào "Thêm quy tắc":
Hiệu quả bộ nhớ đệm truy vấn
Biểu đồ này trực quan hóa hiệu quả của các truy vấn được lưu trong bộ nhớ cache:
Dòng màu xanh lam cho chúng ta biết tỷ lệ thành công của các yêu cầu GET được thực thi so với Bộ nhớ cache truy vấn nơi tập hợp kết quả hiện diện và chưa hết hạn. Dòng màu hồng hiển thị tỷ lệ dữ liệu được ghi (chèn) vào hoặc đọc từ Bộ đệm ẩn truy vấn. Trong trường hợp này, dữ liệu của chúng tôi đọc từ Bộ đệm truy vấn cao hơn so với dữ liệu được ghi cho biết cấu hình bộ đệm hiệu quả.
Biểu đồ này sẽ không được điền nếu bạn không xác định quy tắc bộ nhớ đệm truy vấn.
Lưu lượng truy cập mạng
Biểu đồ này trực quan hóa lưu lượng mạng (dữ liệu nhận + dữ liệu được gửi) từ / đến các máy chủ MySQL phụ trợ, trên mỗi máy chủ:
Ảnh chụp màn hình ở trên cho chúng ta biết rằng một lượng đáng kể lưu lượng truy cập đang được chuyển tiếp / nhận từ / đến nhóm máy chủ người đọc (HG20). Trong khối lượng công việc cần đọc nhiều này, các thao tác đọc thường tiêu tốn một lưu lượng cao hơn nhiều chủ yếu do kích thước tập kết quả của các câu lệnh SELECT.
Chỉ một tỷ lệ nhỏ hơn của lưu lượng được chuyển tiếp / nhận từ / đến nhóm máy chủ ghi (HG10), điều này được mong đợi vì các hoạt động ghi thường tiêu tốn ít lưu lượng mạng hơn với tập kết quả nhỏ đáng kể được trả lại cho máy khách.
Hiệu quả phản chiếu
Biểu đồ chỉ hiển thị trạng thái liên quan đến phản ánh lưu lượng truy cập như Mirror_concurrency so với Mirror_queue_length:
Biểu đồ chỉ được điền nếu bạn đã định cấu hình phản chiếu lưu lượng truy cập ( mirror_hostgroup quy tắc truy vấn bên trong). Nếu hàng đợi phản chiếu đang tăng lên, việc giảm giới hạn phản chiếu đồng thời sẽ tăng hiệu quả phản chiếu. Điều này có thể được kiểm soát thông qua mysql-mirror_max_concurrency Biến đổi. Nói một cách đơn giản, các mục nhập hàng đợi không là mục đích sao chép hiệu quả nhất.
Sử dụng bộ nhớ
Biểu đồ minh họa việc sử dụng bộ nhớ của các thành phần chính bên trong ProxySQL - nhóm kết nối, bộ đệm truy vấn và bộ nhớ lưu trữ liên tục (SQLite):
Ảnh chụp màn hình ở trên cho chúng ta biết rằng dung lượng bộ nhớ ProxySQL khá nhỏ, tổng cộng chưa đến 12 MB. Nhóm kết nối chỉ tiêu thụ 1,3 MB đỉnh để đáp ứng khối lượng công việc 8 luồng (máy khách) của chúng tôi. Với nhiều RAM trống hơn có sẵn trên máy chủ, chúng tôi sẽ có thể tăng số lượng kết nối máy khách với ProxySQL lên gấp ba lần đến bốn lần hoặc lưu vào bộ đệm các truy vấn nóng hơn nhiều bên trong ProxySQL để giảm tải các máy chủ phụ trợ MySQL của chúng tôi.
Tính năng thưởng - Hiệu suất nút
ClusterControl 1.7.0 hiện bao gồm các chỉ số hiệu suất máy chủ cho các phiên bản ProxySQL. Trong phiên bản trước, ClusterControl chỉ giám sát các số liệu liên quan đến ProxySQL như được hiển thị bởi lược đồ thống kê ProxySQL. Tính năng mới này có thể được truy cập trong tab của Node -> Phiên bản ProxySQL -> Hiệu suất của Node:
Biểu đồ cung cấp thông tin chi tiết về các chỉ số chính của máy chủ lưu trữ, tương tự như những gì đang được lấy mẫu cho các nút cơ sở dữ liệu trong phần Nút -> Tổng quan. Nếu phiên bản ProxySQL của bạn được đặt cùng một máy chủ với ứng dụng, nghĩa là bạn cũng đang sử dụng ClusterControl để giám sát máy chủ ứng dụng. Thật tuyệt làm sao ?!
Lời kết
Tích hợp ClusterControl với Prometheus cung cấp một cách thay thế để theo dõi và phân tích ngăn xếp cơ sở dữ liệu của bạn, cho đến khi cấp proxy ngược. Giờ đây, bạn có lựa chọn giảm tải các công việc giám sát cho Prometheus hoặc tiếp tục sử dụng phương pháp giám sát không tác nhân ClusterControl mặc định cho cơ sở hạ tầng cơ sở dữ liệu của bạn.
