My main use case for InfluxDB involved working on a LEO satellite KPI monitoring application, where I gathered latency, throughput, packet loss, jitter, and various types of network data for several probes. We had around a lakh of probes, and I needed to gather information from all these probes and store it in a database. I chose InfluxDB because it is a highly reliable and purpose-built database used for storing and analyzing real-time network and performance metrics. It served as the core data store for latency, jitter, packet loss, and throughput KPIs I collected using tools such as iperf3, MTR, and custom Python scripts. Its strongest advantage was its ability to ingest high-frequency metric data with JSON-based metric payloads generated by automation scripts written efficiently using the Influx line protocol, enabling near real-time visibility through performance bottlenecks.

Regarding further integration of InfluxDB with my tools and scripts, I used Telegraf and Chronograf as well since InfluxDB was the database where I ingested all the data, including throughput, latency, packet loss, and jitter. Although I don't exactly remember all the network data types involved, the main problem was the amount of data. Although InfluxDB is a highly scalable database, the main challenge with InfluxDB, which is common with all databases, was handling very high throughput systems and high throughput message flow. Thus, I had to use Kafka as well, which generated Kafka topics and resolved the high throughput problem.

The best features of InfluxDB that I found most valuable during my projects are the time series capabilities because it is a time series database, allowing me to monitor real-time metrics of all network details. Networking generates a very high volume of data where even a second's delay can cause significant issues, as seen in the recent Cloudflare and Amazon outages. If the network is not operating properly, you cannot rely on the servers. Another important feature I found in InfluxDB is that while it can break under very high throughput data flow, it can still withstand a specific amount. Additionally, another helpful feature was InfluxDB's straightforward approach to aggregating or downsampling and analyzing KPIs over time, which was essential for identifying trends and performance degradation patterns. Overall, InfluxDB delivered excellent performance, stability, and simplicity for telemetry-driven use cases.

InfluxDB positively impacted my organization as we were working on the LEO satellite KPI monitoring project. With InfluxDB's help, we were able to parse the network details for almost a lakh of probes, which greatly helped our business grow and facilitated our stability in the market.

Although I didn't encounter any significant challenges, I think that if there was a NoSQL version of InfluxDB, that would also help because I have used the SQL version. I wish InfluxDB were also available in a NoSQL format similar to MongoDB, making it more user-friendly for those who are not database engineers.

I would emphasize that documentation is very important because while I have found some documentation, the integration parts and technical hurdles that people might face, such as specific producers or consumers, have not been mentioned properly. If better documentation were available, allowing me to find everything, including specific port numbers and procedures, it would have been much easier, and I wouldn't have had to spend time researching how to integrate InfluxDB with my Kafka producers and consumers.

I have been using InfluxDB for quite a long period of time, approximately two years, and the last time I used InfluxDB was in July, around four months back from now.

In my experience, InfluxDB has been stable. There were a few instances it broke down when I attempted to parse a large amount of data at once. However, after integrating Kafka, it never broke again, as Kafka handled messages and metrics appropriately, decreasing the message throughput.

Regarding further integration of InfluxDB with my tools and scripts, I used Telegraf and Chronograf as well since InfluxDB was the database where I ingested all the data, including throughput, latency, packet loss, and jitter. Although I don't exactly remember all the network data types involved, the main problem was the amount of data. Although InfluxDB is a highly scalable database, the main challenge with InfluxDB, which is common with all databases, was handling very high throughput systems and high throughput message flow. Thus, I had to use Kafka as well, which generated Kafka topics and resolved the high throughput problem.

I didn't have to reach out to customer support of InfluxDB, as it was relatively easy for me to integrate; therefore, I had no reason to contact customer support.

I have used almost all types of databases including NoSQL and SQL databases such as MongoDB, PostgreSQL, and PSQL, and I switched to InfluxDB because it was better than other databases for time series data because I needed live feeds from the network details I was gathering. The other databases I worked with weren't providing that very specific feature. Additionally, I was using Telegraf and Chronograf for visualization, and InfluxDB's direct integration with Chronograf made it very easy to use a database that already has built-in connectivity to the visualization tools.

The user interface of InfluxDB was pretty easily integrated using a server from where I installed InfluxDB from a Docker image on the official Docker website. I allowed the port numbers of InfluxDB to be customized through my Python script where all the network details were being stored initially. Therefore, I integrated the port number of the Kafka producer to InfluxDB's port number so that all the Kafka details and topics could pass those data towards InfluxDB.

I did evaluate other options before choosing InfluxDB, specifically PostgreSQL. However, since PostgreSQL doesn't offer direct connectivity with Chronograf, which I was using as my visualization tool, I opted for InfluxDB.

I would rate InfluxDB around an eight on a scale of one to ten.

I chose eight for my rating because it solved a lot of problems. It is a service for high throughput systems and a live database. However, I cannot ignore the challenges I faced while configuring the database with my message brokers, whether Rabbit or Kafka, because the documentation is not properly provided. Additionally, as I mentioned, having a NoSQL version of InfluxDB would make it better for those without SQL skills.

From a financial perspective, I felt that InfluxDB was cheaper than other SQL databases I have used, including PostgreSQL and PSQL. InfluxDB has been quite economical for our needs.

My advice for others looking into using InfluxDB is to be efficient and know the purpose of using it. Just because it is cheap doesn't mean it is better than other databases. While it is certainly effective, PostgreSQL may be better for storage needs. If you lack NoSQL skills, you may not use InfluxDB properly. It is crucial to read through the entire documentation and search online for integrating InfluxDB with other optimization tools and resources. I provided an overall rating of eight for InfluxDB.

A specific example of how I use InfluxDB in my monitoring system is that we gather the metrics from the devices with Prometheus, and then we use InfluxDB to store those data, then consume all the data in Grafana.

I connect everything together by running it in a Docker Compose.

The searching is useful for me because the query is easy to use and very stable, and it is comfortable to use to search for the different metrics.

InfluxDB has positively impacted my organization by solving a monitoring problem that we had, coming up with a solution since we did not have any monitoring system, allowing us to build one from scratch.

The impact includes time saved because with the metrics we can easily troubleshoot a lot of the incidents with the network, making it really useful, and we have the ability to gather a lot of metrics.

It could include automated backup and a monitoring solution for InfluxDB or a script developed by a REST API.

I chose an 8 out of 10 because there is room for improvement, such as regarding backups and enhanced security through other types of authentication or encrypted data in TLS.

My advice for others looking into using InfluxDB is to use it the same way I did, because it is really stable, easy and friendly to use, and it is a great product overall.

I gave this product a rating of 8 out of 10.

InfluxDB is a database where you can insert data. However, it would be best if you had different components for alerting, data sending, and visualization. You need to install tools to collect data from servers. It must be installed on Windows or Linux servers. During installation, ensure that the configuration file is correct to prevent issues. Once data is collected, it can be sent to InfluxDB. For visualization, you can use open-source tools like Grafana.

InfluxDB is generally stable, but we've encountered issues with the configuration file in our ticket stack. For instance, a mistake in one of the metrics out of a hundred KPIs can disrupt data collection for all KPIs. This happens because the agent stops working if there's an issue with any configuration part. To address this, it is essential to ensure that all configurations are part of the agent's EXE file when provided. This makes it easier to package the agent for server installation and ensures all KPIs are available from the server. Additionally, the agent cannot encrypt and decrypt passwords for authentication, which can be problematic when monitoring URLs or requiring authentication tokens. This requires additional scripting and can prolong service restart times.

I have been working with the product for five years.

My company has 20-30 admins and 4,000-5,000 users. We have around 15,000 servers.

If you deviate from their documentation, they may refuse to provide support, stating it's not covered under the agreement. Additionally, their response times are slow, and they often suggest purchasing premium support for quicker resolution.

When you opt for premium support, they usually assign dedicated consultants. This means that whenever you encounter a problem, you have direct access to experts whom you can call, email, or engage in a call to resolve issues.

The tool is an open-source product.

If you're considering using InfluxDB for the first time, I recommend trying it. It's an open-source database with the option to purchase enterprise support.
When purchasing the TICK stack, I recommend you opt for premium support. Premium support can be beneficial, particularly when encountering configuration issues or other challenges. With premium support, you can quickly reach out for assistance via phone and work towards resolving any issues promptly. Otherwise, you may wait for up to another week to resolve the problem.

Learning to use InfluxDB is not necessarily easy for a beginner. It requires some understanding, especially in areas like automation and scripting.

I would rate it as an open-source tool around seven to eight out of ten. You only need to spend money on the resources, not much on the product itself. Essentially, you need to invest in the database.