Webalizer i Google Analytics od wielu lat pomagają mi uzyskać wgląd w to, co dzieje się na stronach internetowych. Teraz rozumiem, że dostarczają bardzo mało przydatnych informacji. Mając dostęp do swojego pliku access.log, bardzo łatwo jest zrozumieć statystyki i zaimplementować dość podstawowe narzędzia, takie jak sqlite, html, język sql i dowolny skryptowy język programowania.
Źródłem danych dla Webalizera jest plik access.log serwera. Tak wyglądają jego słupki i liczby, z których wynika jedynie całkowite natężenie ruchu:
Narzędzia takie jak Google Analytics same zbierają dane z załadowanej strony. Pokazują nam kilka wykresów i linii, na podstawie których często trudno wyciągnąć prawidłowe wnioski. Może należało się bardziej postarać? Nie wiem.
Co więc chciałem zobaczyć w statystykach odwiedzin witryny?
Ruch użytkowników i botów
Często ruch w witrynie jest ograniczony i konieczne jest sprawdzenie, ile przydatnego ruchu jest wykorzystywane. Na przykład tak:
Zapytanie raportu SQL
SELECT
1 as 'StackedArea: Traffic generated by Users and Bots',
strftime('%d.%m', datetime(FCT.EVENT_DT, 'unixepoch')) AS 'Day',
SUM(CASE WHEN USG.AGENT_BOT!='n.a.' THEN FCT.BYTES ELSE 0 END)/1000 AS 'Bots, KB',
SUM(CASE WHEN USG.AGENT_BOT='n.a.' THEN FCT.BYTES ELSE 0 END)/1000 AS 'Users, KB'
FROM
FCT_ACCESS_USER_AGENT_DD FCT,
DIM_USER_AGENT USG
WHERE FCT.DIM_USER_AGENT_ID=USG.DIM_USER_AGENT_ID
AND datetime(FCT.EVENT_DT, 'unixepoch') >= date('now', '-14 day')
GROUP BY strftime('%d.%m', datetime(FCT.EVENT_DT, 'unixepoch'))
ORDER BY FCT.EVENT_DTWykres przedstawia stałą aktywność botów. Interesujące byłoby szczegółowe przestudiowanie najbardziej aktywnych przedstawicieli.
Irytujące boty
Klasyfikujemy boty na podstawie informacji o kliencie użytkownika. Dodatkowe statystyki dotyczące codziennego ruchu, liczby udanych i nieudanych żądań dają dobry obraz aktywności bota.
Zapytanie raportu SQL
SELECT
1 AS 'Table: Annoying Bots',
MAX(USG.AGENT_BOT) AS 'Bot',
ROUND(SUM(FCT.BYTES)/1000 / 14.0, 1) AS 'KB per Day',
ROUND(SUM(FCT.IP_CNT) / 14.0, 1) AS 'IPs per Day',
ROUND(SUM(CASE WHEN STS.STATUS_GROUP IN ('Client Error', 'Server Error') THEN FCT.REQUEST_CNT / 14.0 ELSE 0 END), 1) AS 'Error Requests per Day',
ROUND(SUM(CASE WHEN STS.STATUS_GROUP IN ('Successful', 'Redirection') THEN FCT.REQUEST_CNT / 14.0 ELSE 0 END), 1) AS 'Success Requests per Day',
USG.USER_AGENT_NK AS 'Agent'
FROM FCT_ACCESS_USER_AGENT_DD FCT,
DIM_USER_AGENT USG,
DIM_HTTP_STATUS STS
WHERE FCT.DIM_USER_AGENT_ID = USG.DIM_USER_AGENT_ID
AND FCT.DIM_HTTP_STATUS_ID = STS.DIM_HTTP_STATUS_ID
AND USG.AGENT_BOT != 'n.a.'
AND datetime(FCT.EVENT_DT, 'unixepoch') >= date('now', '-14 day')
GROUP BY USG.USER_AGENT_NK
ORDER BY 3 DESC
LIMIT 10W tym przypadku efektem analizy była decyzja o ograniczeniu dostępu do serwisu poprzez dodanie go do pliku robots.txt
User-agent: AhrefsBot
Disallow: /
User-agent: dotbot
Disallow: /
User-agent: bingbot
Crawl-delay: 5
Ze stołu zniknęły dwa pierwsze boty, a roboty MS przesunęły się z pierwszych linii.
Dzień i godzina największej aktywności
W ruchu widać wzrosty. Aby je szczegółowo przestudiować, należy podkreślić czas ich wystąpienia i nie jest konieczne wyświetlanie wszystkich godzin i dni pomiaru czasu. Ułatwi to odnalezienie poszczególnych żądań w pliku dziennika, jeśli konieczna będzie szczegółowa analiza.
Zapytanie raportu SQL
SELECT
1 AS 'Line: Day and Hour of Hits from Users and Bots',
strftime('%d.%m-%H', datetime(EVENT_DT, 'unixepoch')) AS 'Date Time',
HIB AS 'Bots, Hits',
HIU AS 'Users, Hits'
FROM (
SELECT
EVENT_DT,
SUM(CASE WHEN AGENT_BOT!='n.a.' THEN LINE_CNT ELSE 0 END) AS HIB,
SUM(CASE WHEN AGENT_BOT='n.a.' THEN LINE_CNT ELSE 0 END) AS HIU
FROM FCT_ACCESS_REQUEST_REF_HH
WHERE datetime(EVENT_DT, 'unixepoch') >= date('now', '-14 day')
GROUP BY EVENT_DT
ORDER BY SUM(LINE_CNT) DESC
LIMIT 10
) ORDER BY EVENT_DTNajbardziej aktywne godziny 11, 14 i 20 pierwszego dnia na wykresie obserwujemy. Ale następnego dnia o 13:XNUMX boty były aktywne.
Średnia dzienna aktywność użytkownika według tygodnia
Poprawiliśmy trochę sytuację związaną z aktywnością i ruchem. Kolejnym pytaniem była aktywność samych użytkowników. W przypadku takich statystyk pożądane są długie okresy agregacji, np. tydzień.
Zapytanie raportu SQL
SELECT
1 as 'Line: Average Daily User Activity by Week',
strftime('%W week', datetime(FCT.EVENT_DT, 'unixepoch')) AS 'Week',
ROUND(1.0*SUM(FCT.PAGE_CNT)/SUM(FCT.IP_CNT),1) AS 'Pages per IP per Day',
ROUND(1.0*SUM(FCT.FILE_CNT)/SUM(FCT.IP_CNT),1) AS 'Files per IP per Day'
FROM
FCT_ACCESS_USER_AGENT_DD FCT,
DIM_USER_AGENT USG,
DIM_HTTP_STATUS HST
WHERE FCT.DIM_USER_AGENT_ID=USG.DIM_USER_AGENT_ID
AND FCT.DIM_HTTP_STATUS_ID = HST.DIM_HTTP_STATUS_ID
AND USG.AGENT_BOT='n.a.' /* users only */
AND HST.STATUS_GROUP IN ('Successful') /* good pages */
AND datetime(FCT.EVENT_DT, 'unixepoch') > date('now', '-3 month')
GROUP BY strftime('%W week', datetime(FCT.EVENT_DT, 'unixepoch'))
ORDER BY FCT.EVENT_DTTygodniowe statystyki pokazują, że średnio jeden użytkownik otwiera 1,6 strony dziennie. Liczba żądanych plików na użytkownika w tym przypadku zależy od dodania nowych plików do serwisu.
Wszystkie żądania i ich statusy
Webalizer zawsze pokazywał określone kody stron, a ja zawsze chciałem zobaczyć tylko liczbę udanych żądań i błędów.
Zapytanie raportu SQL
SELECT
1 as 'Line: All Requests by Status',
strftime('%d.%m', datetime(FCT.EVENT_DT, 'unixepoch')) AS 'Day',
SUM(CASE WHEN STS.STATUS_GROUP='Successful' THEN FCT.REQUEST_CNT ELSE 0 END) AS 'Success',
SUM(CASE WHEN STS.STATUS_GROUP='Redirection' THEN FCT.REQUEST_CNT ELSE 0 END) AS 'Redirect',
SUM(CASE WHEN STS.STATUS_GROUP='Client Error' THEN FCT.REQUEST_CNT ELSE 0 END) AS 'Customer Error',
SUM(CASE WHEN STS.STATUS_GROUP='Server Error' THEN FCT.REQUEST_CNT ELSE 0 END) AS 'Server Error'
FROM
FCT_ACCESS_USER_AGENT_DD FCT,
DIM_HTTP_STATUS STS
WHERE FCT.DIM_HTTP_STATUS_ID=STS.DIM_HTTP_STATUS_ID
AND datetime(FCT.EVENT_DT, 'unixepoch') >= date('now', '-14 day')
GROUP BY strftime('%d.%m', datetime(FCT.EVENT_DT, 'unixepoch'))
ORDER BY FCT.EVENT_DTRaport wyświetla żądania, a nie kliknięcia (trafienia). W przeciwieństwie do LINE_CNT, wskaźnik REQUEST_CNT jest obliczany jako COUNT(DISTINCT STG.REQUEST_NK). Celem jest pokazanie skutecznych zdarzeń, np. boty MS odpytują plik robots.txt setki razy dziennie i w tym przypadku takie ankiety będą liczone raz. Pozwala to wygładzić skoki na wykresie.
Na wykresie widać wiele błędów - są to strony nieistniejące. Wynikiem analizy było dodanie przekierowań ze stron zdalnych.
Złe prośby
Aby szczegółowo zbadać żądania, możesz wyświetlić szczegółowe statystyki.
Zapytanie raportu SQL
SELECT
1 AS 'Table: Top Error Requests',
REQ.REQUEST_NK AS 'Request',
'Error' AS 'Request Status',
ROUND(SUM(FCT.LINE_CNT) / 14.0, 1) AS 'Hits per Day',
ROUND(SUM(FCT.IP_CNT) / 14.0, 1) AS 'IPs per Day',
ROUND(SUM(FCT.BYTES)/1000 / 14.0, 1) AS 'KB per Day'
FROM
FCT_ACCESS_REQUEST_REF_HH FCT,
DIM_REQUEST_V_ACT REQ
WHERE FCT.DIM_REQUEST_ID = REQ.DIM_REQUEST_ID
AND FCT.STATUS_GROUP IN ('Client Error', 'Server Error')
AND datetime(FCT.EVENT_DT, 'unixepoch') >= date('now', '-14 day')
GROUP BY REQ.REQUEST_NK
ORDER BY 4 DESC
LIMIT 20Na tej liście znajdą się także wszystkie wywołania, np. żądanie do /wp-login.php Dostosowując zasady przepisywania żądań przez serwer, możesz dostosować reakcję serwera na takie żądania i wysłać je na stronę startową.
Tak więc kilka prostych raportów bazujących na pliku logu serwera daje w miarę pełny obraz tego co dzieje się na stronie.
Jak zdobyć informacje?
Baza danych sqlite jest wystarczająca. Stwórzmy tabele: pomocnicze do logowania procesów ETL.
Etap tabeli, w którym będziemy pisać pliki dziennika przy użyciu PHP. Dwie tabele zbiorcze. Stwórzmy dzienną tabelę ze statystykami dotyczącymi agentów użytkownika i statusów żądań. Co godzinę ze statystykami dotyczącymi żądań, grup statusowych i agentów. Cztery tabele odpowiednich pomiarów.
Rezultatem jest następujący model relacyjny:
Model danych
Skrypt tworzący obiekt w bazie danych sqlite:
Tworzenie obiektów DDL
DROP TABLE IF EXISTS DIM_USER_AGENT;
CREATE TABLE DIM_USER_AGENT (
DIM_USER_AGENT_ID INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT,
USER_AGENT_NK TEXT NOT NULL DEFAULT 'n.a.',
AGENT_OS TEXT NOT NULL DEFAULT 'n.a.',
AGENT_ENGINE TEXT NOT NULL DEFAULT 'n.a.',
AGENT_DEVICE TEXT NOT NULL DEFAULT 'n.a.',
AGENT_BOT TEXT NOT NULL DEFAULT 'n.a.',
UPDATE_DT INTEGER NOT NULL DEFAULT 0,
UNIQUE (USER_AGENT_NK)
);
INSERT INTO DIM_USER_AGENT (DIM_USER_AGENT_ID) VALUES (-1);Scena
W przypadku pliku access.log konieczne jest odczytanie, przeanalizowanie i zapisanie wszystkich żądań do bazy danych. Można to zrobić bezpośrednio, używając języka skryptowego lub narzędzi sqlite.
Format pliku dziennika:
//67.221.59.195 - - [28/Dec/2012:01:47:47 +0100] "GET /files/default.css HTTP/1.1" 200 1512 "https://project.edu/" "Mozilla/4.0"
//host ident auth time method request_nk protocol status bytes ref browser
$log_pattern = '/^([^ ]+) ([^ ]+) ([^ ]+) ([[^]]+]) "(.*) (.*) (.*)" ([0-9-]+) ([0-9-]+) "(.*)" "(.*)"$/';
Propagacja klucza
Gdy surowe dane znajdują się w bazie danych, należy wpisać klucze, których tam nie ma, do tabel pomiarowych. Wtedy możliwe będzie zbudowanie odniesienia do pomiarów. Na przykład w tabeli DIM_REFERRER kluczem jest kombinacja trzech pól.
Zapytanie o propagację klucza SQL
/* Propagate the referrer from access log */
INSERT INTO DIM_REFERRER (HOST_NK, PATH_NK, QUERY_NK, UPDATE_DT)
SELECT
CLS.HOST_NK,
CLS.PATH_NK,
CLS.QUERY_NK,
STRFTIME('%s','now') AS UPDATE_DT
FROM (
SELECT DISTINCT
REFERRER_HOST AS HOST_NK,
REFERRER_PATH AS PATH_NK,
CASE WHEN INSTR(REFERRER_QUERY,'&sid')>0 THEN SUBSTR(REFERRER_QUERY, 1, INSTR(REFERRER_QUERY,'&sid')-1) /* отрезаем sid - специфика цмс */
ELSE REFERRER_QUERY END AS QUERY_NK
FROM STG_ACCESS_LOG
) CLS
LEFT OUTER JOIN DIM_REFERRER TRG
ON (CLS.HOST_NK = TRG.HOST_NK AND CLS.PATH_NK = TRG.PATH_NK AND CLS.QUERY_NK = TRG.QUERY_NK)
WHERE TRG.DIM_REFERRER_ID IS NULLPropagacja do tabeli agentów użytkownika może zawierać logikę bota, na przykład fragment kodu sql:
CASE
WHEN INSTR(LOWER(CLS.BROWSER),'yandex.com')>0
THEN 'yandex'
WHEN INSTR(LOWER(CLS.BROWSER),'googlebot')>0
THEN 'google'
WHEN INSTR(LOWER(CLS.BROWSER),'bingbot')>0
THEN 'microsoft'
WHEN INSTR(LOWER(CLS.BROWSER),'ahrefsbot')>0
THEN 'ahrefs'
WHEN INSTR(LOWER(CLS.BROWSER),'mj12bot')>0
THEN 'majestic-12'
WHEN INSTR(LOWER(CLS.BROWSER),'compatible')>0 OR INSTR(LOWER(CLS.BROWSER),'http')>0
OR INSTR(LOWER(CLS.BROWSER),'libwww')>0 OR INSTR(LOWER(CLS.BROWSER),'spider')>0
OR INSTR(LOWER(CLS.BROWSER),'java')>0 OR INSTR(LOWER(CLS.BROWSER),'python')>0
OR INSTR(LOWER(CLS.BROWSER),'robot')>0 OR INSTR(LOWER(CLS.BROWSER),'curl')>0
OR INSTR(LOWER(CLS.BROWSER),'wget')>0
THEN 'other'
ELSE 'n.a.' END AS AGENT_BOTTabele zbiorcze
Na koniec załadujemy tabele zbiorcze; na przykład tabelę dzienną można załadować w następujący sposób:
Zapytanie SQL do ładowania agregatu
/* Load fact from access log */
INSERT INTO FCT_ACCESS_USER_AGENT_DD (EVENT_DT, DIM_USER_AGENT_ID, DIM_HTTP_STATUS_ID, PAGE_CNT, FILE_CNT, REQUEST_CNT, LINE_CNT, IP_CNT, BYTES)
WITH STG AS (
SELECT
STRFTIME( '%s', SUBSTR(TIME_NK,9,4) || '-' ||
CASE SUBSTR(TIME_NK,5,3)
WHEN 'Jan' THEN '01' WHEN 'Feb' THEN '02' WHEN 'Mar' THEN '03' WHEN 'Apr' THEN '04' WHEN 'May' THEN '05' WHEN 'Jun' THEN '06'
WHEN 'Jul' THEN '07' WHEN 'Aug' THEN '08' WHEN 'Sep' THEN '09' WHEN 'Oct' THEN '10' WHEN 'Nov' THEN '11'
ELSE '12' END || '-' || SUBSTR(TIME_NK,2,2) || ' 00:00:00' ) AS EVENT_DT,
BROWSER AS USER_AGENT_NK,
REQUEST_NK,
IP_NR,
STATUS,
LINE_NK,
BYTES
FROM STG_ACCESS_LOG
)
SELECT
CAST(STG.EVENT_DT AS INTEGER) AS EVENT_DT,
USG.DIM_USER_AGENT_ID,
HST.DIM_HTTP_STATUS_ID,
COUNT(DISTINCT (CASE WHEN INSTR(STG.REQUEST_NK,'.')=0 THEN STG.REQUEST_NK END) ) AS PAGE_CNT,
COUNT(DISTINCT (CASE WHEN INSTR(STG.REQUEST_NK,'.')>0 THEN STG.REQUEST_NK END) ) AS FILE_CNT,
COUNT(DISTINCT STG.REQUEST_NK) AS REQUEST_CNT,
COUNT(DISTINCT STG.LINE_NK) AS LINE_CNT,
COUNT(DISTINCT STG.IP_NR) AS IP_CNT,
SUM(BYTES) AS BYTES
FROM STG,
DIM_HTTP_STATUS HST,
DIM_USER_AGENT USG
WHERE STG.STATUS = HST.STATUS_NK
AND STG.USER_AGENT_NK = USG.USER_AGENT_NK
AND CAST(STG.EVENT_DT AS INTEGER) > $param_epoch_from /* load epoch date */
AND CAST(STG.EVENT_DT AS INTEGER) < strftime('%s', date('now', 'start of day'))
GROUP BY STG.EVENT_DT, HST.DIM_HTTP_STATUS_ID, USG.DIM_USER_AGENT_IDBaza danych sqlite umożliwia pisanie złożonych zapytań. Z zawiera przygotowanie danych i kluczy. Główne zapytanie zbiera wszystkie odniesienia do wymiarów.
Warunek nie pozwoli na ponowne załadowanie historii: CAST(STG.EVENT_DT AS INTEGER) > $param_epoch_from, gdzie parametr jest wynikiem żądania
„WYBIERZ COALESCE(MAX(EVENT_DT), '3600') JAKO LAST_EVENT_EPOCH Z FCT_ACCESS_USER_AGENT_DD”
Warunek zostanie załadowany tylko cały dzień: CAST(STG.EVENT_DT AS INTEGER) < strftime('%s', date('teraz', 'początek dnia'))
Liczenie stron lub plików odbywa się w sposób prymitywny, poprzez wyszukiwanie punktu.
Raporty
W złożonych systemach wizualizacji możliwe jest tworzenie metamodelu w oparciu o obiekty bazy danych, dynamiczne zarządzanie filtrami i regułami agregacji. Ostatecznie wszystkie przyzwoite narzędzia generują zapytanie SQL.
W tym przykładzie utworzymy gotowe zapytania SQL i zapiszemy je jako widoki w bazie danych - są to raporty.
Wizualizacja
Bluff: Jako narzędzie wizualizacji wykorzystano piękne wykresy w JavaScript
W tym celu należało przejrzeć wszystkie raporty przy pomocy PHP i wygenerować plik html z tabelami.
$sqls = array(
'SELECT * FROM RPT_ACCESS_USER_VS_BOT',
'SELECT * FROM RPT_ACCESS_ANNOYING_BOT',
'SELECT * FROM RPT_ACCESS_TOP_HOUR_HIT',
'SELECT * FROM RPT_ACCESS_USER_ACTIVE',
'SELECT * FROM RPT_ACCESS_REQUEST_STATUS',
'SELECT * FROM RPT_ACCESS_TOP_REQUEST_PAGE',
'SELECT * FROM RPT_ACCESS_TOP_REQUEST_REFERRER',
'SELECT * FROM RPT_ACCESS_NEW_REQUEST',
'SELECT * FROM RPT_ACCESS_TOP_REQUEST_SUCCESS',
'SELECT * FROM RPT_ACCESS_TOP_REQUEST_ERROR'
);Narzędzie po prostu wizualizuje tabele wyników.
Wniosek
Na przykładzie analizy sieciowej w artykule opisano mechanizmy niezbędne do budowy hurtowni danych. Jak widać z wyników, do głębokiej analizy i wizualizacji danych wystarczą najprostsze narzędzia.
W przyszłości na przykładzie tego repozytorium postaramy się wdrożyć takie struktury jak wolno zmieniające się wymiary, metadane, poziomy agregacji i integracja danych z różnych źródeł.
Przyjrzyjmy się także najprostszemu narzędziu do zarządzania procesami ETL w oparciu o jedną tabelę.
Wróćmy do tematu pomiaru jakości danych i automatyzacji tego procesu.
Przeanalizujemy problemy środowiska technicznego i utrzymania magazynów danych, dla których zrealizujemy serwer magazynujący przy minimalnych zasobach, na przykład oparty na Raspberry Pi.
Źródło: www.habr.com