Migrating from
syslog-ng Store Box to Axoflow Locker
A planning and execution guide for organizations replacing syslog-ng Store Box (SSB) with Axoflow Locker. Note that upgrading syslog-ng Premium Edition (PE) deployments is covered in separate guides for migrating to AxoSyslog or to the Axoflow Platform.
Why this is a low-risk migration
The original creator and maintainers of syslog-ng built Axoflow Locker on top of AxoSyslog, an actively developed syslog-ng fork. Axoflow Locker is a software-only log management appliance for environments that can't or don't want to rely on SaaS solutions (like Axoflow Platform) for log management.
Built on modern technologies, Axoflow Locker can be deployed on-premises and in air-gapped environments, and offers secure and tamperproof data storage, access control, search, and analytics for your log data.
Axoflow Locker can receive data using the same protocols that SSB supports, so you don't need to change your clients when you replace SSB with Axoflow Locker.
Data already on SSB is not affected by the migration — you can keep accessing it using the usual methods, or even remotely from the Axoflow Locker search interface. If needed, we can help you transform your data from the proprietary format used by SSB to plain-text or encrypted, open-format Apache Parquet files.
A high-level overview of the migration process
At a high level, the migration process involves the following steps.
- Review your SSB configuration
- Deploy Axoflow Locker
- Configure Axoflow Locker to replicate your SSB configuration
- Test that Axoflow Locker works as expected and routes incoming data properly
- Direct traffic from SSB to Axoflow Locker
- Verify that everything is working properly
- (Optional) Decommission SSB
Concept mapping
SSB and Axoflow follow different mental models and have different concepts. Here's a quick mapping of the most important ones. You can use the table below as a reference throughout the migration.
| syslog-ng Store Box (SSB) concept | Axoflow equivalent |
|---|---|
| source (network listener) | Connector Rule |
| destination (network destination) | Destination |
| Log path | Flow |
| filter | Select Messages processing step using a label- or content-based Axoflow Query Language (AQL) filters in the Flow |
| parser(), rewrite(), db-parser | Automatic classification (preferred); FilterX processing step as fallback |
| Logstores and logspaces | Stores |
| Patterndb rules | Automatic classification and parsing, out-of-the-box, for hundreds of COTS products. Contact us if you have custom patterns or custom applications that need to be classified. |
| Search interface | Axoflow search uses the label- or content-based Axoflow Query Language (AQL) |
The largest conceptual shift is how data processing works:
In SSB and syslog-ng PE you authored regex filters, parsers, and rewrite rules. In Axoflow Locker automatic classification handles standard vendor formats out of the box, and usually you select messages by label, not by pattern-matching the message text.
Logpaths in SSB and syslog-ng PE are processed sequentially, and their order is important. Flows in Axoflow get every incoming message, but have a powerful filtering mechanism to select only specific messages, for example, messages from a specific product.
Review your SSB configuration
To be able to properly configure Axoflow Locker, you need to know the details of your SSB configuration and collect the credentials and other information. In particular, collect:
- User roles and groups: who needs to access what.
- SSB sources that receive data: collect the ports, protocols, and protocol-specific parameters for each source. For TLS-encrypted protocols, collect the certificates and private keys.
- Logspaces: collect a list of logspace names, encryption parameters (certificates and decryption keys), and retention details.
- External destinations: destination URLs/addresses, tokens and other credentials for the external destinations SSB is forwarding data to (for example, Splunk or Elasticsearch).
- Logpaths: sources, destinations, and message-processing performed in each logpath.
Deploy Axoflow Locker
You can deploy Axoflow Locker in a VM or on any enterprise-grade server hardware running Ubuntu (24.04 or later) or Red Hat (9 or later) distributions. For production environments, we recommend at least 16 vCPUs (x86_64) and 16 GB RAM. Contact us for hardware sizing recommendations based on your exact use case.
- 16 vCPU / 16 GB — recommended minimum for production (x86_64)
- Ubuntu 24.04+ / RHEL 9+ — supported host distributions, VM or bare metal
Axoflow Locker can run on-premises and in air-gapped environments, and supports high-availability mode. You'll receive the installer and the license key from Axoflow. Follow the on-premises or air-gapped deployment guide to deploy Axoflow Locker.
Configure user access
- Configure authentication and authorization (for example, to your LDAP server or OIDC provider).
- Map your SSB usergroups to the roles available in Axoflow Locker. If you need other roles, contact the Axoflow support team. Composing other roles is possible as part of a custom integration. Note that SSB splits access per UI menu (Basic Settings, AAA, Search, Reports, Policies, Log), while Axoflow splits access per domain. You can set access permissions on the Settings > Roles page.
Recommended user role mapping
| SSB usergroup | Axoflow role | Notes |
|---|---|---|
| basic-view | infrastructure-viewer | Since Axoflow Locker is not a hardware appliance, most of the related information and configuration is available in the hypervisor or external OS. |
| basic-write | infrastructure-manager | Since Axoflow Locker is not a hardware appliance, most of the related information and configuration is available in the hypervisor or external OS. |
| auth-view | admin | admin has read-only access to Roles. |
| auth-write | IAM-admin | The only role that can modify Settings > Roles and reach the Identity Provider Admin Panel. |
| search | content-viewer | |
| policies-view | infrastructure-viewer | |
| policies-write | infrastructure-manager | |
| log-view | content-viewer | |
| log-write | content-manager or infrastructure-manager | Use infrastructure-manager if the user needs to manage Sources and Hosts in Axoflow, content-manager if managing Flows (logpaths) is enough. |
| changelog | infrastructure-viewer | Has read access to the Activity Logs page. |
Receiving data
Create Connector Rules to receive data
By default, Axoflow Locker can receive data on:
- port 4317 — OpenTelemetry (gRPC)
- ports 514 and 601 — syslog UDP/TCP
Check the sources in your SSB, particularly the ports and transport options configured, and the keys/certificates used for TLS-encrypted connections.
- Create Connector Rules or modify the existing ones to receive data on the ports your clients are sending.
- To receive data via TLS or ALTP TLS, you'll need the appropriate certificates and private keys.
- To match the default TLS (syslog TLS) source of SSB, create a syslog connector rule on port 6514 and provide the certificate and private key used in SSB.
- If you've created connectors on new ports, make sure to check your firewall rules (on the Axoflow Locker host) and open the new ports.
Configure storage
- Create AxoStores. Functionally these are identical to SSB logspaces: they can be encrypted, have access rules, and so on.
- Create stores that match your logspaces. (By default, SSB has two logspaces: local for storing SSB's own logs, and central, the default logspace for all data received from external hosts.)
- Data cleanup for the stores is regulated by the Retention time option.
- For filtered logspaces, create a simple store — filtering can be configured later in the Flow (logpath).
- Remote and multiple logspaces allow you to search data on other SSBs. Axoflow Locker can search SSB data remotely, but that's not related to logspaces.
- Based on your SSB logpaths that send data to local logstores, create Flows (logpaths) that route the incoming data to the appropriate store.
- Set Processing steps to filter and parse the messages. For details, see the Axoflow documentation and the Mapping SSB logpath filters to Axoflow queries section below.
- Set the appropriate store as the Destination of the flow.
Destinations and host setup
Configure external destinations
If you forward data from your SSB to other destinations (like syslog, Splunk, Google Pub/Sub, Microsoft Sentinel, Elasticsearch, or other):
- Create each destination in Axoflow. You'll need credentials (like an authorization token) and the address (for example, the URL of the ingestion endpoint) for each destination.
- Based on your SSB logpaths that forward data to external destinations, create Flows that route the messages you want to forward to the destination.
- Set Processing steps to filter and parse the messages. For details, see the Axoflow documentation.
- Set the appropriate Destination of the flow.
Configure the external host
Configure the host or VM Axoflow Locker will be running on. Make sure to create:
- The network interfaces needed for your environment
- NTP synchronization
- Monitoring and backups
Cutover
Send test data or light traffic to Axoflow
Test that Axoflow Locker works as expected and routes incoming data properly. In particular, check that:
- Data that should be stored locally arrives in the appropriate store. Use the Search Logs page and the Store filter to check that, or Log Tapping and Flow Tapping to track down any issues.
- External destinations receive the data as expected.
- Other users can log in and have the appropriate privileges.
Setup remote SSB search on Axoflow Locker
If you want to use Axoflow Locker's search interface to access data on SSB:
- Make sure that the RPC API is enabled and configured on SSB.
- Configure Axoflow Locker to access your SSB via the RPC API.
Redirect traffic to Axoflow
If everything is working normally with the test data, redirect the traffic from SSB to Axoflow.
Mapping SSB logpath filters to Axoflow queries
SSB offers a number of syslog-specific filters. The following list maps these filters to Axoflow Select messages or other processing steps.
| SSB filter | Axoflow AQL query | Notes |
|---|---|---|
| facility | log.attributes.priority == <facility> | Selects messages sent by a specific facility (for example, kernel) |
| host | meta.host.name == <hostname> | Selects messages sent by a specific host, based on hostname or IP address. |
| message | log.body =* <keyword> | Selects messages containing a specific keyword (=*) or POSIX (extended) regular expression (=~) in the text of the log message (excluding the headers). |
| priority | log.attributes.priority == <priority> | Selects messages of a specific priority. |
| program | meta.service.name == <programname> | Selects messages sent by a specific application. |
| sender | meta.connection.src_ip == <ipaddress> | Filters on the address of the host that sent the message to syslog-ng Store Box (SSB) |
Migrate with confidence
Talk to us about your SSB migration
Axoflow classifies, normalizes, reduces, and manages security data automatically — so your team is freed from regex and parser maintenance.