Skip to main content
Version: 3.3.0

Basic Concepts

Understand Alert Manager Enterprise (AME) by exploring its core concepts. Each term below explains a key feature, why it exists, and the benefits it offers, with links to dive deeper into setup and usage.

Alert​

In Splunk, an "alert" is a triggered search result that initiates AME event creation or updates an existing event. This feature exists to integrate Splunk’s alerting system with AME, capturing critical notifications for management. It benefits users by providing the starting point for tracking and acting on Splunk-detected issues (see Quick Start and Alert Action).

Event​

An "event" in AME is a managed instance of an alert, stored and tracked with attributes like status or tags. It exists to organize and enhance Splunk alerts into a structured workflow, enabling aggregation and automation. The benefit is a centralized, actionable view of alerts tailored to your needs (see Event Aggregation and Working with Events).

Event Summary​

The event summary is AME’s customizable interface for viewing and managing events. It exists to give users a clear, tailored overview of alert data, reducing clutter and focusing on what matters. The benefit is faster decision-making with a dashboard that adapts to your needs (see Event Summary Overview and Event Summary Configuration).

Notification​

Notifications send messages via email, Slack, or Teams when events change, like assignment. They exist to keep teams informed in real-time, ensuring no critical update is missed. This benefits users by enabling prompt responses through preferred communication channels (see Notifications).

Observable​

Observables are key data colletions, sourced and structured by AME through a Splunk Alert Action and Search. They include critical information such as user identities (e.g., usernames, roles) and asset details (e.g., device IPs, hostnames). This data is stored in KV Store collections, organized by tenant, and serves to enrich security and IT operations. By providing valuable context, observables enhance investigations and event management, improving overall effectiveness(see Observables).

Report​

Reports are dashboards that analyze event metrics, such as SLA compliance or trends. They exist to provide insights into alert performance and system health, supporting data-driven decisions. The benefit is improved visibility and accountability with actionable analytics (see Reports).

Resolution​

Resolutions define an event’s final state (e.g., Resolved), set manually or automated. This feature exists to formalize alert closure, tracking when and how issues are addressed. It benefits users by clarifying event lifecycles and automating repetitive tasks (see Resolutions).

Rule​

Rules automate event updates, like changing status when a user is assigned. They exist to reduce manual effort and ensure consistent alert handling based on conditions. The benefit is increased efficiency and reliability in managing large alert volumes (see Rules).

SLA (Service Level Agreement)​

SLAs enforce time-based objectives (e.g., 60-minute response), triggering actions on violation or fulfillment. They exist to uphold service standards and accountability within teams. This benefits users by automating compliance monitoring and response escalation (see SLAs).

Status​

Statuses (e.g., Assigned) indicate an event’s current state, set manually or via rules. This feature exists to track alert progress, providing clarity on their lifecycle stages. It benefits users by organizing workflows and enabling automation triggers (see Statuses).

Tag​

Tags (e.g., PCI) label events for categorization, often based on conditions like subnet matching. They exist to group and filter alerts, simplifying management and reporting. The benefit is enhanced organization and quick identification of related events (see Tags).

Template​

Templates preset event attributes (e.g., medium urgency) as a basis for alert creation, though values can be overridden later. They exist to standardize event data across alerts while allowing flexibility for unique cases. This benefits users by saving time on setup and adapting to specific needs (see Templates).

Tenant​

Tenants are containers isolating events, configurations, and roles; the default tenant starts at install. They exist to support multi-team or multi-client environments, keeping data separate. The benefit is secure, organized event management tailored to specific groups (see Tenants).

Workflow Action​

Workflow actions trigger Splunk actions (e.g., a webhook) from event data in Notable Fields. They exist to integrate AME with external systems, extending alert responses. The benefit is seamless automation and connectivity with tools like ticketing systems (see Working with Events).

Next Steps​