Operations | Monitoring | ITSM | DevOps | Cloud

Latest Posts

Anomaly Detection for Time Series Data: Anomaly Types

Welcome to the second chapter of the handbook on Anomaly Detection for Time Series Data! This series of blog posts aims to provide an in-depth look into the fundamentals of anomaly detection and root cause analysis. It will also address the challenges posed by the time-series characteristics of the data and demystify technical jargon by breaking it down into easily understandable language. This blog post (Chapter 2) is focused on different types of anomalies.

Anomaly Detection for Time Series Data: An Introduction

Welcome to the handbook on Anomaly Detection for Time Series Data! This series of blog posts aims to provide an in-depth look into the fundamentals of anomaly detection and root cause analysis. It will also address the challenges posed by the time-series characteristics of the data and demystify technical jargon by breaking it down into easily understandable language. This blog post (Chapter 1) is focused on.

VictoriaMetrics Long-Term Support (LTS): Current State

We release VictoriaMetrics several times a month, including at least one major update. However, because these new releases often introduce new features, they may be less stable. That’s why we also regularly publish Long-term support releases (LTS) alongside our regular releases. These LTS versions focus exclusively on bug fixes without new features and performance improvements. We committed to publishing LTS versions every six months and supporting them for one year.

Monitoring Kubernetes costs with OpenCost and VictoriaMetrics

Control over operational costs is pivotal in Kubernetes' deployment and management. Although Kubernetes brings power and control over your deployments, it also necessitates thorough understanding and management of costs. OpenCost, specifically designed for Kubernetes cost monitoring, combined with VictoriaMetrics, an efficient time series database, offers a comprehensive solution for this challenge.

The BSL is a short-term fix: Why we choose open source

On August 13 2023, users of HashiCorp’s Terraform forked the software under the name OpenTF. This was a strong and rapid community reaction to HashiCorp switching the license on their products merely three days before. The list of companies and individuals pledging their support to the new fork has been overwhelming. The new license that HashiCorp has chosen for its products, the Business Source License (BSL), is no longer open source, but instead source-available.

Why we generate & collect logs: About the usability & cost of modern logging systems

Logs and log management have been around far longer than monitoring and it is easy to forget just how useful and essential they can be for modern observability. Most of you will know us for VictoriaMetrics, our open source time series database and monitoring solution. Metrics are our “thing”; but as engineers, we’ve had our fair share of frustrations in the past caused by modern logging systems that tend to create further complexity, rather than removing it.

Q2 Round Up: Roadmap Review & Q3 2023 Look Ahead

Many thanks to everyone who joined us for our recent virtual meetup, during which we discussed some of our Q2 2023 highlights, including features highlights, the 2023 roadmap for VictoriaMetrics and of course: The launch of VictoriaLogs! In this blog post, we’d like to share a summary of these highlights.

VictoriaMetrics bolsters move from monitoring to observability with VictoriaLogs release

Today we’re happy to announce our new open source, scalable logging solution, VictoriaLogs, which helps users and enterprises expand their current monitoring of applications into a more strategic ‘state of all systems’ enterprise-wide observability. Many existing logging solutions on the market today offer IT professionals a limited window into live operations of databases and clusters.

Never-firing alerts: What they are and how to deal with them

Alerting is one of the main reasons for having a monitoring system. It is always better to be notified about an issue before an unhappy user or customer gets to you. For this, engineers build systems that would check for certain conditions all the time, day and night. And when the system detects an anomaly - it raises an alert. Monitoring could break, so engineers make it reliable. Monitoring could get overwhelmed, so engineers make it scalable. But what if monitoring was just poorly instructed?