Forum Discussion

neilticktin's avatar
neilticktin
Icon for Neophyte rankNeophyte
7 months ago

Collectors: Open Telemetry vs. LM Collector

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:

  1. if not interchangeable, what to use each for?
  2. can Open Telemetry collector be used for the most basic monitoring?
  3. 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. :)

collectors
  • Anonymous's avatar
    Anonymous
    7 months ago

    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

  • RobRoca's avatar
    RobRoca
    Icon for Neophyte rankNeophyte
    4 months ago

    I'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.

    • RobRoca's avatar
      RobRoca
      Icon for Neophyte rankNeophyte
      4 months ago

      I 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's avatar
    rszewczyk
    Icon for Neophyte rankNeophyte
    7 months ago

    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. 

    • Anonymous's avatar
      Anonymous
      7 months ago

      Every 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's avatar
    Mike_Moniz
    Icon for Professor rankProfessor
    7 months ago

    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's avatar
    neilticktin
    Icon for Neophyte rankNeophyte
    7 months ago

    One 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?

    • Anonymous's avatar
      Anonymous
      7 months ago

      I'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.

  • neilticktin's avatar
    neilticktin
    Icon for Neophyte rankNeophyte
    7 months ago

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

  • Anonymous's avatar
    Anonymous
    7 months ago

    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