Comments 37
cat access.log | awk '{print $9}' | grep 200 | wc -l
А теперь представьте, что на сервере таймзона не +0400, а +0200
UFO just landed and posted this here
Хм, ну да. Тем не менее, способ разбора видится несколько ненадежным. Нужно больше регекспов.
Предложите тогда, пожалуйста, более «надежный» способ. Всем будет интересно. :)
Навскидку не готов. Но зато я придумал, до чего ещё докопаться: успешный запрос это не только код 200. Ещё как минимум есть 300-ые редиректы, а в спеке и 200-ых кодов хватает.
awk '{if($9==200)sum+=1}END{print sum}' access.log
Более того, там вообще весь скрипт можно на один awk заменить, чтобы лог дважды не читать. Особенно это будет полезно, если он большой:
awk '{sum+=1;if($9==200)ok+=1}END{printf "Passed: %3.2f%%\n", ok / sum * 100}' access.log
Спасибо, добавлю к статье если вы не против.
Да, конечно.
Сам скрипт, кстати, не совсем рабочий. В COUNT=`wc -l access.log` будет «количество_строк access.log» а не просто количество строк, из-за этого последний awk навернётся, т.к. в -v передастся оно криво, кавычек то у вас там нет (:
Сам скрипт, кстати, не совсем рабочий. В COUNT=`wc -l access.log` будет «количество_строк access.log» а не просто количество строк, из-за этого последний awk навернётся, т.к. в -v передастся оно криво, кавычек то у вас там нет (:
Для такого случая (требуется только результат) можно использовать перенаправление:
Переменная sum — лишняя. Для определения количества строк есть встроенная переменная NR (см. habrahabr.ru/company/centosadmin/blog/222469/#comment_7581431).
wc -l < FILENAME
Переменная sum — лишняя. Для определения количества строк есть встроенная переменная NR (см. habrahabr.ru/company/centosadmin/blog/222469/#comment_7581431).
Верно подмечено, очепяточка. Спасибо, исправлю.
Как-то году эдак в 1997, работал я в одной телефонной компании, которая эксплуатировала АТС, вываливающие свои логи в com порт, все это перемежалось какими-то асинхронными сообщениями, влезающими в середину нормальных записей и все портящих, короче еще тот недокументированный винегрет. Так вот, для пост-обработки всей этой неземной красоты, я начал пилить sed скрипт (к сожалению, за давностью лет он не сохранился). Где-то через пол года он вырос до ~1000! строк адского-ада и работал 10 минут (логи были большие), что напрягало. Выручили GNU flex и GNU bison, постобработка стала происходить за 10 секунд и, кончено, стало гораздо проще вносить изменения в код в случае появления новых типов сообщений.
Причем в данном примере таймзона вообще?
UFO just landed and posted this here
Это же все стандартные инструменты их вообще любой админ Linux использует, иначе как вообще на linux рабоать без их знания. Я думал напишите про что-нить вроде zabbix, chef, а лучше что-то новенькое, чего я не слышал)
Да, все верно, первая часть про стандартные инструменты. :) Это полезно для начинающих админов. Удивлять опытных юниксоидов не было задачи.
Про что-то новенькое напишем в следующих статьях.
Про что-то новенькое напишем в следующих статьях.
Если бы подобный пост был тогда, когда я линуксом только начал сталкиваться, то это сэкономило бы кучу времени. А так — толстенный талмуд по RHEL оказался наиболее информативной книжкой на тот момент (хотя и дистрибутив был другой). Так что не думаю, что лишним будет в копилке.
Хороший пост. Пригодится для начинающих админов и особенно для начинающих программистов.
Напишем простой скрипт для подсчета процента успешно обработанных запросов
Можно еще проще
awk '$9 == 200 { s++ } END { print s / NR * 100; }' access.log
Спасибо за структурную выкладку основных инструментов.
Хотелось бы в следующих статьях почерпнуть следующие аспекты:
— ваш личный best practice в мониторинге (оповещениях)
— реальные графики работы высоконагруженных серверов
— какой инструментарий для бекапа используется вами для разных типов данных (большой объем, большое количество, малый объем, малое количество, бекапы баз). Хотелось бы узнать ваш практический опыт в этом, какие инструменты используете в обоих направлениях (создание+восстановление бекапа)
— как проводится тестирование сервера до введения его в боевой режим
Хотелось бы в следующих статьях почерпнуть следующие аспекты:
— ваш личный best practice в мониторинге (оповещениях)
— реальные графики работы высоконагруженных серверов
— какой инструментарий для бекапа используется вами для разных типов данных (большой объем, большое количество, малый объем, малое количество, бекапы баз). Хотелось бы узнать ваш практический опыт в этом, какие инструменты используете в обоих направлениях (создание+восстановление бекапа)
— как проводится тестирование сервера до введения его в боевой режим
Есть ошибочка в формировании даты =)
Так вы месяц выводите, а не минуты. Скорее тогда уж так:
date +%H:%m -d "-1 hour"
Так вы месяц выводите, а не минуты. Скорее тогда уж так:
date +%H:%M -d "-1 hour"
А не подскажете чего-нибудь прочитать поподробнее про strace, а то как-то пока не довелось использовать? Ну кроме мана, естественно. Желательно на примерах.
Желательно почитать об архитектуре Linux/Unix в целом и о системных вызовах в частности (Таненбаума например). Можно и погуглить немного:
www.opennet.ru/base/dev/intercept_lnx.txt.html
rflinux.blogspot.ru/2008/03/linux-syscalls-linux.html
www.opennet.ru/base/dev/intercept_lnx.txt.html
rflinux.blogspot.ru/2008/03/linux-syscalls-linux.html
Невижу ssh в утилитах командной строки.
Она может быть не первая команда с коротой начинается изучение линукса, но точно первая с которой начинается рабочий день.
Она может быть не первая команда с коротой начинается изучение линукса, но точно первая с которой начинается рабочий день.
Напишем простой скрипт для подсчета процента успешно обработанных запросов.
Более правильный вариант для подсчета процента успешно обработанных запросов
И самый правильный вариант — использовать mod_status, а не городить огород из анализа access логов. А так же использовать custom лог со всей необходимой информацией.
P.S.
< access.log awk…
Sign up to leave a comment.
«Инструментарий системного администратора» или «Как мы работаем»