Collectors: Open Telemetry vs. LM Collector
Summary: neilticktin is looking to create a networking appliance for small locations, exploring the use of a LM Collector or Open Telemetry collector on a 64-bit ARM container. The concerns are the lack of ARM support for LM Collectors and whether Open Telemetry can fulfill basic monitoring needs. LM User clarifies that LM Collectors are for infrastructure monitoring, while Open Telemetry collectors are used for APM capabilities. Discussions suggest using x86-based mini PCs until ARM support improves. ROBINSON ROCA mentions using Auvik's Collector on ARM64 Raspberry Pi as an alternative.
Hi,
We're looking to create a networking "appliance" that we can send to small locations, like a retail store. Among other things, this appliance will allow us to do some gateway to gateway tunneling allowing for user support, but in addition, we want to include key devices in monitoring as well.
Originally, we were thinking that we would do a LM Collector install in a container on the device (in this case, we were experimenting with a MikrtoTik). The problem is that LM Collector supports Linux on 64-Bit AMD installs, but not 64-bit ARM installs which many (most?) appliance types would use.
Open Telemetry, however, can be used in a 64-bit ARM container.
On the surface, it appeared that we could maybe use an Open Telemetry collector for basic stuff instead of LM Collector. But, the closest I get to a comparison of what Open Telemetry collector can do, compared to LM Collector is that Open Telemetry collects "telemetry" and LM Collector collects "metrics" ... which are, of course, entirely useless descriptions if you don't know already what they are doing. :)
I understand that they are not interchangeable, but in the end, I'm trying to determine a few things:
- if not interchangeable, what to use each for?
- can Open Telemetry collector be used for the most basic monitoring?
- any other ideas for Linux 64-bit ARM based collector?
Since every time I ask anything close to this question to support, I get pointed to the links about Open Telemetry collector, let me pre-empt that (to avoid that in the answer) and say that we've looked at these links:
https://www.logicmonitor.com/support/adding-an-opentelemetry-collector
https://www.logicmonitor.com/support/configurations-for-opentelemetry-collector-container-installation
https://www.logicmonitor.com/support/opentelemetry-collector-for-logicmonitor-overview
https://www.logicmonitor.com/support/opentelemetry-collector-installation-from-contrib-distribution
https://www.logicmonitor.com/support/opentelemetry-collector-installation-from-logicmonitor-wizard
and they don't answer the questions above, far as we can tell. :)
Patrick Rouse
·3 months agoGood news. The current plan is to introduce Arm support in EA 40.400, scheduled for release on July 20th. Also, we’re planning to introduce support sending OpenTelemetry protocol (OTLP) metrics directly to LogicMonitor without use of a LogicMonitor-specific exporter. So, in the next few months we aim to check both the Arm and OTEL boxes.
ROBINSON ROCA
·2 years agoI've been looking to get an LM collector on ARM64 as well. I found Auvik, they have a collector that runs on ARM64 Raspberry PI 4 and 5. If LM can't do what I need, I'll leverage Auvik for my remote sites that have no hosts for VMs.
ROBINSON ROCA
·2 years agoI Ideally would want to run both in docker, but I don't want to deploy x86 machines and have to worry about their maintenance and overhead.
rszewczyk
·2 years agoCreating an ARM collector seems like such a low hanging fruit it is beyond me why it is not there yet. It is a freaking JVM... it can't be any easier.
Anyways. We also look into getting appliance to branches and for now we paused and reconsidering x86 mini-pcs.
LM User
·2 years agoEvery time i've gotten anything close to an official reply, the answer has been something around certain java/groovy libraries that the collector uses that aren't compiled for ARM. Seems like weaksauce to me.
Mike Moniz
·2 years agoYou can get x86 based mini PCs. I believe Asus has taken over the older Intel NUCs which were a good option for that kinda thing. They will be more expensive then your cheap android-based boxes though.
neilticktin
OP2 years agoOne more thing ... anyone else interested in ARM based collectors? Maybe we can actually make enough noise to get noticed. Whether it be for an appliance like I was looking for ... to even better, Raspberry Pi collectors that I'm sure many people would want ... are Stuart and I alone?
LM User
·2 years agoI'm sure we're not alone.
Just some thoughts about building an appliance: the easiest way to do this would be through a container based solution. Each collector has a unique id so you can't just make an appliance with the collector installed and copy it. If you did, the platform would see them all as the same collector. Even the container doesn't do this; it has an init script that downloads and installs the collector each time the container is started (this is why containerized collectors take so long to startup compared to other containerized appliances).
If you were running on a supported CPU architecture, you could simply define your appliance in a docker compose or k8s resources file. That would specify the services you want to run including the LM container, your tunnelling app (if it can run containerized), the user support app (if it can run containerized), etc. The ID and size of the collector would be specified in your compose/resource file which would start it up, download the installer into the container, install it, and start it up phoning home to the LM platform. Then your host system is pretty simple, only running docker/k8s and maybe providing you with a way of managing the compose/resource file centrally.
If i were going to do what you're trying to do, docker compose is how i'd do it. It has the lesser steep learning curve and works well in standalone situations.
Michael Raymond
·2 years agoneilticktin
OP2 years agoAnonymous
There's a reason that you've reached "Legend" level on this forum. That answer was complete, succinct, and definitive. THANK YOU.LM User
·2 years agoDon't get me started on the lack of ARM support. Raspberry Pi collectors would be dope.
LM Collectors receive tasks from the platform and execute those tasks to collect data from endpoints on the same network as the collector. OpenTelemetry collector cannot execute LogicMonitor collection tasks. You would get no data for DataSources, no discovery, no pinging, nothing to do with active data collection.
OTel collectors are open source and LM has written a plugin that allows telemetry data sent via a few different protocols to OTel collectors to stream that data to LM. Usually that data is for Distributed Tracing, which is an APM capability.
LM Collectors = infrastructure monitoring
OTel Collectors = APM