TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Making syslog() not block

37 点作者 jamesgpearce超过 11 年前

6 条评论

phunge超过 11 年前
For new projects that aren&#x27;t already tied to syslog(), Apache Kafka is also an interesting library to look at.<p>I&#x27;ve always felt that using UDP is an uneasy tradeoff -- you&#x27;re solving the problem of blocking, but at the cost of getting no batching whatsoever. When you&#x27;re logging to disk, TCP, or memory, the fast path call to log just plops your data into a buffer and returns to you. More messages, the bigger your buffer gets. With UDP, each message instead goes straight to the NIC and out.<p>Kafka makes a different tradeoff -- buffer&#x2F;batch to disk. Once you have enough data, compress it and ship it off reliably. If your consumer goes away, buffer as much as you can before losing messages; disk is cheap! The cost comes as small additional latency. In the fast path, it&#x27;s quick (data stays RAM resident, and it&#x27;s much cheaper to compress &amp; batch send 1000 messages than 1000 UDPs).
评论 #7220596 未加载
gyepi超过 11 年前
I hate to be that guy, but this software (with a patent, natch) is definitely not the first or best solution to the potential problem of the &#x2F;dev&#x2F;log buffer filling up.<p>If the standard syslogd is inadequate, how about using a different logger? Gerritt Pape&#x27;s svlogd, an implementation of DJB&#x27;s daemontools loggers, solves this problem very nicely, is very reliable, can log over UDP <i>and</i> write to disk if desired. Heck, it can even replace syslog and run more reliably.<p>Not to say that this software is not useful. It is a great solution if the client software insists on using syslog and cannot be modified or reconfigured and syslogd cannot be modified or replaced. However, these are quite specific and generally unusual cases. For more prosaic circumstances, there are simpler and better solutions.
评论 #7220438 未加载
评论 #7220404 未加载
oofabz超过 11 年前
What happens when a program logs messages faster than the log daemon can process them? Since it&#x27;s non-blocking, the program no longer pauses to wait for it to catch up.<p>Does it drop messages in this situation? Is that why you warn that &quot;liblogfaf should not be used in an environment where reliable log message delivery is required.&quot;? That is probably the most elegant solution.
评论 #7220261 未加载
评论 #7220700 未加载
digitalsushi超过 11 年前
&quot;liblogfaf is BSD-licensed. We also provide an additional patent grant.&quot;<p>Hi, I am a country bumpkin nerd. What does this mean, please? Thanks.
评论 #7220692 未加载
评论 #7220280 未加载
geocar超过 11 年前
My knee-jerk reaction is that this is a terrible idea. Why would someone do this?<p>Is this to workaround programs that respond to logs and can deadlock when logging (e.g. logrotate)? Workaround other broken programs (noncritical logspam at emergency level)?
评论 #7220263 未加载
malkia超过 11 年前
I wish that was easy on Windows too (not the logging, but LD_PRELOAD) - and yes, there are many hooking libraries (vld, google-perflibs, various anti-viruses etc.) - but I can always find failure cases for them.<p>e.g. I wish there was less magic (or whole mini-industry) behind hooking functions this way.