# Glossary A standardized list of Axoflow terminology. Filter the terms by tag Architecture Data flow Fundamental Operation Processing Storage No tags are selected, so no terms are shown. Pick a tag above, or select all of them. * ## AxoConsole # Also known as: _Axoflow Console_ The management and data visualization UI of Axoflow, available as SaaS and as an on-premises deployment. Read 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]( "The configuration object that describes how the pipeline routes and processes a set of data between sources and destinations.") that route and process your data, and [tap into a running data flow]( "Sampling the live data flow of an AxoRouter to see what the pipeline is receiving and what it sends on.") 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. [More about AxoConsole](../../architecture/index.md#console) * ## Axoflow agent # Also known as: _AxoEdge_ The managed collector agents that run on a host and send its local data to an AxoRouter instance. Read 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]( "A source host that runs a managed collector agent, or reports metrics through Axolet."), and a [collection rule]( "A rule that defines how edge hosts collect their local data.") sets what it collects. [More about Axoflow agent](../../architecture/index.md#axoedge) * ## Axoflow Platform # Also known as: _Axoflow_ Axoflow is an end-to-end pipeline for security data. It collects telemetry from your [sources]( "A host or service that sends data into the pipeline.") and hands it to your [SIEM]( "Security Information and Event Management: the platform where a security team searches and correlates security data, and raises alerts on it.") or storage in the shape that destination expects. Read 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]( "The half of the Axoflow Platform that carries your telemetry: the agents, routers, and storage that handle the data itself.") is the components themselves. A plain log forwarder moves bytes. Axoflow works on the data in transit: * it [classifies]( "Identifying which device or service a message came from by verifying its content, not the port it arrived on.") each message by verifying its content, * it repairs common errors, such as missing hostnames and invalid timestamps, * it [normalizes]( "Delivering data in the schema and field names the destination expects, instead of raw blobs.") the data to the schema your destination expects, * it [reduces volume]( "Cutting the volume of security data by dropping noise and redundant content before it reaches the destination.") by dropping noise, and * it routes by [what the source is]( "Routing data by what the source is, rather than by sender IP or application name.") 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. [More about Axoflow Platform](../../architecture/index.md) * ## AxoLake # A tiered SaaS security lake: a scalable hot tier for fast queries over a cost-efficient, S3-compatible cold tier. Read more AxoLake handles long-term retention with open access, and integrates with [SIEMs]( "Security Information and Event Management: the platform where a security team searches and correlates security data, and raises alerts on it.") and security analytics tools. [Policy-based routing]( "Routing data by what the source is, rather than by sender IP or application name.") decides which data goes to cold storage, to hot storage, or straight to your SIEM. When you need cold data back, [rehydrate]( "Selecting stored data and sending it to another destination.") it into the hot tier, or replay it into your SIEM. [More about AxoLake](../../architecture/index.md#axolake) * ## Axolet # The monitoring and management agent that integrates with a local log collector and reports host and traffic metrics to AxoConsole. Read 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. [More about Axolet](../../architecture/index.md#axolet) * ## AxoRouter # The router and data curation engine of Axoflow: it collects security data from your [sources]( "A host or service that sends data into the pipeline."), curates it, and delivers it to your [destinations]( "A SIEM, storage, or analytics system that the pipeline delivers security data to."). Read 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]( "Identifying which device or service a message came from by verifying its content, not the port it arrived on."), 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]( "Commercial off-the-shelf: hardware or software that ships ready to deploy, such as a firewall or a web gateway.") devices, and * it performs [data reduction]( "Cutting the volume of security data by dropping noise and redundant content before it reaches the destination.") and [normalization]( "Delivering data in the schema and field names the destination expects, instead of raw blobs."). Before sending data on, AxoRouter converts it into the format that suits the destination best. On Splunk that means setting the right `sourcetype` and `index`, which improves both ingestion speed and data quality. Optionally, you can store data locally on the AxoRouter host in a [Store]( "Lightweight, queryable, temporary storage that keeps data locally on the AxoRouter host."). [More about AxoRouter](../../architecture/index.md#router) * ## AxoStore # Lightweight, queryable, temporary storage that keeps data locally on the AxoRouter host. Read 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]( "Security Information and Event Management: the platform where a security team searches and correlates security data, and raises alerts on it.") 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]( "Selecting stored data and sending it to another destination.") anything in it to another destination later. [More about AxoStore](../../storage/index.md) * ## AxoSyslog # The cloud-native syslog-ng fork Axoflow develops and maintains, and the log processing engine inside AxoRouter. Read 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]( "The monitoring and management agent that reports host and traffic metrics to AxoConsole.") instead of replacing them. [More about AxoSyslog](../../data-sources/connector-rules/index.md) * ## Classification # Identifying which device or service each message came from by verifying its content, rather than trusting the port it arrived on. Read 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]( "Routing data by what the source is, rather than by sender IP or application name."), analytics, and search can act on. [More about Classification](../../concepts/classify-reduce-security-data/index.md) * ## Cloud connector # A pull-based collector, built on OpenTelemetry, that fetches data from a cloud service, an API, or a streaming source. Read 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. [More about Cloud connector](../../architecture/index.md#axoedge) * ## Collection rule # A rule that defines how [edge hosts]( "A source host that runs a managed collector agent, or reports metrics through Axolet.") collect their local data. Read 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]( "A policy that determines which listeners AxoRouter instances offer, based on host labels.") defines the methods and entry points where AxoRouter receives data from the sources. [More about Collection rule](../../data-sources/collection-rules/index.md) * ## Connector rule # Also known as: _Connector_ A policy that determines which listeners a set of AxoRouter instances offers, based on dynamic host labels. Read more A connector is the entry point where AxoRouter receives data from a [source]( "A host or service that sends data into the pipeline."), for example: * a syslog listener, * an [OTLP]( "The OpenTelemetry protocol, used to transport data between Axoflow components.") 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]( "Identifying which device or service a message came from by verifying its content, not the port it arrived on.") and parsing are among them, so the connector enriches the data before a [flow]( "The configuration object that describes how the pipeline routes and processes a set of data between sources and destinations.") 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]( "A rule that defines how edge hosts collect their local data.") define how [edge hosts]( "A source host that runs a managed collector agent, or reports metrics through Axolet.") collect their local data. [More about Connector rule](../../data-sources/connector-rules/index.md) * ## Control plane # Also known as: _Axoflow control plane_ The management half of Axoflow: it configures the pipeline and describes what flows through it, but never carries your data. Read more In practice the control plane is [AxoConsole]( "The management and data visualization UI of the Axoflow Platform."). 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]( "The half of the Axoflow Platform that carries your telemetry: the agents, routers, and storage that handle the data itself."). AxoConsole deploys managed components such as AxoRouter and Axoflow agent, and it translates each [flow]( "The configuration object that describes how the pipeline routes and processes a set of data between sources and destinations.") you configure into component-level configuration that it deploys to the managed [data plane]( "The half of the Axoflow Platform that carries your telemetry: the agents, routers, and storage that handle the data itself.") 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. [More about Control plane](../../architecture/index.md#control-plane) * ## COTS # Also known as: _Commercial off-the-shelf_ Commercial 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 plane_ The collector agents, processing engines, and storage that carry and process your telemetry data, as opposed to the control plane that manages them. Read more The data plane covers AxoRouters, the Axoflow agents, and the [cloud connectors]( "A pull-based collector built on OpenTelemetry that fetches data from a cloud service, API, or streaming source."). 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]( "The management half of the Axoflow Platform: it configures the pipeline and describes what flows through it, but never carries your data."), compiled from the [flows]( "The configuration object that describes how the pipeline routes and processes a set of data between sources and destinations.") you configure. Every AxoRouter and Axoflow agent deployment also includes [Axolet]( "The monitoring and management agent that reports host and traffic metrics to AxoConsole."), which reports the host’s metrics to AxoConsole. [More about Data plane](../../architecture/index.md#data-plane) * ## Data reduction # Also known as: _Reduction_ Cutting the volume of your security data by removing noise and redundant content before it reaches the [destination]( "A SIEM, storage, or analytics system that the pipeline delivers security data to."). Read more Reduction follows from [classification]( "Identifying which device or service a message came from by verifying its content, not the port it arrived on."). 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]( "Security Information and Event Management: the platform where a security team searches and correlates security data, and raises alerts on it.") means lower ingestion cost, and it’s the reason classification is worth doing before routing rather than after. [More about Data reduction](../../concepts/classify-reduce-security-data/index.md) * ## Destination # The [SIEM]( "Security Information and Event Management: the platform where a security team searches and correlates security data, and raises alerts on it."), storage, or analytics system that the pipeline delivers your security data to. Read 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]( "Delivering data in the schema and field names the destination expects, instead of raw blobs.") does, and it’s what keeps ingestion fast and the stored data queryable. A single [axorouter]( "The router and data curation engine of the Axoflow Platform. It collects your security data and delivers it, curated, to your destinations.") can send the same data to several destinations, each in the format that destination supports. [More about Destination](../../destinations/index.md) * ## Edge host # Also known as: _Edge_ A [source]( "A host or service that sends data into the pipeline.") host that runs a collector agent managed by AxoConsole, or has [Axolet]( "The monitoring and management agent that reports host and traffic metrics to AxoConsole.") reporting metrics from it. Read more The distinction matters because it decides how you configure collection. A [collection rule]( "A rule that defines how edge hosts collect their local data.") 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]( "A policy that determines which listeners AxoRouter instances offer, based on host labels.") on AxoRouter instead. [More about Edge host](../../data-sources/collection-rules/index.md) * ## Flow # The configuration object that describes how the pipeline routes and processes a set of data on its way from sources to destinations. Read 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]( "Routing data by what the source is, rather than by sender IP or application name.") means in practice. The **Flows** page lists every configured flow and shows which ones have alerts on them. [More about Flow](../../data-management/flow-overview/index.md) * ## Host attribution # Also known as: _Inventory_ Enriching your data with metadata about the host that produced it, so you can pinpoint the origin of every entry. Read 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]( "A host or service that sends data into the pipeline.") by adding labels: vendor and product, physical location, owning team. That metadata is what makes [policy-based routing]( "Routing data by what the source is, rather than by sender IP or application name.") possible. [More about Host attribution](../../concepts/inventory/index.md) * ## Log tapping # Sampling the live data flow of an AxoRouter to see what the pipeline receives and what it sends on. Read 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]( "A SIEM, storage, or analytics system that the pipeline delivers security data to.")? 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]( "The configuration object that describes how the pipeline routes and processes a set of data between sources and destinations."). [More about Log tapping](../../onboard-hosts/log-tapping/index.md) * ## Normalization # Delivering data in the schema, field names, and data types the [destination]( "A SIEM, storage, or analytics system that the pipeline delivers security data to.") expects, instead of ingesting raw blobs. Read 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. [More about Normalization](../../concepts/normalization/index.md) * ## OTLP # Also known as: _OpenTelemetry protocol_ The OpenTelemetry protocol, which Axoflow components use to transport data between themselves. Read 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]( "A SIEM, storage, or analytics system that the pipeline delivers security data to.") 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. [More about OTLP](../../concepts/reliable-transport/index.md) * ## 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. Read more Technical parameters make coarse routing rules. [Host attribution]( "Enriching data with metadata about the host that produced it, so you can trace every entry to its origin.") 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 configuration object that describes how the pipeline routes and processes a set of data between sources and destinations."). The policy keeps holding as you add and replace hosts. [More about Policy-based routing](../../concepts/policy-based-routing/index.md) * ## Rehydration # Selecting a set of stored data and sending it on to another [destination]( "A SIEM, storage, or analytics system that the pipeline delivers security data to."). Read 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]( "Security Information and Event Management: the platform where a security team searches and correlates security data, and raises alerts on it.") 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. [More about Rehydration](../../data-management/rehydration/index.md) * ## SIEM # Also known as: _Security Information and Event Management_ Security Information and Event Management. The platform where your security team searches and correlates security data, and raises alerts on it. Read more A SIEM is the most common [destination]( "A SIEM, storage, or analytics system that the pipeline delivers security data to.") in a security pipeline. It’s usually the most expensive one, because vendors price it by ingested volume. That price is why [data reduction]( "Cutting the volume of security data by dropping noise and redundant content before it reaches the destination.") and [policy-based routing]( "Routing data by what the source is, rather than by sender IP or application name.") matter. You send the SIEM the data your team needs for detection, and route the rest to AxoStore or AxoLake. [More about SIEM](../../destinations/index.md) * ## Source # A host or service that sends data into the pipeline. Read 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]( "A SIEM, storage, or analytics system that the pipeline delivers security data to."), 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]( "The monitoring and management agent that reports host and traffic metrics to AxoConsole."), is an [edge host]( "A source host that runs a managed collector agent, or reports metrics through Axolet."). One that simply sends syslog at a listener isn’t. [More about Source](../../data-sources/index.md)