<?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>Monitoring on Brave New Geek</title><link>https://bravenewgeek.com/tag/monitoring/</link><description>Recent content in Monitoring on Brave New Geek</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Mon, 19 Feb 2024 14:21:05 -0700</lastBuildDate><atom:link href="https://bravenewgeek.com/tag/monitoring/index.xml" rel="self" type="application/rss+xml"/><item><title>Choosing Good SLIs</title><link>https://bravenewgeek.com/choosing-good-slis/</link><pubDate>Mon, 19 Feb 2024 14:11:17 -0700</pubDate><guid>https://bravenewgeek.com/choosing-good-slis/</guid><description>&lt;p&gt;&lt;img loading="lazy" src="https://bravenewgeek.com/wp-content/uploads/2024/02/dashboard-1024x671.jpg"&gt;&lt;/p&gt;
&lt;p&gt;Transitioning from an on-prem environment to a cloud environment involves a lot of major shifts for organizations. One of those shifts is often around how we monitor the overall health of systems. The typical way to measure things like the availability, reliability, and performance of systems is with SLIs or &lt;a href="https://sre.google/sre-book/service-level-objectives/"&gt;Service Level Indicators&lt;/a&gt;. SLIs are a valuable tool both on-prem and in the cloud, but when it comes to the latter, I often see organizations carrying over some operational anti-patterns from their data center environment.&lt;/p&gt;</description></item><item><title>Microservice Observability, Part 2: Evolutionary Patterns for Solving Observability Problems</title><link>https://bravenewgeek.com/microservice-observability-part-2-evolutionary-patterns-for-solving-observability-problems/</link><pubDate>Fri, 03 Jan 2020 14:18:10 -0600</pubDate><guid>https://bravenewgeek.com/microservice-observability-part-2-evolutionary-patterns-for-solving-observability-problems/</guid><description>&lt;p&gt;In &lt;a href="https://bravenewgeek.com/microservice-observability-part-1-disambiguating-observability-and-monitoring/"&gt;part one&lt;/a&gt; of this series, I described the difference between monitoring and observability and why the latter starts to become more important when dealing with microservices. Next, we’ll discuss some strategies and patterns for &lt;em&gt;implementing&lt;/em&gt; better observability. Specifically, we’ll look at the idea of an &lt;a href="https://bravenewgeek.com/the-observability-pipeline/"&gt;observability pipeline&lt;/a&gt; and how we can start to iteratively improve observability in our systems.&lt;/p&gt;
&lt;p&gt;To recap, observability can be described simply as the ability to ask questions of your systems without knowing those questions in advance. This requires capturing a variety of signals such as logs, metrics, and traces as well as tools for interpreting those signals like log analysis, SIEM, data warehouses, and time-series databases. A number of challenges surface as a result of this. &lt;a href="https://twitter.com/clintsharp"&gt;Clint Sharp&lt;/a&gt; does a great job &lt;a href="https://cribl.io/blog/the-observability-pipeline/"&gt;discussing&lt;/a&gt; the key problems, which I’ll summarize below along with some of my own observations.&lt;/p&gt;</description></item><item><title>Microservice Observability, Part 1: Disambiguating Observability and Monitoring</title><link>https://bravenewgeek.com/microservice-observability-part-1-disambiguating-observability-and-monitoring/</link><pubDate>Thu, 03 Oct 2019 10:55:23 -0500</pubDate><guid>https://bravenewgeek.com/microservice-observability-part-1-disambiguating-observability-and-monitoring/</guid><description>&lt;p&gt;“Pets versus cattle” has become something of a standard vernacular for describing the shift in how we build systems. It alludes to the elastic and dynamic nature of these (typically, but not necessarily) container-based systems with on-demand scaling and more transparent fault-tolerance. I’ve &lt;a href="https://bravenewgeek.com/the-observability-pipeline/"&gt;talked before about this transition&lt;/a&gt; before and specifically how it relates to monitoring. In particular, with these more dynamic, microservice-based systems, the conversation starts to shift away from traditional &lt;em&gt;monitoring&lt;/em&gt; toward &lt;em&gt;observability&lt;/em&gt;. In this series, I’ll describe that distinction, explain why it matters, and share some concrete tactical items for implementing observability in a microservice environment.&lt;/p&gt;</description></item><item><title>Authenticating Stackdriver Uptime Checks for Identity-Aware Proxy</title><link>https://bravenewgeek.com/authenticating-stackdriver-uptime-checks-for-identity-aware-proxy/</link><pubDate>Tue, 29 Jan 2019 14:46:43 -0600</pubDate><guid>https://bravenewgeek.com/authenticating-stackdriver-uptime-checks-for-identity-aware-proxy/</guid><description>&lt;p&gt;&lt;a href="https://cloud.google.com/stackdriver/"&gt;Google Stackdriver&lt;/a&gt; provides a set of tools for monitoring and managing services running in GCP, AWS, or on-prem infrastructure. One feature Stackdriver has is “uptime checks,” which enable you to verify the availability of your service and track response latencies over time from up to six different geographic locations around the world. While Stackdriver uptime checks are not as feature-rich as other similar products such as &lt;a href="https://www.pingdom.com/"&gt;Pingdom&lt;/a&gt;, they are also completely &lt;em&gt;free&lt;/em&gt;. For GCP users, this provides a great starting point for quickly setting up health checks and alerting for your applications.&lt;/p&gt;</description></item><item><title>The Observability Pipeline</title><link>https://bravenewgeek.com/the-observability-pipeline/</link><pubDate>Wed, 12 Sep 2018 11:37:24 -0500</pubDate><guid>https://bravenewgeek.com/the-observability-pipeline/</guid><description>&lt;p&gt;The rise of cloud and containers has led to systems that are much more distributed and dynamic in nature. Highly elastic microservice and serverless architectures mean containers spin up on demand and scale to zero when that demand goes away. In this world, servers are very much cattle, not pets. This shift has exposed deficiencies in some of the tools and practices we used in the world of servers-as-pets. It has also led to new tools and services created to help us support our systems.&lt;/p&gt;</description></item></channel></rss>