Logi serwera SSRS

Logi serwera SSRS to dzienniki usługi raportowej, pomocne przy diagnozowaniu błędów generowania raportów.

Rodzaje logów w SQL Server Reporting Services

Logi serwera SSRS obejmują kilka źródeł informacji, które opisują różne etapy pracy usługi raportowej. Dzienniki śledzenia usługi zawierają komunikaty dotyczące działania procesu Report Server, inicjalizacji komponentów, komunikacji z bazą danych serwera raportów, ładowania konfiguracji oraz błędów występujących podczas przetwarzania żądań. W instalacjach natywnych spotyka się pliki o nazwie ReportServerService_<timestamp>.log. W nowszych instalacjach SSRS mogą występować także pliki Microsoft.ReportingServices.Portal.WebHost_<timestamp>.log, związane z portalem internetowym.

Drugim ważnym źródłem jest dziennik wykonania raportów przechowywany w bazie danych serwera raportów, zwykle w bazie ReportServer. Widok ExecutionLog3 rejestruje informacje o uruchomionych raportach, między innymi ścieżkę raportu, użytkownika, format wyniku, status wykonania oraz czasy poszczególnych etapów. Dodatkowych informacji diagnostycznych może dostarczać kolumna AdditionalInfo. Zdarzenia usługi są również zapisywane w dzienniku aplikacji systemu Windows, który można przeglądać w Podglądzie zdarzeń.

Położenie i rotacja plików śledzenia SSRS

Dokładna lokalizacja plików zależy od wersji SQL Server Reporting Services, trybu instalacji oraz nazwy instancji. W instalacjach SSRS 2017 i nowszych typowa ścieżka zawiera katalog C:\Program Files\Microsoft SQL Server Reporting Services\SSRS\LogFiles. W starszych wersjach SQL Server używany jest katalog znajdujący się pod C:\Program Files\Microsoft SQL Server\MSRS<wersja>.<nazwa_instancji>\Reporting Services\LogFiles. Nie należy zakładać jednej ścieżki bez sprawdzenia konfiguracji konkretnego serwera.

Pliki śledzenia są tworzone po wystąpieniu pierwszego wpisu po północy oraz po ponownym uruchomieniu usługi. Znacznik czasu w nazwie pliku odnosi się do czasu UTC, dlatego może różnić się od czasu wyświetlanego przez system Windows w strefie Europe/Warsaw. Domyślny limit rozmiaru pliku śledzenia wynosi 32 MB, a pliki są domyślnie usuwane po 14 dniach. Parametry zapisu są związane z konfiguracją usługi, między innymi z plikiem ReportingServicesService.exe.config, dlatego przy analizie trzeba uwzględnić ustawienia konkretnej instalacji.

Jak odczytywać wpisy przy błędzie raportu

Analizę należy rozpocząć od ustalenia czasu wystąpienia problemu, nazwy raportu, użytkownika oraz adresu lub aplikacji, która wysłała żądanie. Następnie warto porównać wpisy z dziennika śledzenia usługi z rekordem w widoku ExecutionLog3. Przykładowe zapytanie może ograniczyć wyniki do konkretnego raportu i przedziału czasu: SELECT TimeStart, TimeEnd, ReportPath, UserName, Format, Status, TimeDataRetrieval, TimeProcessing, TimeRendering, ByteCount, RowCount FROM ExecutionLog3 WHERE ReportPath = N'/Folder/Raport' ORDER BY TimeStart DESC;. Nazwa widoku i kolumny odnoszą się do dziennika wykonania SSRS, a samo zapytanie należy uruchomić w bazie danych serwera raportów.

Podział czasu wykonania pomaga rozróżnić przyczynę opóźnienia. Wysoka wartość TimeDataRetrieval wskazuje na czas pobierania danych ze źródła raportu, natomiast wysokie TimeProcessing może oznaczać koszt przetwarzania danych, grupowania lub wyrażeń raportu. Duże TimeRendering wiąże się z generowaniem wybranego formatu, na przykład PDF lub Excela. Status wykonania należy zestawić z komunikatem błędu w pliku śledzenia i w dzienniku aplikacji Windows. Sam wpis w ExecutionLog3 może potwierdzić nieudane wykonanie, ale nie zawsze zawiera pełny wyjątek ani szczegółową przyczynę.

Wykorzystanie logów SSRS w serwisie sprzętu komputerowego

Logi SSRS są analizowane na serwerze, na którym działa usługa raportowa, dlatego przy problemach z dostępem do raportów trzeba odróżnić awarię samej usługi od problemu komputera użytkownika. Na laptopie lub komputerze PC można sprawdzić, czy błąd występuje także w innej przeglądarce, czy dotyczy jednego raportu, oraz czy połączenie z adresem serwera raportów jest stabilne. Takie testy nie zastępują analizy logów, ale pomagają ustalić, czy zgłoszenie dotyczy klienta, sieci, uwierzytelniania czy przetwarzania raportu po stronie SSRS.

Podczas diagnostyki warto zachować oryginalne pliki logów, odnotować strefę czasową i nie zmieniać konfiguracji poziomu śledzenia bez określenia celu. Zbyt szerokie logowanie może zwiększyć liczbę zapisywanych danych i przyspieszyć rotację plików. Jeżeli wpisy wskazują na błędy systemu Windows, niestabilność dysku, brak pamięci lub problemy z usługą systemową, dalsza diagnoza powinna objąć stan serwera, jego podzespołów i systemu operacyjnego.