Are you a member of the Splunk Community?
- Find Answers
- :
- Using Splunk
- :
- Other Using Splunk
- :
- Alerting
- :
- Report v.s. Alert, what's the difference?
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark Topic
- Subscribe to Topic
- Mute Topic
- Printer Friendly Page
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
When I run a search query in Splunk, it can be saved as Report or Alert. What's the difference between them?
I looked at the stanza at savedsearches.conf but they are almost identical. Is there a systematic way to find out the number of reports vs alerts in all the saved searches?
Thanks in advance!
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In Splunk, we really only have at a technology level the idea of a Search.
Searches have a LOT in them. They can be saved, permissioned, put in dashboards, scheduled, hooked up to terminal actions that fire when they complete, and more. Searches have so many optional pieces that it becomes hard to communicate the possible kinds of things that you can do with a Search.
As a result, in the UI layer we try to offer some compartmentalization to provide a simpler story. Here, we tend to use Report for a Search or Search workflow that you would produce results that people will typically look at, while we use Alert for a Search that will make a determination to take action in contacting the outside world via email or script execution if its results match a criteria.
In the save action, we take the hint if the user selects Alert to go through a workflow of helping provide useful decision making around setting up the alerting mechanism, timing, possible throttling, and so on. For a Report, there's some opportunity to go ahead and attach it to a dashboard.
If you do the configuration yourself, eg by accessing the Saved Search in the Manager UI, then you'll see they're the same type of thing. You can in fact have one search that you run to send out alerts, but that you also retain the output of to view in a visualization in a dashboard, for example. But this kind of dual-use scenario is hard to build focused workflows around so it only becomes relevant for people who are really fully controlling the sceanario, such as possibly some Splunk Admin scenarios, or possibly advanced App creators.
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In Splunk, we really only have at a technology level the idea of a Search.
Searches have a LOT in them. They can be saved, permissioned, put in dashboards, scheduled, hooked up to terminal actions that fire when they complete, and more. Searches have so many optional pieces that it becomes hard to communicate the possible kinds of things that you can do with a Search.
As a result, in the UI layer we try to offer some compartmentalization to provide a simpler story. Here, we tend to use Report for a Search or Search workflow that you would produce results that people will typically look at, while we use Alert for a Search that will make a determination to take action in contacting the outside world via email or script execution if its results match a criteria.
In the save action, we take the hint if the user selects Alert to go through a workflow of helping provide useful decision making around setting up the alerting mechanism, timing, possible throttling, and so on. For a Report, there's some opportunity to go ahead and attach it to a dashboard.
If you do the configuration yourself, eg by accessing the Saved Search in the Manager UI, then you'll see they're the same type of thing. You can in fact have one search that you run to send out alerts, but that you also retain the output of to view in a visualization in a dashboard, for example. But this kind of dual-use scenario is hard to build focused workflows around so it only becomes relevant for people who are really fully controlling the sceanario, such as possibly some Splunk Admin scenarios, or possibly advanced App creators.
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the detail explanation. Your description is the same as I thought. Basically, it's mainly for the workflow in Splunk 6 UI.
Leveraging Automated Threat Analysis Across the Splunk Ecosystem
Can’t Make It to Boston? Stream .conf25 and Learn with Haya Husain
Splunk Lantern’s Guide to The Most Popular .conf25 Sessions
