Adding your Kubernetes Cluster into Monitoring

Before you start, please ensure you’ve imported the most recent suite of Kubernetes DataSources from LogicMonitor’s Repository (Settings | DataSources | Add | From LogicMonitor’s Repository). To add your Kubernetes Cluster into monitoring, start by selecting the Add | Kubernetes Cluster option from the Resource Page:

If you don’t see this option, please contact your CSM. Selecting Add | Kubernetes Cluster will launch a setup wizard for the Kubernetes monitoring integration, as shown (and discussed) next.

Enter a meaningful name – this name will be used to display your monitored cluster in the LogicMonitor Resource Tree.

Then you’ll need to provide LogicMonitor API tokens sufficient for adding Collectors, Collector groups, devices, device groups, and dashboards, as well as for removing devices. Note that because dynamic groups are used to represent the cluster, these tokens need permission to manage the root device group. It is recommended that you have a dedicated API-only user for the integration. You may create a new API-only user within the wizard for this purpose, if desired.

The Kubernetes Version field defaults to Kubernetes version 1.14 or higher (>= 1.14.0), which prompts LogicMonitor to provide Helm 3 installation commands on the following wizard screen. Alternatively, if you are adding Kubernetes versions older than 1.14, you can select "< 1.14.0" from the field's dropdown and LogicMonitor will generate installation commands using Helm 2.

The namespace field controls which cluster namespace the applications needed for monitoring run in, and the resource group controls which group your monitored Kubernetes Cluster will display under in the Resources Tree in LogicMonitor.

The collector group dictates which group your collectors will be added into, and defaults to a new dedicated collector group.

The dashboard group dictates which group your dashboards will be added into, and defaults to a new dedicated dashboard  group.

Ensure that the Kubernetes RBAC Enabled toggle is appropriately selected based on whether or not Kubernetes RBAC is enabled in your cluster.

Opt in to etcd  monitoring if you have etcd running external to your cluster – you’ll be prompted to enter a discovery token if you opt in here.

Enable proxy access if it will be needed for cluster applications to access LogicMonitor’s API to add/remove resources to/from monitoring, and specify proxy server, username and password details accordingly.

The Collector Information section prompts you for a desired number of Collector replicas, a desired Collector size, and a Collector escalation chain. These fields control how many containerized Collectors run within the cluster, what size those Collectors are, and where Collector down alerts get routed:

Step 2 of the wizard provides the Helm install commands you can use to install the applications needed for monitoring (Argus and the Collectorset-Controller), including the command to add LogicMonitor’s Helm Charts. Note that these install commands assume that you already have Helm configured with a Tiller serviceaccount that has a cluster-admin or other sufficient role to create custom resource definitions. Example commands for setting up Helm with this serviceaccount are provided at the top in the comments:

You can copy and paste these commands directly to install the integration in your cluster.

Note that if you are using OpenShift, you may need to elevate the permissions of the serviceaccount for the Collector (after you install the collectorset-controller via Helm) to enable the Collector install. You can do this via the following command (assumes the default namespace is used): oc adm policy add-scc-to-user anyuid system:serviceaccount:default:collector

Note that if you are using Helm v3, you should omit the tiller-related line items in the commands provided (–tiller-namspace).

Once installed, you can use the ‘Verify Connection’ button to ensure that cluster resources were properly added into monitoring and that Collectors were installed. Note that this process may take up to a minute.

Step 3 of the wizard allows you to optionally create Services for specific Kubernetes label key-value pairs. Note that Step 3 will not display if LM Service Insight is not enabled in the account. Each key-value pair you add to the table will result in a new Service that groups together all Pods and Nodes with that label assigned. Metrics will be aggregated across these grouped Pods and Nodes to provide monitoring for overall health based on that label. New Pods and Nodes will be automatically incorporated in the Service, and terminated Pods and Nodes will be automatically removed. The aggregated Service-level data will persist regardless of changes in underlying resources.

After completing the wizard, you’ll see a notice for a new Resource Group, Collector Group and Dashboard Group.

The Resource Group representing your cluster dynamically groups Nodes based on worker role, Pods based on namespace, and Services also based on namespace:

Data is automatically collected from the Kubernetes API for Nodes, Pods, Containers (which are automatically discovered for each Pod), and Services. Additionally, standard applications will be automatically detected and monitored with LogicMonitor’s existing LogicModule library (based on AD for existing modules).