Aggregator Agents

Edge Delta agents are installed by default as a daemonset in a distributed agent approach. This works well for most architectures as most data sources such as files, system events, and container logs are specific to the host. However, there are some scenarios where running Edge Delta agents as daemons is not appropriate:

• A single agent has to process high-volume traffic such as syslog TCP monitoring over a single port. This may overwhelm an agent’s daemonset resource allocation.
• There are external pull-based data sources such as Kafka queues, Azure Event Hubs, Amazon S3 and SQS or Amazon CloudWatch. Each agent in the daemonset may try to calculate metrics for these logs independently leading to duplication.
• There are external push-based data sources such as Fastly logs that need to be consumed by an HTTPS endpoint. An agent daemonset may be saturated and scaling it might cause duplication.

An Agent for Aggregation

An Aggregator agent configuration solves for these scenarios by splitting up the role of a single agent daemonset between two agent components that share a single configuration:

• Multiple Processor Agents: These agents are responsible for consuming raw log data, source discovery, and running the metric, pattern and TopK processing logic of the configuration before passing metrics to the aggregator agent. They also handle flushing of raw logs, such as EDACs, to the data destinations in response to trigger events generated by the aggregator agent.
• An Aggregator Agent: This agent is responsible for consuming the derived data from the processor agents and running the sum, max, min and threshold logic against the aggregated data and generating threshold triggers.

In addition, the Aggregator Agent solution has a buffering layer made up of an HTTP/TCP Recorder and Persistent Volume per processor agent. These components provided persistence and log queuing in case one agent restarts or lags behind the input volume.

The Aggregator Agent Manifest

To install the aggregator agent you need to enable the aggregatorProps parameter in the Edge Delta values.yaml manifest as follows.

aggregatorProps:
  enabled: true
  port: 9191
  serviceDNSSuffix: "svc.cluster.local"
  storageClassName: ""

You set the aggregatorProps.enable parameter to true.

The port and service DNS shouldn’t need to be adjusted, they are used to construct an endpoint for the aggregator agent service so that processor agents can communicate with aggregator: http://ed-aggregator-svc.my-namespace.svc.cluster.local:9191

The buffering layer needs a small amount of disk space to persist some internal source-related information to be able to work smoothly after restarts and upgrades. The storageClassName shouldn’t need to be changed but if your k8s cluster has specific storage classes you can set storageClassName accordingly.

When this updated manifest is used to install the agent in your environment, it installs the load balancer, buffering layer, processor agents, and an aggregator agent.

Installing an Aggregator Agent

Before you install the agent, you should create an agent configuration in the Edge Delta web app and copy the API key to pass in during the installation. All the processor agents and the aggregator agent share a single configuration.

You can use Helm to install the aggregator agent passing in the aggregator parameter:

--set aggregatorProps.enabled=true

Alternatively, you an create a yaml file with all your customizations and pass it in to make upgrades or redeployment easier. See Install with Custom Settings for more information.