PRTG Network Monitor is the flagship offering from German software company Paessler, for monitoring local and wide area networks (LANs & WANs), servers, websites, apps, and more.
Perfect for projects where Elasticsearch makes sense: if you decide to employ ES in a project, then you will almost inevitably use LogStash, and you should anyways. Such projects would include: 1. Data Science (reading, recording or measure web-based Analytics, Metrics) 2. Web Scraping (which was one of our earlier projects involving LogStash) 3. Syslog-ng Management: While I did point out that it can be a bit of an electric boo-ga-loo in finding an errant configuration item, it is still worth it to implement Syslog-ng management via LogStash: being able to fine-tune your log messages and then pipe them to other sources, depending on the data being read in, is incredibly powerful, and I would say is exemplar of what modern Computer Science looks like: Less Specialization in mathematics, and more specialization in storing and recording data (i.e. Less Engineering, and more Design).
If there are a number of different protocols and devices to monitor PRTG is really an all in one solution. There are network specific solutions, telephony solutions, server solutions, etc - but this tool can do anything. Even if you don't use this tool as your main "monitoring solutions" every IT professional should have access to this tool for at least troubleshooting purposes. If you are looking for something specific built for a task you may be able to find [a] more direct and easy tool to use that would be easier and quicker to setup as customization is not needed.
Logstash design is definitely perfect for the use case of ELK. Logstash has "drivers" using which it can inject from virtually any source. This takes the headache from source to implement those "drivers" to store data to ES.
Logstash is fast, very fast. As per my observance, you don't need more than 1 or 2 servers for even big size projects.
Data in different shape, size, and formats? No worries, Logstash can handle it. It lets you write simple rules to programmatically take decisions real-time on data.
You can change your data on the fly! This is the CORE power of Logstash. The concept is similar to Kafka streams, the difference being the source and destination are application and ES respectively.
Very, very configurable. You can create all kinds of monitors for all kinds of things. Plus it has loads of suggestions out of the box. It can get complicated but monitoring is complicated. Pretty decent interface and good support - active community.
I really liked how easy it was to add alerts by SMS. So easy to setup.
I like their sizing models (for purchase). We're actually small enough that we are free. But it's not free as in stripped down - it's free because we don't use many "sensors" and don't honestly have the need.
Since it's a Java product, JVM tuning must be done for handling high-load.
The persistent queue feature is nice, but I feel like most companies would want to use Kafka as a general storage location for persistent messages for all consumers to use. Using some pipeline of "Kafka input -> filter plugins -> Kafka output" seems like a good solution for data enrichment without needing to maintain a custom Kafka consumer to accomplish a similar feature.
I would like to see more documentation around creating a distributed Logstash cluster because I imagine for high ingestion use cases, that would be necessary.
The probe service can be quite resource-intensive. This can cause false-positive readings from some sensors sometimes.
The software gets updated very regularly. Whilst this is usually a good thing to fix bugs etc, it does meantime downtime of the monitoring quite often while they are installed.
The ability to create Maps from Libraries. Very specific issue but a lot of people have been asking for it for years and it is still not available.
The tool is very intuitive to use and it is Windows-based (everybody knows how to use Windows) so it's easy to get into. Every time is setup in a hierarchy so if you have a good initial hierarchy design, it will really reduce administrative effort down the road.
I am giving this a 6 simply because I have never had to contact support. The online documentation is adequate for most things, and the user-maintained knowledgebase is excellent. The few times I have run into issues that were not easily resolvable with intuitive UI, I was able to find the answers that I needed either in the PRTG-provided documentation, the knowledgebase, or with a quick online web search.
MongoDB and Azure SQL Database are just that: Databases, and they allow you to pipe data into a database, which means that alot of the log filtering becomes a simple exercise of querying information from a DBMS. However, LogStash was chosen for it's ease of integration into our choice of using ELK Elasticsearch is an obvious inclusion: Using Logstash with it's native DevOps stack its really rational
I have deployed and tested three products for evaluation I found [PRTG Network Monitor] very easy to deploy, the deployment literally took not more than one hour including basic configuration and network discovery. After deployment few configuration changes and creation of maps, reports and little tweaking is required. [Then] it would go through its process of recommendation that took some time to complete, while [on] other hand other software's took lot of time to install and configure. And features were also missing, which resulted in decision in favor of [PRTG Network Monitor].
Positive: Learning curve was relatively easy for our team. We were up and running within a sprint.
Positive: Managing Logstash has generally been easy. We configure it, and usually, don't have to worry about misbehavior.
Negative: Updating/Rehydrating Logstash servers have been little challenging. We sometimes even loose data while Logstash is down. It requires more in-depth research and experiments to figure the fine-grained details.
Negative: This is now one more application/skill/server to manage. Like any other servers, it requires proper grooming or else you will get in trouble. This is also a single point of failure which can have the ability to make other servers useless if it is not running.
The ability to analyze multiple pieces of information in one place, especially with historical data, has saved our IT department time and headaches. It would be so much more difficult to trace an issue without PRTG, just relying on event logs and an open task manager window.
The cost is not cheap, so it's an expense that hits the bottom line like everything else. Figure in hardware costs as well, ideally a server outside of your main environment.
I keep saying this, but the historical data piece is worth so much. There's really no good way to collect all of that information in one place without something like PRTG. And that definitely saves time and money in the long run.
