You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The APM Agent teams are often asked to add support for a new type of data (ex: log events) that will be sent to a new method on the collector. This implementation typically involves duplicating a set of logic so that the new data type has its own record_ function that creates a record of the new data type, list/queue/aggregator for the data to be sent, configuration for tuning how much information to hold before sampling, configuration for how often to harvest the data, and logic to actually harvest the new list/queue/aggregator data on the correct intervals.
Instead of cloning the logic required to support a new data type sent to a new collector method (build the list/queue/aggregator, configuration, harvester, etc) the proposal is to build application logic that would allow defining a new type of custom event with its own configuration, list/queue/aggregator, and harvester. It is a subtle distinction in that most of the effort is the same. The key difference is that this agent implementation should allow agents to support a new category of event in the future that has it’s own sampling rate with minimal future changes to the agent required to support that new category.
Acceptance Criteria
As an agent engineer, it should be clear on how to add a new aggregator and all the necessary logic for it to function
Additional context
This is a recent-ish PR that implemented a new aggregator and all the necessary plumbing to enqueue and send a new type of events.
The text was updated successfully, but these errors were encountered:
Description
The APM Agent teams are often asked to add support for a new type of data (ex: log events) that will be sent to a new method on the collector. This implementation typically involves duplicating a set of logic so that the new data type has its own record_ function that creates a record of the new data type, list/queue/aggregator for the data to be sent, configuration for tuning how much information to hold before sampling, configuration for how often to harvest the data, and logic to actually harvest the new list/queue/aggregator data on the correct intervals.
Instead of cloning the logic required to support a new data type sent to a new collector method (build the list/queue/aggregator, configuration, harvester, etc) the proposal is to build application logic that would allow defining a new type of custom event with its own configuration, list/queue/aggregator, and harvester. It is a subtle distinction in that most of the effort is the same. The key difference is that this agent implementation should allow agents to support a new category of event in the future that has it’s own sampling rate with minimal future changes to the agent required to support that new category.
Acceptance Criteria
As an agent engineer, it should be clear on how to add a new aggregator and all the necessary logic for it to function
Additional context
This is a recent-ish PR that implemented a new aggregator and all the necessary plumbing to enqueue and send a new type of events.
The text was updated successfully, but these errors were encountered: