Edge Delta Environment Variables

Environment Variables for Edge Delta Pipelines.

  5 minute read  

Overview

Environment variables are dynamic values that can affect the behavior of running processes. They are used by the operating system and applications running on it to pass configuration options and other important parameters. These values are set during installation and can be used to control and influence various aspects of the agent’s behavior.

Frequently Used Environment Variables

The following environment variable parameters can be passed in when you deploy the Edge Delta pipeline.

DNS_SERVICE_NAME and DNS_SERVICE_NAMESPACE

Overrides the default DNS service configuration. Most standard Kubernetes clusters will use kube-dns (even if CoreDNS is running, the service is usually still named kube-dns in the kube-system namespace). OpenShift clusters typically use dns-default in the openshift-dns namespace. If you encounter an environment that uses a different DNS service configuration, you can override it by setting DNS_SERVICE_NAMESPACE and DNS_SERVICE_NAME before starting your application.

ED_API_KEY

Identifies and authorizes access to your pipeline’s configuration in the Edge Delta back end.

ED_ARCHIVE_FLUSH_INTERVAL

Specifies the duration after which logs are flushed and sent to the configured archiving destination. The default value is 30m.

ED_CLUSTER_NAME

Specifies a value that is injected into the ed.cluster.name resource field.

ED_CUSTOM_TAGS

Attaches attributes statically. Format should be in form: <key 1>:<value 1>|<key 2>:<value 2>|...

ED_HOST_OVERRIDE

By default, the agent fetches the host name using the operating system’s built-in methods:

  • macOS: The agent calls os.HostName(), which retrieves the host name from kern.hostname.
  • Linux: The agent calls os.HostName(), which retrieves the host name from /proc/sys/kernel/hostname.
  • Windows: The agent calls ComputerNameEx system call, which retrieves the hostname from the kernel.

You can configure a custom name with the ED_HOST_OVERRIDE variable. This is useful to help identify agents.

export ED_HOST_OVERRIDE="custom-hostname"

Alternatively you can change the host name:

  • macOS: sudo scutil --set HostName "new-hostname"
  • linux: sudo hostname new-hostname

Note: This command changes the hostname temporarily. To make it permanent, additional steps, such as editing the /etc/hostname and /etc/hosts files, may be required, depending on the Linux distribution.

  • windows (PowerShell): Rename-Computer -NewName "new-hostname"; Restart-Computer

ED_INSTALL_PATH

Specifies a custom location to install the agent in a Unix based system (Linux or macOS)

ED_K8S_NAMESPACE_NAME

Indicates the Kubernetes namespace in which the Edge Delta agent is deployed. This helps in categorizing logs and metrics by namespace, aiding multi-tenant or multi-team environments.

ED_K8S_NODE_NAME

Identifies the Kubernetes node where the Edge Delta agent pod is scheduled. This provides node-level context to the data, which is valuable for troubleshooting node-specific issues.

ED_K8S_POD_NAME

Specifies the Kubernetes Pod name in which the Edge Delta agent is running. This variable enhances observability and tracing of log data by associating collected data with the specific pod instance.

ED_LOGGING_DIR

Overrides the default logging directory of the agent. The default is /var/log/edgedelta/*. This is useful if the default location on disk can only be accessed by root users.

ED_TAG_OVERRIDE

Specifies a tag that is different to the one configured in the Web App. Use this option to deploy two pipelines with the same configuration.

HTTP_PROXY

Uses proxy details to route the pipeline’s outbound traffic through an HTTP internal proxy.

HTTPS_PROXY

Uses proxy details to route the pipeline’s outbound traffic through an HTTPS internal proxy.

NO_PROXY

Disables the proxy for requests that hit a specific destination.

OTEL_SERVICE_NAME

Defines the resource.service.name field in Edge Delta OTEL messages.

STORE_PORT

Uses a port number to expose agent metrics storage.

Scenarios

  • API Key Management: Using variables like ED_API_KEY to manage authorization tokens for accessing services securely.
  • Custom Tagging and Identification: Using variables like ED_CUSTOM_TAGS for tagging resources and ED_HOST_OVERRIDE to specify custom host names, which can help during debugging and monitoring.
  • Proxy Configuration: Setting HTTP_PROXY and HTTPS_PROXY to route traffic through proxies, crucial in environments with tight network security policies.
  • Log Management: Using variables such as ED_ARCHIVE_FLUSH_INTERVAL to manage how logs are processed and stored.
  • Service Setup: Configuring services via variables like OTEL_SERVICE_NAME and STORE_PORT to set up monitoring and service-specific parameters.

Setting Environment Variables

Linux/macOS

Only ED_ENV_VARS, ED_INSTALL_PATH and ED_API_KEY are passed as installation variables when installing in Linux/macOS. To use other variables you need to use ED_ENV_VARS and pass in a child variable:

export VARIABLE_NAME="value"

or

export ED_ENV_VARS="<VARIABLE>=value"

Example:

export ED_API_KEY="your-api-key"

or

Example 2:

export ED_ENV_VARS="ED_CUSTOM_TAGS=tag1:value1|tag2:value2|tag3:value3" ED_API_KEY=your-api-key

Note: Variables exported in this way only persist in the shell session unless passed to the install command or configured persistently.

To update the variable for a running pipeline you don’t need to reinstall but you do need to restart the agent. Using a custom installation path requires a re-install.

For Linux-based Edge Delta agents running as systemd services (where the default Linux install path is /opt/edgedelta/agent/), environment variables must be set in a system-level context (i.e. use /etc/sysconfig/edgedelta). Using export in a shell session will not propagate these variables to the agent if it’s managed by systemd.

For example, if your YAML config uses:

aws_key_id: '{{ Env "ENV_AWS_ACCESS_KEY" }}'
aws_sec_key: '{{ Env "ENV_AWS_SECRET" }}'

and credentials are not being picked up, do the following:

  1. Create the Sysconfig File
sudo mkdir -p /etc/sysconfig/
sudo touch /etc/sysconfig/edgedelta
  1. Add Environment Variables Edit the file:
sudo vi /etc/sysconfig/edgedelta

Press i and add:

ENV_AWS_ACCESS_KEY=AKIAIOSFODNN7EXAMPLE
ENV_AWS_SECRET=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

Save and exit:

  • Press Esc
  • Type :wq and hit Enter
  1. Restart the Agent
sudo systemctl daemon-reexec
sudo systemctl daemon-reload
sudo systemctl restart edgedelta
  1. Validate the Environment Confirm variables are set:
sudo cat /proc/$(pidof edgedelta)/environ | tr '\0' '\n' | grep ENV

Expected output:

ENV_AWS_ACCESS_KEY=AKIAIOSFODNN7EXAMPLE
ENV_AWS_SECRET=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

Edge Delta’s Linux agent is managed by systemd, and its service unit explicitly supports loading environment variables from /etc/sysconfig/edgedelta. This method is preferred over alternatives like export commands or systemctl edit overrides because it integrates directly with the service’s existing configuration, requires no changes to unit files, and ensures variables are securely and persistently loaded at startup. It also aligns with standard Linux practices for service-level environment management, making it easier to automate, audit, and maintain.

Security Best Practices

Restrict file access:

sudo chmod 600 /etc/sysconfig/edgedelta
sudo chown root:root /etc/sysconfig/edgedelta

Use IAM roles when possible: If your agents run on EC2 or EKS, prefer IAM roles over static credentials to reduce risk.

Windows (Command Prompt)

set VARIABLE_NAME="value"

Example:

set ED_API_KEY="your-api-key"

Windows (PowerShell)

$env:VARIABLE_NAME="value"

Example:

$env:ED_API_KEY="your-api-key"