Glossary
No tags are selected, so no terms are shown. Pick a tag above, or select all of them.
-
AxoConsole
#Also known as: Axoflow ConsoleThe management and data visualization UI of Axoflow, available as SaaS and as an on-premises deployment.
More about AxoConsoleRead more
AxoConsole collects the metrics its pipeline components report and draws them as a live topology of your security data. From it you can deploy managed components such as AxoRouter and Axoflow agent. You can also configure the flows that route and process your data, and tap into a running data flow to troubleshoot it.
AxoConsole translates the routing and processing you configure into component-level configuration, then deploys it. You don’t edit agent configuration files by hand.
-
Axoflow agent
#Also known as: AxoEdgeThe managed collector agents that run on a host and send its local data to an AxoRouter instance.
More about Axoflow agentRead more
Axoflow agent covers Linux, Kubernetes, and Microsoft Windows. It provides file and journald collectors on Linux, and Event log and Event trace collectors on Windows. Besides the data itself, it reports the metadata that AxoConsole needs to place the host on your pipeline topology.
A host that runs Axoflow agent is an edge host, and a collection rule sets what it collects.
-
Axoflow Platform
#Also known as: AxoflowAxoflow is an end-to-end pipeline for security data. It collects telemetry from your sources and hands it to your SIEM or storage in the shape that destination expects.
More about Axoflow PlatformRead more
The platform has two halves. AxoConsole is the management and visualization side. You configure routing and processing there, and AxoConsole deploys the result to the components that do the work. The Data Plane is the components themselves.
A plain log forwarder moves bytes. Axoflow works on the data in transit:
- it classifies each message by verifying its content,
- it repairs common errors, such as missing hostnames and invalid timestamps,
- it normalizes the data to the schema your destination expects,
- it reduces volume by dropping noise, and
- it routes by what the source is rather than by IP address.
You can also keep data inside the platform. AxoStore holds it locally on the AxoRouter host, and AxoLake holds it long term.
-
AxoLake
#A tiered SaaS security lake: a scalable hot tier for fast queries over a cost-efficient, S3-compatible cold tier.
More about AxoLakeRead more
AxoLake handles long-term retention with open access, and integrates with SIEMs and security analytics tools. Policy-based routing decides which data goes to cold storage, to hot storage, or straight to your SIEM.
When you need cold data back, rehydrate it into the hot tier, or replay it into your SIEM.
-
Axolet
#The monitoring and management agent that integrates with a local log collector and reports host and traffic metrics to AxoConsole.
More about AxoletRead more
Axolet runs on the data source alongside the collector that’s already there, whether that’s AxoSyslog, Splunk Connect for Syslog (SC4S), or syslog-ng. It reports detailed metrics about the host and its data traffic. That’s how AxoConsole can show a host you haven’t migrated yet, on the same topology as your managed components.
Every AxoRouter and Axoflow agent deployment includes Axolet.
-
AxoRouter
#The router and data curation engine of Axoflow: it collects security data from your sources, curates it, and delivers it to your destinations.
More about AxoRouterRead more
AxoRouter has every low-level function you expect of a log-forwarding agent or relay, and adds the curation work that usually falls to you:
- it identifies the product that sent each message, rather than trusting the port it arrived on,
- it corrects common errors in the incoming data, such as missing hostnames and invalid timestamps,
- it parses the logs of hundreds of COTS devices, and
- it performs data reduction and normalization.
Before sending data on, AxoRouter converts it into the format that suits the destination best. On Splunk that means setting the right
sourcetypeandindex, which improves both ingestion speed and data quality.Optionally, you can store data locally on the AxoRouter host in a Store.
-
AxoStore
#Lightweight, queryable, temporary storage that keeps data locally on the AxoRouter host.
More about AxoStoreRead more
AxoConsole provides federated search across every AxoRouter that has AxoStore deployed, so one query runs against all of them at once. It’s available to all Axoflow customers on every AxoRouter node, with 7 days of retention and up to 1 TB of storage. Longer retention or more space needs an extended subscription.
It suits the cases where a SIEM is the wrong instrument. Keep debug-level logs for a day in case something happens, search ad hoc during maintenance, or hold a lightweight local backup. You can rehydrate anything in it to another destination later.
-
AxoSyslog
#The cloud-native syslog-ng fork Axoflow develops and maintains, and the log processing engine inside AxoRouter.
More about AxoSyslogRead more
AxoSyslog is a scalable, drop-in replacement for syslog-ng with container and Kubernetes support. It’s open source, and you can run it on its own. Axoflow also uses it as the processing engine inside AxoRouter, where it does the parsing, filtering, and rewriting work.
If you already run AxoSyslog, syslog-ng, or SC4S, you can bring those hosts into AxoConsole with Axolet instead of replacing them.
-
Classification
#Identifying which device or service each message came from by verifying its content, rather than trusting the port it arrived on.
More about ClassificationRead more
Dedicating a port per device type is the usual approach, and it’s only as good as the discipline around it. Axoflow verifies the data instead: a single appliance emits several kinds of message, and you have to recognize each one uniquely.
Doing that well needs vendor-specific understanding of the data and of the syslog formats. Sources frequently send invalid messages, and you have to recognize and repair them as part of the same step. Axoflow ships classification as a core function covering over hundreds of data sources, so you never write another parsing regular expression. A regexp is what sits at the core of most ingestion pipelines today, and it’s neither reliable nor fast.
Classification is what produces the labels that policy-based routing, analytics, and search can act on.
-
Cloud connector
#A pull-based collector, built on OpenTelemetry, that fetches data from a cloud service, an API, or a streaming source.
More about Cloud connectorRead more
Where AxoRouter waits for a source to push data to it, a Axoflow Cloud Connector goes and gets it. It covers:
- modern cloud services, such as AWS CloudWatch, Amazon S3, GCP Pub/Sub, and Azure Event Hub, and
- API and streaming sources, such as CrowdStrike and Kafka.
Because they’re OpenTelemetry receivers, the set is extensible: the Axoflow team can add support for a custom HTTP or streaming API source.
-
Collection rule
#A rule that defines how edge hosts collect their local data.
More about Collection ruleRead more
Collection rules configure the Axoflow agent agent on the host. A rule sets which files to read, which journald units or Windows Event channels to follow, and what labels to attach.
AxoConsole deploys the rule to every host that the rule’s selector matches. To add a host, you give it the label the selector looks for, rather than edit a configuration file.
Collection rules cover hosts that run an agent. Connector rules defines the methods and entry points where AxoRouter receives data from the sources.
-
Connector rule
#Also known as: ConnectorA policy that determines which listeners a set of AxoRouter instances offers, based on dynamic host labels.
More about Connector ruleRead more
A connector is the entry point where AxoRouter receives data from a source, for example:
- a syslog listener,
- an OTLP endpoint,
- a webhook, or
- a Windows Event Collector subscription.
It’s more than a port, because connectors also run the processing steps that matter at the ingestion point. Classification and parsing are among them, so the connector enriches the data before a flow sees it.
Connector rules define which connectors should exist on which routers, so you describe intent rather than maintain each instance by hand.
Collection rules define how edge hosts collect their local data.
-
Control plane
#Also known as: Axoflow control planeThe management half of Axoflow: it configures the pipeline and describes what flows through it, but never carries your data.
More about Control planeRead more
In practice the control plane is AxoConsole. It collects the metrics that the pipeline components report and draws them as a live topology, so what it holds is the metadata of each event: the source it came from, its size in bytes, the event count over time, the destination it went to, and anything else that describes the data.
You also manage the pipeline from here, which is the data plane. AxoConsole deploys managed components such as AxoRouter and Axoflow agent, and it translates each flow you configure into component-level configuration that it deploys to the managed data plane components. You don’t edit agent configuration files by hand.
Your security data is never stored on the control plane. It stays in your self-managed cloud or in your on-premises instance, where your sources, destinations, Axoflow agents, and AxoRouters run. Only metrics travel up to AxoConsole, which is what makes the SaaS deployment viable for security data you can’t move.
-
COTS
#Also known as: Commercial off-the-shelfCommercial off-the-shelf. Hardware or software that ships ready to deploy, rather than something you build or customize.
Read more
Most of the hardware in an enterprise network is COTS: firewalls, switches, and web gateways.
Each vendor logs in its own format, and a single device emits several kinds of message. AxoRouter parses the logs of hundreds of COTS devices, so you don’t have to.
-
Data plane
#Also known as: Axoflow data planeThe collector agents, processing engines, and storage that carry and process your telemetry data, as opposed to the control plane that manages them.
More about Data planeRead more
The data plane covers AxoRouters, the Axoflow agents, and the cloud connectors. These components collect your data, classify it, filter it, transform it, and deliver it to your destinations, and they report metrics upward as they go. The storage the data lands in belongs on this side of the line too: AxoStore keeps it on the AxoRouter host, and AxoLake keeps it long term.
The split is between the data and the description of it. The data plane handles the events themselves, while AxoConsole handles only the metadata: where an event came from, how large it was, and where it went. Your security data stays in your self-managed cloud or in your on-premises instance, where your sources, destinations, Axoflow agents, and AxoRouters run.
You can manage data plane components from AxoConsole, or run them independently of it. A managed component gets its configuration from the control plane, compiled from the flows you configure. Every AxoRouter and Axoflow agent deployment also includes Axolet, which reports the host’s metrics to AxoConsole.
-
Data reduction
#Also known as: ReductionCutting the volume of your security data by removing noise and redundant content before it reaches the destination.
More about Data reductionRead more
Reduction follows from classification. Once the pipeline knows exactly what a message is, it also knows which parts of it carry no information. It knows which messages you don’t need to keep at full fidelity. Volume drops without coding, and without you deciding message type by message type what’s safe to discard.
Less volume reaching a SIEM means lower ingestion cost, and it’s the reason classification is worth doing before routing rather than after.
-
Destination
#The SIEM, storage, or analytics system that the pipeline delivers your security data to.
More about DestinationRead more
Axoflow doesn’t simply forward bytes to a destination. It converts the data into the shape that destination ingests best: the right schema, the right field names, the right index or stream. That’s what normalization does, and it’s what keeps ingestion fast and the stored data queryable.
A single axorouter can send the same data to several destinations, each in the format that destination supports.
-
Edge host
#Also known as: EdgeA source host that runs a collector agent managed by AxoConsole, or has Axolet reporting metrics from it.
More about Edge hostRead more
The distinction matters because it decides how you configure collection. A collection rule governs what an edge host collects, and AxoConsole deploys that rule to the agent. Data from a source without an agent arrives at a connector on AxoRouter instead.
-
Flow
#The configuration object that describes how the pipeline routes and processes a set of data on its way from sources to destinations.
More about FlowRead more
A flow applies to one or more AxoRouter instances. You build it in AxoConsole: which data to select, what to do to it, where to send it. AxoConsole then translates the flow into the configuration each component needs, and deploys it.
Selection is by label rather than by port or IP, which is what policy-based routing means in practice. The Flows page lists every configured flow and shows which ones have alerts on them.
-
Host attribution
#Also known as: InventoryEnriching your data with metadata about the host that produced it, so you can pinpoint the origin of every entry.
More about Host attributionRead more
Looking at one log entry during an incident, it’s rarely obvious what generated it. An appliance or an application? Which team owns it? If it was one of the dozens of switches and access points an organization of any size runs, which one, and where is it?
Cloud-native environments solved this with resource metadata: labels on containers, pods, and nodes that the collector attaches to the data. Axoflow’s inventory brings the same idea to sources by adding labels: vendor and product, physical location, owning team. That metadata is what makes policy-based routing possible.
-
Log tapping
#Sampling the live data flow of an AxoRouter to see what the pipeline receives and what it sends on.
More about Log tappingRead more
You filter by label, for example on messages with parse errors, and Axoflow shows you matching messages as they pass. Axoflow samples the output automatically, to roughly one message per second, so a busy flow doesn’t overwhelm the view.
Tapping answers two questions. What was in the original message, and what does the pipeline send in the final payload to the destination? It catches both curation and parsing errors and destination ingest errors, without adding a debug destination or restarting anything.
You can also tap into the data processed in a flow.
-
Normalization
#Delivering data in the schema, field names, and data types the destination expects, instead of ingesting raw blobs.
More about NormalizationRead more
The same event, described by two vendors, arrives under two different field names. Your detection engineers shouldn’t have to know which of your firewalls calls the client address what. Detection rules ought to be agnostic to how the pipeline collected the data and where it came from.
Axoflow normalizes in real time inside the pipeline and supports several frameworks, including Elastic Common Schema (ECS) and Open Cybersecurity Schema Framework (OCSF). Where a destination has a schema of its own, Axoflow applies it by default. You can send the same data to several destinations, each normalized to the form that destination supports.
-
OTLP
#Also known as: OpenTelemetry protocolThe OpenTelemetry protocol, which Axoflow components use to transport data between themselves.
More about OTLPRead more
OTLP runs over gRPC. It encodes data as protocol buffers, so it’s faster than the traditional log transport protocols and uses less bandwidth.
It also provides:
- on-the-wire compression,
- authentication,
- application-layer acknowledgment,
- batched sending, and
- multi-worker scalability on the client and the server.
Acknowledgment is the part that matters for a security pipeline: it’s what lets a sender know its data arrived.
Components also use disk buffers. If a destination or the network to it becomes unavailable, the buffer holds the data. When the connection returns, the component sends the data on in the order it received it.
-
Policy-based routing
#Deciding where data goes from what the source actually is: its vendor, role, location, and owner, rather than its IP address or application name.
More about Policy-based routingRead more
Technical parameters make coarse routing rules. Host attribution gives you a finer vocabulary to write them in:
- the vendor and product, for example a SonicWall firewall,
- the physical location, down to a rack number,
- the owning organization, department, or team.
You then say what kind of data should go where in those terms, in a flow. The policy keeps holding as you add and replace hosts.
-
Rehydration
#Selecting a set of stored data and sending it on to another destination.
More about RehydrationRead more
Rehydration is what makes cheap storage usable during an investigation. You route data to AxoStore or to AxoLake’s cold tier because it isn’t worth SIEM ingestion cost at the time. When an incident makes it relevant, you select it and replay it into a SIEM for analysis.
It’s also why retention policy and detection policy needn’t be the same decision.
-
SIEM
#Also known as: Security Information and Event ManagementSecurity Information and Event Management. The platform where your security team searches and correlates security data, and raises alerts on it.
More about SIEMRead more
A SIEM is the most common destination in a security pipeline. It’s usually the most expensive one, because vendors price it by ingested volume.
That price is why data reduction and policy-based routing matter. You send the SIEM the data your team needs for detection, and route the rest to AxoStore or AxoLake.
-
Source
#A host or service that sends data into the pipeline.
More about SourceRead more
Sources are the endpoints where your security data originates. Common ones are:
- a firewall,
- another kind of appliance,
- a Kubernetes cluster, or
- an application server.
A source sends its data either straight to a destination, or, more usually, to an AxoRouter that collects from a whole set of them.
A source that runs a collector agent managed by AxoConsole, or reports metrics through Axolet, is an edge host. One that simply sends syslog at a listener isn’t.