Forum Discussion

Lewis_Beard's avatar
4 months ago

LogicModules, Exchange, Kubernetes

A week or two ago, I opened a ticket about Kubernetes modules with support. I was having a hard time finding things in the LogicModules section for Kubernetes, but at the time I didn't realize that UIv4, which is required now for LogicModules, split out installation to Exchange and management to My Modules Toolbox. Ultimately chatting with support, and really reading about UIv4 modules from some of your old posts here, I figured out that install and management are split out. At least I think that's the case.

But I also asked LM in that conversation if there exists documentation on each Kubernetes module (answer: no) and also why there are 13 installed on my portal and 96 that aren't, and I asked if I really had to install 96 modules from the Exchange.

I got a screenshot showing a portal (couldn't tell if it was mine due to the top not being present) of the Toolbox with all 100+ modules, but on my portal, I just see 13 installed and 96 different ones on Exchange.

Twice I was given this link ( https://www.logicmonitor.com/support/modules-management ) in my conversation so I assume that I'm completely misunderstanding something, because I've read that document a dozen times before.

I need to start acting instead of scratching my head. But I'm aware I'm probably missing something important. We have no Kubernetes clusters installed, I see 13 up-to-date modules for it in my portal, and 96 in the Exchange. And I know none of the applies-to conditions are met (yet) on my portal

But the Kubernetes doc I found is about how to install a cluster, with a one-liner up top on that page saying to install the Kubernetes logicmodules ( https://www.logicmonitor.com/support/monitoring/containers/kubernetes/adding-your-kubernetes-cluster-into-monitoring ).  It mentions using the repository, but its hard for me to be sure how many because its harder to search.

TL;DR: Is there any reason I shouldn't install these 96 Kubernetes modules? If you don't feel you can say, no worries. I let myself get paranoid. If nobody told me otherwise, I'd just install all of them from Exchange, and then start adding a cluster using the docs for that. However the large number of modules makes me hesitate, and my seeming misunderstanding in the support ticket.Apologies for my ignorance.

Thanks for your time.

  • I don't know much about monitoring Kubernetes specifically, but what I've done in general... If a NEW DataSource has an AppliesTo that does not apply to ANY device, it is safe to just import it. It will not apply to any devices so will not cause new alerts, which is my primary concern with DataSource updates. When I've done rounds of DataSource updates in the past, that was the first thing I did, to get them out of the way before digging into the rest.

    I personally just import everything, even if I was not likely to ever use it. I think it was just easier that way and as an MSP I never know if I would need it eventually anyway. But as I think about it, I wonder if that is mostly because I've used the legacy Repository method for years and it shows everything. It was easier to try to get the list down to be as small as possible. But now that New DataSources (Exchange) is separated from existing DataSources (My Toolbox), perhaps that isn't as important anymore. But I'm still likely to continue to do it. 109 DataSources for Kubernetes is quite a lot, might be the largest I've seen. But again I'm not aware of any issues with having too many DataSources that are not being used or anything.

    In your situation, where you want to start monitoring Kubernetes but have no devices yet, I personally would first start by adding and updating all the related official LogicModules, all 109 or so. It's a lot easier to update LogicModules when it's not being used, it becomes A LOT harder to update them later. Also it's easier to just let LM auto-add what DataSources it wants (after completing requirements/properties) rather than try to work out what DataSources you will end up needing.

  • I don't know much about monitoring Kubernetes specifically, but what I've done in general... If a NEW DataSource has an AppliesTo that does not apply to ANY device, it is safe to just import it. It will not apply to any devices so will not cause new alerts, which is my primary concern with DataSource updates. When I've done rounds of DataSource updates in the past, that was the first thing I did, to get them out of the way before digging into the rest.

    I personally just import everything, even if I was not likely to ever use it. I think it was just easier that way and as an MSP I never know if I would need it eventually anyway. But as I think about it, I wonder if that is mostly because I've used the legacy Repository method for years and it shows everything. It was easier to try to get the list down to be as small as possible. But now that New DataSources (Exchange) is separated from existing DataSources (My Toolbox), perhaps that isn't as important anymore. But I'm still likely to continue to do it. 109 DataSources for Kubernetes is quite a lot, might be the largest I've seen. But again I'm not aware of any issues with having too many DataSources that are not being used or anything.

    In your situation, where you want to start monitoring Kubernetes but have no devices yet, I personally would first start by adding and updating all the related official LogicModules, all 109 or so. It's a lot easier to update LogicModules when it's not being used, it becomes A LOT harder to update them later. Also it's easier to just let LM auto-add what DataSources it wants (after completing requirements/properties) rather than try to work out what DataSources you will end up needing.

  • Anonymous's avatar
    Anonymous

    Do you have any kubernetes clusters to monitor? If not, you don't need any of the k8s datasources.

    • Lewis_Beard's avatar
      Lewis_Beard
      Icon for Expert rankExpert

      I have some portal users who want to monitor one. So I want to get all the modules installed so that we have all the options.