• v7.5.0
    • v7.11.0 (latest)
    • v7.10.0
    • v7.9.0
    • v7.8.0
    • v7.7.0
    • v7.6.0
    • v7.5.0
    • v7.3.0
    • v7.2.0
    • v7.1.1
    • v7.1.0
    • v7.0.8
  • Services & Support
  • Devo.com
  • Contact
    • Contact Us
    • Request a Demo
    • Partner Inquiry
  • Log In
    • USA Devo
    • EU Devo
PREVIOUS
Scenario 2: Apply a Devo tag based on data found in the inbound event
NEXT
Scenario 4: Assign dynamic Devo tag using inbound source data

Sending data to Devo / Devo Relay / Configuring Devo Relay / Configuring Devo Relay from the web application / Relay input configuration / 5 common relay rule scenarios / Scenario 3: Filter out unwanted events

Download as PDF

Scenario 3: Filter out unwanted events

Some data sources generate events that contain less valuable information and which you prefer not to forward to Devo. In these cases, you can use a relay rule to identify and drop these events. For this to be possible, you need to be able to specify exactly how the relay can recognize which events it should drop. There are a few possibilities:

  • By the syslog tag - You can specify this in the Source tag field
  • By content found within the syslog header or message - You can specify this in using text or regex in the Source message or Source data fields
  • By the syslog level or facility - You can specify this in the Source level or Facility fields in the Advanced parameters section of the rule

Once you define the conditions that identify the events you want to filter out, select Drop event and Stop processing to finish the rule.

Create the rule

  1. Identify the Source port on which the relay will receive the inbound events. Again, it is a best practice to dedicate a single port to a single event source.
  2. Enter the regular expression in the Source data field. 
  3. Select both Drop event and Stop processing.

Take for example...

Bluecoat ProxySG can generate comment-style headers in log files that are not useful to send to Devo. These lines begin with a # and we can use a regular expression to identify that. So, the rule below drops all events received on port 13005 and start with #. Because Stop processing is selected, events that meet the rule criteria will not be subjected to processing by subsequent rules. This is good practice for all rules that are designed to filter out (or drop) events.

To learn about the fields in the relay rule form, check out the Defining a relay rule article.


Related articles

  • proxy.bluecoat
  • Defining a relay rule
Download as PDF

PREVIOUS
Scenario 2: Apply a Devo tag based on data found in the inbound event
NEXT
Scenario 4: Assign dynamic Devo tag using inbound source data

Export

See what Devo can do for you. Request a demo!
Discover what's new (Release notes)
  • v7.5.0
    • v7.11.0 (latest)
    • v7.10.0
    • v7.9.0
    • v7.8.0
    • v7.7.0
    • v7.6.0
    • v7.5.0
    • v7.3.0
    • v7.2.0
    • v7.1.1
    • v7.1.0
    • v7.0.8
  • Services & Support
  • Devo.com
  • Contact
    • Contact Us
    • Request a Demo
    • Partner Inquiry
  • Log In
    • USA Devo
    • EU Devo
  • +1 888 6830910 (USA)
  • +34 900 838 880 (Spain)
Copyright © 2019 Legal Terms Privacy Policy Cookies Policy

Powered by Confluence and Scroll Viewport