Agent Schedule Configuration
I am looking for a definitive guide for the proper configuration of Agent schedules in an HA cluster, and I cannot find any sort of document or discussion that covers this properly.
- which agents to run
- which agents are not required
- which agents should run on which NodeType
- which agents should only be run on a single node.
the document needs to include all the Marketing Agents as well.
all I can find are basic guides on how to use NodeType, and configure Agent Schedules, but no details on how the individual agents should be run ...
This configuration should be a documented science and not an art. I would like to ensure we do this properly, but without guidance from Pega, some of this is just a guessing game.
for instance ... 3 agents clearly generate errors if they are run on more than one node.
ADMSnapshot
RuleUsageSnapshot
PurgeComplianceScores
so, assigning them to a NodeType will not make sense.
does a comprehensive document exist? surely it must.
is is applicable to PRPC 7.3.1 with Marketing?
thanks in advance for any help you can provide.
Pegasystems Inc.
US
Pega Marketing agents: https://community.pega.com/knowledgebase/articles/pega-marketing/pega-marketing-agents. The best documentation is from that of software itself. If possible, you can check out the latest Pega 8.x Admin Studio>>Resources>>Node Classification, which will show you all the OOTB node association for all agents.
Ford Motor Company
CA
I hadn't thought to look at a Pega 8.x install, which uses nodeType by default.
but it still leaves me asking the question on items like the 3 Agents I noted in my original question ...
- ADMSnapshot
- RuleUsageSnapshot
- PurgeComplianceScores
each of these if run on more than one node will generate errors. every night when the agent runs ...
is that just acceptable behaviour? do we just expect to see errors in the production log files due to OOTB Pega agents running on the recommended Agent Schedule (in 8.x all of these are assigned to BackgroundProcessing).
I am trying to eliminate ALL production errors and with these three Agents, they must run on a single node to achieve that.
Pegasystems Inc.
US
Good day @PaulNFord,
Here is a document that will help you at least get started on how to manage "Agents" on 7.3.x environments. There are others like this going back to 7.2.2GA which will be extremely helpful depending on which version you upgraded from.
As to your direct question about how to know where Agents should be running (One Node, All Nodes, BackgroundProcessing Nodes), it depends on each customers cluster, performance and personal preferences. Think of it this way, if you have one agent running at 1AM each night on one node that takes 1 hour to complete, that agent would best be served by running on more than one node to reduce the time it takes to complete. The caveat here is, a) what the agent is doing, b) is it a cluster specific agent and can/should only run on one node and c) would it be better to have the agent running on the BackgroundProcessing DNodeType only. This would mean, the hour it takes to complete is not going to impact live users on the WebUser nodes. That's the performance gain/decision to make on each agent you have running in the cluster.
Good day @PaulNFord,
Here is a document that will help you at least get started on how to manage "Agents" on 7.3.x environments. There are others like this going back to 7.2.2GA which will be extremely helpful depending on which version you upgraded from.
As to your direct question about how to know where Agents should be running (One Node, All Nodes, BackgroundProcessing Nodes), it depends on each customers cluster, performance and personal preferences. Think of it this way, if you have one agent running at 1AM each night on one node that takes 1 hour to complete, that agent would best be served by running on more than one node to reduce the time it takes to complete. The caveat here is, a) what the agent is doing, b) is it a cluster specific agent and can/should only run on one node and c) would it be better to have the agent running on the BackgroundProcessing DNodeType only. This would mean, the hour it takes to complete is not going to impact live users on the WebUser nodes. That's the performance gain/decision to make on each agent you have running in the cluster.
Second, personal preference basically means where do YOU want them to run and at what time to do it. Same scenario as above, but let's say your application has one/more agents and they must run at 12:01AM and take higher priority over others. Simply override the other agents scheduled runtime to before or after that time when you feel it is applicable to do so.
Hope this detail helps answer your questions and if not, do feel free to reply again! Thanks! -Steve
Ford Motor Company
CA
I had that knowledge base guide already, but thank you.
I am not concerned about custom agents, defined for our own use, that design is of course up to us.
but the OOTB Agents and Schedules (as noted in my reply to Kevin above) still present issues, as in they generate errors in production log files on a nightly basis; basically because if they run on more than one node they all try to do the same work, at the same time. This results in Database lock errors (ADMSnapshot, RuleUsageSnapshot) or Error in Obj-Delete-By-Handle errors because the rule was already deleted by another instance of the agent (PurgeComplianceScores)
IMHO Agents should not generate error messages, if they are run in the correct fashion.
so ... either there is a prescribed 'correct' way to schedule them, OR ... it is simply expected that they will generate errors, and we have to live with that.
either way I would expect that the Vendor would have a recommended design for how ALL of the OOTB agents should run in an HA cluster ... preferably without generating errors.
Pegasystems Inc.
US
I agree, none of the OOTB Agents should be causing exceptions assuming they have the appropriate Access Group(s) associated with each to properly run. For example, the SLA Agent runs on all your cases, so that agent must have access to the rules to use or it will generate exceptions. RuleUsageSnapshot is one that should only be running on the BackgroundProcessing node(s). If this is failing, there is something else going on and should be reported as a Support Request so we can investigate more fully. Not knowing what you upgraded from what you have for Data-Agent-Queue instances and how they are setup, what platform you are running on, it would be difficult to diagnose the "why" you see errors. It also goes beyond the scope of the Collaboration Center. Some OOTB Agents do require additional setup/configuration and that info can be found in online help or Pega Community (https://community.pega.com).
Please report the bug/errors you are experiencing through our online support site here: https://community.pega.com/support and select "Submit a Support Request" option so that we can get a full picture of your environment and provide the appropriate course of action to resolve them. Thanks!
Pegasystems Inc.
US
Please reply back with your SR # so that we may keep track of it for this thread.
Also reference this post when opening your SR so that our GCS Engineer has this information to catch up on when working on your ticket.
Thanks!
Marissa | Senior Moderator | Pega Collaboration Center