A lot of companies bequeath the projects that they build internally unto the world as open source. But they’re usually up for a pretty rude awakening when they ship their software and it has to be run for the first time by someone other than them.
Telemetry data – the metrics and measurement data emitted by all machines and devices from servers to robots – is exploding. Telemetry data generation is growing so fast, there are no reliable estimates of just what that growth rate looks like. Theo Schlossnagle, founder of Circonus and widely respected computer scientist, estimates that telemetry data is growing at the rate of 1×1012 every ten years. Suffice to say, that’s a lot.
The monitoring industry is changing rapidly. Gartner reports that by 2022, 50% of enterprise-generated data will be created and processed outside of a traditional data center or cloud, up from less than 10% in 2019 and that number could reach 75% by 2025.
Complex architectures, pressures to deploy faster, and demand for optimal performance have placed greater strain on monitoring teams and as a result, an increasing number are looking to implement more advanced monitoring techniques. Part of the initial challenge around this is understanding what advanced monitoring techniques actually are. In this article, I help clarify this by differentiating basic and advanced monitoring, with examples on how each would be applied to Postgres monitoring.
Whether you’re just beginning your monitoring journey or are a seasoned pro, being reminded of monitoring’s core principles is still helpful. From my own experience as a former SRE to what I’ve seen from our customers at Circonus, here are 10 essential monitoring tenets to live by.
In our era of rapid release cycles, engineers make frequent API updates in an effort to constantly improve user experiences. But while updates are designed with user benefits in mind, they can also have the opposite effect — potentially creating new performance issues. Ensuring that your APIs are meeting performance requirements and SLOs as you release new updates is dependent on correctly monitoring API latencies.
We’re pleased to share that Circonus saw record sales for the quarter ending June 30, 2021 and substantial year-over-year growth in annual recurring revenue (ARR). We’re experiencing significant momentum in 2021 as more organizations look to consolidate monitoring solutions, unify observability metrics across the stack, and manage a significantly greater volume of telemetry data.
Latency measurements have become an important part of IT infrastructure and application monitoring. The latencies of a wide variety of events like requests, function calls, garbage collection, disk IO, system-call, CPU scheduling, etc. are of great interest to engineers operating and developing IT systems. But there are a number of technical challenges associated with managing and analyzing latency data.
StatsD is a key unifying protocol and set of tools for collecting application metrics and gaining visibility into the performance of applications. StatsD as a protocol was created by Etsy in 2011 for emitting application metrics. Soon after, the StatsD Server was developed as a tool for receiving StatsD line protocol metrics and subsequently aggregating them. While there are no official backends as part of the StatsD ecosystem, Graphite became the most commonly used.
As more companies transform into service-centric, “always on” environments, they are implementing Site Reliability Engineering (SRE) principles like Service Level Objectives (SLOs). SLOs are an agreement on an acceptable level of availability and performance and are key to helping engineers properly balance risk and innovation.
