Giám sát các ứng dụng C ++

Chúng tôi đang thực hiện một giải pháp giám sát tập trung mới (Zenoss). Việc kết hợp các máy chủ, mạng và các chương trình Java rất đơn giản với SNMP và JMX.

Tuy nhiên, câu hỏi đặt ra là các thực tiễn tốt nhất để giám sát và quản lý các ứng dụng C ++ tùy chỉnh trong các môi trường lớn, không đồng nhất (Solaris x86, RHEL Linux, Windows) là gì?

Khả năng tôi thấy là:

1. Mạng SNMP

• Ưu điểm

1. daemon đơn, trung tâm trên mỗi máy chủ
2. tiêu chuẩn nổi tiếng
3. tích hợp dễ dàng vào các giải pháp giám sát
4. chúng tôi đã chạy Net SNMP daemon trên các máy chủ của mình

1. triển khai phức tạp (MIB, thư viện SNMP Net)
2. công nghệ mới để giới thiệu cho các nhà phát triển C ++

• Ưu điểm

1. daemon đơn, trung tâm trên mỗi máy chủ
2. tiêu chuẩn nổi tiếng
3. tích hợp không xác định vào các giải pháp giám sát (Tôi biết họ có thể thực hiện cảnh báo dựa trên văn bản, nhưng nó sẽ hoạt động tốt như thế nào để gửi từ xa như sử dụng bộ nhớ, độ sâu hàng đợi, dung lượng luồng, v.v.)
4. thực hiện đơn giản

1. vấn đề tích hợp có thể
2. công nghệ hơi mới cho các nhà phát triển C ++
3. vấn đề chuyển có thể xảy ra nếu chúng ta chuyển đổi nhà cung cấp giám sát
4. có lẽ liên quan đến việc đưa ra một giao thức truyền thông đặc biệt (hoặc sử dụng dữ liệu có cấu trúc RFC5424; tôi không biết liệu Zenoss có hỗ trợ điều đó mà không cần mã hóa Zenpack tùy chỉnh không)

• Ưu điểm

1. giao diện quản lý nhất quán cho cả Java và C ++
2. tiêu chuẩn nổi tiếng
3. tích hợp dễ dàng vào các giải pháp giám sát
4. thực hiện hơi đơn giản (chúng tôi đã làm điều này ngày hôm nay cho các mục đích khác)

1. độ phức tạp (JNI, lớp kết nối giữa C ++ và Java bản địa, về cơ bản viết mã quản lý hai lần)
2. vấn đề ổn định có thể
3. yêu cầu JVM trong mỗi quy trình, sử dụng nhiều bộ nhớ hơn
4. JMX là công nghệ mới dành cho nhà phát triển C ++
5. mỗi quy trình có cổng JMX riêng (chúng tôi chạy rất nhiều quy trình trên mỗi máy)

• Ưu điểm

1. daemon đơn, trung tâm trên mỗi máy chủ
2. giao diện quản lý nhất quán cho cả Java và C ++
3. tiêu chuẩn nổi tiếng
4. tích hợp dễ dàng vào các giải pháp giám sát

1. độ phức tạp (về cơ bản viết mã quản lý hai lần)
2. cần tìm hoặc viết một daemon như vậy
3. cần một giao thức giữa daemon JMX và tiến trình C ++
4. JMX là công nghệ mới dành cho nhà phát triển C ++

• Ưu điểm

1. giao diện quản lý nhất quán cho cả Java và C ++
2. tiêu chuẩn nổi tiếng
3. tích hợp dễ dàng vào các giải pháp giám sát
4. daemon đơn, trung tâm trên mỗi máy chủ khi chạy trong chế độ JVM được chia sẻ
5. thực hiện hơi đơn giản (yêu cầu tạo mã)

1. độ phức tạp (tạo mã, yêu cầu GUI và một số vòng điều chỉnh để tạo mã proxy)
2. vấn đề ổn định JNI có thể
3. yêu cầu JVM trong mỗi quy trình, sử dụng nhiều bộ nhớ hơn (trong chế độ nhúng)
4. Không hỗ trợ Solaris x86 (bộ ngắt thỏa thuận)
5. Ngay cả khi nó đã hỗ trợ Solaris x86, vẫn có thể xảy ra sự cố tương thích trình biên dịch (chúng tôi sử dụng kết hợp kỳ lạ giữa STLPort và Forte trên Solaris
6. mỗi quy trình có cổng JMX riêng khi chạy ở chế độ nhúng (chúng tôi chạy rất nhiều quy trình trên mỗi máy)
7. có thể loại trừ một máy chủ JMX được chia sẻ cho các quy trình không phải C ++ (?)

Có một số giải pháp đơn giản, hợp lý hóa mà tôi đang thiếu?

Không có giải pháp hợp lý nào khác, giải pháp nào trong số những giải pháp này thường được sử dụng cho các chương trình C ++ tùy chỉnh?

Tôi cảm thấy ruột thịt là Net SNMP là cách mọi người làm điều này, nhưng tôi thích đầu vào và trải nghiệm của người khác trước khi tôi đưa ra quyết định.

Tôi không quen thuộc lắm với Zenoss nhưng khi tôi thường sử dụng nagios cho loại điều này, chúng tôi sẽ làm cho quá trình c / c ++ lắng nghe trên một ổ cắm và viết một plugin nagios tùy chỉnh để cung cấp thông tin chẩn đoán và trạng thái.

Bước đầu tiên là chọn lib bạn muốn sử dụng để làm cho quá trình của bạn lắng nghe .. Một cái gì đó như Thư viện ổ cắm C ++ sẽ làm điều đó. Không có gì phức tạp ở đó .. chỉ cần làm cho quá trình lắng nghe.

Sau đó, bạn phải xác định phản hồi mà quá trình của bạn sẽ gửi cho một kích thích cụ thể. Điều này thực sự có nghĩa (ít nhất là với nagios) xác định 'dịch vụ' và sau đó gửi quy trình tín hiệu tương ứng với dịch vụ đó. Điều đơn giản nhất bạn có thể làm là tạo ra một 'quy trình ping' chỉ để xem liệu bạn có thể kết nối thành công với quy trình đang chạy hay không. Nếu bạn làm hơn plugin nagios tùy chỉnh thì biết ít nhất quá trình vẫn còn tồn tại.

Có nhiều thứ phức tạp hơn bạn có thể làm nhưng ý tưởng đủ đơn giản. Bạn có thể viết lib nhỏ của riêng mình về quá trình nghe mã được gói gọn trong các đối tượng và kéo nó vào công cụ c ++ tùy chỉnh của bạn theo cách chuẩn hóa bất cứ khi nào bạn xây dựng một (hoặc tất cả) các tệp thực thi của mình

Hiểu biết của tôi là Zenoss thể làm điều này quá .

Có lẽ vì Zenoss là python nên bạn sẽ viết plugin tùy chỉnh cho nó bằng cách sử dụng một cái gì đó như Twisted để kết nối với khả năng thực thi c ++ của bạn.

Tôi không quen thuộc với những sản phẩm này mà bạn đặt tên nhưng đối với windows tôi theo dõi mức tiêu thụ bộ nhớ bằng perfmon, có một số bộ đếm đặc biệt, như lỗi bể bơi không phân trang, sẽ cho bạn biết nếu chương trình của bạn chứa rò rỉ bộ nhớ, chúng có thể rất ít và do đó mất nhiều thời gian thời gian để theo dõi nhưng theo tôi đây là một phương pháp kiểm tra đơn giản.

Trên các cửa sổ, bạn có thể thực hiện rất nhiều bằng cách sử dụng perfmon, thậm chí từ xa Hoặc sử dụng WMI để gắn vào cùng một bộ đếm và thực hiện một số tự động hóa trên nó (trong wmi) để thực hiện các hành động.

Tôi đang xử lý vấn đề này vì gần đây chúng tôi đã trải qua quá trình tương tự như bạn: Chúng tôi đang tìm kiếm một giải pháp nguồn mở nhẹ, không chặn, cho phép phơi bày và theo dõi các số liệu từ xa trong các dịch vụ C / C ++ ( chúng tôi có khoảng ~ 3000).

SNMP đến gần nhất nhưng việc tích hợp vào nguồn và hệ thống giám sát là một điều khó khăn và không phù hợp với các quy trình thời gian thực của chúng tôi.

Cuối cùng, chúng tôi quyết định phát triển một giải pháp mới gọi là CMX sử dụng công nghệ bộ nhớ dùng chung và biến nó thành nguồn mở. Bạn có thể kiểm tra nó ở đây: www.cern.ch/cmx .

Tôi không quá quen thuộc với khía cạnh c ++ nhưng trong Java, chúng tôi sử dụng rộng rãi các số liệu CodaHale kết hợp với Graphite . CodaHale lưu trữ các số liệu trên cơ sở từng trường hợp trong bộ nhớ cục bộ của cá thể sau đó sử dụng một luồng nền để tuôn ra các số liệu cho máy chủ than chì mỗi phút (có thể định cấu hình). Trong than chì, chúng tôi có thể tổng hợp qua các trường hợp cũng như xác định các trường hợp bị lỗi. Nếu bạn không muốn sự phức tạp của việc duy trì một cụm than chì, bạn có thể sử dụng HostedGraphite .

Thiết lập này có nghĩa là không có điểm thất bại nào đối với tổng hợp số liệu hoặc báo cáo vì (tổng hợp dựa trên thời gian xảy ra trên chính các nút và tập hợp báo cáo xảy ra trong cụm than chì phân tán (hoặc than chì được lưu trữ).

Cuối cùng, bạn có thể sử dụng Seyren để cung cấp các cảnh báo trên đầu dữ liệu giám sát.

Nếu bạn đang ở trên Windows, bạn có xu hướng ghi vào nhật ký sự kiện, sau đó sử dụng WMI hoặc quy trình tương tự để đọc các sự kiện. Nếu bạn muốn theo dõi, bạn thêm bộ đếm màn hình hiệu suất vào ứng dụng của mình và để perfmon đọc chúng. Cả hai đều là dịch vụ hệ thống trong Windows.

Trên Linux, rõ ràng nó có xu hướng linh hoạt hơn, nhưng tôi luôn thấy các màn hình kiểu nagios được triển khai, với một ổ cắm tùy chỉnh gửi dữ liệu đến một máy chủ kiểu nagios.

Như đã nói, tôi đã thấy một số nơi sử dụng SMNP và thật lòng mà nói, tôi không thể thấy lý do tại sao bạn không sử dụng nó - đặc biệt nếu bạn đang điều hành một môi trường hoàn toàn không đồng nhất.