<?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>Logging on Giedrius Statkevičius</title><link>https://giedrius.blog/categories/logging/</link><description>Recent content in Logging 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/logging/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><item><title>ABCs of Logstash capacity planning</title><link>https://giedrius.blog/2019/08/13/abcs-of-logstash-capacity-planning/</link><pubDate>Tue, 13 Aug 2019 18:26:43 +0000</pubDate><guid isPermaLink="false">https://giedrius.blog/?p=574</guid><description>&lt;p&gt;Recently I had to do some capacity planning of this software that is relatively popular and it stands for the L in the ELK (Elasticsearch, Logstash, Kibana) stack so I thought that I should share what I have learned. While researching, I have found an appalling lack of information regarding this matter so I hope that this article will at least a bit help fill this void on the Internet.&lt;/p&gt;</description></item></channel></rss>