Tôi có nên định vị trình đẩy SNMP gần DB hoặc các thiết bị được giám sát không?


7

Với các công cụ thăm dò SNMP, tốt hơn là xác định vị trí của chúng gần DB hơn để đảm bảo lưu lượng truy cập DB có cơ hội tốt hơn để tạo ra nó. Hoặc đặt xe đẩy gần hơn với thiết bị được giám sát, để lưu lượng truy cập chính xác hơn về độ trễ và làm cho thiết bị đến thiết bị?

ví dụ: tôi có 3 vùng và 3 người bỏ phiếu và 1 DB. Tôi có đặt tất cả bốn thiết bị ở một vị trí hoặc phân phối người bỏ phiếu không?

Tôi có một số ý kiến ​​nhưng muốn có được khía cạnh khác của câu chuyện.


Có câu trả lời nào giúp bạn không? nếu vậy, bạn nên chấp nhận câu trả lời để câu hỏi không xuất hiện mãi mãi, tìm kiếm câu trả lời. Ngoài ra, bạn có thể cung cấp và chấp nhận câu trả lời của riêng bạn.
Ron Maupin

Câu trả lời:


5

Điều này có vẻ như tối ưu hóa vô dụng trong mọi trường hợp, điều mà bạn không nên lo lắng cho đến khi vấn đề thực tế thực sự phát sinh, điều này dường như không bao giờ.

Tuy nhiên, về mặt học thuật, bạn nên đặt snmp pug gần thiết bị mà nó đang bỏ phiếu vì nó là giao thức yêu cầu / phản hồi bị ràng buộc bởi RTT. Trình đẩy có thể tổng hợp dữ liệu được thăm dò và sử dụng TCP với các cửa sổ để gửi số lượng lớn dữ liệu nhanh đến DB.


3

FWIW đây là một câu hỏi hay và tôi không thể không đồng ý với @ytti vì điều này có rất nhiều tiềm năng để đi xuống một lý thuyết / học viện thỏ.

Từ góc độ thực tế, đặt những người bỏ phiếu gần các đối tượng được thăm dò là những gì bạn muốn làm. Tôi không phải là chuyên gia hệ thống phân tán / SDE, nhưng tôi tưởng tượng rằng bất kỳ NMS nào được thiết kế để phân phối đều phải có chức năng trong đó để tách các dấu thời gian chèn db khỏi dữ liệu SNMP được thăm dò thực tế và dấu thời gian của chính nó. Đây vẫn không phải là một vấn đề dễ giải quyết, nhưng như ytti đã nói (và tôi đồng ý), việc chèn db không nên ưu tiên hơn dữ liệu được thu thập từ bỏ phiếu. Những người có sự sang trọng được gói trong TCP để bảo vệ tính toàn vẹn dữ liệu tốt hơn. Với các cuộc thăm dò và bẫy SNMP thực tế, bạn có "nỗ lực tốt nhất" lần thứ hai để tranh đấu - số một là UDP rõ ràng và số 2 là quản lý quy trình / "toàn vẹn dữ liệu" (tức là bộ đếm chính xác, v.v.) trên hộp mà bạn đang bỏ phiếu. Đôi khi, một hộp chỉ bắt đầu bị nghẹt và trả về các số thông qua SNMP sẽ bị lạc hậu so với những thứ khác.


snmp đã qua udp và kết nối DB rất có thể sẽ là TCP. Vì vậy, bỏ phiếu gần với nguồn là tốt hơn. Bên cạnh đó, điều gì sẽ xảy ra nếu pug được đặt ở một trang web khác từ các thiết bị đang được thăm dò và mất kết nối. Thu thập cục bộ (trong thời gian thực), cuộn dữ liệu từ xa (gần thời gian thực).
generalnetworkerror

1

Số lượng người bỏ phiếu được sử dụng phải dựa trên số lượng nút đang được thăm dò và tần suất của các cuộc thăm dò. Ngoài ra, một số nhà cung cấp không hỗ trợ pug cách xa DB. Solarwinds có hạn chế này.


1

Gần gũi hơn với các thiết bị được thăm dò cũng có nghĩa là bạn có thể có tần suất bỏ phiếu cao hơn do độ trễ thấp hơn. Tôi thấy rằng khi tôi đang cố gắng thăm dò một thiết bị qua các mạch xuyên Đại Tây Dương của chúng tôi trong khoảng thời gian 5 hoặc 10 giây thì mất quá nhiều thời gian để đi lại các bảng.


Về mặt kỹ thuật bạn có thể thực hiện bỏ phiếu không đồng bộ. Bạn có thể có hai thiết kế quy trình trong đó một quy trình phun ra tỷ lệ dây UDP khác quy trình lưu trữ trả lời. Sau đó, bạn có quy trình thứ ba thực hiện phân tích ngoại tuyến nếu bạn nhận được dữ liệu tại các cửa hàng khoảng thời gian phù hợp, nếu không, hãy tăng cảnh báo và có lý do điều tra.
ytti
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.