• Articles
• admin

domyślnie monitorowanie SNMP jest wyłączone w Messaging Server. Wartość ta jest wybierana w celu zminimalizowania liczby usług prezentowanych przez domyślną konfigurację serwera wiadomości. Nie interpretuj tej wartości domyślnej, co oznacza, że korzystanie z monitorowania SNMP wiąże się z karą za wydajność.Rzeczywiście, obsługa SNMP Messaging Server zużywa bardzo mało zasobów i ma mieć minimalny wpływ na serwer wiadomości. Rezultatem tego jest oczywiście konieczność wykonania jednorazowych kroków konfiguracyjnych przed użyciem obsługi SNMP serwera wiadomości. Dodatkowo domyślna konfiguracja Net platformy – SNMP master agent, snmpd, typowo musi zostać zmieniona w celu uruchomienia podagentów, takich jak serwery wiadomości. Ten temat jest tematem następnej sekcji.

A. 3.1 Konfiguracja Net-SNMP

subagent SNMP oparty na Net-SNMP serwera wiadomości używa protokołu AgentX do komunikacji z głównym agentem SNMP platformy (RFC 2741). Agent Net-SNMPmaster, snmpd, musi być skonfigurowany tak, aby zezwalał na użycie protokołu AgentX. Aby to zrobić, upewnij się, że platforma jest snmpd.plik conf zawiera linię

master agentx

jeśli nie ma tej linii, dodaj ją i uruchom ponownie demona snmpd. Zauważ, że wysyłanie sygnału SIGHUP do demona nie jest niewystarczające. Po ponownym uruchomieniu demona snmpd poszukaj gniazda domeny uniksowej, które snmpd tworzy dla AgentXcommunications. W systemach Solaris i Linux gniazdo to domyślnie pojawia się jako specjalny plik / var / agentx / master; jednakże jego lokalizacja i nazwa mogą zostać zmienione poprzez snmpd.confile.

Konfiguracja snmpd Solaris 10 OS jest pokazana poniżej:

%cp /etc/sma/snmp/snmpd.conf /etc/sma/snmp/snmpd.conf.save% cat >> /etc/sma/snmp/snmpd.conf# Messaging Server's subagent requires the AgentX protocolmaster agentx^D% cat >> /etc/sma/snmp/snmpd.conf% ls -al /var/agentx/srwxrwxrwx 1 root root 0 Aug 9 13:58 /var/agentx/master

dodatkowo, na Red Hat Enterprise Linux jako 3 systemy, domyślny snmpd.plik conf ogranicza informacje, które mogą być przeglądane przez „publiczną” społeczność SNMP. W związku z tym konieczne jest usunięcie tego ograniczenia lub rozszerzenie go o MIBs serwowane przez Messaging Server ’ ssubagent. W przypadku testów wstępnych zaleca się wykonanie tego ostatniego. Osiąga się to poprzez włączenie OID podtrees mib-2.27 i mib-2.28 w widoku o nazwie „systemview”, jak pokazano poniżej. W przypadku rzeczywistego wdrożenia każdy obiekt musi wziąć pod uwagę ogólną politykę bezpieczeństwa. Zauważ, że informacje dostarczane przez podagent SNMP są „tylko do odczytu”.

% cp /etc/snmp/snmpd.conf /etc/snmp/snmpd.conf.save% cat >>/etc/snmp/snmpd.conf# Messaging Server's subagent requires the AgentX protocolmaster agentx# Messaging Server's subagent exports mib-2.27 and .28# Add the mib-2.27 and .28 OID subtrees to the systemviewview systemview included .1.3.6.1.2.1.27view systemview included .1.3.6.1.2.1.28^D% /sbin/service snmpd restart% ls -al /var/agentx/mastersrwxr-xr-x 1 root root 0 Aug 8 21:20 /var/agentx/master

jeśli używasz nazw kontekstowych SNMP v3 do rozróżniania siłek różnych instancji Messaging Server działających jednocześnie na tym samym komputerze-hoście, to musisz również skonfigurować co najmniej jedną nazwę Użytkownika i hasło SNMPv3 do użycia z zapytaniami SNMP v3.

A. 3.2 Konfiguracja Subagentu serwera wiadomości

do podstawowej obsługi subagentu SNMP serwera wiadomości należy go tylko uruchomić i wydać jednorazowe polecenie ręcznego uruchamiania. Odtąd, gdy serwer wiadomości zostanie uruchomiony lub zatrzymany, subagent zostanie uruchomiony lub zatrzymany. Polecenia niezbędne do wykonania tej konfiguracji zarówno na Solarisie, jak i Linuksie są następujące:

% configutil -o local.snmp.enable -v 1% start-msg snmp

po uruchomieniu możesz przetestować podagent z wiersza poleceń za pomocą polecenia snmpwalk. Zobacz zrzuty ekranu poniżej przykładowy program Solaris i Linux. Zauważ, że pliki rfc2248.txt i rfc2249.txt to kopie Usług Sieciowych i Mibów MTA. OnSolaris systems, pliki te można również znaleźć w katalogu/etc/SMA/ snmp / MIBs / pod nazwą NETWORK-SERVICES-MIB.txt i MTA-MIB.txt. Nie jest konieczne dostarczanie tych plików do narzędzia snmpwalk, jednak pozwala to na tworzenie nazw toprint snmpwalk dla każdej ze zmiennych MIB, a nie ich numerycznych identyfikatorów obiektów (OID).

podstawowe testy na Solarisie:

% D=/opt/SUNWmsgsr/examples/mibs /usr/sfw/bin/snmpwalk -v 1 -c public \ -m +$D/rfc2248.txt:$D/rfc2249.txt 127.0.0.1 mib-2.27NETWORK-SERVICES-MIB::applName.1 = STRING: /opt/SUNWmsgsr MTA on mail.siroe.com...% D=/opt/SUNWmsgsr/examples/mibs /usr/sfw/bin/snmpwalk -v 1 -c public \ -m +$D/rfc2248.txt:$D/rfc2249.txt 127.0.0.1 mib-2.28MTA-MIB::mtaReceivedMessages.1 = Counter32: 1452MTA-MIB::mtaStoredMessages.1 = Gauge32: 21...

podstawowe testy na Linuksie:

% export D=/opt/sun/messaging/examples/mibs% /usr/bin/snmpwalk -v 1 -c public \ -m +$D/rfc2248.txt:$D/rfc2249.txt 127.0.0.1 mib-2.27NETWORK-SERVICES-MIB::applName.1 = STRING: /opt/sun/messaging MTA on mail.siroe.com...% /usr/bin/snmpwalk -v 1 -c public \ -m +$D/rfc2248.txt:$D/rfc2249.txt 127.0.0.1 mib-2.28MTA-MIB::mtaReceivedMessages.1 = Counter32: 21278MTA-MIB::mtaStoredMessages.1 = Gauge32: 7...

A. 3.3 uruchamianie jako samodzielny Agent SNMP

przed skonfigurowaniem subagentu SNMP serwera wiadomości, aby działał jako samodzielny agent SNMP, musisz najpierw zdecydować, który interfejs Ethernet i port UDP chcesz, aby go nasłuchiwał dla żądań SNMP. Domyślnie nasłuchuje onwszystkie dostępne interfejsy Ethernet przy użyciu portu UDP 161. W większości przypadków będziesz chciał zmienić numer portu, aby nie zakłócać działania głównego agenta ssnmp platformy, snmpd. W pewnych okolicznościach, takich jak przełączanie awaryjne asHA, będziesz również chciał zmienić interfejs Ethernet ze wszystkich dostępnych interfejsów — INADDR_ANY — na określony interfejs identyfikowany przez jego adres IP. Te dwie koncepcje, interfejs Ethernet i port UDP, są kontrolowane przez lokalny.snmp.listenaddr i lokalny.snmp.opcje portów.

po wybraniu interfejsu Ethernet i portu UPD,lokalny.snmp.opcja standalone powinna mieć swój zestaw wartości do jednego i subagent ponownie uruchomiony. Po ponownym uruchomieniu będzie działał agent SNMP Asa niezależny od snmpd i wszelkich podagentów.

na przykład, aby uruchomić jako samodzielny agent nasłuchujący na porcie UDP 9161 interfejsu Ethernet o adresie IP 10.53.1.37, wydaj polecenia pokazane poniżej.

Konfigurowanie do uruchamiania jako samodzielny agent:

% configutil -o local.snmp.port -v 9161% configutil -o local.snmp.listenaddr -v 10.53.1.37% configutil -o local.snmp.standalone -v 1% stop-msg snmp% start-msg snmp% snmpwalk -v 1 -c public 10.53.1.37:9161 .SNMPv2-SMI::mib-2.27.1.1.2.1 = STRING: "/opt/SUNWmsgsr MTA on mail.siroe.com"...

A. 3. 4 monitorowanie wielu wystąpień serwera wiadomości

omówiono dwie techniki monitorowania wielu wystąpień serwera wiadomości na tym samym komputerze-hoście. Pierwsza technika, uruchamiająca subagent w trybie autonomicznym, dobrze nadaje się do konfiguracji o wysokiej dostępności (HA), w których poszczególne instancje MessagingServer mogą dynamicznie przemieszczać się między komputerami hosta. Druga technika, użycie nazw kontekstowych SNMP v3, ma pewne ograniczone korzyści w sytuacjach, gdy wiele instancji serwera wiadomości jest ograniczone do jednego systemu i pożądane jest ograniczenie liczby adresów IP ankietowanych przez oprogramowanie monitorujące SNMP (na przykład, gdy licencjonowanie oprogramowania monitorującego ma składnik kosztowy adresu peryp). Ta ostatnia technika może być również używana w Ha failoversettings, ale wymagałaby odpytywania tak wielu adresów IP, jak technika standalonemode.

A. 3.5 korzystanie z samodzielnych agentów do pracy awaryjnej o wysokiej dostępności

w ustawieniu pracy awaryjnej o wysokiej dostępności, w którym pożądane jest monitorowanie SNMP MessagingServer, zaleca się uruchomienie SNMPsubagent serwera wiadomości jako samodzielnego agenta, jak opisano w A. 3.3, działającego jako samodzielny Agent SNMP. Gdy podagenty są uruchamiane w standalonemode, każda instancja Ha Messaging Server powinna mieć swoją lokalną.snmp.opcja listenaddr ustawiona na wartość IP przełączania awaryjnego tej instancji address.To uprość zarządzanie, każda instancja powinna używać tego samego portu UDP, ale ten port powinien się różnić od tych używanych przez demony snmpd na każdym z fizycznych hostów klastra. Zazwyczaj demony te będą używać portu UDP 161, więc wyraźnie określ inny numer portu z lokalnym.snmp.opcja portu.

gdy obsługa SNMP Messaging Server jest skonfigurowana zgodnie z zaleceniami,stacja monitorująca może monitorować każdą instancję Messaging Server za pomocą swojego adresu IP lub nazwy hosta, niezależnie od tego, na którym fizycznym Hostie klastra instancja jest uruchomiona. Co więcej, masz pewność, że standardowe agenci SNMP serwera wiadomości nie będą ze sobą kolidować, ponieważ każdy nasłuchuje tylko na swoim własnym wirtualnym interfejsie Ethernet identyfikowanym przez unikalny adres IP danej instancji. (Te wirtualne interfejsy Ethernet są automatycznie tworzone przez ha failover framework.) Ze względu na staranny dobór portu aUDP, agenci nie kolidują z demonami snmpd na systemach w klastrze.

A. 3.6 rozróżnianie wielu instancji poprzez nazwy SNMP v3kontekst

chociaż nie ma żadnych wad w używaniu obsługi SNMP Messaging Server w trybie autonomicznym, jak opisano w A. 3.3 działającym jako samodzielny Agent SNMP, uznaje się, że niektóre witryny mogą preferować użycie bardziej tradycyjnego trybu podagentowego, zachowując jednocześnie możliwość monitorowania wielu instancji serwera wiadomości działającego jednocześnie w tym samym systemie.Na przykład system monitorowania SNMP, którego model licencjonowania ogranicza liczbę adresów IP, które mogą być badane. Aby osiągnąć ten cel, Kontynuuj uruchamianie subagentu SNMP serwera wiadomości z lokalnym.snmp.samodzielny ustawiony na zero. Dodatkowo, skonfiguruj każdą instancję Messaging Server tak, aby używała odrębnej nazwy kontekstu SNMP v3, określając wartość niezerową dla lokalnej.snmp.włącz opcję contextname. Jeśli nazwa kontekstu różni się od wartości usługi.jest pożądana defaultdomain, a następnie ustawić żądaną nazwę z lokalnym.snmp.opcja contextname. Po ponownym uruchomieniu każdej instancji subagentis SNMP serwera, mogą one być monitorowane za pomocą zapytań SNMP v3, które zawierają odpowiednie nazwy kontekstowe. MIB dwóch instancji Messaging Server uruchomionych w tym samym systemie wyróżnia się nazwą kontekstową SNMP v3 instancji, a więc nie powstaną konflikty identyfikatora obiektu MIB (OID).

A. 3. 7 Opcje Subagentu SNMP opartego na Net-SNMP serwera wiadomości

poniższe opcje dotyczą tylko subagentu serwera wiadomości opartego na Net-SNMP. Ten podagent jest używany na platformach Solaris z systemem Solaris10 i późniejszych oraz na platformach Linux. Opcje opisane poniżej nie odnoszą się do starszego podagentu SNMP dostarczonego dla platform Solaris z solaris9 i wcześniejszych systemów operacyjnych.

opcje opisane poniżej to configutil options.As takich, ich wartości są sprawdzane za pomocą polecenia formularza:

% configutil -o option-name

gdzie opcja-name jest nazwą opcji, której wartość zostanie wyświetlona. Aby ustawić lub zmienić wartość opcji, Użyj polecenia formularza

% configutil -o option-name -v option-value

gdzie opcja-value jest wartością do Ustawienia.Zmiany w tych opcjach wymagają ponownego uruchomienia:

% stop-msg snmp% start-msg snmp

Poniżej znajduje się opis każdej opcji wraz z jej wartością domyślną.

Table a-1 SNMP Subagent Options

opcja (domyślnie)	opis
lokalne.snmp.włącz(0)	subagent SNMP serwera wiadomości zostanie uruchomiony tylko wtedy, gdy ta opcja będzie miała wartość 1 lub true, w której serwer wiadomości automatycznie zatrzyma się i uruchomi subagent jako część jego normalnych procedur uruchamiania i zamykania. Domyślnie ta opcja jest ustawiona na zero, co wyłącza działanie podagentu. Przed włączeniem subagentu upewnij się, że główny agent platformy został prawidłowo skonfigurowany zgodnie z opisem A. 3.3 działającym jako samodzielny Agent SNMP.
lokalne.snmp.samodzielny(0)	obsługa SNMP serwera wiadomości zwykle działa jako subagent SNMP, odbierając żądania NMP za pośrednictwem głównego agenta SNMP platformy, snmpd.Ten tryb pracy jest domyślny i jest wybierany przez podanie tej opcji wartości 0 lub false. Jednakże, jak opisano w A. 3.3 działa jako samodzielny Agent SNMP, subagent może działać w trybie „samodzielny”, w którym działa jako agent SNMP niezależny od snmpd. Po uruchomieniu w trybie autonomicznym, podagent–nowa agent SNMP — nasłuchuje bezpośrednio żądań SNMP na interfejsie Ethernet i porcie UDP określonym odpowiednio przez lokalny.snmp.listenaddr i lokalny.snmp.opcje portów. Aby uruchomić w tym trybie autonomicznym, określ wartość 1 lub TRUE dla tej opcji. uruchamianie w trybie autonomicznym nie koliduje z innymi podagentami nadrzędnymi SNMP działającymi w systemie.
lokalne.snmp.listenaddr (INADDR_ANY)	Nazwa hosta lub adres IP interfejsu Ethernet do nasłuchiwania zapytań Snmprequest podczas pracy w trybie autonomicznym. Domyślnie słuchane są wszystkie dostępne interfejsy. Odpowiada to określeniu wartości INADDR_ANY.Określony interfejs może być wybrany przez podanie adresu IP lub nazwy hosta powiązanego z tym interfejsem. Interfejs może być fizycznyminterfejsem lub interfejsem wirtualnym. ta opcja jest ignorowana, gdy jest lokalna.snmp.standalone jest ustawione na 0 lub FALSE.
lokalne.snmp.cachettl(30)	czas na żywo (TTL) w sekundach dla buforowanych danych monitorowania. Ta opcja kontroluje, jak długo subagent będzie zgłaszał te same dane monitorujące przed odświeżeniem tych danych nowymi informacjami uzyskanymi z serwera wiadomości.Z wyjątkiem informacji o pętli wiadomości, dane są buforowane domyślnie nie dłużej niż 30 sekund. Informacje o pętli, określone przez skanowanie .Przechowywane pliki są aktualizowane tylko raz na 10 minut. To dlatego, że koszt zasobów skanowania wszystkich kolejek wiadomości na dysku. zauważ, że subagent nie aktualizuje w sposób ciągły swoich danych monitorujących:jest aktualizowany tylko po otrzymaniu żądania SNMP, a buforowane dane zostały wyeksploatowane (to znaczy przetrwały swój TTL). Jeśli TTL jest ustawiony na 30 sekund, a zapytania Snmprequest są wykonywane tylko co pięć minut, to każde żądanie SNMP spowoduje, że podagent uzyska świeże dane z serwera wiadomości. Oznacza to, że dane z serwera wiadomości będą uzyskiwane tylko raz na pięć minut. Jeśli z drugiej strony żądania SNMP są wysyłane co 10 sekund, to subagent odpowie na niektóre z tych żądań z buforowanymi danymi tak starymi jak 29 sekund; MessagingServer będzie odpytywany tylko raz na 30 sekund.
lokalne.snmp.servertimeout(5)	subagent określa status operacyjny każdej monitorowanej usługi faktycznie otwierając połączenia TCP do każdej usługi i przechodząc przez wymianę protokołów. Ta wartość limitu czasu, mierzona w sekundach, określa, jak długo subagent będzie czekał na odpowiedź na każdy krok w wymianie protokołu. Domyślnie używana jest wartość timeout wynosząca pięć sekund.
lokalne.snmp.directoryscan(1)	Użyj tej opcji, aby kontrolować, czy subagent wykonuje skanowanie kolejek wiadomości na dysku .Przechowywane pliki wiadomości i najstarsze pliki wiadomości. Informacje te odpowiadają zmiennym MIB mtaGroupLoopsDetected, mtaGroupOldestMessageStored i mtaGroupOldestMessageId. Jeśli ta opcja ma wartość 1 lub true, wtedy pamięć podręczna tych informacji jest utrzymywana i aktualizowana w razie potrzeby. Sites with thousands of queue messages, which are not interested in these particularMIB variables should consider setting this option ’ s value to 0 or false.
lokalne.snmp.enablecontextname(0)	subagent ma możliwość rejestrowania swoich MIB-ów pod nazwą kontekstu SNMP v3. Gdy to zrobisz, MIBs mogą być żądane tylko przez Klienta SNMP v3, który określa nazwę kontekstu w swoim żądaniu SNMP.Użycie nazw kontekstowych pozwala wielu niezależnym podagentom rejestrować MIB-y NetworkServices i MTA pod tym samym drzewem OID (czyli pod tym samym agentem SNMPmaster). Patrz A. 3. 4 monitorowanie wielu instancji serwera wiadomości w celu uzyskania dalszych informacji. aby włączyć używanie nazw kontekstowych SNMP v3, podaj wartość 1 lub true dla tej opcji. Kiedy to nastąpi, subagent domyślnie użyje wartości usługi.defaultdomain optiondla nazwy kontekstu. Aby użyć innej wartości dla nazwy kontekstu, użyj lokalnej.snmp.opcja contextname.
lokalne.snmp.contextname (serwis.defaultdomain)	kiedy użycie nazw kontekstowych SNMP v3 zostało włączone z lokalnym.snmp.enablecontextname, opcja ta może być użyta do jawnego ustawienia nazwy kontekstu używanej przez podagent dla jego MIBs. Wartości podane dla tej opcji są wartościami stringvalues i muszą być odpowiednie do użycia jako nazwa kontekstu SNMP v3. Ta opcja jest ignorowana, gdy lokalny.snmp.enablecontextname ma wartość 0 lub false.