ACC Check definitions for Visiblity vs Policies

[Tone1]

Hello,

i checked the docs but i'm still not sure what the difference between the Check definition and a policy is especially in view of the Agent itself and what jobs the agent "schedules".

For instance, I have an active policy that runs an "Enhanced Discovery Policy Check" check definition instance, I renamed the check instance to make it distinguishable from the standard check definition, with a scheduled intervall of 86400 seconds (24h), according to the ACC logs of a client this "Check Instance" runs as expected:

2022-01-23T00:49:06.30 [INFO] [agent] Running check, name: policy: Enhanced Discovery Policy, check:Enhanced Discovery Policy Check, id: 4031aa8c07351010722a783eced300c6_bb7da1721bde7810e4dd42ede54bcb7d
2022-01-24T00:49:06.28 [INFO] [agent] Running check, name: policy: Enhanced Discovery Policy, check:Enhanced Discovery Policy Check, id: 4031aa8c07351010722a783eced300c6_bb7da1721bde7810e4dd42ede54bcb7d

I also have an "Enhanced Discovery" Check definition set as "Active" but without any intervall- or cron-based scheduling, anyway it looks like the Agent just decided to run those checks aswell in a 24h intervall:

2022-01-22T15:27:49.16 [INFO] [agent] scheduling check execution, name: Enhanced Discovery, id: 840497441b194910e4dd42ede54bcbf3_d76dea2607515010722a783eced300eb
2022-01-23T15:27:49.12 [INFO] [agent] scheduling check execution, name: Enhanced Discovery, id: f19dd4e81b198910e4dd42ede54bcbe3_d76dea2607515010722a783eced300eb

Without any intervall set i expect the "Check Definition" not to be run at all and that the agent only starts the check instance of the policy.
What do i miss here, is this an expected behaviour, and if so, can i simply set the "Check Definition" itself to "inactive"?

Thanks in advance

[Greg Hubbard1]

Hi there,

Agent Client Collector can be confusing because the relationships between the components are not all that obvious.

First, most of the agent behavior is controlled by policies.

A policy links a collection of agents to a collection of check instances.

A check instance is a copy of a check definition.  Check instances are configured (via parameters) as needed for the task at hand; check definitions provide the "master" definition that is the starting point for each check instance.

There are several ways to stop a check from running, but each method has a different scope:

1. Disable a check instance in a policy, and republish the policy.  This will stop the check for all agents associated with that policy, but the check will still be available to other policies (if any) that reference it.

2. Disable a policy -- this will stop all of the check instances in the policy for all agents associated with the policy.

3. Disable a check definition -- this will stop the check from running regardless of which policy is using it.

I had trouble with the ACC Visibility content, and I found that the easiest way to stop it was to disable the check definitions that were not working correctly.  I also disabled the discovery policy, so I put it in Park AND I set the parking brake.

There are a few checks that the agents can run even if they are not in any policy.  Some examples:

• check-read-log -- reads the agent log file
• config file reader -- reads the acc.yml file
• Restart agent -- request the agent to restart itself

These checks are run when an admin initiates the corresponding UI actions on an agent information page.

Regarding intervals:

• You can set an interval in the check definition record
• You can set an interval in the policy
• You can set an interval in the check instance

I do not know how the hierarchy works, except that the interval in the check instance is used if defined, otherwise one of the other intervals is used.

Until recently, the MID server scheduled each and every check instance for each agent.  This is how "interval" scheduling works.  The "cron" schedule type was added a couple of releases ago, and I think that if you use this then the agent handles its own scheduling for the associated service checks, reducing the load on your MID servers.  The "cron" schedule enables you to use cron-style definitions if you know how to configure them -- for instance, you can run certain checks at a higher rate during business hours and maybe at a different rate during off hours, etc.

The 24 hour interval thing might be a corner case -- it appears that each agent does "something" every 24 hours.  For instance, if you have a check that persistently returns a bad status, the agent will issue a new event for that check every 24 hours (or 24 hours + 1 poll cycle).

You might have found a bug (or feature?) -- if an agent is linked to a policy that has no check interval defined, and the policy contains a check instance that has no interval defined, and the check definition has no interval defined -- does the agent run the check anyway when it goes through its daily refresh?

I am sorry that this was a ramble, but I hope it helps you get a handle on the agent < policy > check instance < check definition thing.

Regards,

Greg Hubbard

[Tone1]

Hi Greg,

I disabled everything (policy and definition) and nothing gets started as expected, i start to enable policies and checks gradually and have a look what the agent does. If it starts check defenitions again without any schedules configured i open an issue.

thanks for the reply.