Monitorowanie logów i błędów w TYPO3: narzędzia, alerty i szybkie reagowanie

Rola monitorowania logów i błędów w dużych wdrożeniach TYPO3

Dlaczego „debugowanie na żywo” zabija projekty korporacyjne

Przy małych stronach na TYPO3 wielu developerów radzi sobie, włączając chwilowo wyświetlanie błędów PHP, sprawdzając coś szybko w przeglądarce i poprawiając kod „na oko”. Przy pojedynczej instalacji, kilku edytorach i niewielkim ruchu taki styl pracy bywa tolerowany, choć już wtedy jest ryzykowny. W momencie, gdy w grę wchodzi portal korporacyjny, kilka środowisk (dev, test, stage, prod), dziesiątki edytorów i zewnętrzne integracje – takie podejście prowadzi wprost do incydentów, których źródła nie da się później odtworzyć.

„Debugowanie na żywo” jest problematyczne z kilku powodów. Po pierwsze, wpływa bezpośrednio na użytkowników – komunikaty o błędach, ostrzeżenia PHP czy ślady stosu na froncie to gotowa recepta na wyciek informacji o środowisku, ścieżkach na serwerze i strukturze aplikacji. Po drugie, logika działania systemu w czasie incydentu zwykle jest bardziej złożona, niż to się początkowo wydaje. To, że błąd udało się odtworzyć raz w przeglądarce, nie oznacza, że rozumiany jest pełny kontekst (użytkownik, sesja, obciążenie, cache, scheduler). Bez rzetelnych logów to głównie zgadywanie.

W dużych wdrożeniach TYPO3 nie da się też „na szybko” przeklikać wszystkich ścieżek biznesowych po wdrożeniu zmiany. Nawet jeśli developer na devie ma wszystko pod kontrolą, na produkcji pojawiają się inne konfiguracje, inne pluginy, inna ilość danych i użytkowników. Logi są wtedy jedynym sposobem, aby zobaczyć, jak system faktycznie zachowuje się pod obciążeniem i przy użyciu rzadziej używanych funkcji.

Trzeci aspekt to compliance i odpowiedzialność. W organizacjach regulowanych (finanse, administracja publiczna, medycyna) nie ma dyskusji: zmiany, błędy i dostęp do danych muszą być logowane i możliwe do zbadania po fakcie. „Debugowanie na produkcji” bez spójnego systemu logów oznacza brak śladu audytowego. Przy incydencie bezpieczeństwa albo poważnej awarii trudno wtedy udowodnić, co naprawdę się wydarzyło i czy procedury zostały dochowane.

Logi jako jedyne stabilne źródło prawdy po incydencie

Po poważnym incydencie każdy z członków zespołu ma swoją narrację: „to na pewno serwer bazy danych”, „to był timeout API partnera”, „to nowa wersja rozszerzenia”. Bez logów te hipotezy są tylko przypuszczeniami, najczęściej skażonymi efektem świeżości („dzień wcześniej deployowaliśmy X, więc X jest winny”) i błędną korelacją („spadek ruchu nastąpił po restartcie, więc restart coś popsuł”).

Spójnie prowadzone logi w TYPO3 – od poziomu PHP i serwera WWW, przez logging framework, po zewnętrzne narzędzia – dostarczają twardych danych. Można sprawdzić:

• o której godzinie zaczęły pojawiać się błędy i z jaką częstotliwością,
• z których endpointów (URL) pochodziły,
• na których hostach / instancjach w farmie serwerów,
• dla jakich użytkowników backendu i jakie akcje wywołały problem,
• jakie były równolegle błędy w schedulerze, bazie danych czy w zewnętrznych API.

Taka rekonstrukcja zdarzeń jest możliwa tylko wtedy, gdy logowanie jest przemyślane, ustandaryzowane i konsekwentnie wdrożone. Chaotyczne wpisy, logowanie „od czasu do czasu” albo rozproszone logi z różnym formatem z wielu maszyn bez centralizacji szybko zamieniają się w śmietnik informacji. Monitoring logów ma sens wyłącznie wtedy, gdy traktuje się je jak źródło prawdy, a nie „opcjonalny dodatek”.

Monitorowanie reaktywne a proaktywne: dwie zupełnie różne strategie

W praktyce zespoły utrzymaniowe przechodzą zwykle trzy etapy dojrzałości. Na pierwszym logi służą jedynie do reagowania po zgłoszeniu użytkownika („nie działa mi formularz kontaktowy”, „nie mogę się zalogować do backendu”). To model reaktywny: ktoś zgłasza problem, zespół zaczyna przekopywać logi z wybranego zakresu czasu i stara się odtworzyć incydent.

Na kolejnym poziomie pojawia się proaktywne monitorowanie symptomów. Zespół definiuje wskaźniki, których przekroczenie uruchamia alerty: gwałtowny wzrost liczby błędów 500, skok liczby wyjątków w schedulerze, brak ruchu w logach frontendu przez określony czas, nagłe zwiększenie liczby 404 w wybranej sekcji serwisu. Tutaj logi przestają być wyłącznie archiwum zdarzeń, a zaczynają pełnić funkcję czujników ostrzegawczych.

Trzeci etap to połączenie logów z metrykami wydajności (czas odpowiedzi, obciążenie CPU, limity pamięci, liczba otwartych połączeń do bazy) i z procesami operacyjnymi (incident management, on-call, runbooki). W tym wariancie zdarzenia z logów są elementem większego systemu obserwowalności. Nie każdy projekt musi do tego poziomu dojść, ale już samo przejście z trybu „reaktywny tylko po zgłoszeniu” na „proaktywny z alertami” radykalnie poprawia dostępność portalu.

Gaszenie pożarów kontra usuwanie przyczyn źródłowych

Bez porządnego monitoringu logów zespół utrzymaniowy funkcjonuje w trybie permanentnego gaszenia pożarów. Pojawia się problem – szybka łatka, wyłączenie problematycznego pluginu, restart serwera, wyczyszczenie cache. Problem na chwilę znika, ale nikt nie jest w stanie stwierdzić, co go dokładnie wywołało. Po kilku tygodniach podobny incydent pojawia się w innej części systemu, w nieco zmienionej formie, i cykl zaczyna się od nowa.

Przykładowo: w TYPO3 zaczynają co jakiś czas pojawiać się błędy 500 na losowych podstronach. Restart PHP-FPM „pomaga”, więc administratorzy przyjmują, że to „chwilowe problemy z PHP”. Dopiero analiza logów aplikacyjnych i serwerowych pokazuje, że w czasie błędów na jednej z instancji kończy się pamięć wskutek błędnie zaimplementowanego zapytania do zewnętrznego API (brak paginacji, zbyt duży payload). Bez wglądu w logi błąd może być przypisywany infrastrukturze, a jego prawdziwa przyczyna nigdy nie zostanie usunięta.

Monitoring logów daje narzędzia do klasycznej analizy przyczyny źródłowej (root cause analysis). Można prześledzić łańcuch wydarzeń, zidentyfikować wzorce (np. błędy zawsze występują po automatycznym imporcie danych) i wprowadzić trwałe rozwiązania (limitowanie, retry, lepsze logowanie). Zespół przestaje reagować tylko na objawy, a zaczyna usuwać źródła problemów.

Przegląd mechanizmów logowania w TYPO3: co faktycznie istnieje i po co

TYPO3 Logging Framework – podstawowa architektura

Nowoczesne wersje TYPO3 oferują wbudowany Logging Framework, który zastąpił wiele starszych, rozproszonych mechanizmów. Jego trzy kluczowe elementy to:

• logger – obiekt, który przyjmuje komunikaty logów w kodzie (np. $this->logger->error('Problem z API', ['endpoint' => $url]););
• writer – komponent odpowiedzialny za fizyczne zapisanie logu (do pliku, bazy, syslog, narzędzia zewnętrznego);
• processor – element modyfikujący / rozszerzający dane logu przed zapisem (dodanie request ID, user ID, anonimizacja).

Całość działa w oparciu o kanały logowania (channels) i poziomy logów (DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, EMERGENCY). Kanał to logiczne źródło, np. TYPO3.CMS.Frontend albo MyVendor.MyExtension. Dzięki temu można niezależnie konfigurować, gdzie i jak logowane są komunikaty z różnych części systemu. To kluczowy mechanizm w większych projektach – zamiast monolitycznego logu „ze wszystkiego” da się rozdzielić dane na sensowne strumienie.

Poziomy logowania pozwalają decydować, co trafia do którego writera. Przykładowo, na produkcji DEBUG może być całkowicie ignorowany, INFO zapisywany tylko lokalnie, a WARNING+ wysyłany do centralnego systemu logów. Takie granularne podejście jest jedynym rozsądnym rozwiązaniem w środowiskach, gdzie logów generują się tysiące lub setki tysięcy na godzinę.

System Log (sys_log) a DevLog – dwie różne funkcje

W środowisku TYPO3 do dziś pojawia się sporo mitów wokół System Log i DevLog. System Log to głównie tabela sys_log w bazie danych, przez lata wykorzystywana do rejestrowania działań w backendzie: logowania użytkowników, edycji rekordów, publikacji treści, błędów w module backendowym. To nadal ważne źródło informacji dla administratorów, ale nie jest pełnoprawnym systemem logowania całej aplikacji.

DevLog to z kolei historyczny mechanizm przeznaczony stricte dla developerów do debugowania w fazie rozwoju. Starsze rozszerzenia potrafią nadal z niego korzystać, ale obecnie preferowaną drogą jest przejście na Logging Framework. Utrzymywanie osobno DevLog i osobno nowego systemu prowadzi do rozproszenia informacji i niepotrzebnych komplikacji. W projektach, w których utrzymanie jest istotne, opłaca się zainwestować czas w migrację kodu na nowe API logowania.

Próba używania DevLog w środowisku produkcyjnym to jeden z typowych błędów. Zwykle kończy się to niekontrolowanym rośnięciem tabel, brakiem sensownej rotacji logów i trudnością w centralizacji. Co gorsza, wiele wpisów DevLog ma mało uporządkowaną strukturę, bo były pisane z myślą o jednorazowej diagnostyce podczas developmentu. W projektach firmowych, gdzie liczy się spójność i skalowalność, dużo rozsądniej jest trzymać się jednego, konsekwentnie wdrożonego frameworka.

Logi PHP, logi serwera HTTP, logi bazy danych – jak to się zazębia z TYPO3

TYPO3 żyje w ekosystemie innych komponentów: PHP, serwera HTTP (Apache, Nginx), bazy danych (MySQL/MariaDB, PostgreSQL), cache (Redis, Memcached) czy reverse proxy (Varnish). Każdy z tych elementów posiada własny mechanizm logowania, który częściowo nachodzi na to, co loguje sam CMS.

W uproszczeniu:

• logi PHP rejestrują błędy na poziomie interpretera – od fatal errorów i wyjątków nieprzechwyconych, po ostrzeżenia typu deprecated (w zależności od error_reporting);
• logi serwera HTTP (Apache/Nginx) obejmują access log (każdy request, kod odpowiedzi, czas) oraz error log (problemy przy obsłudze żądania – czasem także błędy PHP, jeśli tak skonfigurowano);
• logi bazy danych dokumentują błędy połączeń, zapytania przekraczające próg czasu, ewentualne błędy składniowe lub problemy z blokadami.

W dobrze skonfigurowanym środowisku te trzy warstwy uzupełniają logi TYPO3. Przykład: użytkownik widzi błąd 500 na stronie. W TYPO3 Logging Framework zapisany jest wyjątek z informacją o kontrolerze i akcji. W logach PHP widać dokładny stack trace i potencjalne ostrzeżenia poprzedzające błąd. W access logu serwera HTTP znajdzie się czas odpowiedzi i nagłówki, a w logu bazy – informacja o długotrwałym zapytaniu tuż przed błędem. Złączenie tych danych daje pełny obraz sytuacji.

W korporacyjnych wdrożeniach sensowne jest przechwytywanie logów ze wszystkich tych źródeł do jednego centralnego systemu (ELK, Graylog, SIEM). Wówczas logi TYPO3 nie żyją w oderwaniu, tylko są jednym z wielu strumieni, które można analizować wspólnie.

Przestarzałe rozszerzenia logujące i dlaczego lepiej ich unikać

Ekosystem TYPO3 jest bogaty, ale nie każdy moduł, który kiedyś pomagał debugować projekty, nadaje się dziś do dużych instalacji firmowych. Rozszerzenia opracowane wiele lat temu często:

• piszą logi bezpośrednio do własnych tabel w bazie, bez rotacji i ograniczeń,
• nie wspierają współczesnego Logging Framework i PSR-3,
• nie mają żadnych mechanizmów anonimizacji danych osobowych,
• nie działają poprawnie w środowiskach wieloserwerowych i kontenerowych.

Typowy scenariusz: stare rozszerzenie loguje każdy request i stan sesji do własnej tabeli. Przy niskim ruchu testowym wszystko wygląda w porządku. Po uruchomieniu portalu dla tysięcy użytkowników tabela rośnie w niekontrolowany sposób, spowalnia backupy, wydłuża czas replikacji, a w skrajnym przypadku potrafi doprowadzić do wyczerpania przestrzeni dyskowej. Z perspektywy działu utrzymania to klasyczna bomba z opóźnionym zapłonem.

W projektach, w których liczy się przewidywalność i bezpieczeństwo, lepiej trzymać się mechanizmów wbudowanych w TYPO3 oraz sprawdzonych integracji z narzędziami zewnętrznymi. Każde rozszerzenie dodające własny, „magiczny” sposób logowania powinno być traktowane z dużą rezerwą, chyba że jest aktywnie rozwijane i jasno integruje się z TYPO3 Logging Framework.

Gdzie trafiają logi domyślnie i co to znaczy dla wydajności oraz RODO

Domyślna konfiguracja TYPO3 zapisuje logi przede wszystkim do plików (w katalogu var/log lub typo3temp/var/log w zależności od wersji) oraz do tabel bazodanowych (np. sys_log). W mniejszych środowiskach to bywa wystarczające, ale w projektach firmowych warto świadomie zarządzić tym obszarem.

Po pierwsze trzeba zdecydować, co faktycznie ma trafiać do plików lokalnych, a co do zewnętrznego systemu logowania. Trzymanie wszystkich poziomów logów (zwłaszcza DEBUG) w plikach na produkcji prowadzi zwykle do szybkiego zapychania dysków, a przy intensywnym ruchu także do zauważalnego narzutu I/O. Rozsądny schemat to ograniczenie się lokalnie do WARNING+ i krótkiego okresu retencji, a szczegółowe dane techniczne trzymać centralnie, gdzie istnieją lepsze narzędzia do filtrowania i rotacji.

Druga kwestia to zawartość samych wpisów. Logowanie pełnych payloadów requestów, ciasteczek sesyjnych, tokenów OAuth czy danych osobowych użytkowników wprost do plików aplikacji jest prostą drogą do problemów przy audytach bezpieczeństwa i RODO. Zamiast tego lepiej logować identyfikatory techniczne (request ID, ID użytkownika z backendu, klucz rekordu), a dane wrażliwe maskować lub anonimizować już na poziomie processorów Logging Framework. Jeśli ktoś musi odtworzyć konkretne zdarzenie, po identyfikatorach zwykle da się sięgnąć do systemu źródłowego, bez kopiowania kompletu danych do logów.

Kolejny aspekt to dostęp do logów. Pliki na serwerach aplikacyjnych bywają współdzielone między administratorów, devopsów, czasem zewnętrzny serwis wsparcia. Każda taka grupa to dodatkowe ryzyko wycieku, jeśli w logach przypadkowo znalazły się dane klientów. Centralne systemy logowania pozwalają na bardziej granularne uprawnienia, audyt dostępu i szyfrowanie w spoczynku. Jeżeli z jakiegoś powodu trzeba zostać przy logach plikowych, wskazane jest chociaż ograniczenie praw dostępu i regularne sprawdzanie, czy logi nie zawierają pól, które w ogóle nie powinny się tam znaleźć.

Na końcu i tak sprowadza się to do kilku świadomych decyzji: jaki poziom szczegółowości jest niezbędny operacyjnie, jaki okres przechowywania akceptuje biznes i dział prawny, oraz które źródła logów trzeba scentralizować, żeby zespół utrzymaniowy był w stanie zareagować na incydent w rozsądnym czasie. TYPO3 daje wystarczająco elastyczne mechanizmy, żeby te decyzje przełożyć na konkretną konfigurację – reszta zależy już od dyscypliny zespołu i regularnego przeglądu tego, co faktycznie ląduje w logach.

Podstawowa konfiguracja TYPO3 Logging Framework w środowisku firmowym

W małych instalacjach często wystarcza domyślna konfiguracja logowania. W większych projektach korporacyjnych potrzebny jest spójny schemat, który da się odtworzyć na każdym środowisku i łatwo migrować między serwerami. Konfiguracja Logging Framework powinna być przede wszystkim deterministyczna: ten sam kod + te same AdditionalConfiguration.php/settings.php dają ten sam efekt bez ręcznego „dokręcania” w backendzie.

Centralizacja konfiguracji: pliki zamiast „klikania”

TYPO3 pozwala częściowo sterować logowaniem przez panel Install Tool, ale w dużych zespołach szybciej wychodzą na jaw wady takiego podejścia: różne ustawienia na stagingu i produkcji, brak historii zmian, „poprawki” w nocy niewidoczne w repozytorium. Rozsądniejszy sposób to trzymać konfigurację logowania w:

• config/system/settings.php – od TYPO3 v9 wzwyż,
• lub w AdditionalConfiguration.php, jeśli projekt ma bardziej złożoną logikę zależną od środowiska.

Przykładowa, minimalna konfiguracja logowania do plików z rotacją na produkcji może wyglądać tak:

$GLOBALS['TYPO3_CONF_VARS']['LOG'] = [
    'writerConfiguration' => [
        TYPO3CMSCoreLogLogLevel::WARNING => [
            TYPO3CMSCoreLogWriterFileWriter::class => [
                'logFile' => TYPO3CMSCoreCoreEnvironment::getVarPath()
                    . '/log/typo3-warning.log'
            ],
        ],
        TYPO3CMSCoreLogLogLevel::ERROR => [
            TYPO3CMSCoreLogWriterFileWriter::class => [
                'logFile' => TYPO3CMSCoreCoreEnvironment::getVarPath()
                    . '/log/typo3-error.log'
            ],
        ],
    ],
];

Taki zapis wymusza, że każde środowisko z tym samym kodem loguje w ten sam sposób, a zmiana polityki (np. włączenie osobnego writera na ALERT/EMERGENCY) przechodzi razem z releasem.

Hierarchia loggerów: nie wszystko do jednego worka

TYPO3 używa przestrzeni nazw loggerów odpowiadających klasom PHP. Zamiast jednego globalnego „kanału” logowania, każdy komponent może mieć własny logger, wywiedziony z nazwy klasy lub przestrzeni nazw. Na przykład:

• TYPO3.CMS.Frontend.ContentObject.ContentObjectRenderer
• TYPO3.CMS.Scheduler.Task
• Vendor.ExtensionName.Service.ApiClient

Konfiguracja może być przypisana zarówno do całej gałęzi, jak i do pojedynczej klasy. Typowy wzorzec w projektach firmowych to:

• konfiguracja ogólna dla TYPO3.CMS – logi frameworka,
• osobna konfiguracja dla Vendor.ExtensionName – logi własnej aplikacji biznesowej,
• dodatkowe doprecyzowanie dla najbardziej „gadatliwych” komponentów (np. klienci HTTP, integracje zewnętrzne).

Przykład rozdzielenia logów dla własnego rozszerzenia:

$GLOBALS['TYPO3_CONF_VARS']['LOG']['Vendor']['ExtensionName'] = [
    'writerConfiguration' => [
        TYPO3CMSCoreLogLogLevel::INFO => [
            TYPO3CMSCoreLogWriterFileWriter::class => [
                'logFile' => TYPO3CMSCoreCoreEnvironment::getVarPath()
                    . '/log/ext-extensionname-info.log'
            ],
        ],
        TYPO3CMSCoreLogLogLevel::ERROR => [
            TYPO3CMSCoreLogWriterFileWriter::class => [
                'logFile' => TYPO3CMSCoreCoreEnvironment::getVarPath()
                    . '/log/ext-extensionname-error.log'
            ],
        ],
    ],
];

Jeżeli zespół ma nawyk stosowania poprawnych przestrzeni nazw dla klas, rozróżnianie źródeł problemów w centralnym systemie logowania staje się znacznie prostsze.

Procesory logów: czyszczenie i kontekst zanim wpis trafi do writera

Logging Framework oferuje tzw. processors – klasy pozwalające modyfikować wpisy logów przed zapisem. To dość niedoceniany mechanizm, który w środowiskach regulowanych (RODO, branże finansowe) bywa kluczowy. Procesory można wykorzystać m.in. do:

• maskowania danych osobowych (np. zostawiania tylko części adresu e-mail),
• dodawania kontekstu requestu (ID żądania, ID sesji, identyfikator środowiska),
• usuwania pól niepotrzebnych z punktu widzenia utrzymania.

Przykładowy processor dopisujący identyfikator środowiska i user ID backendu mógłby działać podobnie do:

class ContextProcessor implements TYPO3CMSCoreLogProcessorProcessorInterface
{
    public function processLogRecord(array $record): array
    {
        $record['extra']['environment'] = getenv('APP_ENV') ?: 'prod';

        if ($GLOBALS['BE_USER'] ?? false) {
            $record['extra']['be_user_id'] = (int)$GLOBALS['BE_USER']->user['uid'];
        }

        return $record;
    }
}

Podpięcie takiego processor’a odbywa się w konfiguracji:

$GLOBALS['TYPO3_CONF_VARS']['LOG']['Vendor']['ExtensionName'] = [
    'processorConfiguration' => [
        TYPO3CMSCoreLogLogLevel::DEBUG => [
            VendorExtensionLogProcessorContextProcessor::class => [],
        ],
    ],
    // ...
];

Dzięki temu w zewnętrznym systemie logowania można od razu filtrować wpisy po środowisku czy użytkowniku, bez dorabiania ad-hocowych korektorów.

Monitorowanie błędów PHP i wyjątków w TYPO3 (core + własny kod)

Sam fakt, że błąd zostanie zapisany w logu, nie oznacza, że ktoś na niego zareaguje. W typowym projekcie korporacyjnym objętość logów jest tak duża, że manualne przeglądanie plików jest bardziej iluzją kontroli niż realnym procesem. Kluczowe jest zbudowanie ścieżki: błąd PHP → agregacja → korelacja z kontekstem aplikacji → alert tylko, gdy ma to sens.

Obsługa wyjątków w TYPO3: co jest łapane, a co wycieka

TYPO3 core przechwytuje znaczną część wyjątków i renderuje strony błędów (frontend i backend), ale to nie oznacza, że wszystkie problemy lądują w jednym, łatwym do analizowania miejscu. W uproszczeniu:

• wyjątki w kontrolerach Extbase i wielu komponentach core są logowane przez Logging Framework,
• fatal error (np. brak pamięci, błąd kompilacji) jest obsługiwany na poziomie PHP i zwykle kończy się wpisem w logu PHP, bez pełnej kontroli TYPO3,
• ostrzeżenia i notice zależą od poziomu error_reporting i ustawień display_errors/log_errors.

Dość częsty błąd konfiguracyjny: na produkcji pozostawiony jest zbyt wysoki poziom error_reporting, a jednocześnie display_errors bywa włączone. Efekt – szczegóły błędów widoczne dla użytkowników i ryzyko wycieku informacji o strukturze systemu. W dużych instalacjach lepiej jest:

• logować szczegóły w osobnym kanale (PHP error log, centralny system),
• prezentować użytkownikom jedynie generyczne komunikaty błędów HTTP.

Łączenie logów PHP z Logging Framework: wspólny identyfikator

Jednym z praktycznych sposobów na lepszą korelację jest wprowadzenie identyfikatora żądania (request ID), który trafia zarówno do logów TYPO3, jak i logów PHP/serwera HTTP. Można to zrealizować jako middleware ustawiające nagłówek i zapisujące go w globalnym kontekście logowania.

class RequestIdMiddleware implements PsrHttpServerMiddlewareInterface
{
    public function process(
        PsrHttpMessageServerRequestInterface $request,
        PsrHttpServerRequestHandlerInterface $handler
    ): PsrHttpMessageResponseInterface {
        $requestId = $request->getHeaderLine('X-Request-Id')
            ?: bin2hex(random_bytes(8));

        // Zapis w globalnym kontekście (np. do wykorzystania w processorze logów)
        $GLOBALS['TYPO3_REQUEST_ID'] = $requestId;

        $response = $handler->handle($request);
        return $response->withHeader('X-Request-Id', $requestId);
    }
}

Następnie processor logów może dokleić request_id do każdego wpisu:

$record['extra']['request_id'] = $GLOBALS['TYPO3_REQUEST_ID'] ?? null;

Po stronie serwera HTTP (np. Nginx) ten sam nagłówek może być logowany w formacie access/error logu. W centralnym systemie logowania jedno kliknięcie pokaże całą „historię” żądania przez wszystkie warstwy.

Przechwytywanie wyjątków z własnych rozszerzeń

Własny kod biznesowy często bywa największym źródłem problemów – nie dlatego, że jest słabszy niż core, ale dlatego, że robi rzeczy niestandardowe: integracje, przetwarzanie wsadowe, specyficzną logikę. Sceptyczne podejście zakłada, że wyjątki w takim kodzie prędzej czy później się pojawią i trzeba mieć jasny wzorzec ich obsługi.

Podstawowe zasady:

• Nad krytycznymi fragmentami logiki (zewnętrzne API, importy, operacje na plikach) warto mieć wyraźne bloki try/catch, które:
  • logują wyjątek z pełnym kontekstem,
  • rzucają dalej wyjątek „bezpieczniejszy” dla użytkownika (bez danych wrażliwych w treści).
• Nie ma sensu łapać wszystkich wyjątków w ciemno i „połykać” błędów – to prowadzi do cichych awarii.

Przykład wzorca z przekazaniem kontekstu:

try {
    $this->externalApiClient->sendOrder($orderDto);
} catch (VendorExtensionApiApiException $e) {
    $this->logger->error(
        'API order send failed',
        [
            'orderId' => $orderDto->getId(),
            'endpoint' => $e->getEndpoint(),
            'code' => $e->getCode(),
        ]
    );
    throw new RuntimeException(
        'Order processing failed, please try again later.',
        0,
        $e
    );
}

W logach mamy szczegóły techniczne i korelację z wyjątkiem pierwotnym, a użytkownik dostaje komunikat neutralny z punktu widzenia bezpieczeństwa.

Scheduler, CLI i zadania wsadowe – osobna kategoria problemów

Błędy w zadaniach typu Scheduler często wychodzą na jaw za późno – gdy ktoś odkryje, że eksport danych nie działa od tygodni. Domyślne logowanie do sys_log bywa niewystarczające; przy bardziej wrażliwych procesach lepsza jest osobna polityka logowania dla:

• TYPO3.CMS.Scheduler – logi samego frameworka zadań,
• własnych klas tasków – np. Vendor.ExtensionName.Task.

Praktyczny wariant konfiguracyjny to skierowanie logów błędów zadań do osobnego writera (np. kolejki, e-mail lub centralnego SIEM), niezależnego od reszty frontendu. Wtedy awaria nocnego importu nie ginie w szumie logów publicznego portalu.

Narzędzia zewnętrzne: Sentry, ELK, Graylog i inne integracje z TYPO3

Logging Framework rozwiązuje tylko część problemu – zapisuje zdarzenia. W dużych środowiskach równie istotne są narzędzia, które potrafią te zdarzenia zbierać, grupować, korelować i podsuwać zespołowi utrzymaniowemu w formie sensownych alertów, a nie surowych plików tekstowych.

Sentry – monitoring wyjątków i frontendu

Sentry dobrze radzi sobie z wyjątkami z aplikacji PHP i JavaScript, co ma znaczenie w instalacjach TYPO3 mocno korzystających z własnego JS na froncie. Typowy wzorzec integracyjny obejmuje:

• instalację SDK PHP przez Composer w projekcie TYPO3,
• konfigurację DSN i środowisk (production/staging) w zmiennych środowiskowych,
• podpięcie handlera wyjątków, który:
  • łapie nieobsłużone wyjątki PHP,
  • nakłada filtry (np. ignoruje pewne klasy wyjątków biznesowych),
  • wzbogaca event o dane z kontekstu TYPO3 (użytkownik backendu, identyfikator strony, request ID).

Jednocześnie nie ma sensu wysyłać do Sentry wszystkiego – masowe ostrzeżenia E_NOTICE czy „szum informacyjny” z deprecations potrafią zalać projekt tysiącami eventów, przez co realne błędy giną w tle. Bardziej praktyczne jest:

• ograniczenie integracji do wyjątków na poziomie ERROR+ (lub doprecyzowanych typów),
• osobne projekty Sentry dla frontend JS i backend PHP,
• filtrowanie danych osobowych na etapie SDK (tzw. beforeSend).

Przykładowy filtr w PHP (uproszczony):

Sentryinit([
    'dsn' => getenv('SENTRY_DSN'),
    'before_send' => function (SentryEvent $event) {
        $request = $event->getRequest();
        if ($request !== null) {
            // Usunięcie ciasteczek i pełnych URL-i zapytań z parametrami
            $request->setCookies([]);
            $request->setQueryString(null);
        }
        return $event;
    },
]);

ELK / OpenSearch – pełnotekstowa analityka logów

Stos ELK (Elasticsearch, Logstash, Kibana) lub jego odpowiedniki (np. OpenSearch) nadają się szczególnie do środowisk, gdzie logów są gigabajty dziennie i trzeba:

• szybko wyszukać wzorce (np. wszystkie błędy 500 z danego mikrousługowego endpointu),

• budować dashboardy dla konkretnych ról (1–2 kluczowe widoki dla opsów, osobny dla zespołu aplikacyjnego),
• korelować logi TYPO3 z logami reverse proxy, bazy danych czy serwisów zewnętrznych.

Typowy wzorzec w środowisku TYPO3 to wysyłanie logów do Logstash lub bezpośrednio do Elastic/OpenSearch przez Filebeat/Vector, z prostym schematem pól: application=typo3, channel, level, request_id, site_identifier. Dopiero na takim ujednoliconym formacie sensownie działają alerty oparte na zapytaniach, a nie na pojedynczych liniach tekstu. Bez spójnego schematu każdy projekt kończy z własną „dialektową” wersją logów, których nikt poza autorem nie rozumie.

Pułapką przy ELK jest traktowanie go jako wysypiska wszystkiego, co da się zalogować. Przy dużych portalach logi potrafią rosnąć lawinowo: każdy dodatkowy szczegół w context to nie tylko miejsce na dysku, ale też wolniejsze indeksowanie i wyższy koszt klastra. Rozsądniej najpierw zdefiniować scenariusze użycia (np. „szukamy przyczyn 5xx w godzinach szczytu”, „śledzimy awarie Schedulerów”), a dopiero potem zapełniać indeksy tym, co rzeczywiście pomaga w tych scenariuszach.

Graylog i inne systemy SIEM

Graylog i podobne systemy (SIEM/SOAR) są częściej domeną zespołów bezpieczeństwa niż developerów. Z poziomu TYPO3 głównym zadaniem jest dostarczenie im sensownych, ustrukturyzowanych logów, które da się mapować na reguły detekcji incydentów. Dobrze zdefiniowane kanały i poziomy logowania znacząco upraszczają ich pracę – SECURITY i AUTH w osobnych strumieniach, bez mieszania z ogólnymi INFO z frontu.

W praktyce oznacza to niewielkie, ale konkretne modyfikacje: inne formaty logów dla kanałów bezpieczeństwa (np. JSON z polami user, ip, action), osobne writery do syslog/UDP dla reguł SIEM, a czasem wprost uzgodnione typy zdarzeń, które muszą się pojawiać (udane/nieudane logowanie, zmiany ról, masowe operacje na danych). Jeżeli TYPO3 jest tylko jednym z wielu systemów w krajobrazie firmy, spójność takich zdarzeń z resztą ekosystemu bywa ważniejsza niż dopieszczanie lokalnego formatu logów w samym projekcie.

Nie ma sensu próbować „upchnąć” całej semantyki zdarzeń TYPO3 do jednego strumienia SIEM. Część danych będzie za szczegółowa i nada się wyłącznie do analizy operacyjnej (ELK), a tylko wybrane klasy zdarzeń powinny trafiać do systemów bezpieczeństwa. Rozdzielenie tych ról – najlepiej na poziomie konfiguracji Logging Framework i pipeline’u logów – zapobiega scenariuszowi, w którym analitycy bezpieczeństwa dostają setki tysięcy eventów dziennie z informacjami kompletnie nieprzydatnymi z ich perspektywy.

Alerty i powiadomienia: co naprawdę musi dzwonić po nocach

Największym błędem przy projektowaniu alertów jest chęć „nie przegapić niczego” – kończy się to lawiną powiadomień, której nikt nie czyta. Skuteczny system monitorowania w TYPO3 zakłada, że większość logów służy analizie po fakcie, a tylko mały podzbiór zdarzeń wywołuje aktywne alarmy. Zwłaszcza w dużych instalacjach lepiej mieć kilka dobrze przemyślanych reguł, niż 30 przypadkowych notyfikacji o wszystkim i o niczym.

Dobry punkt wyjścia to rozdzielenie dwóch kategorii zdarzeń: rzeczy operacyjnych (wydajność, awarie integracji, Scheduler, pełne dyski) oraz zdarzeń biznesowo‑krytycznych (brak możliwości złożenia zamówienia, niedostępne kluczowe formularze, problemy z logowaniem użytkowników). Pierwsza grupa zwykle trafia do zespołu infrastruktury/DevOps, druga – do właścicieli produktu i zespołu developerskiego. Mieszanie tego w jednym kanale Slacka lub jednym adresie e‑mail kończy się tym, że nikt nie czuje się naprawdę odpowiedzialny za reakcję.

Przy projektowaniu reguł alertów lepsza jest logika oparta na agregacji niż na pojedynczych eventach. Jeden błąd 500 raz na kilka godzin to często szum. Seria kilkudziesięciu takich błędów w ciągu 5 minut na tym samym endpointcie – to już problem. W praktyce sprawdza się kilka prostych progów, np. „więcej niż X błędów 5xx z danego hosta w Y minut”, „więcej niż Z nieudanych prób logowania z tego samego IP”, „brak jakiejkolwiek aktywności w logach Scheduler przez N minut o zaplanowanej porze”. Dzięki temu alarmy działają jak czujnik dymu, a nie jak ciągłe piknięcia lodówki.

Kolejna kwestia to kanały powiadomień i ich „głośność”. SMS, telefon czy głośne pingnięcie na on‑call powinny być zarezerwowane dla zdarzeń klasy „serwis krytyczny nie działa lub zachowuje się nieprzewidywalnie”. Wszystko inne może lądować w mniej inwazyjnych kanałach (Slack, e‑mail, ticket w systemie helpdesk). Typowy błąd to włączanie SMS‑ów dla każdego wyjątku na poziomie ERROR – po tygodniu zespół przestaje reagować, bo 90% z nich dotyczy marginalnych usług lub środowisk testowych.

Alerty trzeba też regularnie korygować. Po pierwszym miesiącu produkcji zwykle widać, które reguły generują fałszywe alarmy lub są zbyt ogólne („błąd bazy danych” bez kontekstu). Wtedy sensownie jest: uszczegółowić warunki, dodać dodatkowe filtry (np. tylko wybrane site identifiers), albo przenieść część przypadków do niższego poziomu – z intensywnego alertu na spokojniejszy raport dzienny. Najgorszy scenariusz to system, którego nikt nie ma odwagi dotykać, więc powoli zamienia się w tło szumu.

Dopiero połączenie rozsądnie skonfigurowanych logów TYPO3, zewnętrznych narzędzi do ich analizy oraz oszczędnie zaprojektowanych alertów daje efekt w postaci przewidywalnego utrzymania. Zespół nie śledzi pojedynczych wpisów w logach, tylko reaguje na wyraźne sygnały, ma jak odtworzyć kontekst zdarzenia i – co równie istotne – nie budzi się w nocy z powodu każdego nieistotnego ostrzeżenia.

Praktyczne wzorce konfiguracji monitoringu TYPO3 w organizacji

Teoretycznie „logowanie i alerty są”, praktycznie – w każdym zespole wyglądają inaczej. Da się jednak wyróżnić kilka powtarzalnych wzorców, które sprawdzają się w dużych instalacjach TYPO3. Zwykle różnią się one głównie budżetem, dojrzałością zespołu i presją biznesową (SLA, kary umowne, widoczność systemu).

Minimalny, ale sensowny setup dla jednej instancji TYPO3

Najczęstszy scenariusz przy jednym, dużym portalu firmowym to zestaw: logi aplikacyjne na dysku + centralny system ticketowy + prosty monitoring infrastruktury. Bez wodotrysków, ale z przewidywalnym zachowaniem.

W takim układzie TYPO3 zwykle ma:

• Logging Framework skierowany do:
  • pliku z rotacją dzienną (np. przez FileWriter) dla kanałów system, security,
  • sysloga lub journald (jeżeli wymusza to standard firmowy),
• moduł backendowy lub prosty panel administracyjny pokazujący ostatnie błędy 4xx/5xx oraz wyjątki aplikacyjne,
• integrację z systemem ticketowym (Jira/ServiceNow/Redmine) przez małą usługę pośredniczącą, która z agregowanego źródła logów tworzy zgłoszenia tylko dla poważnych incydentów.

To rozwiązanie ma ograniczenia – ręczna analiza bywa czasochłonna – ale przy niewielkim obciążeniu portalu i braku restrykcyjnych SLA często wystarcza. Kluczowe jest, żeby:

• nie mieszać logów z dev/stage z produkcją,
• nie trzymać wszystkiego w jednym pliku (oddzielny log bezpieczeństwa),
• zapewnić choćby podstawową korelację z czasem (spójna strefa czasowa, synchronizacja NTP).

Setup dla wielu instancji i kilku zespołów

Przy kilku instancjach TYPO3 (np. per kraj/markę) rozjeżdżające się konfiguracje logowania stają się problemem samym w sobie. Jeden projekt loguje JSON, drugi „ładne” linie tekstu, trzeci nie loguje prawie nic. Potem ktoś próbuje zestawić to w jednym ELK i dopiero wtedy wychodzi, że zaczytanie logów to osobny projekt.

Żeby tego uniknąć, zespoły często standaryzują:

• format logów (np. JSON Lines z polami timestamp, level, channel, request_id, site, user_type),
• nazwy kanałów (z predefiniowaną listą: system, security, frontend, scheduler, ext.{extensionKey}),
• mapowanie poziomów logowania na klasy zdarzeń (np. CRITICAL = niedostępność serwisu, ERROR = błąd funkcjonalności, WARNING = odchylenie od normy).

Na tym dopiero buduje się spójne panele w Kibanie lub innym narzędziu, widoczne dla kilku zespołów równolegle. Uproszczeniem bywa centralny „manifest” logowania (np. plik w repo z opisem pól i kanałów), do którego develeperzy muszą się odnieść przy dodawaniu nowych rozszerzeń.

Środowiska: development, staging, production bez chaosu

Najwięcej szkód w logach robi brak konsekwencji między środowiskami. Na developmencie wszystko jest na DEBUG, na stagingu ktoś „na chwilę” włączył var_dump(), produkcja ma wycięte DEBUG, ale za to generuje milion WARNING na temat drobnych integracji. Potem pojawia się błąd, który występuje tylko na produkcji i nie bardzo wiadomo, co z nim zrobić.

Rozsądny, przewidywalny podział:

• Development:
  • maksymalnie szczegółowe logi (w tym DEBUG) zapisywane lokalnie,
  • brak wysyłki do centralnych systemów, żeby nie mieszać danych,
  • włączone raportowanie deprecations, ale z możliwością ich filtrowania.
• Staging/UAT:
  • zachowanie konfiguracji produkcyjnej (poziomy, format, kanały),
  • dodatkowy kanał z logami testowymi, który nie istnieje na produkcji,
  • opcjonalne wysyłanie do Sentry/ELK z osobnym identyfikatorem środowiska.
• Production:
  • ograniczony zakres poziomów (INFO w dół tylko dla wybranych kanałów),
  • odcięte logi z biblioteki deweloperskiej i testowych rozszerzeń,
  • ścisłe zasady retencji i maskowania danych.

Chodzi o to, żeby przenosząc kod między środowiskami, nie zmieniać za każdym razem filozofii logowania. Inaczej testy na stagingu potwierdzają wyłącznie to, że logi stagingu działają inaczej niż produkcyjne.

Organizacja pracy z logami: kto, kiedy i po co do nich zagląda

Nawet najlepiej skonfigurowany system logowania nie rozwiąże problemu, jeśli nikt nie ma formalnego obowiązku z niego korzystać. Spotykany w praktyce objaw: „Logi są, ale od pół roku nikt ich nie przeglądał, dopóki klient nie zadzwonił, że coś nie działa od tygodnia”.

Dyżury on‑call a TYPO3

W firmach z dyżurami on‑call logi TYPO3 są tylko jednym z wielu źródeł sygnałów. Zazwyczaj:

• on‑call dostaje powiadomienia wyłącznie o zdarzeniach zdefiniowanych jako krytyczne (np. brak odpowiedzi instancji, gwałtowny skok 5xx w access logach),
• analiza wyjątków z warstwy aplikacyjnej jest przekazywana zespołowi developerskiemu w trybie „następny dzień roboczy”,
• część alertów (np. powtarzalne błędy integracji z ERP) ląduje od razu jako zadania w backlogu zespołu odpowiedzialnego za integrację.

TYPO3 nie powinno być wyjątkiem od reguł firmowych. Jeżeli monitoring dla innych usług korzysta z Prometheusa, a alerty idą przez PagerDuty, dokładanie osobnego mechanizmu powiadomień prosto z TYPO3 (np. maile z własnego rozszerzenia) zwykle kończy się powieleniem sygnałów i dezorientacją.

Regularne przeglądy logów zamiast gaszenia pożarów

Oprócz incydentów losowych przydają się proste, cykliczne rytuały. Najprostszy model:

• raz w tygodniu krótki przegląd najczęstszych wyjątków i błędów z ostatnich dni,
• raz w miesiącu analiza trendów (czy liczba 4xx/5xx rośnie, spada, stabilizuje się),
• po każdej większej wdrożonej wersji – porównanie poziomu błędów przed/po deployu.

To w praktyce więcej daje niż reaktywne przeszukiwanie logów przy każdej awarii. Odkrywa się wtedy np. błędy, które nie są krytyczne pojedynczo, ale w dłuższym okresie powodują spadek konwersji albo niezauważalne „wyciekanie” pamięci.

Rozdzielenie ról: deweloperzy, ops, bezpieczeństwo

Zespoły patrzą na te same logi z różnych perspektyw:

• deweloperzy szukają szczegółów wyjątków, stack trace’ów, kontekstu requestu,
• ops/DevOps patrzą na metryki ilościowe (ile błędów, kiedy, z jakich hostów),
• bezpieczeństwo koncentruje się na nietypowych wzorcach: brute force, próbach SQLi/XSS, nadużyciach API.

Jeżeli wszyscy próbują pracować na jednym dashboardzie logów i jednym kanale powiadomień, kompromisy są nieuniknione, a na końcu nikt nie jest zadowolony. Bardziej pragmatyczne są trzy osobne widoki ogarniające te potrzeby niż „jeden, który wszystko ma, ale nikt go nie umie czytać”.

Specyfika TYPO3, która komplikuje monitorowanie

TYPO3, zwłaszcza w większych instalacjach, ma kilka cech utrudniających sensowne monitorowanie. Spora część problemów wynika nie z braku narzędzi, tylko z ignorowania tego kontekstu.

Scheduler i zadania cykliczne

Scheduler w TYPO3 bywa ukrytą przyczyną wielu incydentów – od nieodświeżających się cache’y po niewysłane newslettery. Niby w backendzie widać listę zadań, ale przy wielu rozszerzeniach i kilkudziesięciu jobach miesięczny log Scheduler potrafi być nieczytelny.

Parę prostych zasad:

• każde zadanie Scheduler powinno logować:
  • początek i koniec wykonania (INFO),
  • czas trwania,
  • liczbę przetworzonych rekordów (jeżeli ma to sens),
• błędy w jobach muszą trafiać do dedykowanego kanału, np. scheduler.error, a nie ginąć w ogólnym system,
• centralny alert powinien monitorować „brak aktywności” wybranych krytycznych zadań (cache warmup, synchronizacje, eksporty), a nie tylko same błędy.

Typowa pułapka: zadanie Scheduler wykonuje się technicznie poprawnie, ale z powodu błędnych danych „nic nie robi”. Bez logowania liczby przetworzonych elementów trudno zauważyć, że job od tygodnia nie wprowadził ani jednej aktualizacji.

Cache, CDN i „fałszywe” 200‑tki

Przy agresywnym cache’owaniu i użyciu CDN logi TYPO3 nie zawsze są pełnym obrazem sytuacji. Użytkownik może widzieć błędy po stronie krawędzi (time‑out, błąd połączenia), podczas gdy aplikacja raportuje wyłącznie 200‑tki z cache’u.

Żeby nie wyciągać pochopnych wniosków, przydaje się:

• spójny request_id lub correlation_id przenoszony między CDN a aplikacją (nagłówki HTTP),
• logowanie „missów” cache’u w osobnym kanale (np. w rozszerzeniach odpowiedzialnych za intensywne zapytania),
• rozsądne agregowanie access logów z warstwy frontowej (nginx/HAProxy/CDN) razem z logami TYPO3.

Bez tego łatwo dojść do wniosku, że „na aplikacji jest idealnie, więc problem jest gdzieś indziej”, co rzadko bywa w pełni prawdą.

Multisite i identyfikacja „która strona naprawdę ma problem”

W instancjach hostujących wiele portali zdarza się, że jeden z nich generuje 90% błędów, ale logi tego nie pokazują wprost. Jeżeli nie ma jednoznacznego identyfikatora strony w każdym wpisie, analiza sprowadza się do zgadywania po URL‑ach.

Bezpieczniejszy wzorzec:

• w każdym logu z frontu – pole site_identifier lub site_root_page_id,
• osobne kanały dla kilku największych serwisów (gdy istotna jest izolacja): frontend.siteA, frontend.siteB,
• możliwość filtrowania alertów per serwis (np. tylko błędy z najważniej strony e‑commerce wywołują on‑call).

Bez takiej separacji duży portal informacyjny potrafi kompletnie zdominować sygnał, a problemy mniejszych, ale równie ważnych serwisów przepadają w hałasie.

Bezpieczeństwo, prywatność i compliance w logach TYPO3

Większość organizacji ma dziś wymogi regulacyjne – od RODO po wewnętrzne polityki bezpieczeństwa. Logi, szczególnie z systemów webowych, są w naturalny sposób „zanieczyszczone” danymi osobowymi i biznesowo wrażliwymi.

Maskowanie i pseudonimizacja danych

Najprostsza, ale często ignorowana praktyka to filtrowanie danych przed zapisaniem ich do logów. Przykłady pól, które w logach zwykle nie są potrzebne w pełnej postaci:

• adresy e‑mail (wystarczy hash lub ucięta domena),
• identyfikatory użytkowników (można logować wewnętrzne ID, a nie loginy),
• numery telefonów, identyfikatory zamówień, tokeny resetu hasła.

W TYPO3 można to robić na kilku poziomach:

• własne procesory (processors) w Logging Framework, które modyfikują kontekst,
• hooki / middleware czyszczące request i session przed przekazaniem do loggera,
• konfiguracja SDK zewnętrznych narzędzi (Sentry, APM) z funkcją „beforeSend” lub odpowiednikiem.

Brak takiej warstwy pośredniej skutkuje tym, że za każdym razem, gdy ktoś chce dopisać nowe logowanie, musi się zastanawiać „czy przypadkiem nie ujawnię za dużo” – i zwykle wybiera bezpieczeństwo przez unikanie logowania, co też nie jest rozwiązaniem.

Retencja logów: ile to „wystarczająco długo”

Od strony utrzymaniowej logi chciałoby się trzymać jak najdłużej, od strony RODO – jak najkrócej. Realny kompromis różni się w zależności od branży, ale parę ogólnych zasad jest powtarzalnych:

• krótsza retencja dla logów szczegółowych (np. 30–90 dni),
• dłuższa dla zagregowanych metryk i anonimowych statystyk,
• osobne polityki retencji dla logów bezpieczeństwa (często wymogi prawne narzucają minimalny okres przechowywania).

• jasne rozdzielenie logów operacyjnych od logów zawierających dane osobowe, z różnymi okresami przechowywania i różnym zakresem dostępu,
• automatyczne „starzenie się” logów – rotacja, kompresja, anonimizacja po określonym czasie zamiast ręcznego kasowania raz na kilka lat,
• udokumentowane wyjątki od standardowej retencji (np. logi z incydentów bezpieczeństwa zamrożone na czas postępowania wyjaśniającego).

Technicznie w TYPO3 część retencji da się kontrolować na poziomie logfile (rotacja, rozmiar plików), ale realne zarządzanie okresem przechowywania zwykle i tak dzieje się w warstwie zewnętrznej – w systemie logów centralnych, backupach, snapshotach. Bez spójnej polityki łatwo o sytuację, w której aplikacja zgodnie z polityką usuwa logi po 90 dniach, a jednocześnie te same dane latami leżą w backupach i eksportach zewnętrznych narzędzi monitoringu.

Dostęp do logów i rozdzielenie uprawnień

Logi są często traktowane jako „mniej wrażliwe” niż baza danych, co przy dzisiejszej ilości danych kontekstowych jest raczej życzeniowym myśleniem. Wgląd w szczegółowe logi requestów potrafi ujawnić więcej o zachowaniu użytkowników niż panel administracyjny.

W praktyce przydaje się podzielenie dostępu na kilka poziomów. Administratorzy aplikacji i bezpieczeństwo powinni mieć pełne logi, ale już zespół wsparcia lub marketingu zazwyczaj potrzebuje tylko wycinków: zanonimizowanych identyfikatorów użytkowników, informacji o błędach procesu zakupowego, metryk ogólnych. Reszta to jedynie dodatkowe ryzyko. Warto też w centralnym narzędziu logującym prowadzić audyt dostępu do logów – kto, kiedy, jakich danych szukał – co w razie sporu lub incydentu bywa kluczowe.

Od strony TYPO3 nie ma rozbudowanego, natywnego modelu uprawnień do logów aplikacyjnych; wszystko i tak kończy w pliku lub zewnętrznym narzędziu. To kolejny argument za tym, by nie przechowywać pełnych danych osobowych w kontekście logów, bo później nie da się już tego „odlogować” ani łatwo ograniczyć.

Logi jako materiał dowodowy i baza do analizy incydentów

W wielu branżach logi muszą być traktowane jako potencjalny materiał dowodowy – zarówno w kontekście sporów z klientami, jak i incydentów bezpieczeństwa. To implikuje dwie dodatkowe cechy: integralność oraz możliwość odtworzenia chronologii zdarzeń między systemami. Spójny request_id, znacznik środowiska, dokładne znaczniki czasu i unikanie lokalnych stref czasowych w logach (UTC) przestają być „ładnym usprawnieniem” i stają się koniecznością.

Drugie zagrożenie to debug logging włączany „na chwilę” w produkcji i zapominany na lata. Rozszerzenia TYPO3 potrafią w trybie debug wypluwać pełne payloady requestów API lub zawartość sesji użytkownika, co w połączeniu z długą retencją jest prostą drogą do naruszenia zasad prywatności. Debug na produkcji powinien być ściśle limitowany czasowo, monitorowany, a po zakończeniu analizy – logi z takiego okresu albo usunięte, albo szybko zanonimizowane.

Dobrze skonfigurowany logging w TYPO3 to nie zestaw „fajnych dashboardów”, tylko część infrastruktury, na której polega utrzymanie i rozwój systemu. Kiedy kanały, poziomy, alerty, specyfika Schedulerów i wymagania prawne są ogarnięte, diagnoza problemu z „strona czasem nie działa” skraca się z godzin do minut, a każda awaria dokłada kawałek wiedzy zamiast kolejnego, nieprzeczytanego pliku logu.

Najczęściej zadawane pytania (FAQ)

Jak najlepiej logować błędy w TYPO3 na produkcji, żeby nie pokazywać ich użytkownikom?

Na produkcji komunikaty błędów PHP i wyjątki nie powinny być wyświetlane w przeglądarce. W TYPO3 włącza się raportowanie błędów do logów (error_reporting, display_errors = 0 po stronie PHP), a same błędy rejestruje się przez TYPO3 Logging Framework. Front ma zachowywać się przewidywalnie: komunikat dla użytkownika jest prosty i ogólny, a szczegóły trafiają wyłącznie do logów.

Typowy schemat to: DEBUG i INFO tylko lokalnie (dev/test), WARNING, ERROR i wyżej wysyłane do scentralizowanego systemu logów. Dzięki temu deweloperzy mają pełen kontekst incydentu, ale osoba odwiedzająca stronę nie widzi śladów stosu ani ścieżek serwerowych.

Jakie logi w TYPO3 trzeba monitorować w dużym portalu korporacyjnym?

W większych wdrożeniach nie wystarczy patrzeć tylko w jeden plik typo3.log. Zazwyczaj monitoruje się równolegle:

• logi aplikacyjne TYPO3 z Logging Framework (kanały TYPO3.CMS.*, własne kanały rozszerzeń),
• logi serwera WWW (Apache/Nginx – szczególnie błędy 4xx/5xx),
• logi PHP-FPM / PHP (fatale, ostrzeżenia, problemy z pamięcią),
• logi bazy danych (wolne zapytania, błędy połączeń),
• logi integracji zewnętrznych (API partnerów, importy, schedulery).

Dopiero zestawienie tych źródeł pozwala odtworzyć pełny obraz incydentu. Ograniczanie się do jednego logu zwykle kończy się zgadywaniem, a nie analizą przyczyny.

Jak skonfigurować proaktywne alerty na błędy TYPO3 zamiast czekać na zgłoszenia użytkowników?

Punkt wyjścia to zdefiniowanie progów, które mają wywołać alarm. W praktyce są to najczęściej: skok liczby błędów 500 w logach serwera, gwałtowny wzrost wyjątków na określonym kanale TYPO3, seria błędów w schedulerze albo nagły brak ruchu w logach frontendu (co może oznaczać, że serwis „umiera po cichu”).

Logi z TYPO3 warto wysłać do zewnętrznego narzędzia (np. ELK, Graylog, Sentry, Datadog) i tam skonfigurować reguły alertów. Dzięki temu zespół dostaje powiadomienie (e‑mail, Slack, system on‑call) zanim problem zacznie być masowo zgłaszany przez użytkowników. Reguły trzeba później korygować, bo pierwsza wersja zwykle jest albo zbyt czuła, albo za mało wrażliwa.

Czym jest TYPO3 Logging Framework i dlaczego powinien zastąpić własne „logowanie do pliku”?

TYPO3 Logging Framework to wbudowany system obsługi logów oparty na loggerach, writerach i procesorach oraz kanałach logowania i poziomach (DEBUG–EMERGENCY). Pozwala rozdzielać logi według źródła (np. front, importy, konkretna rozszerzenie) i poziomu ważności, a także centralnie sterować tym, gdzie są zapisywane.

Ręczne „logowanie do pliku” (np. file_put_contents w losowych miejscach) kończy się zwykle chaotycznym zbiorem plików o różnych formatach i bez kontekstu. W małym serwisie jeszcze da się to przeżyć, ale w korporacyjnym portalu analizowanie tego typu logów jest praktycznie niewykonalne. Standaryzacja przez Logging Framework znacząco obniża koszt utrzymania i analizy.

Jak rozróżnić normalne ostrzeżenia od realnych problemów w logach TYPO3?

Nie każdy wpis WARNING oznacza krytyczny incydent, ale ich ignorowanie „bo są zawsze” jest prostą drogą do przeoczenia poważnego problemu. Podstawowa strategia to:

• sklasyfikowanie powtarzających się komunikatów (znane, akceptowalne, do usunięcia),
• obniżenie poziomu logowania dla znanych, niegroźnych przypadków (np. z WARNING do NOTICE),
• utrzymanie zasad, że WARNING i wyżej powinny mieć właściciela, który decyduje, co z nimi robić.

Jeżeli jakiś komunikat powtarza się stale, to zazwyczaj oznacza dług techniczny, a nie „szum”. Lepiej go wyeliminować (poprawka w kodzie, konfiguracji, integracji), niż przyzwyczajać się do czerwonej lampki, która świeci cały czas.

Jak logi pomagają znaleźć prawdziwą przyczynę błędów 500 w TYPO3, a nie tylko „gasić pożary”?

Same restarty PHP-FPM czy czyszczenie cache zwykle rozwiązują tylko objaw – błąd 500 znika na chwilę, ale bez logów nie wiadomo, co go wywołało. Analiza logów pozwala powiązać incydent z konkretnymi zdarzeniami: określoną instancją serwera, typem żądania, użytkownikiem, zadaniem w schedulerze czy wywołaniem zewnętrznego API.

Typowy wzorzec: logi pokazują, że każdemu błędowi 500 towarzyszy wzrost zużycia pamięci i seria timeoutów na jednym endpointcie API. Wtedy można przejść do trwałego rozwiązania (paginacja, limit rozmiaru odpowiedzi, retry z backoffem), zamiast planować kolejny crontab z automatycznym restartem usług.

Czy w każdym projekcie TYPO3 trzeba wdrażać pełny, scentralizowany monitoring logów?

Nie zawsze. Dla prostej, mało obciążonej strony centralizacja logów w rozbudowanym systemie może być przesadą. Natomiast w momencie, gdy pojawia się kilka środowisk, wielu edytorów i integracje zewnętrzne, rozproszone pliki logów na różnych serwerach szybko stają się poważnym ograniczeniem.

Sensownym kompromisem jest podejście etapowe: najpierw porządek w Logging Framework i spójna konfiguracja na wszystkich środowiskach, później wysyłanie logów z produkcji do jednego miejsca, a dopiero na końcu rozbudowa o dashboardy i złożone alerty. Chodzi o to, żeby narzędzie odzwierciedlało skalę i krytyczność projektu, a nie było wdrożone „bo tak się teraz robi”.

Opracowano na podstawie

• TYPO3 Explained (Core Documentation). TYPO3 Association (2024) – Oficjalna dokumentacja architektury, logowania i konfiguracji TYPO3
• TYPO3 Logging Framework (Core API Reference). TYPO3 Association (2024) – Szczegóły loggerów, writerów, konfiguracji logów i poziomów logowania
• PSR-3: Logger Interface. PHP-FIG (2018) – Standard interfejsu loggera w PHP, poziomy logowania i dobre praktyki
• Site Reliability Engineering: How Google Runs Production Systems. O’Reilly Media (2016) – Modele reaktywnego i proaktywnego monitoringu, incident management, SLO
• NIST Special Publication 800-92: Guide to Computer Security Log Management. National Institute of Standards and Technology (2006) – Wytyczne zarządzania logami, centralizacja, analiza po incydentach
• ISO/IEC 27002:2022 Information security, cybersecurity and privacy protection. International Organization for Standardization (2022) – Kontrole dot. rejestrowania zdarzeń, ślad audytowy i wymagania compliance
• The Art of Monitoring. James Turnbull (2016) – Projektowanie systemów monitoringu, alertów i korelacji logów z metrykami