Collectors: Open Telemetry vs. LM Collector

Question

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.&nbsp;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). &nbsp;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. &nbsp;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-collectorhttps://www.logicmonitor.com/support/configurations-for-opentelemetry-collector-container-installationhttps://www.logicmonitor.com/support/opentelemetry-collector-for-logicmonitor-overviewhttps://www.logicmonitor.com/support/opentelemetry-collector-installation-from-contrib-distributionhttps://www.logicmonitor.com/support/opentelemetry-collector-installation-from-logicmonitor-wizardand they don't answer the questions above, far as we can tell. :)

stuart_weenig · Accepted Answer

Don'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

neilticktin · Answer

Stuart_WeenigThere's a reason that you've reached "Legend" level on this forum. That answer was complete, succinct, and definitive. THANK YOU.

mike_moniz · Answer

You 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 · Answer

One more thing ... anyone else interested in ARM based collectors? &nbsp;Maybe we can actually make enough noise to get noticed. &nbsp;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?

stuart_weenig · Answer

I'm sure we're not alone.&nbsp;
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.

rszewczyk · Answer

Creating 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.

Forum Discussion

Collectors: Open Telemetry vs. LM Collector

7 Replies

Related Content

Bug early release Collector Update V34.500

Container-based Collector - DNS issues in 35.001

Stop collector or batshscript queued tasks from collector debug?

AWS EC2 cloud collector vs local collector

Collectors Capacity review

Recent Discussions

Using !snmpdiagnose

Best way to deal with "dynamic" SNMP data

CRL Monitoring...is it possible?

LM Logs SDT

Website Downtimes via API