Add "Entity" field to Sensu Check Type

[portertech]

In order to provide Proxy Check functionality, a Check needs to be able to have a direct association/relation with an Entity. The Sensu Check Type needs an "Entity" attribute (JSON tag "entity"), specifying an Entity by ID (name?).

The Proxy Checks proposed spec can be found at: https://github.com/sensu/engineering/wiki/Proxy-Checks

TODO

• [x] Add "Entity" (JSON tag "entity") to Check Type
• [x] Update Check Type validation function (alphanumeric string)

[grepory]

In the agent, if an entity exists in the Check definition, do not insert the agent entity in the Event. Only fill in the check result.

Then in Eventd, we can query for the Entity and insert it there before storing the event.

[grepory]

If the configured entity doesn't exist, we should log an error indicating as such.

[grepory]

As part of this, we should document any oddities we encounter while looking into the implementation.

[palourde]

If the configured entity doesn't exist, we should log an error indicating as such.

@portertech @grepory I probably misunderstood something but how does the proxy entity get created? I don't see any equivalent to proxy clients in Sensu v1 (https://sensuapp.org/docs/latest/reference/clients.html#proxy-clients).

[grepory]

Oh. I misunderstood this completely. We don’t require the existence of an entity.

Should we just create an entity with only an ID?

[palourde]

So it seems that we already have some notions of proxy entities in the agent code:

https://github.com/sensu/sensu-go/blob/04b2cbc387ce68fab2fd183a7cd2fd1f6141eb8a/agent/validators.go#L23-L36

Therefore, I guess we could use that when an entity is configured in the check and on the backend, we extend the logic implemented in https://github.com/sensu/sensu-go/pull/581 to also create proxy entities.

The only thing I see missing is the equivalent of the client and source attributes of a check result in Sensu v1, so we have know which agent executed the check for this external entity.

[grepory]

OK. So let's port what we have in the documentation, because that will be easier to talk about.

Instead of adding Entity to CheckConfig, add Source. From the 1.x docs:

Proxy clients are created when a check result includes a source attribute

NOTE: this source attribute can be provided in a check definition, or included in a check result published to the Sensu client input socket.

By default, proxy client data includes a minimal number of attributes. The following is an example of proxy client data that is added to the registry.

{
  "name": "switch-x",
  "address": "unknown",
  "subscriptions": [],
  "keepalives": false
}

So, if we go by that documentation:

1. Add Source to CheckConfig
2. If an Agent receives a CheckConfig with a Source, the Agent should not put its Entity into the Event it's publishing with the Check Result.
3. In Eventd, query the store for the Entity ID specified in the Source field (using the CheckConfig's Organization and Environment. a. If an Entity does not exist with the ID specified in Source, then create it with minimal data (using, again, the org/env from checkconfig) -- Entity Class should be proxy (make that an exported, documented constant alongside the agent entity type) b. If the Entity does exist, insert that Entity into the Event
4. Users can customize Entities via the API already--proxy entities are no different.

Make sense?

[grepory]

Sensu 2.x Check results don't have a client attribute, the Event has an Entity instead.

[palourde]

@grepory I would suggest one simple modification regarding the following statement:

If an Agent receives a CheckConfig with a Source, the Agent should not put its Entity into the Event it's publishing with the Check Result.

I believe the agent should still put its Entity into the event since it's used by eventd to determine the organization and environment. But then, if the Source field is not empty, we replace the entity with the one retrieved in the store using this Source field.

Make sense?

[grepory]

That is fine as well.