<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Metrics on Netdata</title><link>https://www.netdata.cloud/tags/metrics/</link><description>Recent content in Metrics on Netdata</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sat, 30 May 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://www.netdata.cloud/tags/metrics/index.xml" rel="self" type="application/rss+xml"/><item><title>High Cardinality Metrics At Scale: A Better Playbook</title><link>https://www.netdata.cloud/blog/high-cardinality-metrics-observability-scale/</link><pubDate>Sat, 30 May 2026 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/blog/high-cardinality-metrics-observability-scale/</guid><description>&lt;p>The &amp;ldquo;high cardinality is expensive&amp;rdquo; sentence has become observability&amp;rsquo;s version of &amp;ldquo;in this economy&amp;rdquo;: said so often that nobody questions whether it&amp;rsquo;s true. Every vendor pricing page invokes it. Every glossary article repeats it. Every architecture diagram shows aggregation buffers placed &lt;em>before&lt;/em> the storage layer.&lt;/p>
&lt;!--truncate-->
&lt;p>&amp;ldquo;High cardinality is expensive&amp;rdquo; is not a fact about the universe; it&amp;rsquo;s a fact about one architectural choice: centralizing time-series storage and querying it through an index that scales with unique series. Once you accept that choice, everything follows. You pay per metric, you drop labels you wish you&amp;rsquo;d kept, you pre-aggregate before storage, and you discover that the bug you were debugging only existed at the full resolution you already threw away.&lt;/p></description></item><item><title>OpenTelemetry Backend</title><link>https://www.netdata.cloud/opentelemetry/</link><pubDate>Wed, 20 May 2026 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/opentelemetry/</guid><description>An open OTEL backend with native OTLP ingestion, per-second granularity, ML anomaly detection, and infrastructure correlation. Traces coming soon. No per-metric pricing. No vendor lock-in.</description></item><item><title>OpenTelemetry and Netdata, Today</title><link>https://www.netdata.cloud/blog/opentelemetry-metrics-and-logs-ingestion/</link><pubDate>Fri, 15 May 2026 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/blog/opentelemetry-metrics-and-logs-ingestion/</guid><description>&lt;p>OpenTelemetry has become the default way to instrument applications and ship telemetry. The hard part has never been the data model. It&amp;rsquo;s been picking a backend that handles OTLP without quietly turning into a per-metric bill or a black box that swallows your data.&lt;/p>
&lt;p>Netdata is a native OTLP backend. Stand up an OpenTelemetry Collector with any of its hundreds of receivers, point its OTLP exporter at Netdata, and you get per-second charts, ML anomaly detection on every signal, AI-assisted troubleshooting, and infrastructure correlation, with no per-metric, per-series, or per-host charges. Metrics and logs work today. Trace support is coming soon.&lt;/p></description></item><item><title>Distributed Observability For Scale, Speed &amp; Control</title><link>https://www.netdata.cloud/features/dataplatform/metrics-management/</link><pubDate>Thu, 18 Dec 2025 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/features/dataplatform/metrics-management/</guid><description>Collect unlimited metrics at per-second granularity with zero configuration. Netdata&amp;rsquo;s edge-native architecture eliminates cardinality cost traps while delivering ML-based anomaly detection on every metric.</description></item><item><title>Netdata vs Graylog | Monitoring Tools Comparison</title><link>https://www.netdata.cloud/comparisons/graylog/</link><pubDate>Thu, 18 Dec 2025 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/comparisons/graylog/</guid><description>Netdata and Graylog serve different but complementary purposes in modern observability stacks. Netdata provides real-time infrastructure metrics monitoring with ML-based anomaly detection, while Graylog offers centralized log management for security analysis and forensic investigations. Together, they deliver complete observability.</description></item><item><title>Long-Term Data Storage and Retention in Netdata</title><link>https://www.netdata.cloud/blog/long-term-data-retention/</link><pubDate>Tue, 21 Jan 2025 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/blog/long-term-data-retention/</guid><description>&lt;p>Netdata&amp;rsquo;s database engine (dbengine) provides a sophisticated multi-tiered storage system designed for efficient long-term data retention while maintaining high granularity. This article explores the technical details of how Netdata handles metric storage, the advantages of its distributed architecture, and how to configure it for your specific needs.&lt;/p>
&lt;hr>
&lt;h2 id="database-engine-architecture">Database Engine Architecture&lt;/h2>
&lt;p>Netdata&amp;rsquo;s database engine provides a sophisticated, efficient solution for long-term metric storage through:&lt;/p>
&lt;ul>
&lt;li>Intelligent multi-tiered storage architecture&lt;/li>
&lt;li>Efficient compression and caching mechanisms&lt;/li>
&lt;li>Flexible retention strategies&lt;/li>
&lt;li>Distributed deployment options&lt;/li>
&lt;/ul>
&lt;p>This design enables organizations to maintain detailed historical data while optimizing storage use and maintaining query performance.&lt;/p></description></item><item><title>Anomaly detection on Prometheus metrics</title><link>https://www.netdata.cloud/blog/anomaly-detection-on-prometheus-metrics/</link><pubDate>Wed, 01 Mar 2023 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/blog/anomaly-detection-on-prometheus-metrics/</guid><description>&lt;p>&lt;img src="../2023-03-01-anomaly-detection-on-prometheus-metrics/img/img.png" alt="img">&lt;/p>
&lt;p>We have recently extended the native machine learning (ML) based anomaly detection &lt;a href="https://learn.netdata.cloud/guides/monitor/anomaly-detection">capabilities&lt;/a> of Netdata to &lt;a href="https://github.com/netdata/netdata/issues/14218">support all metrics&lt;/a>, regardless on their collection frequency (&lt;code>update every&lt;/code>).&lt;/p>
&lt;p>Previously only metrics collected every second were supported, but now Netdata can run anomaly detection out of the box with zero config on metrics with any collection frequency.&lt;/p>
&lt;p>This post will illustrate an example of what this means using &lt;a href="https://prometheus.io/">Prometheus&lt;/a> metrics (via the &lt;a href="https://learn.netdata.cloud/docs/agent/collectors/go.d.plugin/modules/prometheus#gsc.tab=0">Netdata Prometheus collector&lt;/a>) since they typically have a default collection frequency of 10 seconds.&lt;/p></description></item><item><title>Monitor any SQL metrics with Netdata (and Pandas ❤️)</title><link>https://www.netdata.cloud/blog/monitor-any-sql-metrics-with-netdata/</link><pubDate>Wed, 22 Feb 2023 00:00:00 +0000</pubDate><guid>https://www.netdata.cloud/blog/monitor-any-sql-metrics-with-netdata/</guid><description>&lt;p>&lt;img src="../2023-02-22-monitor-any-sql-metrics-with-netdata/img/img.png" alt="img">&lt;/p>
&lt;p>We recently got this great feedback from a dear user in our &lt;a href="https://discord.com/channels/847502280503590932/1075370683393118278/1075723915265069106">Discord&lt;/a>:&lt;/p>
&lt;blockquote>
&lt;p>I would really like to use Netdata to monitor custom internal metrics that come from SQL, not a fan of having 10 diff systems doing essentially the same thing as is, Netdata is pretty much all there in that regard, just needs a few extra features.&lt;/p>
&lt;/blockquote>
&lt;p>This is great and exactly what we want, a clear problem or improvement we could make to help make that users monitoring life a little easier.&lt;/p></description></item></channel></rss>