Jak powinna wyglądać dobra naprawa
Gdy amavisdproces wykorzystuje 100% lub prawie 100% procesora, celem nie jest po prostu jego zniknięcie. Przydatna poprawka powinna przywrócić normalny przepływ poczty, zmniejszyć opóźnienia w przetwarzaniu, utrzymać działanie ochrony antyspamowej i antywirusowej oraz zapobiec dalszemu wzrostowi kolejki Postfix.
W systemie Zimbra Amavisd-New znajduje się pomiędzy MTA a skanerami treści. Aktualny podręcznik administratora Daffodil firmy Zimbra opisuje Amavisd-New jako interfejs między MTA Zimbra, ClamAV i SpamAssassin. Oznacza to, że wzrost obciążenia procesora może pochodzić z samego Amavisa, reguł SpamAssassin lub treści wiadomości, skanowania antywirusowego lub z zaległości, które obciążają wszystkie dostępne procesy. Zobacz Podręcznik administratora Daffodil firmy Zimbra .
Na pomyślny wynik wskazują cztery oznaki: wydajność procesora Amavis spada do stabilnego poziomu, kolejki odroczone i aktywne przestają rosnąć, nowe wiadomości docierają bez nietypowych opóźnień, a usługi antyspamowe/antywirusowe pozostają sprawne. Jeśli wydajność procesora spada tylko z powodu wyłączenia filtrowania, problem nie został rozwiązany.
Krok 1: Sprawdź, czy Amavis jest rzeczywiście konsumentem procesora
Zacznij od poziomu systemu operacyjnego. Nie zakładaj, że Amavis jest odpowiedzialny tylko za powolne dostarczanie poczty. Sprawdź najbardziej obciążone procesy i upewnij się, że jeden lub więcej amavisdprocesów roboczych stale zużywa cały rdzeń procesora.
top -c
ps -eo pid,user,pcpu,pmem,etime,cmd --sort=-pcpu | head -20
Podpis: Widok terminala, w którym amavisd jest głównym konsumentem mocy obliczeniowej procesora. Jest to pierwszy warunek, który należy sprawdzić przed zmianą ustawień Zimbra.
Krótki skok może być normalny podczas skanowania dużej wiadomości lub skompresowanego załącznika. Należy traktować problem jako trwały, gdy ten sam objaw utrzymuje się, a jednocześnie występują opóźnienia w poczcie lub wzrasta głębokość kolejki. Należy również sprawdzić średnie obciążenie, ilość wolnej pamięci, aktywność wymiany i oczekiwanie na wejście/wyjście. Wysokie obciążenie procesora i duża rywalizacja o zasoby wymiany lub pamięci masowej mogą wymagać szerszej analizy na poziomie hosta, a nie zmiany wyłącznie w systemie Amavis.
Krok 2: Sprawdź stan usługi Zimbra przed ponownym uruchomieniem
Przejdź na konto Zimbra i sprawdź stan usługi. Dokumentacja Zimbra zmcontrol statusstandardowo sprawdza włączone usługi.
su - zimbra
zmcontrol status
zmamavisdctl status
Podpis: Stan usługi Zimbra pokazujący działanie komponentów Amavis, antyspamowych, antywirusowych i MTA przed rozpoczęciem rozwiązywania problemów.
Ten krok jest ważny, ponieważ „100% CPU” i „usługa niedostępna” to różne tryby awarii. Jeśli Amavis nie działa, należy zbadać błędy uruchamiania. Jeśli Amavis działa, ale jest przeciążony, należy kontynuować analizę kolejek i logów.
Krok 3: Zmierz kolejkę pocztową, a nie tylko wykorzystanie procesora
Głębokość kolejki informuje, czy wysokie obciążenie procesora wpływa na dostarczanie. Materiały Zimbra dotyczące rozwiązywania problemów z kolejkami zmqstatzawierają informacje o liczbie kolejek, a polecenia Postfix dotyczące kolejek zawierają szczegóły wiadomości. Sprawdzaj regularnie w odstępach kilku minut.
sudo /opt/zimbra/libexec/zmqstat
postqueue -p
Podpis: Statystyki kolejek i odroczonych wiadomości stanowią lepszy miernik wpływu na przepływ poczty niż sam procent wykorzystania procesora.
Szukaj kierunku, a nie pojedynczej liczby. Kolejka, która rośnie przy każdej próbce, oznacza, że przepustowość jest niższa niż wskaźnik napływu. Kolejka, która systematycznie maleje po zmianie, to jeden z najsilniejszych sygnałów, że zmiana faktycznie pomogła.
Jeśli wdrażasz wiele MTA, sprawdź konkretnie węzeł MTA, którego to dotyczy. Nie zakładaj, że kolejka na innym węźle odzwierciedla to samo wąskie gardło.
Krok 4: Użyj dziennika Zimbra, aby zidentyfikować etap spowolnienia
Wiadomości dotyczące rozwiązywania problemów Amavis i SpamAssassin są wysyłane do /var/log/zimbra.log… Przeszukaj czas w okolicach szczytowego obciążenia procesora i porównaj identyfikatory wiadomości, identyfikatory procesów i czas trwania skanowania.
grep -iE 'amavis|spamassassin|clam' /var/log/zimbra.log | tail -n 200
Podpis: Logi Amavis i SpamAssassin mogą ujawnić, czy poszczególne wiadomości lub etapy skanowania trwają nietypowo długo.
Przydatne wzorce obejmują powtarzające się długie skanowanie SpamAssassin, powtarzające się próby dla tych samych identyfikatorów kolejki, błędy komunikacji ClamAV, awarie związane z dekompresją lub niewielki zestaw wiadomości, które wielokrotnie obciążają procesy robocze. Dokumentacja rozwiązywania problemów Zimbra zaleca w szczególności rejestrowanie debugowania Amavis i SpamAssassin, gdy opóźnienia skanowania zakłócają przepływ poczty. Zobacz materiały Zimbra dotyczące rozwiązywania problemów z rejestrowaniem .
Krok 5: Tymczasowo zwiększ częstotliwość rejestrowania Amavis, jeśli normalny rejestr jest niejednoznaczny
Zimbra udostępnia oddzielne mechanizmy kontroli logów dla Amavis i SpamAssassin. Udokumentowany zakres Amavis wynosi od 0 do 5, podczas gdy zimbraAmavisSALogLevelużywany jest 0 lub 1. Zacznij od poziomu 2 Amavis, a nie od maksymalnej szczegółowości, chyba że potrzebujesz bardziej zaawansowanego debugowania.
su - zimbra
zmprov mcf zimbraAmavisLogLevel 2
zmprov mcf zimbraAmavisSALogLevel 1
Podpis: Tymczasowe zmiany w rejestrowaniu ułatwiają korelację czasu skanowania i zachowania SpamAssassin ze skokowym obciążeniem procesora.
Odtwórz problem lub obserwuj go tylko na tyle długo, aby zebrać przydatne dane. Wyższy poziom rejestrowania generuje zapisy na dysku i może zwiększyć poziom szumów na obciążonym serwerze. Po zakończeniu analizy wróć do poprzednich wartości; Zimbra dokumentuje domyślny poziom rejestrowania SpamAssassin jako 0, a Amavis jako normalnie niski.
zmprov mcf zimbraAmavisSALogLevel 0
zmprov mcf zimbraAmavisLogLevel 1
Krok 6: Jeśli SpamAssassin działa wolno, sprawdź i zaktualizuj jego reguły
Jeśli logi stale wskazują na SpamAssassina, sprawdź, czy problem pojawił się po zmianie reguł, wdrożeniu reguł niestandardowych lub nieudanej aktualizacji reguł. Źle zaprojektowane wyrażenia regularne i problematyczne reguły mogą być kosztowne w przypadku niektórych treści wiadomości.
Oficjalny materiał dotyczący rozwiązywania problemów z Amavis firmy Zimbra dokumentuje dołączone polecenie aktualizacji SpamAssassin dla wersji ZCS 8.8 i nowszych w następujący sposób:
su - zimbra
/opt/zimbra/common/bin/sa-update -D
Podpis: Aktualizacja dołączonych reguł SpamAssassin jest wskazana, gdy dzienniki lub błędy uruchamiania wskazują na nieaktualne lub uszkodzone dane reguł.
Nie traktuj tego sa-updatejako uniwersalnego rozwiązania problemu z procesorem. Jeśli skok wystąpił natychmiast po dodaniu reguły niestandardowej, najpierw przetestuj tę regułę. Zimbra przechowuje nowoczesne, niestandardowe reguły SpamAssassin w /opt/zimbra/data/spamassassin/localrules/. Usuń lub wyłącz tylko podejrzaną personalizację w kontrolowanym oknie konserwacji, a następnie porównaj czas skanowania i zachowanie kolejki.
Oficjalna wiki Zimbra również wspomina o ustawieniach automatycznej aktualizacji reguł i kompilacji dla nowszych wersji ZCS. Przed włączeniem automatycznego działania na istniejącym serwerze zapoznaj się ze strategiami antyspamowymi Zimbra .
Krok 7: Uruchom ponownie Amavis dopiero po ustaleniu zmian
Ponowne uruchomienie może usunąć zablokowane serwery robocze i załadować zaktualizowane reguły, ale powinno być zgodne z diagnozą, a nie zastępować je. Najpierw uruchom ponownie tylko Amavis, chyba że dowody wskazują na szerszy stos MTA.
su - zimbra
zmamavisdctl restart
Podpis: Ponowne uruchomienie Amavis powoduje ponowne załadowanie usługi po wprowadzeniu docelowych reguł lub zmianie konfiguracji bez konieczności niepotrzebnego ponownego uruchamiania wszystkich usług Zimbra.
Jeśli procesor natychmiast powróci do 100%, to jest to cenny dowód: przyczyna nadal występuje. Sprawdź logi i sprawdź, czy ten sam komunikat, skaner lub reguła pojawia się ponownie. Wielokrotne ponowne uruchamianie usługi może tymczasowo złagodzić objawy, pozwalając jednocześnie na wzrost kolejki.
Krok 8: Sprawdź odzyskiwanie za pomocą trzech niezależnych kontroli
Nie nazywaj incydentu rozwiązanym po jednorazowym zauważeniu niższego wyniku procesora. Sprawdź jednocześnie obciążenie procesu, kierunek kolejki i stan usługi.
top -c
sudo /opt/zimbra/libexec/zmqstat
zmcontrol status
Podpis: Odzyskiwanie danych jest skuteczniejsze, gdy wykorzystanie procesora, głębokość kolejki i stan usługi Zimbra poprawiają się w tym samym czasie.
Następnie wyślij wiadomość testową przez MTA i sprawdź, czy została dostarczona w normalnym zakresie opóźnień. Aby wiadomość przeszła filtrowanie, sprawdź jej nagłówki pod kątem oczekiwanych pól skanowania antyspamowego i antywirusowego Zimbra/Amavis. Sprawdź nagłówki dokumentów Zimbra, takie jak „ X-Virus-Scannedi”, X-Spam-Statuskiedy te sprawdzenia są aktywne.
Jak zdecydować, co zrobić dalej
| Co obserwujesz | Najlepsza następna akcja | Dlaczego |
| Jedna wiadomość wielokrotnie powoduje długie skanowanie | Poddaj kwarantannie lub bezpiecznie sprawdź tę wiadomość i skoreluj jej identyfikator kolejki z dziennikami | Wąskim gardłem może być konkretna treść, a nie pojemność |
| Czas dominuje w SpamAssassin | Przejrzyj niestandardowe reguły, aktualizacje reguł i debuguj dane wyjściowe | Zestawy reguł zawierające dużo wyrażeń regularnych lub uszkodzone mogą powodować wysokie koszty punktacji |
| Dominują błędy ClamAV lub przekroczenia limitu czasu | Sprawdź stan oprogramowania antywirusowego i stan aktualizacji | Amavis może po prostu czekać na skaner, który wzywa |
| Procesor jest wydajny, ale kolejki utrzymują się w pobliżu zera | Obserwuj dłużej, zanim wprowadzisz zmiany destrukcyjne | Wysokie wykorzystanie może być akceptowalne, jeśli przepustowość i opóźnienie pozostają na odpowiednim poziomie |
| Kolejki rosną nawet po wprowadzeniu ukierunkowanych poprawek | Eskaluj do poziomu pojemności, wzorca wiadomości lub analizy na poziomie wsparcia | Serwer może być zbyt mały, być pod atakiem lub mieć wadę oprogramowania |
Zmiany, których należy unikać w pierwszej kolejności
Nie należy trwale wyłączać skanowania antyspamowego lub antywirusowego tylko po to, by obniżyć obciążenie procesora. Zimbra obsługuje zasady omijania dla określonego ruchu zaufanego/pochodzącego, ale zmienia to model bezpieczeństwa i powinno być przemyślaną decyzją dotyczącą polityki pocztowej, a nie ogólną modyfikacją wydajności. Dokumentacja Zimbry dotycząca omijania SpamAssassin dla ruchu źródłowego jasno wskazuje, że omijanie jest powiązane z zaufanymi sieciami wewnętrznymi.
Unikaj również bezmyślnego zwiększania liczby procesów roboczych Amavis. Więcej procesów roboczych może zwiększyć współbieżność, ale jednocześnie zwiększa obciążenie pamięci i może nasilić rywalizację o procesor. Prawidłowa wartość zależy od składu komunikatów, rozmiaru załącznika, działania skanera, dostępnych rdzeni, pamięci i operacji wejścia/wyjścia. Testuj zmiany pod kątem przepustowości kolejki i opóźnień, zamiast zakładać, że większa pula procesów roboczych jest szybsza.
Ograniczenia tej ścieżki rozwiązywania problemów
Ta procedura została opracowana dla typowego przypadku, w którym Amavis działa, ale jest trwale obciążony procesorem. Nie zastępuje ona wskazówek pomocy technicznej Zimbra dla konkretnej wersji w przypadku potwierdzonej wady produktu, zainfekowanego serwera, ataku typu „odmowa usługi” z powodu błędnie sformatowanych wiadomości lub architektury wielowęzłowej z zewnętrznymi skanerami.
Materiały techniczne społeczności Zimbra udokumentowały historyczne przypadki, w których specjalnie spreparowane wiadomości lub zachowanie SpamAssassina mogły obciążać procesory Amavis przez dłuższy czas. Ponieważ dokładny poziom narażenia zależy od zainstalowanych wersji Zimbra i SpamAssassina, nie stosuj bezmyślnie starej procedury aktualizacji pakietów. Najpierw zarejestruj swoją wersję Zimbra zmcontrol -v, porównaj ją z obsługiwaną wersją i poziomem poprawek, a następnie skorzystaj z aktualnych wskazówek producenta dotyczących aktualizacji.
Ostateczna lista kontrolna weryfikacji
- Procesor Amavis nie jest już stale przypinany podczas normalnego ruchu.
- Kolejki odroczone i aktywne są stabilne lub zmniejszają się wraz z powtarzaniem próbek.
- Nowe wiadomości testowe przechodzą przez MTA w akceptowalnym czasie.
- Usługi Amavis, antyspamowe, antywirusowe i MTA nadal działają.
- Oczekiwane nagłówki skanowania antyspamowego i antywirusowego są nadal obecne, tam gdzie ma to zastosowanie.
- Tymczasowe rejestrowanie debugowania wróciło do normy.
- Każda niestandardowa reguła lub zmiana konfiguracji jest dokumentowana, dzięki czemu można ją przejrzeć po uaktualnieniu.
Oficjalne referencje