InfluxDB is good as it is, and I have not faced any issues so far, so I could not elaborate on how it can be improved.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.
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.
It's pretty much good regarding my use case, but I want to tell you that the interface of InfluxDB is so complex and should be made easier for non-technical people. With InfluxDB, I have to use Grafana, which provides good visualization, so I will tell you that mixing Grafana and InfluxDB would make visualization better in InfluxDB. Documentation is also required for InfluxDB, as I haven't got the documentation related to this, but there is a video on Udemy that helped me to use InfluxDB effectively.
It is challenging to get long-running backups while running InfluxDB in a Microsoft Azure Kubernetes cluster. Replicating data for on-prem development and testing is difficult. Having a SQL abstraction in InfluxDB could be beneficial, making it more accessible for teams that prefer querying with SQL-style syntax.
One area for improvement is the querying language. InfluxDB deprecated FluxQL, which was intuitive since developers are already familiar with standard querying. Though we can adapt to the Flux ( /products/flux-reviews ) language, I would like to see more development in this area and am unsure why FluxQL was deprecated.
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.
There were concerns about data loss due to infrastructure limitations. We couldn't back up data locally if we were using the InfluxDB cloud, which was a major drawback. So, InfluxDB could improve its data backup capabilities. Having a backup option would allow us to save data and avoid relying solely on cloud infrastructure. We've experienced data loss incidents in the past, so backup is crucial. I've tried both on-premises and cloud-based deployments, and each has its limitations.
The solution's UI can be more user-friendly. I would like to have better more detailed documentation on how to integrate the solution with other tools.
Influx has TICK Stack, which contains multiple services and multiple products that work together. InfluxDB is just a time series database, and it works really well. I haven't yet had the time to look into the new stack based on Influx 2.0, but currently, as a time series database, InfluxDB is working the way it is supposed to work. In terms of features that I would like to see or have, in the community version, some features are not available. I would like to have clustering and authentication in the community version. I would also like to have high availability features, such as replication, active-active, etc. If they can put an extra plugin or service on top of it, it would be something interesting. I am not sure if they have high availability to make it data center-aware for clustering. For example, I am not sure whether you can have it at different locations with big clusters that are location-aware. Even in their documentation or presentation, they talk too little about high availability and extended clusters with different locations. They might already have it in the newer versions. We have Influx 1.8 in our production in the stage and internal workloads environments. The other products in their ecosystem, such as Chronograf, can be improved. Chronograf is a dashboarding or visualization layer product, and that, for sure, can be improved.
InfluxDB can improve by including new metrics on other technologies. They had some changes recently to pool data from endpoints but the functionality is not good enough in the industry. In the next release, it would be beneficial if they added more query language compatibility it is critical for us.
InfluxDB is open-source software that helps developers and enterprises alike to collect, store, process, and visualize time series data and to build next-generation applications. InfluxDB provides monitoring and insight on IoT, application, system, container, and infrastructure quickly and easily without complexities or compromises in scale, speed, or productivity.
InfluxDB has become a popular insight system for unified metrics and events enabling the most demanding SLAs. InfluxDB is used in...
InfluxDB is good as it is, and I have not faced any issues so far, so I could not elaborate on how it can be improved.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.
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.
It's pretty much good regarding my use case, but I want to tell you that the interface of InfluxDB is so complex and should be made easier for non-technical people. With InfluxDB, I have to use Grafana, which provides good visualization, so I will tell you that mixing Grafana and InfluxDB would make visualization better in InfluxDB. Documentation is also required for InfluxDB, as I haven't got the documentation related to this, but there is a video on Udemy that helped me to use InfluxDB effectively.
It is challenging to get long-running backups while running InfluxDB in a Microsoft Azure Kubernetes cluster. Replicating data for on-prem development and testing is difficult. Having a SQL abstraction in InfluxDB could be beneficial, making it more accessible for teams that prefer querying with SQL-style syntax.
One area for improvement is the querying language. InfluxDB deprecated FluxQL, which was intuitive since developers are already familiar with standard querying. Though we can adapt to the Flux ( /products/flux-reviews ) language, I would like to see more development in this area and am unsure why FluxQL was deprecated.
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.
There were concerns about data loss due to infrastructure limitations. We couldn't back up data locally if we were using the InfluxDB cloud, which was a major drawback. So, InfluxDB could improve its data backup capabilities. Having a backup option would allow us to save data and avoid relying solely on cloud infrastructure. We've experienced data loss incidents in the past, so backup is crucial. I've tried both on-premises and cloud-based deployments, and each has its limitations.
The solution's UI can be more user-friendly. I would like to have better more detailed documentation on how to integrate the solution with other tools.
InfluxDB cannot be used for high-cardinality data. It's also difficult and time-consuming to write queries, and there are some issues with bulk API.
Influx has TICK Stack, which contains multiple services and multiple products that work together. InfluxDB is just a time series database, and it works really well. I haven't yet had the time to look into the new stack based on Influx 2.0, but currently, as a time series database, InfluxDB is working the way it is supposed to work. In terms of features that I would like to see or have, in the community version, some features are not available. I would like to have clustering and authentication in the community version. I would also like to have high availability features, such as replication, active-active, etc. If they can put an extra plugin or service on top of it, it would be something interesting. I am not sure if they have high availability to make it data center-aware for clustering. For example, I am not sure whether you can have it at different locations with big clusters that are location-aware. Even in their documentation or presentation, they talk too little about high availability and extended clusters with different locations. They might already have it in the newer versions. We have Influx 1.8 in our production in the stage and internal workloads environments. The other products in their ecosystem, such as Chronograf, can be improved. Chronograf is a dashboarding or visualization layer product, and that, for sure, can be improved.
InfluxDB can improve by including new metrics on other technologies. They had some changes recently to pool data from endpoints but the functionality is not good enough in the industry. In the next release, it would be beneficial if they added more query language compatibility it is critical for us.
The initial setup is a little bit complex. The error logging capability can be improved because the logs are not very informative.
The solution doesn't have much of a user interface. The integration of Chronograf and Capacitor is not so good. They could work to make it better.