Usage with other agents

Installation patterns

AWS Lambda

As AWS Lambda methods cost is based on time and bandwidth, the collector is important to be used to offload the majority of the agents workload and allow them to only send coverage information.

To set up the Sealights agents for AWS lambda support, you provide the HTTPS collector URL to the agent. Each agent can have a different way of deploying and providing the HTTPS collector, see each agent's documentation for further information

Front end applications

The HTTPS collector can be used with the frontend to offload sending the footprints and mapping of the method ID’s from the bundled code to the original code.

To configure the HTTPS collector, you need provided the endpoint at the same time that you perform the scan/instrumentation using --collectorUrl {collector url} flag

For instance:

npx slnodejs scan --instrumentForBrowsers --collectorUrl https://<ServerFQDN>:16500/api --workspacepath ./calculator-app [...] --outputpath "sl_web"

Note: all other communication besides the footprints (like agent events) will still be direct to Sealights

Excluding the token

In some cases, for instance when the frontend is exposed out int he public, including the token in the frontend can be a security risk. Therefore, the HTTPS collector can be used to handle the secured communication with Sealights allowing the frontend to communicate directly within the customers network without a token

It is important to understand, that as the non footprint communication is not handled by the collector, that they will not be sent to Sealights, and therefore some functionality will be lost. For instance, agents will no longer be visible in the cockpit.

In order to do this, you need to provide the flag --excludeTokenFromBrowserConfig during the scan/instrumentation command, and the collector config.yaml needs to be set up with the disableTokenValidation: true

Working as a proxy for other agents

The HTTPS Collector can be used as a proxy to perform as single endpoint between the agents and Sealights.

This is useful when there are network/security limitations requiring this and in general only recommended if so.

Note, as there can be a lot of agents involved in the implementation, this will require large bandwidth and high availability and fault tolerance to ensure all the agents can communicate with the Sealights dashboard.

As it behaves as a standard proxy, it is configured with the agents with their standard proxy parameter that can be found in each agents documentation

Last updated

Was this helpful?