Sensu checks not running on some windows instances

Sensu Go
#1

I have a bunch of windows and linux instances which are running various checks across namespaces but i see the following error on windows instances when the checks are tried to run.

image
image1532×654 50.3 KB

This happens particularly with Windows instances when the checks are not present at the target instance location and therefore the agent is not able to run the check. My understanding of the working of the sensu go architecture is that checks are passed from the backend to the agent for it to execute on the agent instance and therefore should not need the checks present locally. This error generally means the command was run on windows command line (not powershell) and the command file does exist.

The check in the image uses the asset check-memory-usage versions (renamed to window-mem-plugin for the following example) which is meant to work across OS. Check definition is as follows.

  command: check-memory-usage -w 80 -c 95
  runtime_assets:
  - windows-mem-plugin
  subscriptions:
  - windows

This thread is similar to Newbie question...How to add Sensu Checks on Windows but the previous thread was for Sensu EOL where the architecture required the destination instance to have the checks on the instance.

Sensu backend is 6.1.0 (on a Centos 7 instance) and Sensu agent is 6.2.3 on Windows 2016 instance. Both backend and agent are hosted on different AWS machines

No github issue was created on the plugin github repo since this is possibly a Sensu execution issue and not the plugin itself

#2

Hey!

Yeah if you have the asset defined correctly, then the agent on windows should be downloaded the asset in a just in time fashion. I just added this check using this asset in my windows ec2 instance and it just worked as expected.

Question for you… are these perhaps 32bit Windows instances instead of 64bit windows instances?
The builds for this particular asset don’t include a 32bit Windows target, so that could be the problem.

The asset contains multiple builds, each with different filter rules. Only one build has filter rules that matches for Windows OS.

$ sensuctl asset info nixwiz/check-memory-usage
=== nixwiz/check-memory-usage
Name:             nixwiz/check-memory-usage
Namespace:        windows-poc
Builds:           
Build:            0
URL:              https://assets.bonsai.sensu.io/135093ec0aceb37187a0b06f7775155b42a28312/check-memory-usage_0.2.1_windows_amd64.tar.gz
SHA-512 Checksum: e9395838fb849b55bb751d9f418367e8afb1feb4928826ac6adcd726aa86dc9e4f05d046aeac9dfe8a71790c924145b1f27e333706534a2298ebea254b8b48a9
Filters:          entity.system.os == 'windows', entity.system.arch == 'amd64'

check the entity information to see what it says for os and arch
Here’s my running system in EC2:

$ sensuctl entity info windows-demo --format json | jq .system
{
  "os": "windows",
  "platform": "Microsoft Windows Server 2019 Datacenter",
  "platform_family": "Server",
  "platform_version": "10.0.17763 Build 17763",
  "arch": "amd64",
  "libc_type": "",
  "vm_system": "",
  "vm_role": "",
  "cloud_provider": "",
  "processes": null
}

It could be os and arch strings aren’t reporting like we expect on your systems. Or it could be its a 32bit system. If you can provide the system section from the entity info we might be able to figure out more.

#3

Hey,

Definitely related to 32 vs 64 bit. The sensu agent that was pulled by the team was by default 32bit version and that was causing the failure since as @jspaleta rightly mentioned that this asset is not present for 32bit version. As soon as we installed the 64 bit version of the sensu agent 6.2.3, the checks were picked up and executed as expected!

But to not leave @jspaleta question hanging, our system had the following system information

image
image1072×294 16.3 KB

In future i will start noticing these tiny details around assets to be better placed in our infrastructure monitoring. Thanks again!