Hey,
Based on what you are reporting so far, its not clear that your check is even running or that your agent has established a connection with the backend. Before trying to troubleshoot if the assets are working, letβs first confirm that the check is running as scheduled and is creating a Sensu event.
Even if the asset configuration is botched, the check should be running as scheduled (at a 1 minute cadence), possibly returning an error. If the check isnβt running at all that suggests a couple of possible configuration problems that would prevent the agent from scheduling the check execution.
1. Your agent and your check maybe in different Sensu namespaces
Double check that your sensuctl is configured to operate in the same namespace as your agent.
sensuctl config view
I doubt this is the problem since your agent is using default namespace right now and you are just starting to learn how to use Sensu. But if you have painted outside the lines a little bit while kicking the tires you might be in a different namespace than you thought so its good to confirm.
2. Agent may be misconfigured or needs to be restarted
This is the more likely problem you may be having based on the information you have provided so farβ¦
did you restart your sensu-agent service after changing the subscriptions to include system? Did the agent restart correctly? Is it configured to talk to the backend correctly?
You can ask the Sensu cluster what it knows about the registered entities to confirm the subscriptions are up2date.
sensuctl entity list
First is your agent in the list?
Second do the subscriptions look as you expect?
Third is the Last Seen time reasonable? (within 30 seconds or so with default agent settings)
Iβll show out part of my output as an example:
ID Class OS Subscriptions Last Seen
carbon-f31 agent linux test,linux, entity:carbon-f31 2020-07-06 15:21:27 -0800 AKDT
centos6-ipv6 agent linux linux,entity:centos6-ipv6 2020-07-06 15:21:16 -0800 AKDT
After confirming that the agent is participating in the system subscription using the entity list, Iβd next make sure the cpu-check event has been created for the entity.
sensuctl event list
You should see an entry for a βkeepaliveβ check associated with your agent and it should have zero (OKAY) status. If the keepalive is missing or non-zero status, thats a problem with the agent connectivity with the backend weβll need to sort out.
You should also see an entry in the output corresponding to your agent entity and the check-cpu check
If its not-zero status the output column should help us diagnose it.
3. Network misconfiguration
Itβs difficult to separate agent misconfiguration from some types of network misconfiguration so if anything above didnβt verify as expected, there are some networking issues to examine as well.
If you have a firewall or network security group in place, make sure the tcp 8081 port access is configured to let the agent in. Also be aware if you have some sort of proxy server in between managing the 8081 port, that its configured correctly for long lived websocket connections. If your proxy has problems with websockets, you should definitely see artifacts of connecting and reconnecting in your sensu-agent journal using journalctl.