Các hệ thống giám sát ứng dụng / máy chủ lưu trữ thông minh, chịu lỗi và phân phối theo địa lý


12

Lời chào hỏi,

Tôi muốn hỏi ý kiến ​​tập thể và quan điểm về các hệ thống giám sát phân tán, bạn sử dụng cái gì và bạn biết cái gì có thể đánh dấu vào hộp của tôi?

Các yêu cầu khá phức tạp;

  • Không có điểm duy nhất của sự thất bại. Có thật không. Tôi chết thật rồi! Cần có khả năng chịu đựng sự cố một nút / nhiều nút, cả 'chủ' và 'công nhân' và bạn có thể cho rằng không có vị trí giám sát nào ("trang web") có nhiều nút trong đó hoặc nằm trên cùng một mạng. Do đó, điều này có thể loại trừ các kỹ thuật HA truyền thống như DRBD hoặc Keepalive.

  • Logic phân tán, tôi muốn triển khai hơn 5 nút trên nhiều mạng, trong nhiều trung tâm dữ liệu và trên nhiều lục địa. Tôi muốn chế độ xem "Mắt chim" của mạng và các ứng dụng của tôi từ góc độ của khách hàng, điểm thưởng cho logic giám sát không bị sa lầy khi bạn có hơn 50 nút hoặc thậm chí hơn 500 nút.

  • Cần có khả năng xử lý số lượng kiểm tra máy chủ / dịch vụ khá hợp lý, la Nagios, đối với số liệu sân bóng giả định 1500-2500 máy chủ và 30 dịch vụ trên mỗi máy chủ. Sẽ thật tuyệt nếu thêm nhiều nút giám sát cho phép bạn mở rộng quy mô tương đối tuyến tính, có lẽ trong 5 năm nữa tôi có thể tìm cách theo dõi 5000 máy chủ và 40 dịch vụ trên mỗi máy chủ! Thêm vào từ ghi chú của tôi ở trên về 'logic phân tán', thật tuyệt khi nói:

    • Trong trường hợp bình thường, các kiểm tra này phải chạy trên $ n hoặc n% các nút giám sát.
    • Nếu phát hiện lỗi, hãy chạy kiểm tra trên $ n hoặc n% nút khác, tương quan kết quả và sau đó sử dụng chúng để quyết định xem các tiêu chí đã được đáp ứng để đưa ra cảnh báo hay chưa.
  • Đồ thị và quản lý các tính năng thân thiện. Chúng tôi cần theo dõi SLA của mình và biết liệu các ứng dụng 'khả dụng cao' của chúng tôi có tăng 24x7 hay không là hữu ích. Lý tưởng nhất là giải pháp đề xuất của bạn nên báo cáo "ngoài luồng" với faff tối thiểu.

  • Phải có một API hoặc hệ thống plugin vững chắc để phát triển kiểm tra bespoke.

  • Cần phải hợp lý về cảnh báo. Tôi không nhất thiết phải biết (qua SMS, lúc 3 giờ sáng!) Rằng một nút giám sát cho rằng bộ định tuyến lõi của tôi bị hỏng. Tôi thực sự muốn biết liệu một tỷ lệ phần trăm xác định trong số họ có đồng ý rằng điều gì đó thú vị đang diễn ra hay không;) Về cơ bản, điều tôi đang nói ở đây là logic "đại biểu", hoặc ứng dụng của sự tỉnh táo vào sự điên rồ phân tán!

Tôi sẵn sàng xem xét cả hai tùy chọn thương mại và nguồn mở, mặc dù tôi muốn tránh xa phần mềm có giá hàng triệu bảng :-) Tôi cũng sẵn sàng chấp nhận có thể không có gì ngoài đó đánh dấu vào tất cả các hộp đó, nhưng Muốn hỏi tập thể mà.

Khi suy nghĩ về các nút giám sát và vị trí của chúng, hãy nhớ rằng hầu hết chúng sẽ là các máy chủ chuyên dụng trên các mạng ISP ngẫu nhiên và do đó phần lớn nằm ngoài tầm kiểm soát của tôi. Các giải pháp dựa trên nguồn cấp dữ liệu BGP và các trò hề mạng phức tạp khác có thể sẽ không phù hợp.

Tôi cũng nên chỉ ra rằng tôi đã đánh giá, triển khai hoặc sử dụng nhiều / tùy chỉnh hầu hết các hương vị nguồn mở trong quá khứ bao gồm Nagios, Zabbix và bạn bè - chúng thực sự không phải là công cụ tồi nhưng chúng hoàn toàn không phù hợp " phân phối "khía cạnh, đặc biệt liên quan đến logic được thảo luận trong câu hỏi của tôi và cảnh báo 'thông minh'.

Rất vui được làm rõ bất kỳ điểm nào được yêu cầu. Chúc mừng các chàng trai và các cô gái :-)


2
Điều đó thực sự kỳ lạ, tôi đã định hỏi một câu hỏi tương tự. Tuần này chúng tôi đã có một số khiếu nại của khách hàng về việc ngừng hoạt động trang web, nhưng chỉ từ một số địa điểm nhất định. Hệ thống cảnh báo của chúng tôi đã không phát hiện ra những vấn đề này. Chúng tôi đã liên hệ với nhà cung cấp của chúng tôi và họ xác nhận rằng một số họ có vấn đề về xương sống. Vì vậy, tôi cũng quan tâm đến một giải pháp. Cảm ơn!
splattne

Và giải pháp cuối cùng là gì?
ewwhite

Câu trả lời:


4

không phải là một câu trả lời thực sự, nhưng một số gợi ý:

  • chắc chắn hãy xem bài trình bày về nagios @ goldman sachs . họ phải đối mặt với các vấn đề bạn đề cập - dự phòng, khả năng mở rộng: hàng ngàn máy chủ, cũng tạo thế hệ cấu hình tự động.

  • tôi đã thiết lập nagios dự phòng nhưng ở quy mô nhỏ hơn nhiều - 80 máy chủ, tổng cộng ~ 1k dịch vụ. một máy chủ chính chuyên dụng, một máy chủ nô lệ kéo cấu hình từ máy chủ đều đặn vài lần một ngày. Cả hai máy chủ đều giám sát các máy giống nhau, chúng có kiểm tra sức khỏe chéo lẫn nhau. tôi đã sử dụng nagios chủ yếu làm khung để gọi kiểm tra cụ thể sản phẩm tùy chỉnh [bó các công việc định kỳ thực thi các tập lệnh thực hiện 'điều khiển luồng nhân tạo', kết quả được ghi vào sql, các trình cắm bổ sung nrpe để kiểm tra các lần thực hiện thành công / thất bại của những người đó trong x phút cuối]. Tất cả đều hoạt động rất độc đáo.

  • logic đại biểu của bạn nghe có vẻ tốt - hơi giống với 'dòng chảy nhân tạo' của tôi - về cơ bản là tiếp tục, tôi tự thực hiện; -]. và có nrpe chỉ cần kiểm tra một số loại cờ [hoặc sql db với dấu thời gian-trạng thái] cách mọi thứ đang hoạt động.

  • có lẽ bạn sẽ muốn xây dựng một số thứ bậc theo tỷ lệ - bạn sẽ có một số nút thu thập tổng quan về các nút khác, hãy xem phần trình bày từ điểm đầu tiên. nagios mặc định cho mỗi lần kiểm tra là quá mức cần thiết với số lượng dịch vụ được giám sát cao hơn.

để trả lời một số câu hỏi:

  • trong trường hợp của tôi, môi trường được theo dõi là thiết lập master-Slave điển hình [sql chính hoặc máy chủ ứng dụng + chế độ chờ nóng], không có master-master.
  • thiết lập của tôi liên quan đến 'yếu tố lọc con người' - nhóm trình giải quyết là 'bản sao lưu' cho thông báo sms. đã có một nhóm các kỹ thuật viên được trả lương vì những lý do khác đã có ca làm việc 24/5, họ đã 'kiểm tra thư của nagios' vì nhiệm vụ bổ sung không đặt quá nhiều tải cho họ. và họ chịu trách nhiệm đảm bảo rằng db-admins / it-ops / app-admins ware thực sự đứng dậy và khắc phục các sự cố; -]
  • Tôi đã nghe nhiều điều hay về zabbix - để cảnh báo và vạch ra xu hướng, nhưng chưa bao giờ sử dụng nó. Đối với tôi, munin thực hiện thủ thuật này, tôi đã hack kiểm tra plugin nagios đơn giản nếu có màu 'bất kỳ màu đỏ' nào trong danh sách máy chủ của munin - chỉ là một kiểm tra bổ sung. bạn cũng có thể đọc các giá trị từ các tệp rrd munin để giảm số lượng truy vấn bạn gửi đến máy được theo dõi.

1
@astinus - tốt cho các cảnh báo hợp lý tôi đã sử dụng tập lệnh thông báo tùy chỉnh. thay vì dựa vào nagios thông báo qua mail / máy nhắn tin, tôi đã lưu tin nhắn đến fifo que và có người tiêu dùng đã gửi tin nhắn dựa trên logic tùy chỉnh [dựa trên lịch trình cuộc gọi khá linh hoạt, v.v.], ngoài ra còn có một số giới hạn tin nhắn được gửi mỗi giờ không nhận được 50 tin nhắn trong thời gian ngắn. Tôi thấy các cách tiếp cận tương tự ở quy mô lớn hơn - nagios chỉ là bộ xương và kịch bản mọi người xung quanh nó và thực sự sử dụng ngày càng ít các tính năng của nó.
pQd

1
Liên quan đến hệ thống phân cấp, những gì tôi có hiện tại là một thiết lập Nagios hoàn toàn "mô-đun" trong đó thư mục etc / của bạn chứa cấu hình 'lõi' được chia sẻ (và giống hệt nhau) trên tất cả các máy chủ và sau đó etc / module / $ NAME (nghĩa là : Mail, Web, Network, DNS) có khả năng di động 100% giữa các máy chủ. Bao gồm với cfg_dir =) Bạn đặt bất kỳ lệnh, plugin cụ thể nào và mọi thứ vào thư mục đó. Việc tạo> 1 máy chủ chạy các kiểm tra đó khá dễ dàng vì bạn chỉ cần sao chép mô-đun vào nhiều hộp Nagios theo yêu cầu, tuy nhiên, một lần nữa, logic cảnh báo gây ra sự cố :-)
nixgeek

1
@ astinus # 2. trong trường hợp của tôi cấu hình sao chép chính-> nô lệ xảy ra cứ sau 6h. nếu chủ nhân chỉ chết [mất điện, v.v.] - nô lệ sẽ cảnh báo mọi người về việc chủ nhân đã chết [kiểm tra chéo giữa các máy chủ]. người ta có thể tưởng tượng kịch bản khác - khi chủ chết vì cấu hình sai. nếu điều đó xảy ra tối đa 5 phút trước khi cấu hình đồng bộ hóa thành nô lệ - sẽ có thông báo. nếu đó là ngay trước khi đồng bộ hóa cấu hình - không may là chúng ta sẽ không có hệ thống giám sát. "Ai sẽ xem người canh gác"? cũng có thể là một nagios rất đơn giản.
pQd

1
@pQd - thú vị, tôi đồng ý rằng việc triển khai logic trong các tập lệnh thông báo tùy chỉnh có lẽ là cách để đi. Tuy nhiên, thật khó để tránh các thông báo trùng lặp từ hơn 2 máy chủ, khi bạn nói 50 máy chủ giám sát và tôi chưa thấy ai (ở nơi công cộng) đưa logic được chia sẻ của họ vào một hệ thống truyền thông điệp 'thông điệp' thích hợp như Rabbit hay Amazon SQS.
nixgeek

1
@ astinus # 3 trong trường hợp của tôi, đó là giải pháp 'Cấp 8' [của mô hình iso osi]: nagios chính đã gửi tin nhắn cho mọi người trong cuộc gọi + thư đến 24/5 'nhóm người giải quyết', trong khi nagios thứ hai chỉ gửi thư ' nhóm giải quyết '. tùy thuộc vào nhóm đó để lọc các bản sao trước khi leo thang;
pQd

1

Những gì bạn đang yêu cầu cho âm thanh rất giống như những gì Shinken đã làm cho Nagios.

Shinken là một Nagios viết lại.

  • Ngôn ngữ hiện đại (Python)
  • Khung lập trình phân tán hiện đại (Pyro)
  • Giám sát cảnh giới (đa thuê nhà), HA, phụ tùng
  • API Livestatus
  • Tương thích plugin Nagios
  • Thực thi NRPE gốc
  • Kinh doanh quan trọng của các đối tượng
  • Các quy tắc kinh doanh có thể được áp dụng cho trạng thái của các đối tượng (quản lý tính khả dụng của cụm hoặc nhóm)
  • Vẽ đồ thị có thể sử dụng PNP4nagios dựa trên Graphite hoặc RRDtool
  • Ổn định và đang được triển khai trong môi trường lớn
  • Các triển khai lớn có thể xem xét ghép nối nó với Splunk để báo cáo hoặc xem xét về Graphite nơi RRDtool không phù hợp.

Đây nên là thực phẩm cho suy nghĩ.

Chúc mừng

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.