Hãy để tôi thảo luận về một chủ đề vốn dĩ không dành riêng cho PostgreSQL, nhưng tôi thường xuyên gặp phải khi điều tra các vấn đề trên hệ thống của khách hàng, đánh giá “khả năng hỗ trợ” của các hệ thống đó, v.v. Điều quan trọng là phải có giải pháp giám sát các chỉ số hệ thống, định cấu hình nó hợp lý và tại sao sar cho đến nay vẫn là công cụ yêu thích của tôi (ít nhất là trên Linux).
Về tầm quan trọng của việc giám sát
Thứ nhất, việc giám sát các chỉ số cơ bản của hệ thống (CPU, I / O, bộ nhớ) là cực kỳ quan trọng. Hơi kỳ lạ khi phải nêu vấn đề này trong các cuộc thảo luận với các kỹ sư khác, nhưng tôi cho rằng cứ 10 kỹ sư thì có 1 kỹ sư cho rằng họ không thực sự cần giám sát. Lý do thường đi theo những dòng sau:
Việc giám sát thực sự bổ sung thêm chi phí, không còn nghi ngờ gì nữa. Nhưng nó có thể không đáng kể so với những gì ứng dụng đang làm. Trên thực tế, sar không thực sự thêm bất kỳ thiết bị đo bổ sung nào, nó chỉ đơn thuần là đọc các bộ đếm từ nernel, delta tính toán và ghi nó vào đĩa. Nó có thể cần một số dung lượng ổ đĩa và I / O (tùy thuộc vào số lượng CPU và đĩa) nhưng đó là về điều đó.
Ví dụ:thu thập số liệu thống kê mỗi giây trên một máy có 32 lõi và nhiều đĩa sẽ tạo ra ~ 5GB dữ liệu thô mỗi ngày, nhưng nó nén rất tốt, thường là ~ 5-10%). Và nó hầu như không hiển thị trong top . Độ phân giải trên giây hơi cao và việc sử dụng 5 hoặc 10 giây sẽ giảm thêm chi phí.
Vì vậy, không, hóa ra chi phí thực sự không phải là lý do hợp lệ để không cho phép giám sát.
Chi phí so với lợi ích
Tuy nhiên, quan trọng hơn, “Tôi loại bỏ bao nhiêu chi phí khi không bật tính năng giám sát?” là câu hỏi sai để hỏi. Thay vào đó, bạn nên hỏi “Tôi nhận được lợi ích gì từ việc giám sát? Lợi ích có lớn hơn chi phí không? ”
Chúng ta đã biết chi phí (chi phí chung) là khá nhỏ hoặc hoàn toàn không đáng kể. Những lợi ích là gì? Theo kinh nghiệm của tôi, có dữ liệu giám sát hiệu quả là vô giá.
Thứ nhất, nó cho phép bạn điều tra các vấn đề - xem xét một loạt các biểu đồ và tìm kiếm những thay đổi đột ngột mang lại hiệu quả đáng ngạc nhiên và thường dẫn bạn trực tiếp đến vấn đề phù hợp. Tương tự, so sánh dữ liệu hiện tại (được thu thập trong sự cố) với đường cơ sở (được thu thập khi mọi thứ đều ổn) là rất hữu ích và không thể thực hiện được nếu bạn chỉ bật tính năng giám sát khi mọi thứ bị hỏng.
Thứ hai, nó cho phép bạn đánh giá các xu hướng và xác định các vấn đề tiềm ẩn trước khi chúng thực sự tấn công bạn. Bạn đang sử dụng CPU bao nhiêu? Việc sử dụng CPU có tăng lên theo thời gian không? Có một số mô hình đáng ngờ trong việc sử dụng bộ nhớ? Bạn chỉ có thể trả lời những câu hỏi đó nếu bạn có sự giám sát tại chỗ.
Tại sao lại sar là công cụ yêu thích của tôi
Giả sử tôi đã thuyết phục bạn giám sát là quan trọng và bạn chắc chắn nên làm điều đó. Nhưng tại sao lại là sar công cụ yêu thích của chúng tôi, khi có nhiều lựa chọn thay thế ưa thích khác nhau, cả tại chỗ và dựa trên đám mây?
- Nó được bao gồm trong tất cả các bản phân phối, việc cài đặt / thiết lập rất dễ dàng. Điều này khiến việc thuyết phục mọi người bật tính năng này trở nên khá đơn giản.
- Nó nằm ngay trên máy. Vì vậy, nếu bạn SSH cho máy, bạn cũng có thể nhận được dữ liệu giám sát.
- Nó đang sử dụng đầu ra văn bản đơn giản. Xử lý dữ liệu đơn giản - nhập dữ liệu vào cơ sở dữ liệu, phân tích, đính kèm nó vào một phiếu hỗ trợ. Điều đó khá khó với các công cụ khác thường không cho phép bạn xuất dữ liệu dễ dàng, chỉ hiển thị biểu đồ và / hoặc hạn chế đáng kể những gì bạn có thể thực hiện phân tích, v.v.
Tôi thừa nhận một số điều này xuất phát từ thực tế là tôi làm việc cho một công ty cung cấp dịch vụ PostgreSQL cho các công ty khác (có thể là hỗ trợ 24 × 7 hoặc DBA từ xa. Vì vậy, chúng tôi thường chỉ có quyền truy cập rất hạn chế vào hệ thống của khách hàng (hầu hết chỉ là máy chủ cơ sở dữ liệu) và không có gì hơn). Điều đó có nghĩa là có tất cả dữ liệu quan trọng trên chính máy chủ cơ sở dữ liệu, có thể truy cập thông qua SSH đơn giản, cực kỳ thuận tiện và loại bỏ các chuyến đi khứ hồi không cần thiết chỉ để yêu cầu một phần dữ liệu khác từ một số hệ thống khác. Điều này giúp tiết kiệm cả thời gian và sự tỉnh táo ở cả hai bên.
Nếu bạn có nhiều hệ thống để quản lý, có thể bạn sẽ thích giải pháp giám sát thu thập dữ liệu từ nhiều máy vào một nơi duy nhất. Nhưng đối với tôi, sar vẫn thắng.
Vậy, làm thế nào để định cấu hình nó?
Tôi đã đề cập đến việc cài đặt và bật sar (hay đúng hơn là sysstat , là gói bao gồm sar ) rất đơn giản. Thật không may, cấu hình mặc định hơi tệ. Sau khi cài đặt sysstat , bạn sẽ tìm thấy thứ gì đó giống như thế này trong /etc/cron.d/sysstat (hoặc bất cứ nơi nào cửa hàng phân phối của bạn cron cấu hình):
*/10 * * * * root /usr/lib64/sa/sa1 1 1
Điều này nói lên một cách hiệu quả sa1 lệnh sẽ được thực hiện sau mỗi 10 phút và nó sẽ thu thập một mẫu duy nhất trong hơn 1 giây. Có hai vấn đề ở đây. Thứ nhất, 10 phút là độ phân giải khá thấp. Thứ hai, mẫu chỉ bao gồm 1 giây trong số 600, vì vậy 9:59 còn lại không thực sự được bao gồm trong đó. Điều này hơi ổn đối với xu hướng dài hạn, khi lấy mẫu ngẫu nhiên có độ phân giải thấp là đủ. Đối với các mục đích khác, bạn có thể cần phải làm điều gì đó như sau:
* * * * * root /usr/lib64/sa/sa1 -S XALL 60 1
Thu thập một mẫu mỗi phút và mỗi mẫu bao gồm một phút. -S XALL có nghĩa là tất cả các số liệu thống kê phải được thu thập, bao gồm ngắt, thiết bị khối riêng lẻ và phân vùng, v.v. Xem man sadc để biết thêm chi tiết.
Tóm tắt
Vì vậy, tóm tắt bài đăng này thành một vài điểm đơn giản:
- Bạn nên giám sát, ngay cả khi bạn nghĩ rằng bạn không cần nó. Khi bạn gặp sự cố thì đã quá muộn.
- Chi phí giám sát có thể không đáng kể, nhưng chắc chắn thấp hơn nhiều so với lợi ích của việc có dữ liệu giám sát.
-
sarlà thuận tiện và rất hiệu quả. Có thể bạn sẽ sử dụng thứ khác trong tương lai, nhưng đó là bước đầu tiên tốt. - Cấu hình mặc định không đặc biệt tuyệt vời (độ phân giải thấp, mẫu 1 giây). Cân nhắc tăng độ phân giải.
Một điều tôi chưa đề cập là sar chỉ xử lý các số liệu hệ thống - CPU, đĩa, bộ nhớ, quy trình, không liên quan đến thống kê PostgreSQL. Tất nhiên, bạn chắc chắn cũng nên theo dõi phần đó của ngăn xếp.
