Comparison to other monitoring tools

[jbednar]

This project is entering a field already crowded with alternative solutions for monitoring. For tools that are competitors or alternative approaches, it's important to clarify how this one differs, so that people can make an informed choice. For other complementary tools, it's important to clarify how they could be used with this one, e.g. by providing data that it can use or interfacing with it in some other way. In part because some projects include both competitive and complementary components, it's not always obvious which of those categories (or some other category) a related tool falls into. It would be great if the docs could clarify these relationships at least as a rough categorization, which I've started as a first pass below. Of course, there are easily hundreds if not thousands of potentially competitive or complementary tools, but hopefully this selection will give the basic idea and make it easier to categorize any new tool you encounter.

As a background for comparison, the tool in this repo is:

• Python - easily extensible by Python programmers to cover any data source
• Configurable - Controlled with YAML whose capabilities can be extended in Python
• Focused on data science artifacts - making it simple to monitor common classes of locally authored servers, such as Python-based dashboards and REST servers
• General purpose, but focused on higher level needs (not network packets or hardware, but locally maintained apps)
• Fully open source
• Locally installed (not a web service)

Competitors/alternatives: (tools providing monitoring and graphing of external data sources)

• Kibana - specific to Elasticsearch
• Grafana - not Python-configurable
• Sentry - web service focused on app monitoring and error reporting
• glances - lower level
• graphite/web - hard coded web interface to graphite tool
• SolarWinds, MRTG, Zabbix, cacti, zenoss and many, many others - mainly IT audience (networks, attached devices, etc.) compared to this tool's data-science audience (less focused on networks, more focused on domain-relevant info that can be extracted from running servers)

Complements: (possible data sources, add-ons, etc.)

• graphite/carbon, graphite/whisper, Prometheus, RRDtool, Bucky, collectd - logging data that could be queried
• pagerduty - commercial; alerting

[rgpdx]

@jbednar How does this project compare with python panel? Is this intended to be a complement to it or a replacement? It's not obvious based on the github page. Also, are there any working examples I can look at so I understand the intent?

[jbednar]

Good question; this issue is about other monitoring tools, but of course it's important to know how Lumen relates to other tools as well.

In this case, Lumen is built on top of Panel and Intake, letting users write a declarative specification for what they want to monitor or analyze. Lumen then uses Intake to fetch the data and Panel to set up a dashboard or app to view or work with it. Thus Lumen is complementary to Panel in terms of functionality (as Panel doesn't offer a way to turn a declarative text file into a dashboard), but more to the point Lumen is built directly on Panel (and thus requires Panel to be installed).

Basically, Lumen provides some of the power of Panel, without having to write any Python! We anticipate that current users of Panel will continue to use Panel for what they use Panel for, and that Lumen users will either be from a different background (not Python programmers) or else be doing different things (e.g. monitoring a bunch of Panel apps, which was our original goal, or maybe automatically generating .yml files that can be used a specialized apps).

You won't be able to tell whether you're looking at a Lumen app or a Panel app, the same way you can't tell whether you're looking directly at a Bokeh app or at one created by Panel or HoloViews, but the process for generating the app is completely different in all these cases.

Examples and docs are coming! We'll officially announce Lumen once those are ready. Should be in the next couple of months, as we are giving a presentation on Lumen in mid-March.