Wazuh 5.0 renamed a lot of things and introduced several concepts that have no 4.x equivalent. These are the terms you need to read the rest of the tutorial, defined from the 5.0-beta documentation. Where a term changed meaning between versions, the entry says so. Paths and ports are in the ports and paths reference; commands are in the cheat sheet.
A
Active response
A scripted action executed on a monitored endpoint in reaction to a detection, such as blocking an address or deleting a file. In Wazuh 5.0 the trigger is inverted compared with 4.x: an Alerting monitor on the indexer writes a request document to the wazuh-active-responses index, the manager reads it and dispatches the command to the agent. Results land in active-responses.log on the endpoint and are retained in the index for three days by default. See Active Response and when to leave it off.
Agent
The software installed on a monitored endpoint. It collects logs, file integrity changes, system inventory, configuration assessment results and vulnerability inventory, and forwards them to the manager over HTTPS on port 1517. One agent covers Linux, Windows and macOS, and the same package is used for laptops, servers, cloud instances and containers. It runs as wazuh-agent on Linux, as the launch daemon com.wazuh.agent on macOS and as the service WazuhSvc on Windows, where it installs to C:\Program Files (x86)\ossec-agent. See what Wazuh is.
Agent group
A named collection of agents that share a centralised configuration file, agent.conf, held on the manager. In Wazuh 5.0 a group must exist before an agent enrols into it; enrolment is rejected if the group named in <enrollment><groups> is missing. An agent can belong to several groups, and their configurations are merged. See agent groups and centralised configuration.
Alerting monitor
An OpenSearch Alerting job on the indexer that runs a query on a schedule, evaluates a trigger condition and executes an action. In Wazuh 5.0 this is the mechanism for notifying humans and for firing active responses, replacing the manager’s old integration and email daemons. Monitor types include query-level, bucket-level, document-level and a Wazuh-specific Active Response monitor. See notifications.
C
Case management
The workflow layer on top of findings in the Security Analytics module: an analyst sets a status, adds a comment and applies tags, and those land on the finding itself under wazuh.case.*. Documented statuses include ACTIVE, ACKNOWLEDGED and COMPLETED, and a single API call can update up to 50 findings at once. It has its own entry in the dashboard menu under Threat intelligence, and it is the nearest thing 5.0 has to a built-in triage record. See SOAR with Wazuh.
Category
The classification assigned to an integration, which determines the data streams its events and findings are routed to. The eight categories on a 5.0.0-beta5 install are access-management, applications, cloud-services, network-activity, security, system-activity, other and unclassified, with cloud-services as a single stream rather than one per provider. A finding from a firewall integration ends up in wazuh-findings-v5-network-activity, not in one shared alerts index. See rules, decoders and severity levels explained.
Cluster
A set of manager nodes, one master and zero or more workers, that share agent registration data and group configuration over port 1516. In Wazuh 5.0 every install is a cluster, including a single node, so there is no longer a cluster-disabled mode. The indexer runs its own separate cluster on ports 9300 to 9400. See cluster and distributed architecture.
Content Manager
The indexer plugin that holds and synchronises detection content: rules, decoders, integrations, KVDBs and indicators of compromise. It pulls standard content from the Wazuh CTI API, exposes REST endpoints under /_plugins/_content_manager/ for your own content, and keeps the manager and indexer in step. This is the component that replaces the 4.x ruleset directory and update_ruleset. See writing custom rules.
CTI (Wazuh Cyber Threat Intelligence)
The upstream service that supplies Wazuh with detection content, indicators of compromise and vulnerability intelligence. The Content Manager retrieves it and stores it in the indexer, where the vulnerability scanner and the enrichment stage consume it. In 5.0 there is no offline vulnerability feed, so a deployment needs a path to the CTI API to keep vulnerability data current. See threat intelligence.
D
Dashboard
The web interface, built on OpenSearch Dashboards, served on port 443. It queries the indexer for events, findings and endpoint state, and calls the manager API for administration such as enrolling agents, assigning groups and running remote upgrades. It is also where Security Analytics, Alerting, Notifications and Reporting are configured. See the dashboard tour.
Data stream
A logical name that writes to a rotating sequence of backing indices, used for continuously generated time-based data such as events, findings, active response requests and metrics. Wazuh creates them automatically through the Setup module and manages rollover and deletion with ISM policies. By default a stream rolls over at 20 GB primary shard size or 200 million documents. See upgrade, backup and retention.
Decoder
An asset that takes a raw event and normalises it into the Wazuh Common Schema. In 5.0 decoders are YAML, organised in a tree from a root decoder, and use three stages: check to decide whether the decoder applies, parse to extract values, and normalize to map them onto schema fields. They replace 4.x XML decoders, and there is no converter between the two. See writing a custom decoder.
Detector
A scheduled job on the indexer that evaluates indexed events against a selected set of rules and produces findings when they match. You choose the indices it reads, the Space and integration it draws rules from, and how often it runs. Because detection is scheduled rather than inline, findings appear a short interval after the event rather than instantly. See writing custom rules.
Detector period
How often a detector evaluates, expressed as an interval and a unit. It sets the floor on how long a finding takes to appear, so it is a service-level decision rather than a tuning detail. The 22 monitors shipped with 5.0.0-beta5 use three values: one minute for time-sensitive content such as file integrity and indicator matching, two minutes for most detection content, and five minutes for IT hygiene. See performance tuning.
E
Enrolment
The process by which an agent registers with the manager and receives an id and a key. In Wazuh 5.0 it happens over HTTPS on port 1517 through the POST /enroll endpoint, which relays to the wazuh-manager-authd daemon, and it requires the shared enrolment password by default. The alternative is to call POST /agents on the manager API and import the returned key onto the endpoint. See agent enrolment explained.
Event
A log record after collection and normalisation. The documentation distinguishes three stages: the raw log as the source produced it, the input event once the agent has added agent and cluster metadata, and the normalised event as a schema-conformant JSON document. Events are stored whether or not any rule matched, which is a change from 4.x where only alerts were indexed by default. See rules, decoders and severity levels explained.
F
File integrity monitoring (FIM)
The capability that watches files, directories and Windows registry keys for creation, modification and deletion. It stores a baseline of checksums and attributes and reports divergence through scheduled or real-time scans. Current file state lives in the wazuh-states-fim-files and wazuh-states-fim-registry-* indices, separate from the findings that changes generate. See file integrity monitoring setup.
Finding
The security record produced when the detection engine matches an event against a rule. It carries the detection result, the triggering event, rule metadata and investigation fields such as case status, comments and tags, and it preserves the original log line in event.original. Findings in 5.0 serve the role that alerts served in 4.x, and they are stored in wazuh-findings-v5-<category> rather than written to a file. See the dashboard tour.
I
Index State Management (ISM)
The OpenSearch mechanism that moves indices through lifecycle states automatically. Wazuh uses it to roll over data streams and to delete backing indices once their retention period expires, retrying a failed deletion up to three times with exponential backoff. Default retention is 10 minutes for raw events, one hour for categorised events, 90 days for findings and three days for active responses. See upgrade, backup and retention.
Indexer
The storage, search and analytics component, built on OpenSearch and listening on port 9200. In Wazuh 5.0 it does far more than store data: it runs detection through the Security Analytics module, holds detection content through the Content Manager, and provides alerting, notifications, reporting and access control. It is the component that gets the most of your hardware budget. See what Wazuh is.
Indexer connector
The shared library compiled into the manager that sends processed events to the indexer over TLS on port 9200. It is configured in the <indexer> block of the manager configuration file and is the only outbound path from the normalization engine to the indexer. It replaces Filebeat, which is not part of Wazuh 5.0. See what changes in Wazuh 5.
Integration
A logical grouping of decoders, KVDBs and rules that belong to one log source or product, and the unit at which content is enabled and ordered. Every decoder belongs to exactly one integration, and every integration is assigned a category that determines where its events and findings are routed. This is the packaging concept that replaces the flat ruleset directories of 4.x. See writing a custom decoder.
K
Key-Value Database (KVDB)
A named dictionary of string keys and JSON values that decoders and rules query during processing, used for lookup data that changes independently of the parsing logic: normalisation tables, default field sets, blocklists, reference data. Helper functions such as kvdb_get, kvdb_get_array and kvdb_match read from them inline during normalisation. KVDBs replace 4.x CDB lists, and there is no import tool between the two formats. See threat intelligence, MISP and KVDB lists.
L
Label
Arbitrary key-value metadata attached to an agent so that it appears on every document that agent produces, typically used to carry an owner, a site, an environment or a tenant. The <labels> configuration block is not listed in the Wazuh 5.0-beta agent configuration reference and wazuh.agent.labels.* does not appear in the beta field documentation, so treat both the syntax and the field path as unconfirmed until general availability (verify). The related field wazuh.agent.groups does appear on documents. See agent groups and centralised configuration.
M
Manager
The server component that receives data from agents, runs the normalization engine over it and forwards the result to the indexer. In 5.0 it installs to /var/wazuh-manager, runs eight daemons prefixed wazuh-manager- on beta5 (analysisd, apid, authd, clusterd, db, modulesd, monitord and remoted, with monitord documented as going but still shipped), exposes a REST API on port 55000 and holds only ten configuration sections, because every agent capability is configured agent-side or through group configuration. It no longer stores alerts on disk. See what Wazuh is.
N
Normalization engine
The event processing pipeline inside the manager. An Orchestrator sends each incoming event to every active security policy, and each policy runs an ordered set of stages: pre-filtering, decoding, enrichment, post-filtering and output. Because each policy gets its own copy of the event, one incoming record can produce more than one output document. See the normalization engine documentation and rules, decoders and severity levels explained.
Notification channel
A configured destination for messages from the indexer: Slack, Microsoft Teams, Amazon Chime, Amazon SNS, email over SMTP or SES, or a custom HTTP webhook. Channels are managed at /_plugins/_notifications/ and under Explore, Notifications, Channels on the dashboard, and they are what an Alerting monitor calls when a trigger fires. A custom webhook channel is the entry point for anything the built-in types do not cover. See notifications.
R
Rule
The detection logic that decides what counts as interesting. In Wazuh 5.0 rules are written in Sigma format with Wazuh extensions, requiring a UUID identifier, a detection block, a logsource and metadata, and optionally carrying MITRE ATT&CK and compliance mappings. Severity is a string (informational, low, medium, high, critical) rather than the 4.x numeric level, and correlation constructs such as if_sid and frequency have no equivalent. See writing custom detection rules.
S
Security Configuration Assessment (SCA)
The capability that checks an endpoint against a policy of expected configuration, mostly derived from CIS benchmarks, and reports each check as passed or failed with a remediation note. Policies are YAML, shipped with the agent and extensible with your own. Results are stored in the wazuh-states-sca index; the 4.x /sca/{agent_id} API endpoint does not exist in 5.0, so you query the index instead. See SCA and CIS benchmarks.
Space
The logical storage location for detection content in the indexer. There are four, and the dashboard’s Security Analytics application carries a selector for exactly those: standard, which holds official Wazuh content synchronised from CTI and is read-only; draft, where you create and edit; test, where content is validated with log test before release; and custom, the final home of your own content. Log test runs only against test, custom and standard, so draft content has to be promoted before it can be tested: calling it on draft returns Logtest is only supported for the 'test', 'custom' and 'standard' spaces. Keeping standard and custom separate means your policy and Wazuh’s policy run as independent pipelines. See writing custom detection rules.
State file
The agent’s own record of its connection, written to disk and readable without the manager. On Linux and macOS it is wazuh-agentd.state under var/run in the install directory; on Windows it is wazuh-agent.state in the agent folder. It carries status (pending, connected or disconnected), last_keepalive and event counters. A second file, wazuh-logcollector.state, holds per-source collection counters, as a flat listing on Linux and as JSON on Windows. These are the first two files to read when an agent misbehaves. See the disconnected-agent decision tree.
Stateful index
An index holding the current state of monitored endpoints rather than a time series of records, continuously updated as the environment changes. The 5.0 set covers SCA results, FIM file and registry state, vulnerability assessment results, and thirteen inventory indices for packages, processes, ports, users, groups, services, networks, interfaces, protocols, hardware, system, hotfixes and browser extensions. These are the indices you query when you want to know what is true now, not what happened. See vulnerability detection setup.
Syscollector
The agent module that collects system inventory: hardware, operating system, packages, processes, services, ports, network interfaces and addresses, users, groups, browser extensions and, on Windows, installed hotfixes. Its output populates the wazuh-states-inventory-* indices and is the input the vulnerability scanner works from, so vulnerability detection does nothing useful until inventory is arriving. See vulnerability detection setup.
W
Wazuh Common Schema (WCS)
The field naming standard every Wazuh 5.0 document conforms to, based on the Elastic Common Schema with a wazuh.* namespace added. It is why data.srcip became source.ip, full_log became event.original, syscheck.path became file.path and timestamp became @timestamp. Rule detection blocks are validated against WCS at creation time, so a rule referring to a field that does not exist in the schema is rejected. See what changes in Wazuh 5.
WPK
The Wazuh package format used for remote agent upgrades. The manager pushes a WPK file to an enrolled agent over the agent channel, and the agent verifies and installs it, which is what agent_upgrade and the API upgrade endpoints do underneath. Upgrading an agent to 5.0 from 4.x this way requires the agent to be at a recent enough 4.x version first. See upgrade, backup and retention.
Next: Wazuh commands cheat sheet.
Frequently asked questions
What is the difference between a Wazuh event and a Wazuh finding?
An event is a log record that has been collected, decoded and normalised into the Wazuh Common Schema, and it is stored whether or not anything matched. A finding is what the detection engine produces when an event matches a Sigma rule, and it carries the rule metadata alongside the triggering event. Findings in Wazuh 5.0 serve the role that alerts served in Wazuh 4.x.
What replaced alerts in Wazuh 5.0?
Findings. The word alert is retained for OpenSearch Alerting monitor output, but the record produced when a detection rule matches an event is now called a finding and is stored in the wazuh-findings-v5 data streams. There is no more alerts.json on the manager.
What is a Wazuh Space?
A Space is the logical storage location for detection content inside the indexer. There are four: standard, which holds the official Wazuh content synchronised from Wazuh CTI and is read-only; and draft, test and custom, which you manage. Content is written in draft, validated in test, then promoted to custom.