TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Making syslog() not block

37 pointsby jamesgpearceover 11 years ago

6 comments

phungeover 11 years ago
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 未加载
gyepiover 11 years ago
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 未加载
oofabzover 11 years ago
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 未加载
digitalsushiover 11 years ago
&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 未加载
geocarover 11 years ago
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 未加载
malkiaover 11 years ago
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.