Większość problemów z wydajnością SugarAI nie pojawia się nagle. Narastają tygodniami – scheduler przestaje nadążać, integracja zaczyna gubić rekordy, czas ładowania widoku listy rośnie z 2 do 8 sekund. Użytkownicy zgłaszają, że „coś jest wolno”, a administrator zaczyna szukać po omacku.

Monitorowanie rozwiązuje ten problem nie przez naprawianie awarii, ale przez ich przewidywanie. Dowiedz się, gdzie szukać informacji o kondycji systemu, jakie narzędzia są dostępne w zależności od modelu wdrożenia i gdzie najczęściej leżą wąskie gardła.

Zanim przejdziemy do konkretów, warto ustalić jedną rzecz: w zależności od modelu wdrożenia masz dostęp do zupełnie innych warstw systemu.

W Sugar Cloud (SaaS) infrastruktura należy do SugarAI. Nie masz dostępu do serwera, systemu plików ani bazy danych bezpośrednio. Monitorujesz system przez interfejs administratora, Sugar Log Viewer i portal supportowy. SugarAI odpowiada za dostępność i wydajność warstwy infrastrukturalnej zgodnie z SLA – Twoja odpowiedzialność zaczyna się na poziomie konfiguracji aplikacji, procesów i integracji.

W Sugar on-premise (Enterprise, Professional) masz pełen dostęp do serwera, bazy danych, logów systemowych i konfiguracji PHP/Apache/Nginx. To daje znacznie więcej możliwości diagnostycznych – i jednocześnie pełną odpowiedzialność za monitoring.

Poniżej omawiamy oba warianty wspólnie, zaznaczając tam, gdzie różnice są istotne.

Logi to pierwsza linia diagnostyki. Sugar generuje własne logi aplikacyjne niezależnie od modelu wdrożenia, choć dostęp do nich wygląda inaczej.

Główny log aplikacji Sugar znajdziesz w katalogu głównym instalacji:

/var/www/html/sugarcrm/sugarcrm.log

Domyślnie rotacja odbywa się po przekroczeniu określonego rozmiaru (konfigurowalne w Admin > System Settings > Logger Settings). Warto zadbać o automatyczną rotację na poziomie systemu operacyjnego (logrotate), szczególnie gdy Sugar jest obciążony – plik potrafi urosnąć do setek MB w ciągu doby przy włączonym DEBUG.

Poziomy logowania – konfiguracja ma bezpośredni wpływ na wydajność:

• FATAL, ERROR – tylko krytyczne błędy. Odpowiednie dla produkcji.
• WARN – ostrzeżenia, które nie blokują działania, ale sygnalizują problemy.
• INFO – ogólne informacje o przebiegu procesów.
• DEBUG – bardzo szczegółowy zapis każdej operacji. Używaj wyłącznie do diagnozy konkretnego problemu i natychmiast wyłączaj po zakończeniu. Na produkcji tryb DEBUG potrafi sam w sobie degradować wydajność.

Minimalny sensowny poziom dla produkcji to ERROR lub WARN. Jeśli zależy Ci na śledzeniu błędów integracji bez zalewania logów – zostań przy ERROR i włącz WARN selektywnie.

W Sugar Cloud logi aplikacyjne są dostępne przez wbudowany interfejs: Admin > Diagnostic Tool lub bezpośrednio przez Sugar Log Viewer. Masz podgląd logów aplikacji, ale nie logów serwera WWW ani bazy.

Jeśli widzisz powtarzające się błędy, które wymagają głębszej diagnostyki infrastrukturalnej – otwórz zgłoszenie w portalu supportowym SugarAI. Masz tam dostęp do historii błędów i możesz poprosić o logi po stronie serwera.

Niezależnie od wdrożenia, kilka wzorców w logach powinno uruchamiać alert:

• FATAL i ERROR – zawsze warte uwagi, szczególnie jeśli pojawiają się seriami
• Timeout – może dotyczyć połączeń z bazą, zewnętrznymi API lub usługami pocztowymi
• Memory limit – sugeruje nieoptymalne zapytania lub zbyt małe zasoby PHP
• Scheduler + error – scheduler nie wykonał joba, co może oznaczać zablokowany proces
• curl_error/connection refused – problemy z integracjami zewnętrznymi

W on-premise możesz skierować logi do centralnego systemu (ELK Stack, Graylog, Loki) i ustawić alerty na wzorce. To szczególnie wartościowe, gdy obsługujesz kilka środowisk Sugar równolegle.

Schedulery to jeden z najczęściej pomijanych elementów monitorowania. Działają w tle, nie blokują użytkowników bezpośrednio – więc problemy narastają niezauważone.

Sugar używa wbudowanego mechanizmu schedulerów (Admin > Schedulers), który bazuje na cronie systemowym (on-premise) lub odpowiednim procesie w tle (cloud). Lista domyślnych jobów obejmuje m.in.:

• wysyłkę e-maili z kolejki (Process Outbound Emails)
• synchronizację z zewnętrznymi kalendarzami
• odświeżanie raportów i dashboardów
• wykonywanie reguł przepływów procesów (Sugar BPM/AWF)
• czyszczenie rekordów tymczasowych i logów

W interfejsie administratora (Admin > Schedulers) każdy job ma informacje o ostatnim uruchomieniu i statusie. Jeśli job od kilku godzin lub dni nie był uruchamiany – to sygnał do sprawdzenia.

Na on-premise sprawdź najpierw, czy cron działa w ogóle:

crontab -l -u www-data

Powinien tam być wpis uruchamiający cron.php co minutę. Brak wpisu lub błędna ścieżka to najczęstsza przyczyna nieruchomych schedulerów po migracji serwera.

Sprawdź też, czy poprzednie uruchomienie joba nie zablokowało kolejnego – Sugar blokuje ponowne uruchomienie joba, jeśli poprzedni nadal jest aktywny (lock mechanism). Zdarza się to przy długich importach lub zapytaniach bez limitu czasowego.

Masowa wysyłka e-maili w Sugar trafia do kolejki EmailQueue, skąd jest przetwarzana przez scheduler. Jeśli e-maile nie wychodzą, sprawdź:

1. Czy scheduler Process Outbound Emails jest aktywny i był niedawno uruchomiony
2. Konfigurację serwera SMTP (Admin > Email Settings) – błędy uwierzytelnienia są logowane, ale nie zawsze widoczne dla użytkownika
3. Limity wysyłki po stronie dostawcy SMTP (szczególnie przy dużych kampaniach)
4. Rozmiar kolejki – duże zaległości mogą oznaczać, że scheduler przetwarza wolniej niż napływają wiadomości

Zablokowane lub nieskończone przepływy procesów potrafią znacząco obciążyć bazę danych. W Admin > Process Audit (Sugar BPM) lub Admin > AOW_WorkFlow (starszy moduł) możesz podejrzeć status uruchomionych procesów. Procesy w stanie In Progress od dłuższego czasu zwykle wskazują na błąd warunkowy lub nieskończoną pętlę w logice przepływu.

Integracje to obszar, gdzie wąskie gardła są najtrudniejsze do zlokalizowania, bo problem może leżeć po stronie Sugar, po stronie zewnętrznego systemu lub gdzieś pomiędzy.

Sugar udostępnia REST API (v8 oparte na JSON API, starsze v10), przez które działają prawie wszystkie nowoczesne integracje. Co warto monitorować:

Czas odpowiedzi – prawidłowe requesty API powinny odpowiadać w czasie poniżej 500ms dla prostych operacji. Wzrost powyżej 2-3 sekund sygnalizuje problem (przeciążona baza, brakujące indeksy, zbyt złożone zapytanie).

Kody odpowiedzi – seria błędów 401 Unauthorized może oznaczać problem z odświeżaniem tokenów OAuth. Błędy 500 Internal Server Error są logowane po stronie Sugar i warte natychmiastowego sprawdzenia. Błędy 429 Too Many Requests pojawiają się w Sugar Cloud, gdy przekraczasz limity API.

Logi po stronie Sugar – każde żądanie API, które kończy się błędem, trafia do sugarcrm.log. W on-premise możesz włączyć logowanie wszystkich requestów API tymczasowo, żeby zdiagnozować problem z konkretną integracją.

Typowy stos integracyjny w średniej firmie to Sugar połączony z systemem ERP, narzędziem marketing automation (np. Mautic) i helpdeskiem. Kilka zasad, które ułatwiają monitoring:

Loguj po obu stronach. Jeśli rekord nie trafił z ERP do Sugar, nie zakładaj od razu, że wina leży po stronie Sugar. Sprawdź logi systemu źródłowego – może request nigdy nie wyszedł.

Testuj w obie strony. Wiele integracji działa jednostronnie (push z ERP do CRM) – sprawdź, czy system źródłowy otrzymuje potwierdzenie sukcesu.

Monitoruj middleware osobno. Jeśli korzystasz z warstwy pośredniej (iPaaS, własny serwis synchronizacyjny), jej kondycja bezpośrednio wpływa na Sugar. Błędy, które wyglądają jak problem Sugar, często są błędami middleware.

Webhooks w Sugar (moduł Webhooks lub niestandardowe) są podatne na specyficzny typ problemu: niepowodzenie dostarczenia nie powoduje żadnego błędu widocznego dla użytkownika.

Jeśli zewnętrzny endpoint jest niedostępny lub zwraca błąd, Sugar może nie ponowić próby (zależnie od konfiguracji). Efekt: dane przestają płynąć bez jakiegokolwiek alarmu.

Dobre praktyki:

• Upewnij się, że endpoint docelowy loguje przychodzące requesty i błędy
• Skonfiguruj monitoring dostępności endpointu po stronie odbiorcy
• W on-premise sprawdź logi aplikacji pod kątem błędów curl związanych z webhookami

Poniżej zebraliśmy typowe sygnały z praktyki i odpowiadające im miejsca diagnostyki.

Wolne ładowanie widoków listy (powyżej 3-5 sekund). Pierwsza przyczyna do sprawdzenia: zapytania SQL bez indeksów na kolumnach filtrowania i sortowania. W on-premise włącz slow query log w MySQL/MariaDB (próg 1-2 sekundy) i obserwuj przez dobę. Najczęstsze winowajce to niestandardowe pola dodane do layoutów i filtrów bez odpowiednich indeksów w bazie.

Schedulery nie uruchamiają się. Ścieżka diagnostyczna: sprawdź crontab (on-premise) → sprawdź ostatnie uruchomienie w Admin > Schedulers → sprawdź log pod kątem błędów scheduler → sprawdź, czy poprzedni run nie blokuje nowego (tabela job_queue).

E-maile nie wychodzą. Ścieżka diagnostyczna: Admin > Email Settings → test połączenia SMTP → Admin > Schedulers (status Process Outbound Emails) → rozmiar kolejki w tabeli email_queue → logi pod kątem błędów SMTP.

Integracja „zawiesza się” lub gubi rekordy. Ścieżka diagnostyczna: logi Sugar pod kątem timeoutów i błędów API → logi systemu zewnętrznego → sprawdź, czy middleware (jeśli jest) działa poprawnie → sprawdź limity API (szczególnie w cloud).

Wzrost obciążenia bazy danych bez wyraźnej przyczyny. Typowe źródła: przepływ procesów w nieskończonej pętli, raport z zapytaniem bez limitów uruchamiany cyklicznie, import masowy bez ograniczenia wątków, niezoptymalizowane zapytanie w niestandardowym module. W on-premise: SHOW PROCESSLIST w MySQL pokaże aktualnie wykonywane zapytania.

Błędy po aktualizacji Sugar. Zaraz po aktualizacji sprawdź log pod kątem błędów PHP (deprecated functions, niezgodności). Uruchom Repair > Quick Repair and Rebuild. Sprawdź niestandardowe moduły i integracje – zmiany w API między wersjami mogą je zepsuć.

Kilka rzeczy, które warto ustawić raz i zapomnieć – a które ratują od szukania w ciemno:

Poziom logowania na WARN lub ERROR na produkcji. DEBUG jest do diagnozy, nie do ciągłej pracy.

Alert na błędy FATAL i ERROR w logach. W on-premise: prosty skrypt lub integracja z systemem monitoringu (Nagios, Zabbix, Grafana). W cloud: regularne przeglądanie Log Viewer lub otwarte zgłoszenie supportowe przy powtarzających się błędach.

Monitoring schedulerów. Raz w tygodniu (lub automatycznie) sprawdź, że kluczowe joby były uruchamiane zgodnie z harmonogramem. EmailQueue i BPM to priorytety.

Slow query log na on-premise. Próg 2 sekundy, przegląd raz w miesiącu lub po zauważeniu spowolnień. Oszczędza godziny szukania przyczyny.

Weryfikacja integracji po każdej aktualizacji Sugar. Nawet minor release może zmienić zachowanie API. Automatyczny test wysyłający i odbierający rekord przez API to minimum.

Monitorowanie SugarAI nie wymaga rozbudowanej infrastruktury – wymaga wiedzy, gdzie patrzeć. Logi aplikacyjne, stan schedulerów i kondycja kolejki e-mail to minimum, które powinno być pod stałą obserwacją. Integracje i wydajność bazy danych wymagają głębszej diagnostyki, ale tylko wtedy, gdy pojawiają się sygnały.

Różnica między cloud a on-premise jest tu realna: w on-premise masz więcej narzędzi i więcej swobody, ale też pełną odpowiedzialność za infrastrukturę. W cloud Twoja uwaga skupia się na warstwie aplikacyjnej i procesowej.

W obu przypadkach reaktywne podejście – „sprawdzam, gdy coś się zepsuje” – kosztuje więcej niż regularne przeglądy. Kilka godzin miesięcznie na analizę logów i stanu schedulerów potrafi zapobiec dniom przestoju.

Jeśli zainteresował Cię ten temat, skontaktuj się z nami. Chętnie odpowiemy na Twoje pytania.