Блог BB-Admin

В прошлой заметке я рассказывал, как проверить температуру процессора семейства Core под Linux.

Под FreeBSD это делается еще проще, сначала необходимо загрузить модуль ядра, поддерживающий термальные сенсоры командой kldload coretemp. Можно проверить, загружен ли модуль в данный момент командой kldstat. После этого можно смотреть температуру всех ядер при помощи команды:

#sysctl -a | grep temperature

dev.cpu.0.temperature: 59
dev.cpu.1.temperature: 59
dev.cpu.2.temperature: 53
dev.cpu.3.temperature: 53
dev.cpu.4.temperature: 53
dev.cpu.5.temperature: 53
dev.cpu.6.temperature: 50
dev.cpu.7.temperature: 50

Как видно из вывода команды, текущая температура ядер находится в переменных sysctl вида dev.cpu.<номер ядра>.temperature.  Обратите внимание, что нумерация ядер начинается с нуля. Естественно, не составит труда написать шелл скрипт, который будет уведомлять о перегреве процессора.

Для того, чтобы проверить температуру ядер процессоров семейства Intel Core на Linux-системах можно воспользоваться утилитой lm_sensors. Он есть в стандартных репозиториях Centos и Debian.

Чтобы запустить сенсоры предварительно нужно детектировать их командой sensors-detect.  Во многих ОС модуль, поддерживающий снятие данных с датчиков процессоров не загружен по умолчанию, чтобы его включить нужно выполнить команду modprobe coretemp. После того, как сенсоры обнаружены, их можно запустить командой sensors. Утилита выведет список всех ядер с их температурами. Вывод команды легко распарсить для автоматической проверки шелл-скриптом, который будет проверять температуру процессора, и отправлять уведомления при превышении порогового значения.

Система мониторинга Nagios при проверке состояния Web-сервера проверяет не только его доступность, но и код ответа. По умолчанию, при получении кода 403, равно как и других 4xx и 5xx кодов ошибок, nagios выдаёт варнинг. Однако, если такой статус ответа нас устраивает, можно убрать варнинги. Для этого в конфиге commands.cfg нужно найти секцию с командой check_http, и в строке  command_line добавить опцию "-e HTTP". Команда дана для примера, такой вариант будет принимать, как нормальные, все коды ответов HTTP, можно прописать и более сложную фильтрацию ответов. По умолчанию, эта опция установлена в значение "-e OK", т.е. будет при любых кодах ответа, кроме HTTP 200 OK nagios будет выдавать варнинг.

Это рассказ о том, как полезен антихотлинк, и как опасны китайцы.
Никогда не стоит пренебрегать антихотлинком, даже если у вас не очень большой сайт, и пока проблемы хотлинков нет.  Иногда проблема всплывает очень внезапно:

На графиках cacti видно резкий всплеск трафика на сервере, и как сразу выяснилось, этот трафик давал всего лишь 1 единственный сайт. По логам было видно что почти все конекты идут напрямую к картинкам, и с реферером какого-то китайского домена.
После добавления простейшего антихотлинка в .htaccess ситуация сразу пришла в норму.

RewriteCond %{HTTP_REFERER} !^http://(www.)?domain.com/
RewriteRule .*[Jj][Pp][Gg]$|.*[Gg][Ii][Ff]$ - [F]

Всего лишь проверка http_referer-а и все китайцы отдыхают :)
Хоть и ничего особо страшного с этим сайтом не случилось, но всего за пару часов беспредела китайских друзей было израсходовано больше 10Гб трафика, а сайт находится на дешевом тарифном плане с 25Гб трафика в месяц. Так что вполне реально упустить факт антихотлинка и узнать о нём только по громадному счёту за оверьюз трафика от хостера, поэтому заботится о безопасности сайтов нужно заранее, а не по факту проблемы.

Много раз я слышал о резком падении трафика на праздники, и на этот Новый Год решил проверить это. С нескольких серверов с приличным трафиком постоянно собирается статистика по snmp, в том числе и трафика, которая преобразуется в графики при помощи Cacti.

Итак, эффект Нового Года действительно есть:

На первом сервере трафик 31 декабря просел почти на половину, также виден общий тренд падения пиков трафика в предыдущие дни.

При небольшой величине трафика спад заметен не так сильно, но всё же есть.

Как видно, 31 числа трафик падает довольно сильно, а уже первого числа почти восстанавливается до исходных значений.

Мало того, иногда трафик 1 января даже больше декабрьского, видимо все дорвались до интернета :)

Подытоживая, можно сказать что эффект падения трафика есть, по крайней мере на Новый Год точно, на другие большие праздники тоже будет интересно последить за трафиком, но вероятно эффект будет не столь велик. Вообще, я ожидал еще более серьёзного и резкого падения графиков 31 числа вечером, но так как сайты на серверах ориентированы на разные часовые пояса разница во времени сглаживает резкие перепады.