По мере роста переполнения стека мы начинаем внимательно следить за нашими журналами IIS для выявления проблемных HTTP-клиентов - таких, как мошеннические веб-пауки , пользователи, у которых большая страница обновляется каждую секунду, плохо написанные одноразовые веб-скребки, хитрость пользователи, которые пытаются увеличить число страниц, считают миллионы раз, и так далее.
Я придумал несколько запросов LogParser, которые помогают нам идентифицировать большинство странностей и отклонений при указании на файл журнала IIS.
Максимальное использование полосы пропускания по URL
SELECT top 50 DISTINCT
SUBSTR(TO_LOWERCASE(cs-uri-stem), 0, 55) AS Url,
Count(*) AS Hits,
AVG(sc-bytes) AS AvgBytes,
SUM(sc-bytes) as ServedBytes
FROM {filename}
GROUP BY Url
HAVING Hits >= 20
ORDER BY ServedBytes DESC
URL-адреса хиты Avgbyte служил ------------------------------------------------- - ---- ------- ------- /favicon.ico 16774 522 8756028 /content/img/search.png 15342 446 6842532
Самые популярные хиты по URL
SELECT TOP 100
cs-uri-stem as Url,
COUNT(cs-uri-stem) AS Hits
FROM {filename}
GROUP BY cs-uri-stem
ORDER BY COUNT(cs-uri-stem) DESC
хиты URL ------------------------------------------------- - ---- /content/img/sf/vote-arrow-down.png 14076 /content/img/sf/vote-arrow-up.png 14018
Максимальная пропускная способность и хиты по IP / User-Agent
SELECT TOP 30
c-ip as Client,
SUBSTR(cs(User-Agent), 0, 70) as Agent,
Sum(sc-bytes) AS TotalBytes,
Count(*) as Hits
FROM {filename}
group by c-ip, cs(User-Agent)
ORDER BY TotalBytes desc
клиентский агент-клиент насчитывает хиты ------------- ------------------------------------- -------- --------- ----- 66.249.68.47 Mozilla / 5.0 + (совместимо; + Googlebot / 2.1; 135131089 16640 194.90.190.41 omgilibot / 0.3 ++ omgili.com 133805857 6447
Максимальная пропускная способность по часам по IP / User-Agent
SELECT TOP 30
TO_STRING(time, 'h') as Hour,
c-ip as Client,
SUBSTR(cs(User-Agent), 0, 70) as Agent,
Sum(sc-bytes) AS TotalBytes,
count(*) as Hits
FROM {filename}
group by c-ip, cs(User-Agent), hour
ORDER BY sum(sc-bytes) desc
hr клиентский пользовательский агент хиты всего - ------------- ----------------------------------- ------ -------- ---- 9 194.90.190.41 omgilibot / 0.3 ++ omgili.com 30634860 1549 10 194.90.190.41 omgilibot / 0.3 ++ omgili.com 29070370 1503
Топ попаданий по часам по IP / User-Agent
SELECT TOP 30
TO_STRING(time, 'h') as Hour,
c-ip as Client,
SUBSTR(cs(User-Agent), 0, 70) as Agent,
count(*) as Hits,
Sum(sc-bytes) AS TotalBytes
FROM {filename}
group by c-ip, cs(User-Agent), hour
ORDER BY Hits desc
Клиентский пользовательский агент hr достигает тотбайтов - ------------- ----------------------------------- ------ ---- -------- 10 194.90.190.41 omgilibot / 0.3 ++ omgili.com 1503 29070370 12 66.249.68.47 Mozilla / 5.0 + (совместимо; + Googlebot / 2.1 1363 13186302
{Имя_файла}, конечно, будет путем к файлу журнала IIS, таким как
c:\working\sologs\u_ex090708.log
Я сделал много поисков в Интернете для хороших запросов IIS LogParser и нашел очень мало. Эти 5 выше очень помогли нам в выявлении серьезных проблемных клиентов. Но мне интересно - чего нам не хватает?
Какие есть еще способы нарезать и нарезать журналы IIS (желательно с запросами LogParser ), чтобы найти их для статистических аномалий? Есть ли у вас хорошие запросы IIS LogParser, которые вы запускаете на своих серверах?