我使用raven和getsentry在django中记录消息,但是日志记录似乎延迟了代码的执行。例如:
# ...view code
tic = datetime.datetime.now()
logging.warning('foo warning')
toc = datetime.datetime.now()
print "log time %s, %s, %s" % (tic, toc, (toc - tic).total_seconds())
# more view code...
给出输出:
log time 2013-09-25 12:03:56.541091, 2013-09-25 12:03:57.139420, 0.598329
即在这种情况下它将代码的执行延迟600ms。这是预期的吗?我原本以为该消息将在一个单独的线程中发送异步,因此主代码不会被延迟。另外我对app.getsentry.com的ping时间是125ms,所以即使消息是同步发送的,600ms仍然看起来很奇怪。是否有一些配置我可以改变以使事情更快?
设置文件:
LOGGING = {
'version': 1,
'disable_existing_loggers': True,
'handlers': {
'sentry': {
'level': 'INFO',
'class': 'raven.contrib.django.raven_compat.handlers.SentryHandler',
},
},
'loggers': {
'': {
'handlers': ['sentry'],
'level': 'INFO',
'propagate': True,
},
}
}
===编辑===
感谢FilipDupanović指出了线程+协议。可悲的是,由于在启动工作人员时复制了线程,他们并没有在枪支中为我工作。我通过在gunicorn配置文件中添加post_fork挂钩来修复它,如下所示:
import logging
from raven.contrib.django.handlers import SentryHandler
from raven.transport.threaded import ThreadedHTTPTransport
def post_fork(server, worker):
LOG = logging.getLogger()
for handler in LOG.handlers:
if isinstance(handler, SentryHandler):
for url, transport in handler.client._registry._transports.items():
if isinstance(transport, ThreadedHTTPTransport):
if hasattr(transport, '_worker'):
server.log.info("deleting sentry thread worker attribute")
delattr(transport, '_worker')
else:
server.log.info("sentry thread worker not present, nothing to do.")
Obv这是一个黑客攻击,虽然它适用于我,但我不知道它是否适用于其他地方。
答案 0 :(得分:1)
如果您使用托管的Sentry服务,您可能会切换到Raven完全支持的threaded+http
传输。有关如何在服务名称中正确配置传输,请查看Raven's documentation。
您可能还想尝试切换到其他一些专门的并发传输或UDP协议。虽然你无法将ICMP请求延迟与TCP进行比较,但是增加的开销是非常可怕的并且可以解决,所以不要害怕!