<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Logging on Mi&amp;Bee Blog</title><link>https://blog.mickeyzzc.tech/en/tags/logging/</link><description>Recent content in Logging on Mi&amp;Bee Blog</description><generator>Hugo -- gohugo.io</generator><language>en</language><managingEditor>蓝宝石的傻话</managingEditor><lastBuildDate>Wed, 01 Jul 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://blog.mickeyzzc.tech/en/tags/logging/rss.xml" rel="self" type="application/rss+xml"/><item><title>Observability Storage Selection Guide: A Scenario-Driven Decision Framework</title><link>https://blog.mickeyzzc.tech/en/posts/telemetry/obs-tech-08-storage-selection-guide/</link><pubDate>Wed, 01 Jul 2026 00:00:00 +0000</pubDate><guid>https://blog.mickeyzzc.tech/en/posts/telemetry/obs-tech-08-storage-selection-guide/</guid><description>&lt;p&gt;The previous 7 articles in this series analyzed the storage architectures of each observability domain—TSDB, logging, tracing, RUM, profiling, and eBPF—in depth. This article synthesizes that knowledge into a &lt;strong&gt;scenario-driven storage selection decision framework&lt;/strong&gt;. Teams differ in scale, tech stack, budget, and requirements—there is no &amp;ldquo;best&amp;rdquo; storage, only the one that best fits your context. Use this article as a practical reference to quickly narrow down your options.&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;&lt;strong&gt;Beginner Analogy&lt;/strong&gt;: Choosing observability storage is like choosing a vehicle — there&amp;rsquo;s no &amp;ldquo;best&amp;rdquo; car, only the one that fits your journey. A startup needs a cost-efficient compact (Loki + VictoriaMetrics); an enterprise with compliance needs a heavy-duty truck (Elasticsearch); a platform team wants a versatile van (ClickHouse unified). The key dimensions: data volume, query patterns, budget, and team size.&lt;/p&gt;</description></item></channel></rss>