Top Freeware and Open-source IT Monitoring Tools
There are hundreds of monitoring tools available in the market for enterprises and MSPs to choose from. Many of these tools are open source or freeware. Over the years, the functionality of many of these open source tools have improved greatly. In this blog, we highlight the top open source IT monitoring tool options and discuss their pros and cons.
Grafana is a multi-platform open-source analytics and interactive visualization web application. It provides charts, graphs, and alerts for the web when connected to supported data sources. It is primarily a visualization tool that provides interactive graphs for admins and dashboards fed from data input streams.
Grafana is developed by Grafana Labs with a free version of Grafana available on GitHub under a GNU AGPLv3 license. A licensed Grafana Enterprise version with additional capabilities is also available for self-hosted, on-premises installation or as managed SaaS (Software as a Service) via an account on the Grafana Labs cloud service.
Grafana has a pluggable data source model which can connect with a wide range of data sources, including time series data but also relational databases – including Splunk, Graphite, Prometheus, Influx DB, ElasticSearch, Microsoft SQL Server, MySQL, and PostgreSQL.
Prometheus is an open-source data monitoring tool. It is common to find Prometheus and Grafana used together by organizations looking for an open-source solution. The Grafana dashboards are used for visualizing the data, whereas the backend data collection is powered by Prometheus.
Grafana is generally acknowledged to have a high learning curve associated with it. Configuring plugins can require significant effort. Configuration options via the GUI are limited and manual maintenance and editing of configuration files is often necessary. As there is very limited log analysis functionality, most users have another tool to cover that need.
Nagios is a free, open-source monitoring system for computer systems. It was originally designed to run on the Linux operating system and can now monitor devices running Linux, Windows, and Unix operating systems (OSes). Nagios is licensed under GNU GPL v2 licensing.
Nagios can proactively probe systems and resources and raise alerts if problems are detected. Nagios is typically used to monitor application, network, and server resources, such as memory, server CPU usage, and so on. Both agent-based and agentless configurations are possible.
Nagios still feels like a Linux product, and there is a learning curve often involving manual configuration. Limited UI (User Interface) and visualization features means that Nagios feels very much like a sys admin tool designed around event alerting rather than an enterprise observability product. Dashboarding and reporting functionality is extremely limited. Demonstrating due diligence with respect to security with Nagios can also be challenging.
Nagios XI is a proprietary interface using Nagios Core as the back end, with support for RHEL and CentOS OSes and some level of graphing and dashboarding available via integrations. For anyone considering Nagios, it is worth examining the pricing (standard version $1995 and enterprise version $3495) of Nagios Xi and the feature gaps it fills relative to the freeware options.
Zabbix is an open-source solution to monitor IT infrastructure, such as networks, servers, virtual machines, and cloud services. Zabbix collects and displays basic metrics. Zabbix is released under the terms of GNU General Public License version 2; Zabbix is free software that does not require a license to use any of its features. Although Zabbix is open-source software, it is a closed development software product, developed by Zabbix LLC based in Europe.
Zabbix is popular with organizations looking to build a bespoke and customized solution with an ethos based around extensibility, a good API (Application Programming Interface) and integration framework, and options for customized and personalized dashboards. Configuration can be complex and manual and require a significant degree of scripting skills. Many users rely on additional tools such as Grafana for visualization.
Zabbix can be hosted on a server of your choice on-premises or in the cloud, but there is no out-of-the-box SaaS option currently. Deploying Zabbix requires significant skills and investment, and as a result, Zabbix LLC offer “turnkey” packages to assist deployment ranging from $1500-$+22k; exploring these packages is helpful to gain an understanding of the complexity of what undertaking a Zabbix installation will entail and the ongoing maintenance needs.
Zabbix is often evaluated as an alternative/competitor to Microsoft System Center Operations Manager (SCOM) and Nagios.
Graphite is a free open-source software (FOSS) tool that monitors and graphs numeric time-series data, such as the performance of computer systems. Graphite stores time series data and provides functionality to graph that data on-demand.
Graphite is not a collection agent, but it offers a way to get measurements into a time-series database via various integrations. Visualization is often achieved via integration with tools such as Grafana, whilst monitoring integrations include options such as Zabbix or beacon to provide proactive alerts. Graphite is passive, and it listens for data, but components must be configured to send data to the central engine.
Graphite is generally considered simpler and more general than alternatives such as Prometheus.
Prometheus is a free software application used for event monitoring and alerting. It records real-time metrics in a time series database and offers querying functionality and real-time alerting. Prometheus is licensed under the Apache 2 License, with source code available on GitHub. Prometheus is not a dashboard solution and users often rely on its Grafana integration for visualization.
Prometheus does not offer long-term storage so any needs in that area must be implemented. Primarily using a pull model means that thought must be given for security and scalability. (You can learn more about push and pull polling methodologies within monitoring, here: Secure Monitoring – Open TCP Ports are a security risk.)
Prometheus supports monitoring and alerting for microservices, containers, and distributed applications and has gained traction for Go and Docker based applications.
The Challenges of OSS (Open-Source Software) and Freeware
1. Who supports an OSS “product”?
For most organizations, a key question with any software adopted is “Is it supported?” This is a very different question to “Does it work?” Enterprise-quality support should usually formalize questions, such as:
- How long will the software be available; how much notice will you have if the software is deprecated or withdrawn?
- If there is a problem or a fault, whether and how can you raise a support ticket to get an issue fixed?
- Who is responsible for fixing faults and on what timeframes?
- Who is responsible for resolving critical security issues and ensuring any embedded libraries or dependencies are upgraded to be secure?
With OSS, the level of support you can expect can vary enormously but with free software this usually means you can rely on very little. In practice, many open-source projects will have proprietary or enterprise supported versions available from a commercial organization for a license fee, sometimes with additional features, but usually with support commitments especially around bug fixing and security patches. An example is the open-source CentOS operating system, which acts as the upstream development platform for RHEL, which is supported and sold by Red Hat. Organizations who need assurance that their OS is fixed and secure would typically choose RHEL vs an open-source alternative.
As a commercial enterprise grade monitoring solution, eG Innovations offers 24/7 enterprise support options, provided from permanently staffed offices worldwide, in 8 local languages for those customers who need accountability and assurance issues will be resolved.
2. Can the OSS “product” compromise the support status of other enterprise products you use?
This is a slight nuance on supported. Open-source products are particularly prolific in the Linux ecosystem, and Linux is a mainstay of many a datacenter. Hypervisors that virtualize the datacenter are to a large extent just Linux kernels. This means many monitoring products designed for a Linux OS will work if inserted into a hypervisor kernel (on some hypervisors this would be running the monitoring product within dom0). However, whilst you may be willing to take risk of using an unsupported monitoring product – if it breaks, find something else, work around it – the act of inserting something uncertified may invalidate the hypervisor vendor’s support. i.e., you will not be able to raise a support ticket if the hypervisor breaks because you have modified it in an unsupported manner. For monitoring products used with commercial hypervisors, it is always wise to verify the product is certified by the hypervisor vendors compatibility program as this will ensure you are fully supported. For eG Enterprise, you can verify our support for hypervisors with vendors via Citrix Ready, VMware Ready, and similar programs. You should never install any product or tool into a commercial hypervisor without confirming it is approved by the hypervisor vendor.
3. How secure is the product and who is responsible for addressing security issues?
There is an argument that open-source development promotes security because an organization can see the internals of what they are using and there can be intense scrutiny from a large number of organizations of the quality of code. Critical security faults may be diagnosed before a malicious party discovers and exploits them. However, open source also means that malicious parties can have easy access to analyze products to discover flaws to exploit. In practice, many organizations do not have the expertise, time, and resources to undertake effective security auditing of open-source products and rely on the hope that the major contributors to a project or larger users of the project do this. The need to ensure regular and responsive security patches means that many opt for a proprietary/enterprise paid-for derivative of open-source projects or a fully supported closed-source commercial option.
In the realm of monitoring, the options for agent vs agentless monitoring may have both security and support implications (adding an unsupported agent to a component) and the configuration requirements. e.g., whether bad practices such as listening on open ports can be avoided.
4. What sort of licensing is used and what does it commit you to?
Open-source code means that an organization can modify the code to develop their own customized functionality. However, many types of licenses require that any modified code versions (derivatives) must also be made freely available for anyone else to use or adapt. In the area of monitoring this can effectively mean organizations are compelled to reveal information about how and what they are monitoring – information that could assist malicious agents looking to compromise the security of IT systems or information that is proprietary and business-sensitive and could assist competitors.
A few open-source projects even go quite far in stipulating conditions on who can legally use any product using their code, notably excluding certain governments, military uses, or certain industries which in turn could prevent a business relying on that code from dealing with those customers. Ethics of Open Source Software Licensing | Escrow London – JDSupra covers some of the legal nuances and considerations open-source may add to a development and business model.
5. Some OSS products and processes are not considered compatible with modern ethical business practices
In some geographies, there are questions over the ethics of OSS and “free labor” or the expectation that junior staff need to accumulate significant OSS contributions on their own time to obtain interviews or career progression. Many enterprises do fund full-time regular jobs working on open-source code bases, managed through formal personnel and HR systems, and many OSS projects are largely developed by employees. Questions do arise about the inclusivity and diversity of open-source projects, with some studies showing very low participation from female developers and those from certain ethnic groups. Moreover, other studies have found those openly identifiable as belonging to an under-represented group find it harder to get code commits accepted and/or face more online antagonism or abuse. With many organizations moving to ensure their ecosystems and supply chains are sustainable and ethical and offer employees fair opportunities, renumeration, and acceptable working conditions, the informal nature of some OSS projects is often incompatible with demonstrating due diligence in this area. It is often far easier to buy a commercial software title from a recognized regulated company to tick the “do our suppliers treat their staff as well as we do” type box. A reasonable overview of some of the labor ethics is given in Ashe Dryer’s well-circulated article, The Ethics of Open Source – Ashe Dryden | Open Transcripts.
6. What about gaps in the OSS product’s functionality?
There are likely to be gaps in the OSS product’s functionality. By their very nature, OSS projects have often been developed to fill gaps or address a need of the project founders. They often have a clearly envisaged focus and scope avoiding competition with or overlap between similar OSS projects and communities. In the field of monitoring, this may mean one project may focus on dashboards but expect metric collection to fall under the remit of another project. This can also lead to complexity with a wealth of plugins and connectors needed to be manually configured and plumbed in.
Given the wide spectrum of technologies now used in enterprises, if the OSS product doesn’t support an important technology used by your organization, how you address the gap? For example, if you are making wide use of Citrix or VMware Horizon technologies to support work-from-home, most freeware monitoring tools do not have support for these technologies.
Often, organizations end up having in-house teams doing development work to create scripts they integrate with these monitoring tools to bridge the gaps that exist. The challenges with approach are twofold: one is the cost of the development team and another one is the maintenance of code base developed, including documentation.
7. No single owner for product direction
Many OSS have arisen out of a gap in functionality and grown organically based on those using the tools. As such, many have limited remit as they are not designed to be an end-to-end solution and the expectation is that an end-user will collect and plumb together a collection of these tools to build their own bespoke solution. It can be very difficult to get feature requests and additions agreed on and accepted. When you are paying a commercial software vendor for a product, the documented scope of the product will be very clear, and it is usually very simple to request modifications and receive a clear answer as to whether new features will be added to the product to accommodate your needs.
By its very nature, OSS often has many users who are prepared to go-it-alone for support or operate in more informal sectors which do not require regulatory compliance auditing. As such, OSS monitoring tools are often lighter on softer enterprise features, such as automated auditing, RBAC (Role Based Access Control), and help / service desk ticketing integrations.
He who pays the piper!
- Learn about the pros and cons of Agent vs. Agentless Monitoring | eG Innovations
- Open Port Security Considerations for Monitoring Architectures: Secure Monitoring – Open TCP Ports are a security risk (eginnovations.com)
- Integrating Help and Service Desk tools with Monitoring projects: Service and Help Desk Automation Strategies | eG Innovations
- Read about enterprise support options from eG Innovations: IT Monitoring Support & Services | eG Innovations