Devices, developers, applications, and services produce and utilize enormous amounts of JSON data every day. A portion of this data consists of time-stamped events or metrics that are a perfect match for storing and analyzing in InfluxDB. To help developers build the applications of the future, InfluxDB provides several ways to get JSON data into InfluxDB easily.

Gathering data to explore a problem with power outages creating connectivity issues and ultimately draining a laptop battery. Monitoring locations that have intermittent power and/or connectivity outages can be challenging. In this article, I’ll show how to use InfluxDB, an open source time series database, InfluxDB Cloud and Edge Data Replication to store data locally and send it to a central location whenever possible.

People often ask us, “What is the best query language to use with InfluxDB?” The answer to this question has evolved a bit over the years – and the current answer might surprise you.

Partitioning can provide a number of benefits to a sharding system, including faster query execution. Let’s see how it works. In a previous post, I described a sharding system to scale throughput and performance for query and ingest workloads. In this post, I will introduce another common technique, partitioning, that provides further advantages in performance and management for a sharding database.

At InfluxData, one of the common questions we regularly get asked by developers and architects alike the last few months is, “How does InfluxDB compare to MongoDB for time series workloads?” This question might be prompted for a few reasons. First, if they’re starting a brand new project and doing the due diligence of evaluating a few solutions head-to-head, it can be helpful in creating their comparison grid.

This article would not be possible without the contribution of Lars Stegman. The OPC UA Client Listener Plugin was his own contribution to a long-standing issue. Telegraf now includes a new plugin highly anticipated by the community. The OPC UA Client Listener Plugin. So you might be asking yourself: what is the big deal? There was already an OPC UA Plugin — how is this different?

Understand the two dimensions of scaling for database query and ingest workloads, and how sharding can make scaling elastic — or not. Scaling throughput and performance are critical design topics for all distributed databases, and sharding is usually a part of the solution. However, a design that increases throughput does not always help with performance and vice versa. Even when a design supports both, scaling them up and down at the same time is not always easy.

Mean time to resolution (MTTR) is a metric that transcends industry and technology. It’s a measure of how quickly, on average, support teams identify, act, and resolve IT issues and incidents. Because MTTR directly relates to service quality, maintaining a low MTTR is a critical goal for DevOps and SRE teams. These teams have a vested interest in resolving issues quickly because escalating incidents to higher levels of the support team increases response and resolution times.

Fluentd is an open source data collector capable of retrieving and receiving event data from several sources and then filtering, buffering, and routing data to different compatible destinations. It utilizes a plug-in system to help you quickly set up specific inputs, apply any required filtering, and send data to your preferred data ingestion platform. Fluentd supports multiple sources and destinations, and it can be deployed to multiple operating systems, including Windows, Linux, and macOS.