-
-
-
Event Data Filtering
-
-
This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
此内容已经过机器动态翻译。 放弃
このコンテンツは動的に機械翻訳されています。免責事項
이 콘텐츠는 동적으로 기계 번역되었습니다. 책임 부인
Este texto foi traduzido automaticamente. (Aviso legal)
Questo contenuto è stato tradotto dinamicamente con traduzione automatica.(Esclusione di responsabilità))
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
この記事は機械翻訳されています.免責事項
이 기사는 기계 번역되었습니다.책임 부인
Este artigo foi traduzido automaticamente.(Aviso legal)
这篇文章已经过机器翻译.放弃
Questo articolo è stato tradotto automaticamente.(Esclusione di responsabilità))
Translation failed!
Event Data Filtering
What is Event Data Filtering
Event data filtering allows defining rules with conditions that are evaluated for every event before it is sent to the backend. This feature applies to all built-in metrics. With each matching rule, a pre-defined action is executed that controls whether the event is sent to the backend or not. Additionally, it allows clearing the contents of certain fields before the event is sent to the backend.
Use Cases for Event Data Filtering
Data Volume Reduction
Depending on the requirements, one might only need a subset of the events generated by uberAgent for certain sourcetypes. Filtering out unnecessary data at the endpoint may reduce the data volume significantly (see the documentation for other ways to reduce the data volume).
Example: every time a cmd.exe
process is started on Windows, an accompanying console host process is started too. These conhost.exe
processes are rarely of interest and can be safely excluded.
[EventDataFilter]
# Exclude "conhost.exe" (typically started from the path: \??\C:\WINDOWS\system32\conhost.exe)
Action = deny
Sourcetype = Process:ProcessStartup
Query = regex_match_path(ProcPath, r"^(\\\?\?\\)?%SystemRoot%\\System32\\conhost\.exe$")
<!--NeedCopy-->
Example: compared to Windows, macOS runs significantly more concurrent processes. which can also lead to an increased data volume. One way to adjust this is to exclude the processes that belong to the operating system.
[EventDataFilter]
# Exclude processes belonging to the operating system
Action = deny
Sourcetype = Process:ProcessDetail
Sourcetype = Process:ProcessStartup
Sourcetype = Process:ProcessStop
Sourcetype = Process:ProcessStatistics
Sourcetype = Process:NetworkTargetPerformance
Query = AppId == "mcOS"
<!--NeedCopy-->
Sensitive Data Removal
Some sourcetypes have fields with data that may be considered sensitive in nature, such as window titles. Event data filtering allows clearing such fields, on the endpoint, before the data is sent to the backend for indexing and searching.
Example: clear the contents of session detail window title metric.
[EventDataFilter]
# Clear the contents of window titles.
Action = clear
Sourcetype = Session:SessionDetail
Field = SessionFgWindowTitle
Query = true
<!--NeedCopy-->
The query above always evaluates to true
and therefore the action clear
is executed for this particular event and the field SessionFgWindowTitle
is cleared to an empty value.
Configuring Event Data Filtering
An event data filter is configured using the configuration file. The stanza [EventDataFilter]
starts a new filter configuration, followed by multiple settings.
It’s essential to note that filter rules are processed sequentially. Once a rule matches, the filtering process for that particular event stops. Therefore, the order of filters can be crucial for the desired outcome.
Setting | Description | Valid Values |
---|---|---|
Action | Specifies the action to be taken if a query rule is matched. |
allow , deny or clear
|
Sourcetype | The category and name of the sourcetype. | Please refer to the metrics documentation for a list of available sourcetypes. |
Query | The query rule to filter using uAQL. | Please refer to the uAQL documentation. |
Field | Optional setting to specify the field to be cleared if the current Action is clear . This setting can be configured multiple times. |
This can be any field of the given metric. |
Example: Exclude DNS Monitoring Events Caused by Browsers
A browser can generate a significant number of DNS monitoring events that are rarely of interest. Such events can be easily ignored using the following event data filter.
[EventDataFilter]
# Deny any DNS event caused by browsers.
Action = deny
Sourcetype = Process:DnsEvent
Query = ProcName in ["chrome.exe", "iexplore.exe", "firefox.exe", "msedge.exe", "opera.exe"]
<!--NeedCopy-->
Example: Exclude Process Detail Metrics For Certain Processes
[EventDataFilter]
# Exclude processes whose name is exactly one of the given names.
Action = deny
Sourcetype = Process:ProcessDetail
Query = ProcName in ["cmd.exe", "conhost.exe", "csrss.exe", "lsm.exe", "smss.exe", "wininit.exe", "winlogon.exe"]
<!--NeedCopy-->
Example: Exclude Everything Except..
Consider a use case where one wants to exclude an entire metric, except for specific data in events. This is achievable by explicitly allowing certain processes but denying all others. The stanza ordering is important because filter processing stops after the first match.
[EventDataFilter]
# Allow network events caused by John Doe and Jane Doe.
Action = allow
Sourcetype = Process:NetworkTargetPerformance
Query = ProcUser in ["John Doe", "Jane Doe"]
[EventDataFilter]
# Deny any network event that was not allowed in a previous filter.
Action = deny
Sourcetype = Process:NetworkTargetPerformance
Query = true
<!--NeedCopy-->
Per-Receiver Configuration
In addition to the fields of a sourcetype, certain built-in receiver fields may also be used. This allows creating event data filters that are active for certain receivers, only. Check the documentation on routing to different backends to learn more on the use case.
The available fields are Receiver.Name
and Receiver.Index
.
Example: Clear Fields Per Receiver
For this example, we take a look at the Session Detail metric. Consider there are two receivers configured, one for most metrics and an extra receiver for sensitive content with restricted access.
[EventDataFilter]
# Clear the contents of window titles for any receiver except "uberagent_sensitive"
Action = clear
Sourcetype = Session:SessionDetail
Field = SessionFgWindowTitle
Query = Receiver.Name != "uberagent_sensitive"
<!--NeedCopy-->
This configuration will clear the contents of SessionFgWindowTitle
in all receivers, except the receiver uberagent_sensitive
.
Example: Filter Events Per Receiver
We can also use almost the same rule to achieve a different use case: exclude events from all receivers, except uberagent_sensitive
.
[EventDataFilter]
# Exclude this event from all receivers except "uberagent_sensitive"
Action = deny
Sourcetype = Session:SessionDetail
Query = Receiver.Name != "uberagent_sensitive"
<!--NeedCopy-->
Instead of clearing the field content for the non-matching receiver, we simply deny sending the event to all receivers, except uberagent_sensitive
.
More Examples
More examples including rules created by our support for our customers can be found in the knowledge base article here.
Share
Share
This Preview product documentation is Citrix Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Citrix Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Citrix product purchase decisions.
If you do not agree, select I DO NOT AGREE to exit.