Logstash Reviews

A use case for using Logstash that we have involves integration servers that log in files in a non-transformed way. We have more than four servers that log in files, and when we have an issue, we can't determine whether it originated in IS1, IS2, or IS3. To address this, I installed Filebeat, which is the agent that installs in servers that log.

Filebeat sends the logs to Logstash, and the role of Logstash here is taking the logs and transforming these logs in a better way. For example, if we have a request and response, it puts a request field in a separate field, the email and user in a separate field, and the execution time in a separate field. All these separations or transformations of logs help the operation teams investigate issues to determine the root cause and also help management extract reports, insights, and analytics, which aid us in reporting.

Logstash is used for transforming logs, and you can use many plugins in Logstash. Logstash works with configuration files that contain three main parts: an input part, a filter part, and an output part. In the input part, we can take logs from many sources such as Beats, files, or Kafka. The filter part is used to filter the logs that are shipped from Beats.

From my understanding and experience with Logstash, it is usually used for processing logic, meaning I can control what fields should be transferred to Elastic and what fields shouldn't be transferred. This is the main function I use Logstash for.

Elastic is a famous open-source searching engine that helps operation teams speed up the investigation process and provides real-time insights for performance reporting.

An enhancement we could implement is the ability to cluster Logstash to exist in more than one node.

I have been working with Logstash for more than two years.

I haven't faced any challenges while deploying or maintaining Logstash.

I haven't had any challenges with the stability or scalability of Logstash as I am using it in one node only.

I haven't had any challenges with the stability or scalability of Logstash as I am using it in one node only.

I use Logstash in real-time. Logstash in my current architecture is not used as a stand-alone product; it works with Filebeat and Elastic, and we use Kibana as a visualization tool. We have logs that are real-time in integration servers, and these logs are shipped to Elastic with our implementation of transformations. The transformation means we ship the logs in the way that we want them to be presented in Kibana, which is the main function we use Logstash for.

I'm not working with any queuing mechanism in Logstash. The deployment mechanism of Logstash involves deploying it once; we deployed it on-premises and not in the cloud. If we have any changes in logs, we make changes in the configuration file, and then we redeploy this configuration file. The deployment of the product itself is an RPM package that is deployed in a server, and after that, my role is to create a configuration file based on my log architecture. The deployment for Logstash has no complex aspects.

There are no improvements needed for Logstash; it's already working well for us.

On a scale of 1-10, I rate Logstash a 10 out of 10.

The purposes for which I am using Logstash largely include log aggregation and application monitoring.

As both a customer and an integrator, I think the best features in Logstash are that people prefer it because it is open to all, as it is an open-source version.

The functionality of Logstash is quite easy to implement.

I can say that the plugin ecosystem of Logstash is great. I have used some plugins for shell script monitoring and for SQL monitoring, and these are all working well with Logstash.

The real-time processing capabilities of Logstash are also pretty fine with the tool. When I use the community edition, I have to do many things manually. If I am using enterprise Elastic, then that is taken care of by the Elastic native machine learning.

Customization can be automated with Logstash, but it is at the developer's disposal. The developer has to do it, not the tool as such. There is scope for optimization, but that is all outside the tool, which I have to plug into the tool.

I am not able to think of any specific disadvantage of Logstash as such, but the implementation can be made more user-friendly.

There can be a UI to implement with Logstash. Currently, I have to work with config files and everything.

I have been using Logstash for around the last two to three years.

Logstash is stable, and I have not seen any glitches or latency problems.

Scalability is not a problem with Logstash.

The technical support from Elastic is good. I have taken support in some of the enterprise projects.

If I were to rate the support from Elastic, I would give them seven points out of ten.

They can improve, but currently the service is satisfactory. The time to revert back is something which they can improve upon.

Positive

I have not really used something similar to Logstash for the same purpose. I have just dealt with Logstash for this use case and nothing similar.

I am using Logstash for log management and also implement it. Logstash can be deployed both on-cloud and on-premises. On a scale of 1-10, I rate Logstash an 8.

Negative

We already use the Elasticsearch system. Our system is faster than version seven. Version seven does not have very special functions. We don't have the Elastic Agent. We are now using Beats, and it's not very good for importing data. We must upgrade to version eight. The system is quite large. We have three or four Logstash servers for high availability.

Logstash has special functions. We have three or four Logstash servers for high availability. Everything aligns well with improving our organization.

Almost all the research can be very bad. We still have a problem with importing the log system. The earliest type of Syslog data requires creating ingest pipelines, and that work is very difficult for our support vendors and us. 

The system was created by the support vendor. After importing the log, indexes can be created. In Elasticsearch, we must create an ingest pipeline before importing log files. This is a problem for us. Some log files must be changed frequently. We need to create this long ingest pipeline set each time. That's a problem for us.

Most of us have used it for one year.

Sometimes we discuss how to operate the Elastic system with the Elastic support team.

Neutral

I can recommend something else if needed. I can recommend Splunk.

Logstash cannot analyze logs anyway, so we need Elasticsearch and Kibana. Several servers, maybe fifteen or sixteen, are used for the Elasticsearch system.

We had to purchase the entire system. I don't really recognize each component individually.

We are also using Splunk systems. There are some differences between the two. Splunk is better than Elasticsearch.

Almost seven or eight features were good. Importing functionality must be upgraded. We need to create this long ingest pipeline set. That's a problem at the moment. 

Overall, I rate the solution seven out of ten.

I use Logstash primarily for connecting logs from hardware. This is the main use case. The second use case involves making correlations between logs from various sources. 

I can collect logs from various data sources, including hardware.

The product needs to improve its compatibility. 

I rate the product’s stability a ten out of ten. 

Scalability requires planning. The approach involves planning how to scale and add more nodes Before incorporating additional nodes, grouping can be implemented to transition to one of the nodes using Logstash.

I use Grafana Enterprise Stack as well. 

The tool's deployment is easy. The current process involves following the steps outlined in the documentation, which is very good. It includes downloading the entire package, and the process is straightforward for any system.

I rate the overall product a ten out of ten.