<?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>Capacity-Planning on Giedrius Statkevičius</title><link>https://giedrius.blog/categories/capacity-planning/</link><description>Recent content in Capacity-Planning on Giedrius Statkevičius</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Sun, 10 May 2020 11:05:27 +0000</lastBuildDate><atom:link href="https://giedrius.blog/categories/capacity-planning/feed.xml" rel="self" type="application/rss+xml"/><item><title>Load Testing Thanos Query (StoreAPI)</title><link>https://giedrius.blog/2020/05/10/load-testing-thanos-query-storeapi/</link><pubDate>Sun, 10 May 2020 11:05:27 +0000</pubDate><guid isPermaLink="false">https://giedrius.blog/?p=437</guid><description>&lt;h2 id="intro"&gt;Intro&lt;/h2&gt;
&lt;p&gt;Thanos Query is the component of &lt;a href="https://thanos.io"&gt;Thanos&lt;/a&gt; that fans out a query to one or more nodes that implement the &lt;a href="https://thanos.io/integrations.md/#storeapi"&gt;StoreAPI&lt;/a&gt; and then it can deduplicate the results. It also implements the Prometheus API which lets you use it via Grafana.&lt;/p&gt;
&lt;p&gt;Any of the other components may be the receivers:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Thanos Receive;&lt;/li&gt;
&lt;li&gt;Thanos Rule;&lt;/li&gt;
&lt;li&gt;Thanos Sidecar;&lt;/li&gt;
&lt;li&gt;Thanos Compact;&lt;/li&gt;
&lt;li&gt;Thanos Query itself.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;It is tricky to know how much resources you will need for any given deployment of Thanos Query because it depends on a lot of different criteria. So, to know that and to actually test the limits in practice, you ought to perform what is commonly called a load/stress test. We will use a tool called &lt;a href="https://github.com/thanos-io/thanosbench/"&gt;thanosbench&lt;/a&gt; to do that in this tutorial.&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><item><title>Capacity planning of Prometheus 2.4.2 + Thanos Sidecar 0.1.0</title><link>https://giedrius.blog/2018/12/16/capacity-planning-of-prometheus-2-4-2-thanos-sidecar-0-1-0/</link><pubDate>Sun, 16 Dec 2018 19:35:38 +0000</pubDate><guid isPermaLink="false">https://giedrius.blog/?p=313</guid><description>&lt;figure&gt;
&lt;img loading="lazy" src="https://giedrius.blog/wp-content/uploads/2018/12/devops-what-is.png" width="955"/&gt;
&lt;/figure&gt;
&lt;h1 id="intro"&gt;Intro&lt;/h1&gt;
&lt;p&gt;Having a monitoring infrastructure is one of the tenets of the DevOps world. And, it seems that Prometheus and all of its extraneous integrations such as Thanos or Uber&amp;rsquo;s M3DB is taking over that world slowly. They give you a lot of improvements over the old Graphite set-ups such as increased reliability since Prometheus is based on HTTP which uses TCP thus you explicitly know when something goes wrong compared to UDP; it uses a pull based model so you explicitly know when something goes wrong and so on.&lt;/p&gt;</description></item></channel></rss>