Provision pipeline elements

• 1: AxoRouter
• 1.1: Install AxoRouter on Kubernetes
• 1.1.1: Advanced installation options
• 1.2: Install AxoRouter on Linux
• 1.2.1: Advanced installation options
• 1.2.2: Run AxoRouter as non-root
• 2: AxoSyslog
• 3: Splunk Connect for Syslog (SC4S)
• 4: syslog-ng
• 5: Axolet
• 5.1: Install Axolet
• 5.2: Advanced installation options
• 5.3: Run axolet as non-root
• 5.4: Reinstall Axolet
• 6: Data sources
• 7: Destinations
• 8: Windows host - agent based solution
• 8.1: Manage the Windows agent
• 8.2: Advanced installation options
• 8.3: Configure data collection

1 - AxoRouter

1.1 - Install AxoRouter on Kubernetes

To install AxoRouter on a Kubernetes cluster, complete the following steps. For other platforms, see AxoRouter.

Prerequisites

Kubernetes version 1.29 and newer

Minimal resource requirements

• CPU: at least 100m
• Memory: 256MB
• Storage: 8Gi

Network access

The hosts must be able to access the following domains related to the AxoConsole:

• When using AxoConsole SaaS:

  • <your-tenant-id>.cloud.axoflow.io: HTTPS traffic on TCP port 443, needed to download the binaries for Axoflow software (like Axolet and AxoRouter).
  • kcp.<your-tenant-id>.cloud.axoflow.io: HTTPS (mutual TLS) traffic on TCP port 443 for management traffic.
  • telemetry.<your-tenant-id>.cloud.axoflow.io: HTTPS (mutual TLS) traffic on TCP port 443, where Axolet sends the metrics of the host.
  • us-docker.pkg.dev: HTTPS traffic on TCP port 443, for pulling container images (AxoRouter only).

• When using an on-premise AxoConsole:

  • The following domains should point to AxoConsole IP address to access Axoflow from your desktop and AxoRouter hosts:

    • your-host.your-domain: The main domain of your AxoConsole deployment.
    • authenticate.your-host.your-domain: A subdomain used for authentication.
    • idp.your-host.your-domain: A subdomain for the identity provider.

  • The AxoConsole host must have the following Open Ports:

    • Port 80 (HTTP)
    • Port 443 (HTTPS)

• When installing Axoflow agent for Windows:

  • github.com: HTTPS traffic on TCP port 443, for downloading installer packages.

Install AxoRouter

1. Open the AxoConsole.

2. Select Provisioning.

3. Select the Host type > AxoRouter > Kubernetes. The one-liner installation command is displayed.

4. Open a terminal and set your Kubernetes context to the cluster where you want to install AxoRouter.

5. Run the one-liner, and follow the on-screen instructions.

   Current kubernetes context: minikube
   Server Version: v1.28.3
   Installing to new namespace: axorouter
   Do you want to install AxoRouter now? [Y]
   

6. Register the host.

   1. Reload the Provisioning page. There should be a registration request for the new AxoRouter deployment. Select ✓.

      

   2. Select Register to register the host. You can add a description and labels (in label:value format) to the host.

      

   3. Select the Topology page. The new AxoRouter instance is displayed.

Create a flow

1. If you haven’t already done so, create a new destination.
2. Create a flow to connect the new AxoRouter to the destination.

   1. Select Flows.

   2. Select Create New Flow.

   3. Enter a name for the flow, for example, my-test-flow.

      

   4. In the Router Selector field, enter an expression that matches the router(s) you want to apply the flow. To select a specific router, use a name selector, for example, name = my-axorouter-hostname.

      It also makes more complex filtering possible, using the Equals, Contains (partial match), and Match (regular expression match) operators. Note that:

      • To execute the search, click Search, or hit ESC then ENTER.
      • AxoConsole autocompletes the built-in and custom labels and field names, as well as their most frequent values, but doesn’t autocomplete labels and variables created by data parsing and processing steps.
      • You can use the AND and OR operators to combine expressions, and also parenthesis if needed. For details on AQL, see AQL operator reference.
      • The precedence of the operators is the following: parentheses, AND, OR, comparison operators.
      • Use the usual keyboard shortcuts to undo (⌘/Ctrl + Z) or redo (⌘/Ctrl + Shift + Z) your edits.

   5. Select the Destination where you want to send your data. If you don’t have any destination configured, you can select + Create New in the destination section to create a new destination now. For details on the different destinations, see Destinations.

      By default, you can select only external destinations. If you want to send data to another AxoRouter, enable the Show all destinations option, and select the connector of the AxoRouter where you want to send the data.

      

   6. (Optional) To process the data transferred in the flow, select Add New Processing Step. For details, see Processing steps. For example:

      1. Add a Classify, a Parse, and a Reduce step, in that order, to automatically remove redundant and empty fields from your data.
      2. To select which messages are processed by the flow, add a Select Messages step, and enter a filter into the AQL Expression field. For example, to select only the messages received from Fortinet FortiGate firewalls, use the meta.vendor = fortinet AND meta.product = fortigate query.
      3. Save the processing steps.

      

   7. Select Create.

   8. The new flow appears in the Flows list.

      

Send logs to AxoRouter

By default, AxoRouter accepts data on the following ports (unless you’ve modified the default connector rules):

• 514 UDP and TCP for RFC3164 (BSD-syslog) and RFC5424 (IETF-syslog) formatted traffic. AxoRouter automatically recognizes and handles both formats.
• 601 TCP for RFC5424 (IETF-syslog) and RFC3164 (BSD-syslog) formatted traffic. AxoRouter automatically recognizes and handles both formats.
• 6514 TCP for TLS-encrypted syslog traffic.

• 4317 TCP for OpenTelemetry log data.

To receive data on other ports or other protocols, configure other connector rules for the AxoRouter host.

For TLS-encrypted syslog connections, create a new connector rule or edit an existing one, and configure the keys and certificates needed to encrypt the connections. For details, see Syslog.

Upgrade AxoRouter

AxoConsole raises an alert for the host when a new AxoRouter version is available. To upgrade to the new version, re-run the one-liner installation command you used to install AxoRouter, or select Provisioning > Select type and platform to create a new one.

1.1.1 - Advanced installation options

When installing AxoRouter, you can set a number of advanced options if needed for your environment. Setting the advanced options in the AxoConsole automatically updates the one-liner command that you can copy and run.

Alternatively, before running the one-liner you can use one of the following methods:

• Set the related environment variable for the option. For example:

  export AXOROUTER_USER=syslogng
  export AXOROUTER_GROUP=syslogng
  

• Set the related URL parameter for the option. For example:

  curl -fLsH 'X-AXO-TOKEN:random-generated' 'https://<your-tenant-id>.cloud.axoflow.io/setup.sh?type=AXOROUTER&platform=K8S&parameter=value' | sh
  

Proxy settings

Use the http_proxy=, https_proxy=, no_proxy= parameters to configure HTTP proxy settings for the installer. To configure the Axolet service to use the proxy settings, enable the AXOLET_AVOID_PROXY parameter as well. Lowercase variable names are preferred because they work universally.

Installation options

You can pass the following parameters to the installation script as environment variables, or as URL parameters.

AxoRouter image override

Description: Deploy the specified AxoRouter image.

Helm chart

Description: The path or URL of the AxoRouter Helm chart.

Helm chart version

Description: Deploy the specified version of the Helm chart.

Helm extra arguments

Description: Additional arguments passed to Helm during the installation.

Helm release name

Description: Name of the Helm release.

Image repository

Description: Deploy AxoRouter from a custom image repository.

Image version

Description: Deploy the specified AxoRouter version.

Namespace

Description: The namespace where AxoRouter is installed.

Axolet parameters

API server host

Description: Override the host part of the API endpoint for the host.

Axolet executable path

Description: Path to the Axolet executable.

Axolet image override

Description: Deploy the specified Axolet image.

Axolet image repository

Description: Deploy Axolet from a custom image repository.

Axolet image version

Description: Deploy the specified Axolet version.

Initial GUID

Description: Set a static GUID.

1.2 - Install AxoRouter on Linux

AxoRouter is a key building block of Axoflow that collects, aggregates, transforms and routes all kinds of telemetry and security data automatically. AxoRouter for Linux includes a Podman container running AxoSyslog, Axolet, and other components.

To install AxoRouter on a Linux host, complete the following steps. For other platforms, see AxoRouter.

What the install script does

When you deploy AxoRouter, you run a command that installs the required software packages, configures them and sets up the connection with Axoflow.

The installer script installs the axolet packages, then executes the configure-axolet command with the right parameters. (If the packages are already installed, the installer will update them unless the none package format is selected when generating the provisioning command.)

The install script is designed to be run as root (sudo), but you can configure AxoRouter to run as a non-root user.

The installer script performs the following main steps:

• Executes prerequisite checks:
  • Tests the network connection with the console endpoints.
  • Checks if the operating system is supported.
    • Checks if podman is installed.

• Downloads and installs the axorouter RPM or DEB package.

  • The package contains the axorouter-ctl and setup-axorouter commands and the axorouter.container unit files for podman-systemd.

    Note: The legacy version of the package uses docker and standard service units.

• Executes the setup-axorouter command, which

  • Updates the environment variables used by the axorouter service.
  • Enables and starts the AxoRouter service.

• Downloads and installs the axolet RPM or DEB package.
  • The package contains the axolet and configure-axolet commands, and the axolet.service systemd unit file.
• The configure-axolet command is executed with a configuration snippet on its standard input which contains a token required for registering into the management platform. The command:

  • Writes the initial /etc/axolet/config.json configuration file.

    Note: if the file already exists it will only be overwritten if the Overwrite config option is enabled when generating the provisioning command.

  • Enables and starts the axolet service.

axolet performs the following main steps on its first execution:

• Generates and persists a unique identifier (GUID).
• Initiates a cryptographic handshake process to AxoConsole.
• AxoConsole issues a client certificate to AxoRouter, which will be stored in the above mentioned config.json file.
• The service waits for an approval on AxoConsole. Once you approve the host registration request, axolet starts to manage the local services and send telemetry data to AxoConsole. It keeps doing so as long as the agent is registered.

Prerequisites

• AxoRouter should work on most Red Hat and Debian compatible Linux distributions. For production environments, we recommend using Red Hat 9.

• Podman must be installed on the host (sudo yum install podman)
• When using AxoRouter with an on-premises AxoConsole deployment, you must prepare the AxoRouter host

Minimal resource requirements

• CPU: at least 100m
• Memory: 256MB
• Storage: 8Gi

Network access

The hosts must be able to access the following domains related to the AxoConsole:

• When using AxoConsole SaaS:

  • <your-tenant-id>.cloud.axoflow.io: HTTPS traffic on TCP port 443, needed to download the binaries for Axoflow software (like Axolet and AxoRouter).
  • kcp.<your-tenant-id>.cloud.axoflow.io: HTTPS (mutual TLS) traffic on TCP port 443 for management traffic.
  • telemetry.<your-tenant-id>.cloud.axoflow.io: HTTPS (mutual TLS) traffic on TCP port 443, where Axolet sends the metrics of the host.
  • us-docker.pkg.dev: HTTPS traffic on TCP port 443, for pulling container images (AxoRouter only).

• When using an on-premise AxoConsole:

  • The following domains should point to AxoConsole IP address to access Axoflow from your desktop and AxoRouter hosts:

    • your-host.your-domain: The main domain of your AxoConsole deployment.
    • authenticate.your-host.your-domain: A subdomain used for authentication.
    • idp.your-host.your-domain: A subdomain for the identity provider.

  • The AxoConsole host must have the following Open Ports:

    • Port 80 (HTTP)
    • Port 443 (HTTPS)

• When installing Axoflow agent for Windows:

  • github.com: HTTPS traffic on TCP port 443, for downloading installer packages.

Install AxoRouter

1. Select Routers > Create New Router.

   

2. Select the platform (Linux). The one-liner installation command is displayed.

   

   If needed, set the Advanced options (for example, proxy settings) to modify the installation parameters. Usually, you don’t have to use advanced options unless the Axoflow support team instructs you to do so.

3. Open a terminal on the host where you want to install AxoRouter.

4. Run the one-liner, then follow the on-screen instructions.

   Note Running the provisioning command with sudo would mask environment variables of the calling shell. Either start the whole procedure from a root shell, or let the install script call sudo when it needs to. In other words: don’t add the sudo command to the provisioning command.

   Example output:

   Do you want to install AxoRouter now? [Y]
   
   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                   Dload  Upload   Total   Spent    Left  Speed
   100  5480  100  5480    0     0  32076      0 --:--:-- --:--:-- --:--:-- 33414
   Selecting previously unselected package axorouter.
   (Reading database ... 17697 files and directories currently installed.)
   Preparing to unpack axorouter.deb ...
   Unpacking axorouter (0.66.0) ...
   Setting up axorouter (0.66.0) ...
   Low maximum socket receive buffer size value detected: 7500000 bytes (7.2MB).
   Do you you want to permanently set the net.core.rmem_max sysctl value to 33554432 bytes (32MB) on this system? [Y]
   
   net.core.rmem_max = 33554432
   Created symlink '/etc/systemd/system/multi-user.target.wants/axostore.path' → '/etc/systemd/system/axostore.path'.
   Created symlink '/etc/systemd/system/multi-user.target.wants/axorouter-wec.path' → '/etc/systemd/system/axorouter-wec.path'.
   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                   Dload  Upload   Total   Spent    Left  Speed
   100 42.9M  100 42.9M    0     0  28.1M      0  0:00:01  0:00:01 --:--:-- 28.2M
   Selecting previously unselected package axolet.
   (Reading database ... 17707 files and directories currently installed.)
   Preparing to unpack axolet.deb ...
   Unpacking axolet (0.66.0) ...
   Setting up axolet (0.66.0) ...
   Created symlink '/etc/systemd/system/multi-user.target.wants/axolet.service' → '/usr/lib/systemd/system/axolet.service'.
   Now continue with onboarding the host on the Axoflow web UI.
   

5. Register the host.

   1. Reload the Provisioning page. There should be a registration request for the new AxoRouter deployment. Select ✓.

      

   2. Select Register to register the host. You can add a description and labels (in label:value format) to the host.

      

   3. Select the Topology page. The new AxoRouter instance is displayed.

Create a flow

1. If you haven’t already done so, create a new destination.
2. Create a flow to connect the new AxoRouter to the destination.

   1. Select Flows.

   2. Select Create New Flow.

   3. Enter a name for the flow, for example, my-test-flow.

      

   4. In the Router Selector field, enter an expression that matches the router(s) you want to apply the flow. To select a specific router, use a name selector, for example, name = my-axorouter-hostname.

      It also makes more complex filtering possible, using the Equals, Contains (partial match), and Match (regular expression match) operators. Note that:

      • To execute the search, click Search, or hit ESC then ENTER.
      • AxoConsole autocompletes the built-in and custom labels and field names, as well as their most frequent values, but doesn’t autocomplete labels and variables created by data parsing and processing steps.
      • You can use the AND and OR operators to combine expressions, and also parenthesis if needed. For details on AQL, see AQL operator reference.
      • The precedence of the operators is the following: parentheses, AND, OR, comparison operators.
      • Use the usual keyboard shortcuts to undo (⌘/Ctrl + Z) or redo (⌘/Ctrl + Shift + Z) your edits.

   5. Select the Destination where you want to send your data. If you don’t have any destination configured, you can select + Create New in the destination section to create a new destination now. For details on the different destinations, see Destinations.

      By default, you can select only external destinations. If you want to send data to another AxoRouter, enable the Show all destinations option, and select the connector of the AxoRouter where you want to send the data.

      

   6. (Optional) To process the data transferred in the flow, select Add New Processing Step. For details, see Processing steps. For example:

      1. Add a Classify, a Parse, and a Reduce step, in that order, to automatically remove redundant and empty fields from your data.
      2. To select which messages are processed by the flow, add a Select Messages step, and enter a filter into the AQL Expression field. For example, to select only the messages received from Fortinet FortiGate firewalls, use the meta.vendor = fortinet AND meta.product = fortigate query.
      3. Save the processing steps.

      

   7. Select Create.

   8. The new flow appears in the Flows list.

      

Send logs to AxoRouter

Configure your hosts to send data to AxoRouter.

• For appliances that are specifically supported by Axoflow, see Sources.

• For other appliances and generic Linux devices, see Generic tips.

• For a quick test without an actual source, you can also do the following (requires nc to be installed on the AxoRouter host):

  1. Open the AxoConsole, select Topology, then select the AxoRouter instance you’ve deployed.

  2. Select ⋮ > Tap log flow > Input log flow. Select Start.

  3. Open a terminal on your AxoRouter host.

  4. Run the following command to send 120 test messages (2 per second) in a loop to AxoRouter:

     for i in `seq 1 120`; do echo "<165> fortigate date=$(date -u +%Y-%m-%d) time=$(date -u +"%H:%M:%S%Z") devname=us-east-1-dc1-a-dmz-fw devid=FGT60D4614044725 logid=0100040704 type=event subtype=system level=notice vd=root logdesc=\"System performance statistics\" action=\"perf-stats\" cpu=2 mem=35 totalsession=61 disk=2 bandwidth=158/138 setuprate=2 disklograte=0 fazlograte=0 msg=\"Performance statistics: average CPU: 2, memory:  35, concurrent sessions:  61, setup-rate: 2\""; sleep 0.5; done | nc -v 127.0.0.1 514
     

     Alternatively, you can send logs in an endless loop:

     while true; do echo "<165> fortigate date=$(date -u +%Y-%m-%d) time=$(date -u +"%H:%M:%S%Z") devname=us-east-1-dc1-a-dmz-fw devid=FGT60D4614044725 logid=0100040704 type=event subtype=system level=notice vd=root logdesc=\"System performance statistics\" action=\"perf-stats\" cpu=2 mem=35 totalsession=61 disk=2 bandwidth=158/138 setuprate=2 disklograte=0 fazlograte=0 msg=\"Performance statistics: average CPU: 2, memory:  35, concurrent sessions:  61, setup-rate: 2\""; sleep 1; done | nc -v 127.0.0.1 514
     

Manage AxoRouter

This section describes how to start, stop and check the status of the AxoRouter service on Linux.

Start AxoRouter

To start AxoRouter, execute the following command. For example:

systemctl start axorouter

If the service starts successfully, no output will be displayed.

The following message indicates that AxoRouter cannot start (see Check AxoRouter status):

Job for axorouter.service failed because the control process exited with error code. See `systemctl status axorouter.service` and `journalctl -xe` for details.

Stop AxoRouter

To stop AxoRouter

1. Execute the following command.

   systemctl stop axorouter

2. Check the status of the AxoRouter service (see Check AxoRouter status).

Restart AxoRouter

To restart AxoRouter, execute the following command.

systemctl restart axorouter

Reload the configuration without restarting AxoRouter

To reload the configuration file without restarting AxoRouter, execute the following command.

systemctl reload axorouter

Check the status of AxoRouter service

To check the status of AxoRouter service

1. Execute the following command.

   systemctl --no-pager status axorouter

2. Check the Active: field, which shows the status of the AxoRouter service. The following statuses are possible:

   • active (running) - axorouter service is up and running

   • inactive (dead) - axorouter service is stopped

Upgrade AxoRouter

AxoConsole raises an alert for the host when a new AxoRouter version is available. To upgrade to the new version, re-run the one-liner installation command you used to install AxoRouter, or select Provisioning > Select type and platform to create a new one.

1.2.1 - Advanced installation options

When installing AxoRouter, you can set a number of advanced options if needed for your environment. Setting the advanced options in the AxoConsole automatically updates the one-liner command that you can copy and run.

Alternatively, before running the one-liner you can use one of the following methods:

• Set the related environment variable for the option. For example:

  export AXO_USER=syslogng
  export AXO_GROUP=syslogng
  

• Set the related URL parameter for the option. For example:

  curl -fLsH 'X-AXO-TOKEN:random-generated' 'https://<your-tenant-id>.cloud.axoflow.io/setup.sh?type=AXOROUTER&platform=LINUX&user=syslogng&group=syslogng' | sh
  

Proxy settings

Use the HTTP proxy, HTTPS proxy, No proxy parameters to configure HTTP proxy settings for the installer. To avoid using the proxy for the Axolet service, enable the Avoid proxy parameter as well. Lowercase variable names are preferred because they work universally.

Installation options

You can pass the following parameters to the installation script as environment variables, or as URL parameters.

AxoRouter capabilities

Description: Capabilities added to the AxoRouter container.

AxoRouter config mount path

Description: Mount path for custom user configuration.

AxoRouter image override

Description: Deploy the specified AxoRouter image.

Extra container arguments

Description: Additional arguments passed to the AxoRouter container.

Image repository

Description: Deploy AxoRouter from a custom image repository.

Image version

Description: Deploy the specified AxoRouter version.

Package format

Description: File format of the installer package.

Start router

Description: Start AxoRouter after installation.

Axolet parameters

API server host

Description: Override the host part of the API endpoint for the host.

Avoid proxy

Description: Do not use proxy for the Axolet process.

Axolet capabilities

Description: Capabilities added to the Axolet service.

Configuration directory

Description: The directory where the configuration files are stored.

HTTP proxy

Description: Use a proxy to access AxoConsole from the host.

HTTPS proxy

Description: Use a proxy to access AxoConsole from the host.

No proxy

Description: Comma-separated list of hosts that shouldn’t use proxy to access AxoConsole from the host.

Overwrite config

Description: Overwrite the configuration when reinstalling the service.

Service group

Description: The group running the Axolet service.

Service user

Description: The user running the Axolet service.

Start service

Description: Start the Axolet service after installation.

WEC parameters

These parameters are related to the Windows Event Collector server that can be run on AxoRouter. For details, see Windows Event Collector (WEC).

WEC Image repository

Description: Deploy the Windows Event Collector server from a custom image repository.

WEC Image version

Description: Deploy the specified Windows Event Collector server version.

1.2.2 - Run AxoRouter as non-root

To run AxoRouter as a non-root user, set the AXO_USER and AXO_GROUP environment variables to the user’s username and groupname on the host you want to deploy AxoRouter. For details, see Advanced installation options.

Operators must have access to the following commands:

• /usr/bin/systemctl * axolet.service: Controls the axolet.service systemd unit. Usually * is start, stop, restart, enable, and status. Used by the operators for troubleshooting.

• /usr/local/bin/configure-axolet: Creates initial axolet configuration and enables/starts the axolet service. Executed by the bootstrap script.

• Command to install and upgrade the axolet package. Executed by the bootstrap script if the packages aren’t already installed.

  • On RPM-based Linux distributions: /usr/bin/rpm -Uv axo*.rpm
  • On DEB-based Linux distributions: /usr/bin/dpkg -i axo*.deb

• /usr/bin/systemctl * axorouter.service: Controls the axorouter.service systemd unit. Usually * is start, stop, restart, enable, and status. Used by the operators for troubleshooting.

• /usr/local/bin/configure-axorouter: Creates the initial axorouter configuration and enables/starts the axorouter service. Executed by the bootstrap script.

• Command to install and upgrade the axorouter and the axolet package. Executed by the bootstrap script if the packages aren’t already installed.

  • On RPM-based Linux distributions: /usr/bin/rpm -Uv axo*.rpm
  • On DEB-based Linux distributions: /usr/bin/dpkg -i axo*.deb

You can permit the syslogng user to run these commands by running on of the following:

• Package:
• RPM
• DEB

sudo tee /etc/sudoers.d/configure-axoflow <<A
syslogng ALL=(ALL) NOPASSWD: /usr/local/bin/configure-axolet
syslogng ALL=(ALL) NOPASSWD: /bin/systemctl * axolet.service
# for rpm installation:
syslogng ALL=(ALL) NOPASSWD: /usr/bin/rpm -Uv axo*.rpm
A

sudo tee /etc/sudoers.d/configure-axorouter <<A
syslogng ALL=(ALL) NOPASSWD: /usr/local/bin/configure-axorouter
syslogng ALL=(ALL) NOPASSWD: /bin/systemctl * axorouter.service
# for rpm installation:
syslogng ALL=(ALL) NOPASSWD: /usr/bin/rpm -Uv axo*.rpm
A

sudo tee /etc/sudoers.d/configure-axorouter <<A
syslogng ALL=(ALL) NOPASSWD: /usr/local/bin/configure-axorouter
syslogng ALL=(ALL) NOPASSWD: /bin/systemctl * axorouter.service
# for deb installation:
syslogng ALL=(ALL) NOPASSWD: /usr/bin/dpkg -i axo*.deb
A

sudo tee /etc/sudoers.d/configure-axorouter <<A
syslogng ALL=(ALL) NOPASSWD: /usr/local/bin/configure-axorouter
syslogng ALL=(ALL) NOPASSWD: /bin/systemctl * axorouter.service
# for deb installation:
syslogng ALL=(ALL) NOPASSWD: /usr/bin/rpm -Uv axo*.deb
A

2 - AxoSyslog

Onboarding allows you to collect metrics about the host, display the host on the Topology page, and to tap into the log flow.

Onboarding requires you to modify the host and the configuration of the logging agent (AxoSyslog) running on the host.

• Level 1: Install Axolet on the host where AxoSyslog is running. Axolet collects metrics from the host and sends them to the AxoConsole, so you can check host-level metrics on the Metrics & Health page of the host, and displays the host on the Topology page.
• Level 2: Instrument the configuration of the logging agent to provide detailed metrics about the traffic flow. This allows you to display data about the host on the Analytics page.
• Level 3: Instrument the configuration of the logging agent to allow you to access the logs of the logging agent and to tap into the log flow from the AxoConsole. The exact steps for this integration depend on the configuration of your logging agent. We provide basic instrumentation instructions for getting started in this guide, but we strongly recommend to contact us so our professional services can help you with a production integration.

To onboard an existing AxoSyslog instance into Axoflow, complete the following steps.

1. Install Axolet on the host, then approve its registration on the Provisioning page of the AxoConsole.

2. The AxoSyslog host is now visible on the Topology page of the AxoConsole as a source.

3. If you've already added the AxoRouter instance or the destination where this host is sending data to the AxoConsole, add a path to connect the host to the AxoRouter or the destination.

   1. Select Topology > Create New Item > Path.

      

   2. Select your data source in the Source host field.

      

   3. Select the target router or aggregator this source is sending its data to in the Target host field, for example, axorouter.

   4. Select the Target connector. The connector determines how the destination receives the data (for example, using which protocol or port).

   5. Select Create. The new path appears on the Topology page.

      

4. Access the AxoSyslog host and edit the configuration of AxoSyslog. Set the statistics-related global options like this (if the options block already exists, add these lines to the bottom of the block):

   options {
       stats(
           level(2)
           freq(0) # Inhibit statistics output to stdout
           );
   };
   

5. (Optional) To get detailed metrics and analytics about the traffic that flows through the host, instrument your AxoSyslog configuration as follows:

   Note You can use Axolet with an un-instrumented AxoSyslog configuration file, but that limits available metrics to host statistics (for example, disk, memory, queue information). You won’t be able to access data about the actual traffic flowing through the host. To collect traffic-related metrics, instrument configuration with metrics-probe() stanzas. The example below shows how to instrument the configuration to highlight common macros such as $HOST and $PROTOCOL. If you want to customize the collected metrics or need help with the instrumentation, contact us.

   1. Download the following configuration snippet to the AxoSyslog host, for example, as /etc/syslog-ng/conf.d/axoflow-instrumentation.conf for AxoSyslog .

   2. Include it in at the top of your configuration file:

      @version: current
      @include "axoflow-instrumentation.conf"
      

   3. Edit every destination statement to include a parser { metrics-output(destination(my-destination)); }; line (making sure to include the channel construct if your destination block does not already contain it):

      destination my-destination {
          channel {
              parser { metrics-output(destination(my-destination)); };
              destination { file("/dev/null"); };
              };
          };
      

   4. Reload the configuration of AxoSyslog.

      systemctl reload syslog-ng
      

   5. To enable log tapping for the traffic that flows through the host, add the d_axotap destination in your log paths. This allows the Axolet agent to collect rate-limited log samples from that specific point in the pipeline.

      Note There are multiple ways to add tapping to your configuration, which in some cases can introduce unwanted side effects. Contact us to help you create a safe tapping configuration for your use case!

      1. Find a log path that you want to tap into and add the tap destination in a safe way, for example, by adding it in a separate inner log path:

         log {
             source(s_udp514);
             log { destination(d_udp514); };
             log { destination(d_axotap); };
         };
         

      2. Reload the configuration of AxoSyslog.

         systemctl reload syslog-ng
         

      3. Unregister the service so that auto service registration can discover the new tapping point:

         

      4. Test log tapping from the top right menu:

         

3 - Splunk Connect for Syslog (SC4S)

Onboarding allows you to collect metrics about the host, display the host on the Topology page, and to tap into the log flow.

Onboarding requires you to modify the host and the configuration of the logging agent (SC4S) running on the host.

• Level 1: Install Axolet on the host where SC4S is running. Axolet collects metrics from the host and sends them to the AxoConsole, so you can check host-level metrics on the Metrics & Health page of the host, and displays the host on the Topology page.
• Level 2: Instrument the configuration of the logging agent to provide detailed metrics about the traffic flow. This allows you to display data about the host on the Analytics page.
• Level 3: Instrument the configuration of the logging agent to allow you to access the logs of the logging agent and to tap into the log flow from the AxoConsole. The exact steps for this integration depend on the configuration of your logging agent. We provide basic instrumentation instructions for getting started in this guide, but we strongly recommend to contact us so our professional services can help you with a production integration.

To generate metrics for the Axoflow platform from an existing Splunk Connect for Syslog (SC4S) instance, you need to configure SC4S to generate these metrics. Complete the following steps.

1. If you haven’t already done so, install Axolet on the host, then approve its registration on the Provisioning page of the AxoConsole.

2. Download the following code snippet as axoflow-instrumentation.conf.

3. If you are running SC4S under podman or docker, copy the file into the /opt/sc4s/local/config/destinations directory. In other deployment methods this might be different, check the SC4S documentation for details.

4. Check if the metrics are appearing, for example, run the following command on the SC4S host:

   syslog-ng-ctl stats prometheus | grep classified
   

4 - syslog-ng

Onboarding allows you to collect metrics about the host, display the host on the Topology page, and to tap into the log flow.

Onboarding requires you to modify the host and the configuration of the logging agent (syslog-ng) running on the host.

• Level 1: Install Axolet on the host where syslog-ng is running. Axolet collects metrics from the host and sends them to the AxoConsole, so you can check host-level metrics on the Metrics & Health page of the host, and displays the host on the Topology page.
• Level 2: Instrument the configuration of the logging agent to provide detailed metrics about the traffic flow. This allows you to display data about the host on the Analytics page.
• Level 3: Instrument the configuration of the logging agent to allow you to access the logs of the logging agent and to tap into the log flow from the AxoConsole. The exact steps for this integration depend on the configuration of your logging agent. We provide basic instrumentation instructions for getting started in this guide, but we strongly recommend to contact us so our professional services can help you with a production integration.

To onboard an existing syslog-ng instance into Axoflow, complete the following steps.

1. Install Axolet on the host, then approve its registration on the Provisioning page of the AxoConsole.

2. The syslog-ng host will now be visible on the Topology page of the AxoConsole as a source.

3. If you've already added the AxoRouter instance or other destination where this newly-registered host is sending data to the AxoConsole, add a path to connect the host to the AxoRouter or the destination.

   1. Select Topology > Create New Item > Path.

      

   2. Select your data source in the Source host field.

      

   3. Select the target router or aggregator this source is sending its data to in the Target host field, for example, axorouter.

   4. Select the Target connector. The connector determines how the destination receives the data (for example, using which protocol or port).

   5. Select Create. The new path appears on the Topology page.

      

4. Access the syslog-ng host and edit the configuration of syslog-ng. Set the statistics-related global options like this (if the options block already exists, add these lines to the bottom of the block):

   options {
       stats-level(2);
       stats-freq(0); # Inhibit statistics output to stdout
   };
   

5. (Optional) To get detailed metrics and analytics about the traffic that flows through the host, instrument your syslog-ng configuration as follows:

   Note You can use Axolet with an un-instrumented syslog-ng configuration file, but that limits available metrics to host statistics (for example, disk, memory, queue information). You won’t be able to access data about the actual traffic flowing through the host. To collect traffic-related metrics, instrument configuration with metrics-probe() stanzas. The example below shows how to instrument the configuration to highlight common macros such as $HOST and $PROTOCOL. If you want to customize the collected metrics or need help with the instrumentation, contact us.

   1. Download the following configuration snippet to the syslog-ng host, for example, as /etc/syslog-ng/conf.d/axoflow-instrumentation.conf for syslog-ngor /opt/syslog-ng/etc/axoflow-instrumentation.conf for syslog-ng PE .

   2. Include it in at the top of your configuration file:

      @version: current
      @include "axoflow-instrumentation.conf"
      

   3. Edit every destination statement to include a parser { metrics-output(destination(my-destination)); }; line (making sure to include the channel construct if your destination block does not already contain it):

      destination my-destination {
          channel {
              parser { metrics-output(destination(my-destination)); };
              destination { file("/dev/null"); };
              };
          };
      

   4. Reload the configuration of syslog-ng.

      systemctl reload syslog-ng
      

   5. To enable log tapping for the traffic that flows through the host, add the d_axotap destination in your log paths. This allows the Axolet agent to collect rate-limited log samples from that specific point in the pipeline.

      Note There are multiple ways to add tapping to your configuration, which in some cases can introduce unwanted side effects. Contact us to help you create a safe tapping configuration for your use case!

      1. Find a log path that you want to tap into and add the tap destination in a safe way, for example, by adding it in a separate inner log path:

         log {
             source(s_udp514);
             log { destination(d_udp514); };
             log { destination(d_axotap); };
         };
         

      2. Reload the configuration of syslog-ng.

         systemctl reload syslog-ng
         

      3. Unregister the service so that auto service registration can discover the new tapping point:

         

      4. Test log tapping from the top right menu:

         

5 - Axolet

Axolet is the agent software for Axoflow. Its primary purpose is to discover the log collector services that are running on the host (for example, AxoSyslog or SC4S), and report their operating statistics (counters) to Axoflow.

5.1 - Install Axolet

Axolet is the agent software for Axoflow. Its primary purpose is to discover the log collector services that are running on the host (for example, AxoSyslog or SC4S), and report their operating statistics (counters) to Axoflow.

It is simple to install Axolet on individual hosts, or collectively via orchestration tools such as chef or puppet.

What the install script does

When you deploy Axolet, you run a command that installs the required software packages, configures them and sets up the connection with Axoflow.

The installer script installs the axolet packages, then executes the configure-axolet command with the right parameters. (If the packages are already installed, the installer will update them unless the none package format is selected when generating the provisioning command.)

The install script is designed to be run as root (sudo), but you can configure Axolet to run as a non-root user.

The installer script performs the following main steps:

• Executes prerequisite checks:
  • Tests the network connection with the console endpoints.
  • Checks if the operating system is supported.

• Downloads and installs the axolet RPM or DEB package.
  • The package contains the axolet and configure-axolet commands, and the axolet.service systemd unit file.
• The configure-axolet command is executed with a configuration snippet on its standard input which contains a token required for registering into the management platform. The command:

  • Writes the initial /etc/axolet/config.json configuration file.

    Note: if the file already exists it will only be overwritten if the Overwrite config option is enabled when generating the provisioning command.

  • Enables and starts the axolet service.

axolet performs the following main steps on its first execution:

• Generates and persists a unique identifier (GUID).
• Initiates a cryptographic handshake process to AxoConsole.
• AxoConsole issues a client certificate to Axolet, which will be stored in the above mentioned config.json file.
• The service waits for an approval on AxoConsole. Once you approve the host registration request, axolet starts to send telemetry data to AxoConsole. It keeps doing so as long as the agent is registered.

Prerequisites

Axolet should work on most Red Hat and Debian compatible Linux distributions. For production environments, we recommend using Red Hat Enterprise Linux 9.

Network access

The hosts must be able to access the following domains related to the AxoConsole:

• When using AxoConsole SaaS:

  • <your-tenant-id>.cloud.axoflow.io: HTTPS traffic on TCP port 443, needed to download the binaries for Axoflow software (like Axolet and AxoRouter).
  • kcp.<your-tenant-id>.cloud.axoflow.io: HTTPS (mutual TLS) traffic on TCP port 443 for management traffic.
  • telemetry.<your-tenant-id>.cloud.axoflow.io: HTTPS (mutual TLS) traffic on TCP port 443, where Axolet sends the metrics of the host.
  • us-docker.pkg.dev: HTTPS traffic on TCP port 443, for pulling container images (AxoRouter only).

• When using an on-premise AxoConsole:

  • The following domains should point to AxoConsole IP address to access Axoflow from your desktop and AxoRouter hosts:

    • your-host.your-domain: The main domain of your AxoConsole deployment.
    • authenticate.your-host.your-domain: A subdomain used for authentication.
    • idp.your-host.your-domain: A subdomain for the identity provider.

  • The AxoConsole host must have the following Open Ports:

    • Port 80 (HTTP)
    • Port 443 (HTTPS)

• When installing Axoflow agent for Windows:

  • github.com: HTTPS traffic on TCP port 443, for downloading installer packages.

Install Axolet

To install Axolet on a host and onboard it to Axoflow, complete the following steps. If you need to reinstall Axolet for some reason, see Reinstall Axolet.

1. Open the AxoConsole at https://<your-tenant-id>.cloud.axoflow.io/.

2. Select Provisioning > Select type and platform.

   

3. Select Edge > Linux.

   

   The curl command can be run manually or inserted into a template in any common software deployment package. When run, a script is downloaded that sets up the Axolet process to run automatically at boot time via systemd. For advanced installation options, see Advanced installation options.

4. Copy the deployment one-liner and run it on the host you are onboarding into Axoflow.

   Note Running the provisioning command with sudo would mask environment variables of the calling shell. Either start the whole procedure from a root shell, or let the install script call sudo when it needs to. In other words: don’t add the sudo command to the provisioning command.

   Example output:

   Do you want to install Axolet now? [Y]
   y
   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                   Dload  Upload   Total   Spent    Left  Speed
   100 31.6M  100 31.6M    0     0  2127k      0  0:00:15  0:00:15 --:--:-- 2075k
   Verifying packages...
   Preparing packages...
   axolet-0.40.0-1.aarch64
   Created symlink /etc/systemd/system/multi-user.target.wants/axolet.service → /usr/lib/systemd/system/axolet.service.
   Now continue with onboarding the host on the Axoflow web UI.
   

5. On the AxoConsole, reload the Provisioning page. A registration request for the new host should be displayed. Accept it.

6. Axolet starts sending metrics from the host. Check the Topology page to see the new host.

7. Continue to onboard the host as described for your specific log collector agent.

Manage Axolet

This section describes how to start, stop and check the status of the Axolet service on Linux.

Start Axolet

To start Axolet, execute the following command. For example:

systemctl start axolet

If the service starts successfully, no output will be displayed.

The following message indicates that Axolet cannot start (see Check Axolet status):

Job for axolet.service failed because the control process exited with error code. See `systemctl status axolet.service` and `journalctl -xe` for details.

Stop Axolet

To stop Axolet

1. Execute the following command.

   systemctl stop axolet

2. Check the status of the Axolet service (see Check Axolet status).

Restart Axolet

To restart Axolet, execute the following command.

systemctl restart axolet

Reload the configuration without restarting Axolet

To reload the configuration file without restarting Axolet, execute the following command.

systemctl reload axolet

Check the status of Axolet service

To check the status of Axolet service

1. Execute the following command.

   systemctl --no-pager status axolet

2. Check the Active: field, which shows the status of the Axolet service. The following statuses are possible:

   • active (running) - axolet service is up and running

   • inactive (dead) - axolet service is stopped

For AxoRouter hosts, you can check the Axolet logs from the AxoConsole using Log tapping for Agent logs.

Upgrade Axolet

AxoConsole raises an alert for the host when a new Axolet version is available. To upgrade to the new version, re-run the one-liner installation command you used to install Axolet, or select Provisioning > Select type and platform to create a new one.

Run axolet as non-root

You can run Axolet as non-root user, but operators must have access to the following commands:

• /usr/bin/systemctl * axolet.service: Controls the axolet.service systemd unit. Usually * is start, stop, restart, enable, and status. Used by the operators for troubleshooting.

• /usr/local/bin/configure-axolet: Creates initial axolet configuration and enables/starts the axolet service. Executed by the bootstrap script.

• Command to install and upgrade the axolet package. Executed by the bootstrap script if the packages aren’t already installed.

  • On RPM-based Linux distributions: /usr/bin/rpm -Uv axo*.rpm
  • On DEB-based Linux distributions: /usr/bin/dpkg -i axo*.deb

You can permit the syslogng user to run these commands by running on of the following:

• Package:
• RPM
• DEB

sudo tee /etc/sudoers.d/configure-axoflow <<A
syslogng ALL=(ALL) NOPASSWD: /usr/local/bin/configure-axolet
syslogng ALL=(ALL) NOPASSWD: /bin/systemctl * axolet.service
# for rpm installation:
syslogng ALL=(ALL) NOPASSWD: /usr/bin/rpm -Uv axo*.rpm
A

sudo tee /etc/sudoers.d/configure-axoflow <<A
syslogng ALL=(ALL) NOPASSWD: /usr/local/bin/configure-axolet
syslogng ALL=(ALL) NOPASSWD: /bin/systemctl * axolet.service
# for deb installation:
syslogng ALL=(ALL) NOPASSWD: /usr/bin/dpkg -i axo*.deb
A

5.2 - Advanced installation options

When installing Axolet, you can set a number of advanced options if needed for your environment. Setting the advanced options in the AxoConsole automatically updates the one-liner command that you can copy and run.

Alternatively, before running the one-liner you can use one of the following methods:

• Set the related environment variable for the option. For example:

  export AXOLET_USER=syslogng
  export AXOLET_GROUP=syslogng
  

• Set the related URL parameter for the option. For example:

  curl -fLsH 'X-AXO-TOKEN:random-generated' 'https://<your-tenant-id>.cloud.axoflow.io/setup.sh?type=AXOEDGE&platform=LINUX&user=syslogng&group=syslogng' | sh
  

Proxy settings

Use the HTTP proxy, HTTPS proxy, No proxy parameters to configure HTTP proxy settings for the installer. To avoid using the proxy for the Axolet service, enable the Avoid proxy parameter as well. Lowercase variable names are preferred because they work universally.

Installation options

You can pass the following parameters to the installation script as environment variables, or as URL parameters.

API server host

Description: Override the host part of the API endpoint for the host.

Avoid proxy

Description: If set to true, the value of the *_proxy variables will only be used for downloading the installer, but not for the axolet service itself. If set to false, the Axolet service will use the variables from the installer.

Capabilities

Description: Ambient Linux capabilities the axolet service will use.

Configuration directory

Description: The directory where the configuration files are stored.

HTTP proxy

Description: Use a proxy to access AxoConsole from the host.

HTTPS proxy

Description: Use a proxy to access AxoConsole from the host.

Initial labels

Description: Comma-separated list of key=value labels. These labels will be suggested for the host when you add the source to AxoConsole. For example, product=windows,team=windows,vendor=microsoft

No proxy

Description: Destinations that should be reached directly, without going through the proxy.

Overwrite config

Description: If set to true, the configuration process will overwrite existing configuration (/etc/axolet/config.json). This means that the agent will get a new GUID and it will require approval on the AxoConsole.

Package format

Description: File format of the installer package.

Service group

Description: Name of the group and Axolet will be running as. It should be either root or the group syslog-ng is running as.

Service user

Description: Name of the user Axolet will be running as. It should be either root or the user syslog-ng is running as. See also Run axolet as non-root.

Start service

Description: Start axolet agent at the end of installation. Use false for preparing golden images. In this case axolet will generate a new GUID on the first boot after cloning the image.

If you are preparing a host for cloning with Axolet already installed, set the following environment variable in your (root) shell session, before running the one-liner command. For example:

export START_AXOLET=false
curl ... # Run the command copied from the Provisioning page

This way Axolet will only start and initialize after the first reboot.

5.3 - Run axolet as non-root

If the log collector agent (AxoSyslog or syslog-ng) is running as a non-root user, you may want to configure the Axolet agent to run as the same user. To do that, set the AXOLET_USER and AXOLET_GROUP environment variables to the user’s username and groupname. For details, see Advanced installation options.

Operators will need to have access to the following commands:

• /usr/bin/systemctl * axolet.service: Controls the axolet.service systemd unit. Usually * is start, stop, restart, enable, and status. Used by the operators for troubleshooting.

• /usr/local/bin/configure-axolet: Creates initial axolet configuration and enables/starts the axolet service. Executed by the bootstrap script.

• Command to install and upgrade the axolet package. Executed by the bootstrap script if the packages aren’t already installed.

  • On RPM-based Linux distributions: /usr/bin/rpm -Uv axo*.rpm
  • On DEB-based Linux distributions: /usr/bin/dpkg -i axo*.deb

For example, you can permit the syslogng user to run these commands by running the following commands:

• Package:
• RPM
• DEB

sudo tee /etc/sudoers.d/configure-axoflow <<A
syslogng ALL=(ALL) NOPASSWD: /usr/local/bin/configure-axolet
syslogng ALL=(ALL) NOPASSWD: /bin/systemctl * axolet.service
# for rpm installation:
syslogng ALL=(ALL) NOPASSWD: /usr/bin/rpm -Uv axo*.rpm
A

sudo tee /etc/sudoers.d/configure-axoflow <<A
syslogng ALL=(ALL) NOPASSWD: /usr/local/bin/configure-axolet
syslogng ALL=(ALL) NOPASSWD: /bin/systemctl * axolet.service
# for deb installation:
syslogng ALL=(ALL) NOPASSWD: /usr/bin/dpkg -i axo*.deb
A

5.4 - Reinstall Axolet

Reinstall Axolet to a (cloned) machine

To re-install Axolet on a (cloned) machine that has an earlier installation running, complete the following steps.

1. Log in to the host as root and execute the following commands:

   systemctl stop axolet
   rm -r /etc/axolet/
   

2. Follow the regular installation steps described in Axolet.

Recover Axolet after the root CA certificate was rotated

1. Log in to the host as root and execute the following commands:

   export AXOLET_KEEP_GUID=y AXOLET_CONFIG_OVERWRITE=y PATH=$PATH:/usr/local/bin
   

2. Run the one-liner from the AxoConsole Provisioning page in the same shell.

3. The installation may result in an error message, but Axolet should eventually recover. You can check by running:

   journalctl -b -u axolet -n 20 -f
   

6 - Data sources

7 - Destinations

8 - Windows host - agent based solution

Axoflow provides Axoflow agent for Windows (a customized OpenTelemetry Collector distribution) to collect data from Microsoft Windows hosts.

Axoflow agent can collect data from files, Windows Event Log, and Windows Event Traces (ETW).

What the installer does

When you deploy axolet, you run a command that installs the required software packages, configures them and sets up the connection with Axoflow.

The installer script performs the following main steps:

• Executes prerequisite checks:
  • Tests the network connection with the console endpoints.
  • Checks if the operating system is supported.
• Downloads the installers (.msi) of the Axolet agent and the Axoflow agent for Windows.
• The installer script installs the packages. If the packages are already installed, the installer will update them to the latest version.

The installer installs:

• The collector agent (by default) to C:\Program Files\Axoflow\OpenTelemetry Collector\axoflow-otel-collector.exe.
• A default configuration file to C:\ProgramData\Axoflow\OpenTelemetry Collector\config.yaml.
• The axolet management agent (by default) to C:\Program Files\Axoflow\Axolet\axolet.exe.

axolet performs the following main steps on its first execution:

• Generates and persists a unique identifier (GUID).
• Initiates a cryptographic handshake process to AxoConsole.
• AxoConsole issues a client certificate to axolet, which will be stored in the above mentioned config.json file.
• The service waits for an approval on AxoConsole. Once you approve the host registration request, axolet starts to send telemetry data to AxoConsole. It keeps doing so as long as the agent is registered.

To install Axoflow agent on a Windows host, complete the following steps. For other platforms, see Provision pipeline elements.

Prerequisites

• You’ll need Administrator PowerShell access to the Windows host.

• Axoflow agent supports the following Windows versions on x86_64 architectures:

  • Windows Server 2025
  • Windows Server 2022
  • Windows Server 2019
  • Windows Server 2016
  • Windows 11
  • Windows 10

• When using Axoflow agent with an on-premises AxoConsole deployment, you must prepare the Axoflow agent host

Network access

The hosts must be able to access the following domains related to the AxoConsole:

• When using AxoConsole SaaS:

  • <your-tenant-id>.cloud.axoflow.io: HTTPS traffic on TCP port 443, needed to download the binaries for Axoflow software (like Axolet and AxoRouter).
  • kcp.<your-tenant-id>.cloud.axoflow.io: HTTPS (mutual TLS) traffic on TCP port 443 for management traffic.
  • telemetry.<your-tenant-id>.cloud.axoflow.io: HTTPS (mutual TLS) traffic on TCP port 443, where Axolet sends the metrics of the host.
  • us-docker.pkg.dev: HTTPS traffic on TCP port 443, for pulling container images (AxoRouter only).

• When using an on-premise AxoConsole:

  • The following domains should point to AxoConsole IP address to access Axoflow from your desktop and AxoRouter hosts:

    • your-host.your-domain: The main domain of your AxoConsole deployment.
    • authenticate.your-host.your-domain: A subdomain used for authentication.
    • idp.your-host.your-domain: A subdomain for the identity provider.

  • The AxoConsole host must have the following Open Ports:

    • Port 80 (HTTP)
    • Port 443 (HTTPS)

• When installing Axoflow agent for Windows:

  • github.com: HTTPS traffic on TCP port 443, for downloading installer packages.

Install Axoflow agent for Windows

1. Select Provisioning > Select type and platform.

   

2. Select the type (Edge) and platform (Windows). The one-liner installation command is displayed.

   If needed, set the Advanced options (for example, proxy settings) to modify the installation parameters. Usually, you don’t have to use advanced options unless the Axoflow support team instructs you to do so.

3. Only on Windows Server 2016: Complete these steps to install curl when installing Axoflow agent on Windows Server 2016. Other versions have curl installed by default.

   1. Download the latest curl package from the curl download page.

   2. Extract the package into a folder (for example, C:\curl)

   3. Add the curl binary folder (for example, C:\curl\bin) to the system PATH environment variable.

      1. Open the Control Panel, select System > Advanced System Settings.
      2. Select Advanced > Environment Variables.
      3. Select Path from System variables.
      4. Select Edit > New, then enter the curl binary folder path.
      5. Save your settings.

4. Open a PowerShell terminal as Administrator on the host where you want to install Axoflow agent.

5. Run the one-liner, then follow the on-screen instructions.

   Example output:

   curl.exe -fLsH 'X-AXO-TOKEN:xxx' 'https://axoflow.console/setup.sh?type=AXOEDGE&platform=WINDOWS' -o $env:TEMP\axolet-installer.ps1; powershell.exe -File $env:TEMP\axolet-installer.ps1
   Do you want to install Axolet now? [Y]
   
   Installing Axoflow agent...
   
   Axolet service is running.
   Now continue with onboarding the host on the Axoflow web UI.
   

6. Verify that the axolet and axoflow-otel-collector services are running.

   

Metadata fields

The AxoRouter connector that receives data from Axoflow agent adds the following fields to the meta variable:

8.1 - Manage the Windows agent

This section describes how to start, stop and check the status of the axolet and axoflow-otel-collector services on Windows. axolet logs are available under C:\Windows\Temp\axolet.log, while Axoflow agent logs are available in the event log under Windows Logs / Application.

Start the service

To start the axolet or axoflow-otel-collector service, execute the following commands:

• sc.exe start axolet
• sc.exe start axoflow-otel-collector

Alternatively, you can restart the service from AxoConsole:

1. Find the host on the Topology or the Sources page.
2. Select the name of the host.
3. Select Services > Restart.

Stop the service

To stop the axolet or axoflow-otel-collector service, execute the following commands:

• sc.exe stop axolet
• sc.exe stop axoflow-otel-collector

Check the status of the service

To check the status of the axolet or axoflow-otel-collector service, execute the following commands:

• sc.exe query axolet
• sc.exe query axoflow-otel-collector

Upgrade Axoflow agent

AxoConsole raises an alert for the host when a new Axoflow agent version is available. To upgrade to the new version, re-run the one-liner installation command you used to install Axoflow agent, or select Provisioning > Select type and platform to create a new one.

8.2 - Advanced installation options

When installing Axoflow agent on Windows, you can set a number of advanced options if needed for your environment. Setting the advanced options in the AxoConsole automatically updates the one-liner command that you can copy and run.

Alternatively, before running the one-liner you can use one of the following methods:

• Set the related environment variable for the option. For example:

  $Env:AXOLET_INITIAL_LABELS = 'product=windows,team=windows,vendor=microsoft'
  

• Set the related URL parameter for the option. For example:

  curl.exe -fLsH 'X-AXO-TOKEN:random-generated' 'https://<your-tenant-id>.cloud.axoflow.io/setup.sh?type=AXOEDGE&platform=WINDOWS&initial_labels=product%3Dwindows%2Cvendor%3Dmicrosoft%2Cteam%3Dwindows' -o $env:TEMP\axolet-installer.ps1; powershell.exe -File $env:TEMP\axolet-installer.ps1
  

Proxy settings

Use the HTTP proxy, HTTPS proxy, No proxy parameters to configure HTTP proxy settings for the installer. To avoid using the proxy for the Axolet service, enable the Avoid proxy parameter as well. Lowercase variable names are preferred because they work universally.

Installation options

You can pass the following parameters to the installation script as environment variables, or as URL parameters.

API server host

Description: Override the host part of the API endpoint for the host.

Avoid proxy

Description: If set to true, the value of the *_proxy variables will only be used for downloading the installer, but not for the axolet service itself. If set to false, the Axolet service will use the variables from the installer.

Collector agent URL

Description: Deploy the specified agent binary.

Configuration directory

Description: The directory where the configuration files are stored.

HTTP proxy

Description: Use a proxy to access AxoConsole from the host.

HTTPS proxy

Description: Use a proxy to access AxoConsole from the host.

Initial labels

Description: Comma-separated list of key=value labels. These labels will be suggested for the host when you add the source to AxoConsole. For example, product=windows,team=windows,vendor=microsoft

Install collector agent

Description: Deploy the Axoflow agent. If set to false, only the Axolet agent will be installed.

Non-interactive installation

Description: Don’t ask for user confirmation during the installation.

No proxy

Description: Destinations that should be reached directly, without going through the proxy.

Overwrite config

Description: If set to true, the configuration process will overwrite existing configuration (/etc/axolet/config.json). This means that the agent will get a new GUID and it will require approval on the AxoConsole.

Start service

Description: Start axolet agent at the end of installation. Use false for preparing golden images. In this case axolet will generate a new GUID on the first boot after cloning the image.

If you are preparing a host for cloning with Axolet already installed, set the following environment variable in your (root) shell session, before running the one-liner command. For example:

$Env:START_AXOLET = false
curl.exe ... # Run the command copied from the Provisioning page

This way Axolet will only start and initialize after the first reboot.

8.3 - Configure data collection

To configure the agent to collect data from the edge host and send it to an AxoRouter instance, you must have:

• a Collection rule with an Edge Selector that matches this host, and
• a Data forwarding rule with an Edge Selector that matches this host.

The edge selectors of these rules are high-level policies that use dynamic host labels to determine which edge hosts match the rule.

To configure data collection on the edge host, complete the following steps.

1. Create a new Collection rule (select Sources > Collection Rules > Create New Rule), or add the host to an existing rule.
2. Create a new Data Forwarding rule (select Sources > Forwarding Rules > Create New Rule), or add the host to an existing rule.