Analitycs

Показаны сообщения с ярлыком log. Показать все сообщения
Показаны сообщения с ярлыком log. Показать все сообщения

понедельник, 16 июля 2012 г.

Как найти долгие запросы в Tornado?

Если нужно посмотреть, какие http запросы в Tornado (ну или в чем-то подобном) выполняются больше определенного времени.

Пример лог-файла

[I 120704 17:24:50 application:264] 200 GET /session/info/ (xxx.33.251.70) 138.56ms
[I 120705 18:17:15 application:264] 200 GET /catalog/xxxx/(xxx.33.251.70) 572.84ms
[I 120706 12:24:53 application:264] 200 GET /session/info/ (xxx.33.251.70) 127.04ms
[I 120706 13:03:12 application:264] 200 GET /session/login/ (xxx.33.251.70) 10.36ms
[I 120706 13:05:04 application:264] 200 GET /session/info/ (xxx.33.251.70) 209.89ms
[I 120706 13:06:59 application:264] 200 GET /session/info/ (xxx.33.251.70) 10.08ms
[I 120710 16:50:53 application:274] 200 GET /session/info/ (xxx.33.251.70) 171.46ms

Команда

# grep '200 GET' ./log/webapp.log |  sed 's/ms/ ms/g' | awk '{ if ($9 > 100 ) print $p0'}

Где 100 - минимальное время запроса

четверг, 15 марта 2012 г.

Logging в Tornado

После большого рефакторинга проекта на Tornado пропало логгирование в stdout. То есть ошибки писались только в stderr, который выводился в лог сидящего уровнем выше сервиса  Supervisord (который за сервисом, собственно говоря, и наблюдал).

После небольшой отладки выяснилось, что проблема была в одной строчке, случайно удаленной из проекта

tornado.options.parse_command_line()

То есть должно быть примерно так

def main(): 
    application = tornado.web.Application([ 
        (r"/", MainHandler), 
    ]) 
    # this line will setup default logging no matter if you use command options 
    tornado.options.parse_command_line()
    logging.info("starting torando web server") 
    http_server = tornado.httpserver.HTTPServer(application) 
    http_server.listen(8888) # hardcoded port 
    tornado.ioloop.IOLoop.instance().start() 

После восстановления строчки-"беглянки" лог торнадовского приложения выглядит как положено


mneradkov@mneradkov-thinkpad:~/workspace/mysuperproject$ ./webapp.py 
[I 120315 16:33:28 mixins:28] [INFO] Directory [/home/mneradkov/workspace/mysuperproject]
[I 120315 16:33:28 mixins:28] [INFO] Connected to MySQL [xx.xx.xx.xx:xxxx]
[I 120315 16:33:28 mixins:28] [INFO] Connected to memcache [127.0.0.1:11211]
[I 120315 16:33:28 mixins:28] [INFO] 
[I 120315 16:33:28 mixins:28] [INFO] Server [My Super Server] version [X.Xalpha] binded to [127.0.0.1:11100]
[I 120315 16:33:28 webapp:37] Starting I/O loop to serve requests...

вторник, 29 ноября 2011 г.

Как включить показ ошибок PHP в браузере?

Классический вопрос всех похапешников - "как показать ошибки PHP скрипта в окне браузера"

error_reporting(E_ALL);
ini_set("display_errors", 1);

P.S. Причем сам постоянно забываю, как точно пишется эта конструкция - особенно после переключения с языка на язык. Ненавижу переключать контекст мозга ;-)

среда, 23 ноября 2011 г.

PHP - хак быстрого логгирования в файл


Если вам в зубы выдали какой-то очередной супер-мега-пупер проект на PHP, в дебрях которого нет возможности и желания разбираться, однако нужно что-то быстро пофиксить с отладкой, (причем доступа к php error_log нету) - то можно быстро воткнуть небольшой полезный хак.

Это дополнительный метод в класс (или просто - функция) с минимальным количеством кода.

   function log($msg) {
       file_put_contents(SUPER_CMS_ROOT_PATH.'/cache/php-debug.log',"\n".$msg, FILE_APPEND);
   }

Соотвественно, после отладки ее можно либо убить, либо оставить, закомментировав содержимое.

P.S. И да -про некошерность данного метода и недопустимости этого при учете всех методик программирования - я в курсе, не нужно возбуждаться. ;-)
Просто нужно пофиксить и отладить - БЫСТРО.

четверг, 3 ноября 2011 г.

Python, Twisted, logging - Как логгировать несколько процессов/демонов в один файл?

Давайте поговорим немного про логгирование в Python.

Да, меня это ДЕЙСТВИТЕЛЬНО беспокоит, и я хочу об этом поговорить ;-)

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

В общем, мораль сей басни такова...

Есть в Python СТАНДАРТНЫЙ модуль logging  - его и нужно использовать для разного типа логгирования. Батарейка-то уже включена ;-)

Чтобы пример кода не был совсем тривиальным - приведу решение для той ситуации, когда у нас есть несколько многопроцессных РАЗНЫХ демонов на Twisted на одной машине, а еще и cron-скрипт запускается время от времени. И всю жизнедеятельность этого дурдома нужно логгировать в один файл

import os
import logging
from twisted.python import log                                                                                   

CURRENT_PATH = os.path.realpath(os.path.dirname(__file__))

# Все это "по уму" обычно запихивается в нормальный конфиг-файл
LOG_DIR = os.path.join(CURRENT_PATH, 'logs')                            
LOG_FILE = os.path.join(LOG_DIR, 'super-puper.log')  
LOG_LEVEL = logging.INFO
 
# инициализируем
FORMAT = ('%(asctime)-15s %(levelname)s %(message)s') 

if not os.path.exists(LOG_DIR):
    os.mkdir(LOG_DIR) 
 
logging.basicConfig(format=FORMAT, filename=LOG_FILE, handler=logging.handlers.RotatingFileHandler)   
observer = log.PythonLoggingObserver(loggerName='twisted')
observer.start()
observer.logger.setLevel(LOG_LEVEL)  

# класс-примесь для логгирования - в принципе - необязательно, реализация может быть разная - хоть функциями
class BasicLogClass():

    def _log(self, msg):
        log.msg(msg, logLevel=logging.INFO)

    def _error(self, msg):
        log.msg(msg, logLevel=logging.ERROR)

    def _warning(self, msg):
        log.msg(msg, logLevel=logging.WARNING)

В данном варианте работоспособность не проверял, но логика применения именно такая - выкусил из работающего проекта.

Кстати, если у кроновских скриптов нет использования twisted'овского reactor, то могуть быть проблемы, нужно подумать. Как вариант - использовать развилку в инициализации и логгировании без применения observer, но не уверен.