<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>federation &#8211; Robust Perception | Prometheus Monitoring Experts</title>
	<atom:link href="/tag/federation/feed" rel="self" type="application/rss+xml" />
	<link>/</link>
	<description>Prometheus Monitoring Experts</description>
	<lastBuildDate>Mon, 21 Dec 2020 10:29:21 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=5.9.3</generator>

<image>
	<url>/wp-content/uploads/2015/07/cropped-robust-icon-32x32.png</url>
	<title>federation &#8211; Robust Perception | Prometheus Monitoring Experts</title>
	<link>/</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>Policy is for configuration, not metric names</title>
		<link>/policy-is-for-configuration-not-metric-names</link>
		
		<dc:creator><![CDATA[Brian Brazil]]></dc:creator>
		<pubDate>Mon, 21 Dec 2020 10:29:21 +0000</pubDate>
				<category><![CDATA[Posts]]></category>
		<category><![CDATA[best practices]]></category>
		<category><![CDATA[federation]]></category>
		<category><![CDATA[prometheus]]></category>
		<category><![CDATA[relabelling]]></category>
		<category><![CDATA[remote write]]></category>
		<guid isPermaLink="false">https://www.robustperception.io/?p=5845</guid>

					<description><![CDATA[Metric names are part of a time series's identity, so shouldn't include information unrelated to identity. I previously looked at some of the consideration for choosing target labels. Similar applies to the names of metrics, you want something descriptive but not longer than it needs to be. In this context, I'd like to talk about [&#8230;]]]></description>
		
		
		
			</item>
		<item>
		<title>Federation, what is it good for?</title>
		<link>/federation-what-is-it-good-for</link>
		
		<dc:creator><![CDATA[Brian Brazil]]></dc:creator>
		<pubDate>Mon, 16 Jan 2017 13:24:39 +0000</pubDate>
				<category><![CDATA[Posts]]></category>
		<category><![CDATA[best practices]]></category>
		<category><![CDATA[federation]]></category>
		<category><![CDATA[prometheus]]></category>
		<category><![CDATA[promql]]></category>
		<category><![CDATA[scaling]]></category>
		<guid isPermaLink="false">https://www.robustperception.io/?p=2421</guid>

					<description><![CDATA[There's various ways Prometheus federation can be used. To ensure your monitoring is scalable and reliable, let's look at how to best use it. There are two general cases for which federation is well suited. We'll look at each in turn. Prometheus Hierarchy As previously discussed, Prometheus is intended to have at least one instance per datacenter usually [&#8230;]]]></description>
		
		
		
			</item>
		<item>
		<title>Scaling and Federating Prometheus</title>
		<link>/scaling-and-federating-prometheus</link>
		
		<dc:creator><![CDATA[Brian Brazil]]></dc:creator>
		<pubDate>Fri, 14 Aug 2015 13:43:03 +0000</pubDate>
				<category><![CDATA[Posts]]></category>
		<category><![CDATA[federation]]></category>
		<category><![CDATA[prometheus]]></category>
		<category><![CDATA[scaling]]></category>
		<guid isPermaLink="false">http://www.robustperception.io/?p=690</guid>

					<description><![CDATA[A single Prometheus server can easily handle millions of time series. That's enough for a thousand servers with a thousand time series each scraped every 10 seconds. As your systems scale beyond that, Prometheus can scale too. &#160; Initial Deployment When starting out it's best to keep things simple. A single Prometheus server per datacenter or [&#8230;]]]></description>
		
		
		
			</item>
	</channel>
</rss>
