<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Filebeat on Giedrius Statkevičius</title><link>https://giedrius.blog/categories/filebeat/</link><description>Recent content in Filebeat on Giedrius Statkevičius</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Wed, 08 Jul 2020 20:28:27 +0000</lastBuildDate><atom:link href="https://giedrius.blog/categories/filebeat/feed.xml" rel="self" type="application/rss+xml"/><item><title>Crash-Only Software In Practice With Filebeat On Kubernetes</title><link>https://giedrius.blog/2020/07/08/crash-only-software-in-practice-with-filebeat-on-kubernetes/</link><pubDate>Wed, 08 Jul 2020 20:28:27 +0000</pubDate><guid isPermaLink="false">https://giedrius.blog/?p=676</guid><description>&lt;p&gt;Some time ago I read an article called &lt;a href="https://lwn.net/Articles/191059/"&gt;Crash-only software: More than meets the eye&lt;/a&gt;. It&amp;rsquo;s about an idea that sometimes it is easier and faster to just crash and restart the whole process than handle the error appropriately. Sometimes, obviously, it is even impossible to handle errors as in, for example, &lt;a href="https://en.wikipedia.org/wiki/Kernel_panic"&gt;Linux kernel panics&lt;/a&gt;. Nowadays programming languages especially tend to make it so that it would be very hard, almost impossible to &lt;em&gt;not&lt;/em&gt; handle errors. For instance, Rust has a &lt;a href="https://doc.rust-lang.org/std/result/enum.Result.html"&gt;type&lt;/a&gt; that either represents success or an error. You have to explicitly unwrap that type and decide what to do in either case. But, apart from those obvious cases, I haven&amp;rsquo;t seen any examples of crash-only software. Until recently.&lt;/p&gt;</description></item></channel></rss>