Đây là một câu hỏi Canonical về phần mềm giám sát.
Cũng liên quan: Bạn sử dụng công cụ nào để giám sát máy chủ của mình?
Tôi cần theo dõi các máy chủ của mình; Tôi cần cân nhắc điều gì khi quyết định giải pháp giám sát?
Câu trả lời:
Có rất nhiều giải pháp giám sát ngoài kia. Mọi người đều có sở thích của mình và mỗi doanh nghiệp có nhu cầu riêng, vì vậy không có câu trả lời chính xác. Tuy nhiên, tôi có thể giúp bạn tìm ra những gì bạn có thể muốn tìm kiếm khi chọn giải pháp giám sát.
Trong các hệ thống giám sát chung phục vụ hai mục đích chính. Đầu tiên là thu thập và lưu trữ dữ liệu theo thời gian. Ví dụ, bạn có thể muốn thu thập việc sử dụng CPU và vẽ biểu đồ theo thời gian. Mục đích thứ hai là để cảnh báo khi mọi thứ không phản hồi hoặc không nằm trong ngưỡng nhất định. Ví dụ: bạn có thể muốn thông báo nếu một máy chủ nhất định không thể truy cập bằng ping hoặc nếu mức sử dụng CPU cao hơn một tỷ lệ nhất định. Ngoài ra còn có các hệ thống giám sát nhật ký như Splunk nhưng tôi đang coi những hệ thống này là riêng biệt cho việc này.
Hai vai trò chính này đôi khi đến trong một sản phẩm duy nhất, thời điểm khác và phổ biến hơn là có một sản phẩm dành riêng cho từng mục đích.
Người gây ô nhiễm :
Tất cả các hệ thống giám sát cần một số loại pug để thu thập dữ liệu. Không phải tất cả dữ liệu được thu thập theo cùng một cách. Bạn nên xem xét môi trường của mình và quyết định dữ liệu nào bạn cần và cách thu thập dữ liệu. Sau đó, đảm bảo hệ thống giám sát bạn chọn hỗ trợ những gì bạn cần. Một số phương pháp phổ biến bao gồm:
Nếu bạn có hầu hết một HĐH trong môi trường của mình hoặc HĐH chính, một số hệ thống nhất định có thể có nhiều tùy chọn khác.
Cấu hình :
Trong các hệ thống giám sát có xu hướng sử dụng lại rất nhiều đối tượng. Ví dụ: bạn muốn giám sát một ứng dụng nhất định như Apache hoặc IIS trên một loạt các máy chủ. Hoặc bạn muốn một số ngưỡng nhất định để áp dụng cho các nhóm máy chủ. Bạn cũng có thể có một số nhóm người nhất định "gọi điện". Do đó, một hệ thống khuôn mẫu tốt là rất quan trọng đối với một hệ thống màn hình.
Cấu hình thường được thực hiện thông qua giao diện người dùng hoặc tệp văn bản. Tùy chọn giao diện người dùng thường sẽ dễ dàng hơn, nhưng các tệp văn bản có xu hướng tốt hơn để sử dụng lại và các biến. Vì vậy, tùy thuộc vào nhân viên CNTT của bạn, bạn có thể thích sự đơn giản hơn sức mạnh.
Giao diện người dùng : Giao diện
phổ biến nhất cho các hệ thống giám sát hiện nay là giao diện web. Một số điều cần đánh giá liên quan đến giao diện web là:
Công cụ cảnh báo : Công cụ
cảnh báo phải linh hoạt và đáng tin cậy. Có rất nhiều cách khác nhau để được thông báo bao gồm:
Các tính năng khác cần tìm là:
Điều quan trọng là tin tưởng rằng khi có sự cố xảy ra, bạn sẽ nhận được cảnh báo. Điều này dẫn đến hai điều:
Lưu trữ dữ liệu :
Nếu hệ thống thu thập và lưu trữ dữ liệu (tức là các hệ thống bao gồm biểu đồ) so với hệ thống lưu trữ dữ liệu. Một triển khai rất phổ biến cho cả cửa hàng và đồ thị là RRD chẳng hạn.
Một số tính năng cần tìm từ kho lưu trữ dữ liệu là:
Thư viện
đồ thị : Đồ thị có thể hữu ích để nhanh chóng xác định xu hướng và đưa ra bối cảnh cho trạng thái hiện tại của một cái gì đó dựa trên lịch sử của nó. Một số bao gồm cả xu hướng có thể hữu ích để dự đoán mọi thứ trước khi chúng xảy ra (tức là hết dung lượng đĩa). Hãy chắc chắn rằng các biểu đồ sẽ cung cấp cho bạn thông tin mà bạn nghĩ rằng bạn sẽ cần một cách rõ ràng.
Kiểm soát truy cập :
Nếu bạn có một tổ chức lớn, bạn có thể cần kiểm soát truy cập vì các quản trị viên nhất định chỉ có thể điều chỉnh một số điều nhất định. Bạn cũng có thể muốn bảng điều khiển phải đối mặt công khai. Nếu điều này quan trọng, bạn nên đảm bảo hệ thống giám sát có các điều khiển bạn cần.
Báo cáo :
Một hệ thống cung cấp các báo cáo tốt có thể giúp bạn xác định những gì cần cải thiện trong thời gian dài. Ví dụ, nó có thể đưa ra một câu trả lời tốt cho những thứ như "hệ thống nào đi xuống nhiều nhất?". Điều này có thể quan trọng khi bạn đang cố gắng thuyết phục ban quản lý chi tiền cho một số thứ nhất định - giống như bằng chứng cứng của doanh nghiệp.
Các tính năng chuyên dụng :
Một số hệ thống giám sát được nhắm mục tiêu vào các sản phẩm cụ thể hoặc có nhiều hỗ trợ hơn các hệ thống khác. Ví dụ: nếu điều chính bạn cần giám sát là máy chủ SQL hoặc nếu bạn sử dụng nhiều sản phẩm VMWare, bạn sẽ thấy những thứ này được hỗ trợ tốt như thế nào.
Mẫu giám sát được xác định trước :
Một hệ thống đi kèm với rất nhiều mẫu được xác định trước (hoặc có cơ sở người dùng đã tạo nhiều mẫu) có thể là một trình tiết kiệm thời gian rất lớn.
Khám phá :
Nếu bạn có một môi trường rộng lớn hoặc thay đổi. Một số hệ thống cung cấp khả năng thêm các hệ thống mới thông qua API hoặc chạy quét để tìm các máy chủ hoặc thành phần mới.
Giám sát phân tán:
Nếu bạn có nhiều vị trí để giám sát, có thể hữu ích khi theo dõi những người bỏ phiếu ở mỗi địa điểm thay vì nhiều hệ thống độc lập đang giám sát thông qua mạng WAN.
Có rất nhiều hệ thống giám sát ngoài kia. Chúng tôi có một danh sách với một bản tóm tắt về câu hỏi cũ này . Để tham khảo nhanh một số điều mà tôi nghe nhiều nhất là:
Lý do tôi không thể nói cho bạn biết nên sử dụng cái gì vì mọi tổ chức đều có nhu cầu riêng. Nếu bạn muốn đưa ra lựa chọn đúng đắn, bạn nên suy nghĩ về tất cả các thành phần trên và tìm ra những tính năng quan trọng đối với tổ chức của bạn. Sau đó tìm một hệ thống hoặc hệ thống yêu cầu cung cấp những gì bạn cần và thử chúng. Một số trong số này chi phí một chút, rất nhiều, hoặc là miễn phí. Sau đó, đưa tất cả những điều đó vào tài khoản của bạn. Từ những gì tôi đã sử dụng, tất cả đều không hoàn hảo, nhưng ít nhất bạn có thể cố gắng để có được thứ gì đó phù hợp.
Thật hữu ích để phân biệt giữa giám sát và cảnh báo. Giám sát có nghĩa là thu thập dữ liệu và làm đồ thị. Thông báo có nghĩa là gửi cho tôi một tin nhắn SMS khi một máy chủ ngừng hoạt động vào giữa đêm.
Nagios là để cảnh báo. Cacti và Munin là để theo dõi. Các sản phẩm khác kết hợp hai chức năng. Zenoss và Zabbix là những ví dụ.
Tôi sẽ bắt đầu bằng cách trả lời một số câu hỏi:
Bạn có cần giám sát máy chủ, thiết bị mạng, ứng dụng hoặc cả ba không?
Có giới hạn về những phương pháp bạn có thể sử dụng để theo dõi? Bạn có thể cài đặt các máy khách giám sát như NRPE trên các máy chủ không, hoặc bạn sẽ sử dụng SNMP, hoặc có thể cả hai?
Ai sẽ sử dụng biểu đồ và ai sẽ sử dụng cảnh báo? Bạn muốn kết quả cuối cùng trông như thế nào? Giao diện của giao diện có quan trọng không (người kinh doanh sẽ sử dụng cái này hay chỉ nhân viên công nghệ?)
Tài nguyên của bạn là gì, cả về thời gian, kỹ năng và phần cứng? Bạn có ít nhất khả năng kịch bản khiêm tốn? Bạn có cần một giải pháp vượt trội không?
Theo tôi, quy tắc đầu tiên của cả cảnh báo và giám sát nên là Giữ cho nó đơn giản! Một tổ chức có thể sống hoặc chết về cách nó cảnh báo và thu thập dữ liệu, và hầu hết thời gian nó sẽ trở nên phức tạp. Bắt đầu với những điều cơ bản và xây dựng từ đó.
Hãy suy nghĩ về các dịch vụ mà phần mềm của bạn cung cấp , gửi thông báo khi các dịch vụ này không thành công hoặc khi nguy cơ thất bại của các dịch vụ này tăng lên.
Lý thuyết đằng sau các chiến lược giám sát là gắn kết giám sát và cảnh báo với một số loại thỏa thuận cấp độ dịch vụ . Rốt cuộc, bạn muốn được cảnh báo về thực tế rằng bạn đang mất tiền, không nhất thiết là số lượng kết nối TCP tăng lên nji0019.myserver.com. Có nhiều công cụ khác nhau sẽ cung cấp cho bạn hàng tấn cảnh báo, xác định sự phụ thuộc giữa các cảnh báo, nhưng nhiều kiểm tra này không liên quan trực tiếp đến dịch vụ bạn cung cấp cho ai đó.
Xác định các dịch vụ quan trọng mà bạn cung cấp, chẳng hạn như khả năng phục vụ một trang web và khả năng sửa đổi trang web đó (ví dụ: một loại CMS nào đó). Chúng nên được kiểm tra (ví dụ: bằng cách theo dõi rằng bạn có thể lấy trang web và bạn có thể). Sự thất bại của hai Dịch vụ này (được sử dụng ở đây với số vốn S) sẽ kích hoạt cảnh báo để thông báo cho bạn.
Nếu điều quan trọng là trang web phản hồi trong một khoảng thời gian hợp lý, thì điều đó cũng sẽ kích hoạt cảnh báo. Sắp xếp một "vi phạm SLA" nếu bạn muốn.
Thông thường, có một rủi ro cố hữu đối với một Dịch vụ thất bại và thường thì rủi ro đó được giảm thiểu bằng cách bạn giới thiệu dự phòng, ví dụ: máy chủ thứ hai hoặc cơ sở dữ liệu nô lệ hoặc thẻ mạng bổ sung ...
Khi sự dư thừa đó bị mất, Dịch vụ vẫn ổn, nhưng nguy cơ Dịch vụ không thành công.
Đây là lý do chính thứ hai để kích hoạt cảnh báo; sự dư thừa đó đã biến mất (ví dụ: máy chủ thứ hai đã chết) hoặc có nguy cơ sắp xảy ra là rủi ro sẽ tăng lên (ví dụ: đĩa chỉ còn lại 500Mb hoặc xu hướng đĩa cho biết đĩa sẽ đầy trong khoảng 5 giờ).
Nhưng check_mk cho tôi 50-60 séc trên mỗi máy chủ, tất cả có phải là vô giá trị không?
Không. Tất cả điều này không có nghĩa là bạn muốn bỏ rất nhiều kiểm tra tự động mà bạn nhận được với ví dụ: check_mk, nhưng điều đó có nghĩa là bạn nên cố gắng phân loại từng kiểm tra vào những gì Dịch vụ có thể bị ảnh hưởng nếu xảy ra sự cố.
Dịch vụ nào sẽ bị ảnh hưởng nếu / var / phân vùng đầy? Dịch vụ nào sẽ bị ảnh hưởng nếu giao diện eth0 không hoạt động? ... nếu các kết nối TCP bên ngoài bị chặn bởi một số tường lửa? ... Nếu số lượng chủ đề vượt quá 800? ... Nếu cơ sở dữ liệu đi xuống?
Bạn có 2 máy chủ web và máy chủ cơ sở dữ liệu phục vụ một trang web phía sau bộ cân bằng tải mà bạn không sở hữu (ví dụ: ISP). Dịch vụ bạn cung cấp là cổng 80 trên hai máy chủ và chúng có bộ nhớ cache khổng lồ có thể tồn tại, ví dụ như thời gian chết cơ sở dữ liệu (cơ sở dữ liệu trên máy chủ thứ ba).
Trong trường hợp này, sự thất bại hoàn toàn của một máy chủ web sẽ không dẫn đến việc trang web bị sập. Điều đã xảy ra là sự dư thừa đã biến mất để nguy cơ thất bại tăng lên. Điều đó sẽ kích hoạt một cảnh báo.
Sự thất bại hoàn toàn của cơ sở dữ liệu có thể không ảnh hưởng đến khả năng phục vụ trang web, bởi vì các bộ đệm được điều chỉnh tốt tại chỗ; Điều này sau đó không ảnh hưởng đến Dịch vụ phục vụ trang web, nhưng nó có thể ảnh hưởng đến một Dịch vụ khác, cụ thể là cập nhật trang web hoặc chấp nhận đơn đặt hàng ...
Mỗi Dịch vụ sẽ có cấp độ dịch vụ riêng chỉ định mức độ quan trọng của việc khôi phục dịch vụ hoặc tránh mất điện
Mỗi khi bạn nhận được cảnh báo, bạn nên thực hiện một trong các cách sau: - thay đổi hệ thống đang được giám sát để khắc phục sự cố gây ra cảnh báo (ví dụ: thay thế ổ đĩa hoặc cấu hình lại logrotate hoặc một cái gì đó) - thay đổi hệ thống giám sát để tránh cảnh báo gửi đi lần sau khi tình huống đó phát sinh. (ví dụ: thay đổi cấp độ cho "đĩa miễn phí" để đĩa có thể lấp đầy tới 90% thay vì chỉ 80%)
Tôi hầu như quen thuộc với Nagios và cấu hình dài dòng của nó, và từ đó đã được nối vào multisite của Check-mk. Gần đây tôi đã biết rằng check_mk có khái niệm về Business Intelligence (từ 1.11) có vẻ phù hợp với suy nghĩ này. Bạn có thể xác định rằng séc trong nagios là một phần của dịch vụ lớn hơn và có các quy tắc xác định trạng thái của "Dịch vụ" là chức năng của trạng thái của nhiều séc, tổng hợp thành trạng thái xấu nhất hoặc tốt nhất .
Một trong những điểm quan trọng nhất mà các công ty quên khi chọn giải pháp giám sát là đó không phải là tất cả về việc giải quyết các vấn đề vận hành tức thời, đó là về các vấn đề không lường trước được vào ngày mai! Ý tôi là, tất nhiên giải quyết các vấn đề tức thời là quan trọng, nhưng tin tôi đi, trong nhiều trường hợp, chiến lược thiển cận này sẽ không đảm bảo cho sự tồn tại của một công ty.
Có hàng tá giải pháp giám sát tuyệt vời trên thị trường. Danh sách ngắn một bộ giải pháp nhỏ thỏa mãn yêu cầu của bạn là một nhiệm vụ khó khăn và lâu dài, hơn nữa, việc tìm ra một giải pháp phù hợp với ngân sách của bạn thậm chí còn khó khăn hơn. Phần thú vị là tìm một thứ phù hợp với hiện tại và tương lai của bạn . Và không có quá trình đánh giá để phát hiện ra rằng, đó là vấn đề kinh nghiệm + trực giác + một yếu tố rất quan trọng: Sự tin tưởng , đó không phải là một điều dễ dàng để hack .
Theo nguyên tắc thông thường, tìm kiếm và đào tìm những câu chuyện thành công của bộ giải pháp giám sát được liệt kê trong danh sách ngắn của bạn, đặc biệt nếu nó ảnh hưởng đến một công ty trong lĩnh vực của bạn. Yêu cầu nhà cung cấp cho câu chuyện thành công của họ, và thậm chí yêu cầu họ cho phép nói chuyện với một trong những khách hàng của họ. Các công ty không sợ chương trình này cho thấy họ có mối quan hệ thực sự với khách hàng của họ và họ không che giấu điều đó, và đây là một điều cực kỳ hiếm thấy hiện nay.
Zabbix, Icinga, Pandora FMS, op5, Datadog, New Relic ... tất cả đều có những thăng trầm, nhưng vấn đề thực sự là tìm ra cái nào thích nghi tốt hơn với tương lai của bạn.
Nếu bạn đang xem xét giám sát hệ thống từ xa, thì có thể nên tìm kiếm các thử nghiệm vị trí thực tế được thực hiện từ đó. Các vấn đề kết nối không phải là quá khứ và nếu phần cứng của bạn đang phục vụ một nhóm trong một khu vực cụ thể, bạn có thể muốn đảm bảo rằng tài nguyên của bạn có sẵn ở vị trí cụ thể đó.