Proactive monitoring has reduced incidents and supports faster, data-driven decisions
What is our primary use case?
My main use case for InfluxDB has been mostly for monitoring and analyzing the time-series data related to system metrics, and also tracking logs and API performance. In my current role, I use it to track trends and anomalies in the system's health, while I am also able to help identify performance issues early and support root-cause analysis.
In my current role, I have used InfluxDB to monitor API responses, time, and server CPU usage in real-time. For example, I have set up continuous queries in InfluxDB to aggregate metrics such as average response time per minute and CPU load per server. This data feeds into the dashboards and then alerts the team when thresholds are breached, such as a spike in response time or CPU usage above eighty percent. When an alert triggers, I analyze the time-series data in InfluxDB to identify patterns or anomalies, which also helps pinpoint root causes quickly, such as a specific API endpoint. I have used this method for proactive monitoring, which reduces downtime and improves system reliability.
One scenario that really stands out is when we noticed intermittent spikes in API response time, which was affecting user experiences. Using InfluxDB, I was able to quickly analyze the time-series data, which correlated these spikes with specific backend processing runtime at the same time. This insight helped me identify a resource connection issue on certain servers. When we optimized the scheduling of those processes, it stabilized the response time and improved overall system reliability. I leverage InfluxDB as a core part of my monitoring workflow by continuously collecting and aggregating system metrics. This approach ensured that we maintain a balance between adding new features and keeping the system stable and performant.
What is most valuable?
The best InfluxDB features I think are its high-performance time-series storage and also a powerful query language and built-in support for down-sampling and continuous queries and real-time alerting, scalability and clustering options, and also the integrations with visualization tools. These are the features that help deliver a reliable, scalable solution.
I lean more on the query language because it gives me the most control and flexibility to analyze the data in-depth. While real-time alerting is more important for immediate notification, we have the ability to write complex queries with Flux, which allows me to explore data patterns and perform detailed root-cause analysis. The clustering is also valuable for scalability and high availability, but in my day-to-day work, the query language is the tool I use mostly to extract meaningful insights and drive decisions.
InfluxDB has had a significant positive impact on my organization. It has helped by enabling real-time visibility into system performance and user behavior. It helped our organization to quickly identify and resolve performance bottlenecks, which reduced downtime and improved user experience. This also has the ability to build custom dashboards and perform detailed time-series analysis, which has empowered both technical teams and business stakeholders to make data-driven decisions faster. This is how it has improved operational efficiency and allowed us to proactively address issues before they affect customers. Overall, InfluxDB has played a key role in enhancing system reliability and supporting our goal of delivering a seamless, high-quality product.
What needs improvement?
One thing I appreciate about InfluxDB is its balance between performance and ease of use, especially with Flux making complex queries accessible. However, I do wish the documentation and community resources around Flux were more extensive and beginner-friendly. Additionally, InfluxDB handles time-series data well, but deeper native support for anomaly detection or machine learning integrations would be great. Overall, it is a strong platform, and these enhancements could really make it even more powerful for data-driven teams.
InfluxDB is a strong platform, but there are a few areas where it could improve to better serve users and businesses. I would start with expanding and simplifying the documentation and community resources around its query language. It would help new users onboard faster and use the tool more effectively. Secondly, deeper native support for advanced analytics through machine learning integrations would add significant value by automating insights. The next thing I see is that enhancing the user experience around alerting, making it more intuitive and customizable, could really improve operational responsiveness. Lastly, better multi-tenant and role-based access control would really help organizations manage their security and collaboration more effectively. These improvements would make InfluxDB even more powerful and user-friendly for diverse teams.
From a performance perspective, enhancing InfluxDB scalability for very high cardinality data sets would be beneficial as some use cases generate massive volumes of unique time-series. Improving the query optimization to reduce latency on complex queries would also help maintain responsiveness. On the integration side, expanding the native connectors to popular cloud platforms and data tools such as AWS services, BI platforms, and machine learning would be great. These improvements would make InfluxDB more adaptable and performant.
For how long have I used the solution?
I have been using InfluxDB for at least three to four years.
What do I think about the stability of the solution?
InfluxDB has proven to be very stable in our environment. We have used it to support mission-critical systems with continuous data ingestion and real-time analytics, and it is stable.
What do I think about the scalability of the solution?
InfluxDB is highly scalable, which is one of its key strengths. It can handle large volumes of time-series data and with high ingestion rates, making it suitable for enterprise-scale deployments. This ensures consistent performance as data grows. Additionally, its retention policies and down-sampling features help manage stored data while maintaining query efficiency. In my experience, InfluxDB's scalability has allowed us to grow our monitoring and analytics capabilities without major re-architecture.
How are customer service and support?
Customer support was really solid and responsive. In my experience, especially with enterprise deployments, having reliable support is crucial for maintaining uptime and resolving issues quickly. The InfluxDB support team was knowledgeable and helped us troubleshoot complex problems efficiently. They also provided guidance on best practices for scaling and optimizing performance. This support helped us avoid prolonged downtime and ensured smooth operation, which was important for our mission-critical systems. Overall, the support experience gave us confidence in using InfluxDB at scale.
How would you rate customer service and support?
Which solution did I use previously and why did I switch?
Before InfluxDB, we used traditional relational databases and some open-source time-series tools which lacked the scalability and real-time capabilities. For example, we initially relied on PostgreSQL for time-series data, but it struggled with high ingestion rates and complex queries on large data sets. We switched to InfluxDB because it is purpose-built for time-series data, offering better performance. This switch has really improved our ability to handle large volumes of metrics and logs efficiently, reduced query latency, and simplified our data architecture, which was critical for supporting real-time monitoring and analytics use cases.
What was our ROI?
We have seen a clear return on investment with InfluxDB. One specific metric I would like to share is related to our operational efficiency, where we have been automating real-time monitoring and alerting on system metrics using InfluxDB. We reduced manual incident detection time by about forty percent. This has allowed our team to proactively address issues faster, improving system uptime and reducing downtime cost. Additionally, automating these processes reduced the need for manual monitoring efforts, saving roughly twenty percent of the analytics team's time, which we redirected to higher-value tasks. These improvements translated into both cost savings and better service reliability, directly impacting business outcomes.
What's my experience with pricing, setup cost, and licensing?
My experience with InfluxDB pricing and licensing has been generally positive, based on some considerations. Pricing is based on data volume, retention, and features, which really makes it scalable but requires careful planning to avoid unexpected costs. Cost management also involves monitoring data ingestion rates and retention policies closely to balance storage cost with business needs. The licensing terms are flexible enough to accommodate growth, but it is important to align with usage patterns to maximize ROI. Overall, the investment in InfluxDB has been justified by the reliability and insights it delivers, but it is important to have a clear cost strategy.
Which other solutions did I evaluate?
Before choosing InfluxDB, we evaluated several other time-series database options such as TimescaleDB and OpenTSDB. Prometheus was really strong for monitoring, but it lacked long-term storage and advanced querying capabilities we needed. TimescaleDB offered good SQL compatibility, but it did not scale as well for our high ingestion rates. OpenTSDB was considered, but it had more complex setups and maintenance overhead. InfluxDB stood out because of its balance of scalability, ease of use, rich query language, and strong community and enterprise support. This evaluation process helped us select the best fit for our specific business and technical requirements.
What other advice do I have?
My advice for others looking into using InfluxDB would be to clearly define their time-series data use cases upfront to ensure that InfluxDB fits their needs, especially for high-frequency metrics or event data. Also, plan for scalability by evaluating whether the open-source or enterprise version fits their expected data volume and query load. Additionally, set up the proper monitoring and alerting on InfluxDB clusters to catch issues. Finally, engage with the community and support channels to stay updated on best practices and new features. From my experience, these steps helped ensure a smooth implementation and long-term success with InfluxDB.
InfluxDB is a strong choice for time-series, especially when you really need real-time insights and efficient storage of high-volume metrics. The flexibility of a query language such as Flux allows for powerful data analysis, but it also does require some learning investment. From a product perspective, balancing advanced features with ease of use is important. Overall, InfluxDB can deliver great value if you align it well with your business needs and user experiences, and if you plan for scalability and ongoing maintenance. This approach ensures the product stays useful and relevant over time, which is critical for any data platform. I would rate my overall experience with InfluxDB as an eight out of ten.
Which deployment model are you using for this solution?
Hybrid Cloud
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Time series data has been managed efficiently for IoT sensors but reporting still needs improvement
What is our primary use case?
My main use case for InfluxDB is that we are an IoT-based company with sensors and hardware, and we store sensor data into InfluxDB for time series purposes.
A specific example of how I use InfluxDB with my sensor data involves a temperature sensor that requires readings every 30 seconds, such as temperature readings of 20 degrees or 40 degrees. We receive a sample every 30 seconds for temperature, and we also have energy data where we get a 30-second sample based on voltage and current measurements. We receive these kinds of data every 30 seconds, which amounts to a large volume of data per minute.
Regarding my main use case, we typically have sensor data, energy data, and HVAC data every 30 seconds. This is time series data, and it is substantial in volume. InfluxDB, being a time series database, is the only database suitable for storing this data. It is not feasible to use any other database for our purposes, so we chose InfluxDB.
How has it helped my organization?
we are the startups company but we have too much data we store for 30s interval , managing our own DB solution is very tough for us, we don't want to manage on premises DB, we choose to influxDB cloud DB. and for monitoring purpose we use free version with docker to publish application metrics.
What is most valuable?
The best features InfluxDB offers are related to the cloud version, which is very useful because there is no burden at all in maintaining an on-premises server. Everything is handled by InfluxDB, and we also have access to the support team. If we need optimization or help with queries, we ask for guidance and optimization from InfluxDB.
InfluxDB has positively impacted Energy Box by being the best choice for our needs. The cloud version and time series capabilities, along with a task scheduler, allow us to schedule tasks such as converting data from 30 seconds to one hour or one day. We can automate this process, so we do not need to worry about conversion code or scripting. We simply retrieve the data from InfluxDB.
What needs improvement?
How InfluxDB can be improved is relevant since for Energy Box, we face certain issues. We have customers worldwide, including the United States, United Kingdom, and Europe, but when we expanded to China two years ago, they indicated that they do not support the cloud version there. Our application is built on the cloud, which required us to create a separate application for Azure China, which was painful for us. The second issue involves frequent version changes. For example, we started with version one, transitioned to version two, and I heard they are considering InfluxDB version three, reverting to earlier practices. InfluxDB should improve without completely changing its approach. Now we have to redo our work for InfluxDB version three.
Regarding needed improvements, the documentation is sufficient, but pricing presents a challenge. InfluxDB has standard pricing, which is acceptable for large companies. However, for startups in our position, they should provide special discounts so everyone can utilize it. The pricing should adapt as companies grow, which is a reasonable expectation.
For how long have I used the solution?
I have been using InfluxDB at this company for the last four years with Energy Box.
What do I think about the stability of the solution?
Regarding features and performance, we sometimes face outages. One of the biggest outages occurred when AWS experienced downtime, and we suffered considerably because InfluxDB cloud is hosted on AWS. We endured this for almost the entire day. Apart from that, we regularly encounter query issues. Additionally, we have another environment for Azure China, where unfortunately, the InfluxDB team does not support the China region. They indicate that we can use the licenses, but they do not provide the cloud version there. This is a significant challenge for us as we must maintain the on-premises servers that we installed with InfluxDB. Performance is generally good, and with the help of the InfluxDB support team, we handle both Azure China and AWS day-to-day problems such as buffering data. For example, some devices being offline leads to missed data, which we address directly with the manager and technical support. They also helped us by establishing monitoring on Azure China since it is our on-premises server, managing and monitoring our database performance.
InfluxDB's stability is generally good, being stable 99 percent of the time.
What do I think about the scalability of the solution?
Regarding scalability, since we use the cloud version, we do not need to scale at all.
How are customer service and support?
The customer support is good, and they typically respond within 8 to 10 hours.
My experience with the cloud version is that for reporting purposes, we need to retrieve a lot of data to create reports on our platform. These reports can include substantial amounts of data, such as one year or one month of energy, sensor, and other device data. Obtaining that quantity of data directly from InfluxDB is quite challenging, and that is why we ask for help from the InfluxDB team to retrieve the data to avoid timeouts and those kinds of issues.
Which solution did I use previously and why did I switch?
Before InfluxDB, we used MongoDB for storing time series data. We switched to InfluxDB due to its superior performance, as it was difficult to maintain data in MongoDB for our time series needs. We were also encouraged to make the switch due to better pricing, especially when we had a good budget.
What was our ROI?
I have seen a return on investment, as it is good for the company. It simplifies processes and reduces the need for additional employees. We invest in InfluxDB instead of spending time on workforce management.
What's my experience with pricing, setup cost, and licensing?
I find the cloud version pricing of InfluxDB reasonable, and for the on-premises solution we use in our service, we need to purchase licenses. The price seems fair enough as per our organizational needs since we have a substantial amount of data that we are storing.
Which other solutions did I evaluate?
Before deciding on InfluxDB, we evaluated other options, including PostgreSQL time series data, which is quite good and widely used. We opted for InfluxDB because we found it more valuable, requiring less effort with no maintenance on on-premises servers. We simply wanted the cloud version.
What other advice do I have?
On a scale of 1 to 10, I would rate InfluxDB a 7.
I give it a 7 because the support and cloud version are available. I reduced the rating by 3 points due to some shortcomings. One shortcoming is that when we request too much data, it hangs considerably and does not provide results in one instance or experiences delays. However, 7 is an appropriate rating in terms of performance, pricing, support, and the cloud version.
InfluxDB is deployed as we use the InfluxDB cloud version, and in our application, we incorporate that cloud version. Our application is public, but it is specifically designated for customers.
We use two cloud providers for the InfluxDB cloud version, with 90 percent usage on AWS and the secondary being Azure China.
We do not purchase InfluxDB through the AWS Marketplace. Instead, we purchase it directly from InfluxDB and use it in our applications.
Additionally, I have further thoughts about InfluxDB. Sometimes, when we write too much data within a minute, the data count becomes excessive, reaching perhaps 100,000 or 500,000 data points, and InfluxDB gives a timeout exception, which we must handle in our application. Additionally, if the code is not adequate, we need to change it. These challenges also arise during production support. My overall rating for InfluxDB is 7 out of 10.
Which deployment model are you using for this solution?
Public Cloud
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Amazon Web Services (AWS)
Monitoring has improved login analytics and alerts but still needs richer metric handling
What is our primary use case?
We are using InfluxDB with Prometheus and Grafana for monitoring the logs that are coming up as well as to create a powerful monitoring and analytics solution, encompassing data collection, metrics, and data storage.
Whenever the number of connections increases or we have our Elasticsearch where we have the logs, InfluxDB gathers them and sends them. We created an analytics on it using the SRE people that are there.
Based on InfluxDB, we have great analytics produced by our SRE team, and with that, we have an alerting and monitoring system in place. Whenever there are a lot of things that are happening, such as the interaction going up and the number of logins increasing, then we get an alert that this is happening and we see that it's genuine or someone is trying to attempt something. This has helped us significantly.
We have our own metrics, as I mentioned from the SRE team, along with those logs. From there, we maintain the number of logins, the number of unique logins, and the number of logins at which period of time. These metrics are there so that we can even think about having an auto-scaler in place so that everything is auto-scaled.
What is most valuable?
InfluxDB's feature of data series over an extended period of time is valuable. We can watch logs even from the past three years and into a small range. For instance, in the past three years, from this moment till this moment, we can see how many logs are there and everything. We can watch it that way.
Firstly, the query language, as I mentioned, is based on SQL, so we can use SQL. Additionally, there is an open-source solution for it, which we can install on our system and work with those things directly. It is providing our own infrastructure-based solution, and it has a large community around it. That is the primary reason we chose it.
Firstly, it is open-source and has a great community. However, there could be much more improvement on the metric side that I have mentioned.
What needs improvement?
If it gets a little bit more into the metric side, then it would really be great, similar to Prometheus. However, Grafana handles those things together, so I do not feel that improvement is needed.
Rather than having two data sources, we could have just one data source with InfluxDB, and it could handle those things rather than having Prometheus and InfluxDB in place.
For how long have I used the solution?
I have been using InfluxDB for the past four years.
What do I think about the stability of the solution?
InfluxDB is pretty much stable.
What do I think about the scalability of the solution?
In terms of scalability, it is highly scalable, as I mentioned that it has HA and backup plans available for it. It has handled a lot of data.
How are customer service and support?
There is nothing as such that I can complain about. It is pretty much usable and very much intact.
How would you rate customer service and support?
Which solution did I use previously and why did I switch?
Before InfluxDB, we were using Loki. However, we switched to InfluxDB because it has high availability, scalability is there, and error loggings sometimes perform better on that. For that reason, we moved from Loki and Prometheus to InfluxDB.
How was the initial setup?
The first thing is that it will have a learning curve. You should have a POC or something that takes time because setting it up is somewhat difficult because it is a new thing for us. However, once it is set up, then you do not need to take care of it every time. It is auto-scalable, auto-healable, and all those things. That is the feature that you will always appreciate about InfluxDB. You must have a willingness to learn new things.
What about the implementation team?
InfluxDB is set up in a database setting where we have authentication and it is pretty much easy to use with a query language similar to SQL. That is why it works for us.
What was our ROI?
Time saved is there, as I mentioned, because we have an analytics system from where we get alerting and monitoring. It is pretty much time-saving and things go right. However, not on the fewer employee side. We need employees because it has a learning curve, but it is definitely time-saving.
What's my experience with pricing, setup cost, and licensing?
We are using an open-source solution, so there is no cost on that. However, on the server side, we needed a few things, such as CPU. We needed a good CPU and everything. This cost a bit for us.
Which other solutions did I evaluate?
We checked Apache Druid and TimescaleDB.
Which deployment model are you using for this solution?
Private Cloud
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Has supported long-term metric tracking and fast data access for performance monitoring
What is our primary use case?
My main use case for InfluxDB involves gathering metric data from our storage clusters and putting them into Grafana dashboards, so InfluxDB is the data source for Grafana.
I collect and display metrics in Grafana such as throughputs, IOPS, latencies, quota consumptions, network and cart errors.
Regarding my main use case, there are no particular challenges; we run our scripts every five minutes, so we gather data from our clusters every five minutes and keep more than six months.
What is most valuable?
The best features InfluxDB offers include a web UI that I love because sometimes I need to check some details about my metrics, enabling me to easily see simple details on it.
While the API does not stand out to me since we don't use it regularly for InfluxDB, we primarily use it as a data source for Grafana.
InfluxDB has positively impacted my organization by being a part of our solution, which helps us maintain our solution easily.
It helps me maintain my solution easily because it is very reliable, so we didn't face any performance issues or crashes regarding our queries; we can get the results very fast.
What needs improvement?
I believe InfluxDB can be improved, but I'm not sure how; maybe some people can say more than me, but for myself, it is enough.
I don't have any additional improvements to suggest regarding documentation, UI, or anything else that I wish was different; nothing comes to mind.
For how long have I used the solution?
I have been using InfluxDB almost for two years.
What do I think about the stability of the solution?
What do I think about the scalability of the solution?
We haven't faced any issues with InfluxDB's scalability; maybe our capacity consumptions are small, or it is simply good enough to handle that much capacity.
Which solution did I use previously and why did I switch?
I did not previously use a different solution; there was no switch required.
How was the initial setup?
We do not purchase InfluxDB through the AWS Marketplace; instead, we use the open-source version.
What was our ROI?
I haven't seen a return on investment; unfortunately, I cannot share relevant metrics such as time saved, fewer employees needed, or money saved.
What's my experience with pricing, setup cost, and licensing?
I'm not sure about the details regarding pricing, setup cost, and licensing.
Which other solutions did I evaluate?
Before choosing InfluxDB, I only evaluated Prometheus, but it is not the right solution for us because it has a different methodology than InfluxDB, which exactly matches our requirements.
What other advice do I have?
My advice to others looking into using InfluxDB is that if they need any time-series database, InfluxDB is a good solution with its stable, high performance, and scalable capabilities, and I love the web UI, which also allows us to create dashboards without any other third-party tools.
On a scale of one to ten, I rate InfluxDB a ten.
Which deployment model are you using for this solution?
Hybrid Cloud
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?