Server logs are one of the most valuable sources of evidence during troubleshooting, security investigations, and incident response. The challenge is that modern environments generate enormous amounts of telemetry: authentication events, process activity, network connections, DNS requests, file operations, web traffic, and application events can all appear in the same investigation.
UDM queries make this data easier to investigate by allowing you to search normalized event fields instead of relying entirely on the original format produced by each server or security product.
The key to effective UDM searching is not simply knowing the query syntax. It is understanding which UDM fields represent the evidence you are looking for, how your server’s logs were normalized, and how to progressively narrow a search without accidentally excluding relevant events.
What is a UDM query?
UDM stands for Unified Data Model. In Google SecOps, incoming security and server telemetry is represented using a common structure.
Instead of searching every product’s native field names, you can query fields such as:
metadata.event_type
metadata.log_type
principal.hostname
principal.ip
principal.user.userid
target.hostname
target.ip
target.user.userid
network.application_protocol
network.http.response_code
security_result.action
A basic query follows a simple pattern:
field = value
For example:
principal.hostname = "web-server-01"
This asks for events associated with that principal hostname.
You can then combine conditions:
principal.hostname = "web-server-01"
AND metadata.event_type = "NETWORK_CONNECTION"
The first condition establishes the server you are interested in. The second limits the results to network-connection events.
This field-oriented approach is particularly useful when several different products contribute logs to the same investigation.
Start with the server, not the suspected problem
A common mistake is to begin with a highly specific query such as:
"authentication failed"
That can work when the log message is predictable, but it can also miss events because different sources may represent the same activity differently.
A more reliable investigation usually starts with an entity:
principal.hostname = "web-server-01"
Then establish what kinds of events actually exist for that server.
For example:
principal.hostname = "web-server-01"
AND metadata.event_type = "USER_LOGIN"
or:
principal.hostname = "web-server-01"
AND metadata.event_type = "PROCESS_LAUNCH"
or:
principal.hostname = "web-server-01"
AND metadata.event_type = "NETWORK_CONNECTION"
This creates a useful investigation sequence:
server → event type → actor → target → unusual attribute
That sequence is generally more dependable than trying to construct one enormous query immediately.
Understand principal and target before searching
One of the most important concepts in UDM investigation is the distinction between principal and target.
The principal generally represents the entity initiating an activity, while the target represents the entity receiving or being acted upon.
For example, a network connection might contain:
principal.ip
target.ip
A process event might contain information about the process that initiated the activity and the process or object it interacted with.
Authentication events can similarly contain:
principal.user.userid
target.user.userid
This distinction matters because searching the wrong side can produce misleadingly small results.
Suppose you are investigating an account:
target.user.userid = "admin"
That searches for the account being targeted.
If you instead want activity performed by that account, investigate fields under the principal side where appropriate:
principal.user.userid = "admin"
The correct field depends on how the particular event was normalized.
Searching authentication logs
Authentication investigations are a common starting point for server-log analysis.
A broad login search can begin with:
metadata.event_type = "USER_LOGIN"
AND principal.hostname = "web-server-01"
You can then narrow the investigation by account:
metadata.event_type = "USER_LOGIN"
AND principal.hostname = "web-server-01"
AND target.user.userid = "admin"
If the security result records an action, you can investigate blocked events:
metadata.event_type = "USER_LOGIN"
AND security_result.action = "BLOCK"
The useful feature here is that you do not necessarily have to know the original operating-system message. You are searching the normalized representation of the event.
For a server-wide investigation, avoid adding too many assumptions initially. First determine whether the login events are represented as expected, then add username, source IP, hostname, or action filters.
Searching process activity
Process logs are particularly useful when investigating unexpected software execution.
A broad process search might look like:
metadata.event_type = "PROCESS_LAUNCH"
AND principal.hostname = "web-server-01"
You can then search for a particular executable:
metadata.event_type = "PROCESS_LAUNCH"
AND principal.hostname = "web-server-01"
AND target.process.file.full_path = /powershell/
Regular expressions are useful when the exact path varies.
For example:
target.process.file.full_path = /powershell/ nocase
You can also investigate relationships between processes:
metadata.event_type = "PROCESS_LAUNCH"
AND principal.process.file.full_path = /winword/
AND (
target.process.file.full_path = /cmd.exe/
OR target.process.file.full_path = /powershell.exe/
)
The important investigation technique is to search the event relationship, rather than merely searching for a word such as “powershell.”
That distinction reduces noise because the presence of a program name is not necessarily meaningful by itself.
Searching network connections
Network investigations can begin with:
metadata.event_type = "NETWORK_CONNECTION"
AND principal.hostname = "web-server-01"
Then narrow the results using destination information:
metadata.event_type = "NETWORK_CONNECTION"
AND principal.hostname = "web-server-01"
AND target.ip = "203.0.113.25"
You can also investigate destination ports:
metadata.event_type = "NETWORK_CONNECTION"
AND principal.hostname = "web-server-01"
AND target.port = 443
For outbound traffic:
metadata.event_type = "NETWORK_CONNECTION"
AND network.direction = "OUTBOUND"
Combining these conditions allows you to move from “what network activity occurred?” toward questions such as “which server initiated it?”, “where did it connect?”, and “which service was involved?”
Searching HTTP server activity
For web servers, HTTP-specific UDM fields can provide more useful results than searching the raw message.
For example:
metadata.event_type = "NETWORK_HTTP"
AND principal.hostname = "web-server-01"
A response-code investigation might use:
network.http.response_code = 403
You can combine it with the server:
principal.hostname = "web-server-01"
AND network.http.response_code = 403
This is especially useful when investigating repeated authorization failures or unexpected web traffic.
For URLs and user-agent information, regular-expression searches can help when values contain paths, parameters, or other variable content.
Searching DNS activity
DNS searches can help connect a server to external infrastructure.
A basic approach is:
metadata.event_type = "NETWORK_DNS"
AND principal.hostname = "web-server-01"
You can then investigate a particular domain:
metadata.event_type = "NETWORK_DNS"
AND principal.hostname = "web-server-01"
AND target.hostname = "example.com"
If the exact field differs because of the event type or parser, use the available UDM fields exposed by the search interface rather than assuming that every DNS source maps identically.
Combine OR carefully
OR is powerful but can easily make a query much broader than intended.
For example:
target.user.userid = "admin"
OR target.user.userid = "administrator"
means either condition can match.
If you also require a particular server, group the alternatives:
principal.hostname = "web-server-01"
AND (
target.user.userid = "admin"
OR target.user.userid = "administrator"
)
Without parentheses, a query can become logically different from what you intended.
A useful rule is:
Use parentheses whenever an OR condition is being combined with an AND condition.
This makes the query’s intended logic explicit and makes later modifications safer.
Use NOT as an investigation filter
NOT is useful after you understand what normal activity looks like.
For example:
metadata.event_type = "NETWORK_CONNECTION"
AND principal.hostname = "web-server-01"
AND NOT target.port = 443
This removes HTTPS connections from the result set.
However, exclusion filters should generally come later in an investigation. If you exclude something before understanding the dataset, you can accidentally remove evidence that turns out to be relevant.
Search numeric fields directly
Not every useful field is a string.
For example:
target.port = 443
and:
network.http.response_code = 500
use numeric comparisons.
You can also investigate thresholds:
metadata.event_type = "NETWORK_CONNECTION"
AND network.sent_bytes > 10000000
This is more useful than searching for the literal text “10 MB,” because the normalized field contains the numeric measurement.
Use UDM Lookup when you do not know the field
One of the most practical techniques is to use UDM Lookup to discover the field representing the information you want to investigate.
Suppose you know the server produced a particular application name, URL, username, or hostname, but you do not know where that value was normalized.
Searching the available values can reveal the relevant UDM field and provide a starting condition.
This is particularly helpful when moving between different log sources.
However, discovery and investigation are two different tasks.
Once you know the correct field, edit the generated query and make the logic explicit. Do not blindly treat a generated expression as the finished investigation.
When the standard UDM field is not enough
Some log sources contain information that does not map neatly to a standard UDM field.
Custom information can appear in fields such as:
additional.fields
For example:
additional.fields["pod_name"] = "web-frontend"
This is useful in environments where application or infrastructure metadata is carried as key-value information.
You can also test whether a particular key exists:
additional.fields["pod_name"] != ""
This technique can be valuable when investigating containerized workloads, application-specific metadata, or parser-specific fields.
A practical investigation workflow
A repeatable workflow is more valuable than memorizing dozens of queries.
Begin with the server:
principal.hostname = "web-server-01"
Determine the event category:
principal.hostname = "web-server-01"
AND metadata.event_type = "NETWORK_CONNECTION"
Identify the relevant actor:
principal.hostname = "web-server-01"
AND metadata.event_type = "NETWORK_CONNECTION"
AND principal.user.userid = "service-account"
Add the destination:
principal.hostname = "web-server-01"
AND metadata.event_type = "NETWORK_CONNECTION"
AND principal.user.userid = "service-account"
AND target.ip = "203.0.113.25"
Finally, add the characteristic that makes the event interesting, such as a port, protocol, action, process, or response code.
This progressive approach has an important advantage: each additional condition can be validated against the previous result set.
If adding a condition suddenly produces no results, you know exactly which assumption needs investigation.
Why a query returning zero results does not always mean nothing happened
A zero-result query can have several explanations.
The event may genuinely not exist. But it can also mean:
- The event was normalized under a different event type.
- The value was stored in a different UDM field.
- The hostname is represented on the target rather than principal side.
- The log source was not ingesting during the selected time range.
- The original value was transformed during normalization.
- The relevant information exists only in a custom field.
- The query is logically more restrictive than intended.
This is why effective UDM investigation is partly a data-model debugging exercise.
When a query fails, do not immediately make it more complicated. Remove the newest condition and determine whether the broader query produces events.
Build queries for investigation, not just discovery
A good server-log query should answer a specific question.
Instead of:
principal.hostname = "web-server-01"
ask what you actually need to establish:
- Did this server authenticate users?
- Which accounts interacted with it?
- Which processes executed?
- Which destinations did it contact?
- Which HTTP responses occurred?
- Which events were blocked?
- Which activity occurred outside the expected pattern?
Then translate that question into UDM fields.
The most effective UDM searches are therefore not necessarily the longest ones. They are the ones where every condition has an investigative purpose.
The key idea: treat UDM as an investigation language
UDM queries become much easier once you stop treating them as complicated log-search syntax and start treating them as a way of expressing relationships.
Think in terms of:
Who → did what → to what → where → using which protocol/process → with what result?
For a server investigation, that might become:
principal.hostname
→ metadata.event_type
→ principal.user.userid
→ target.ip
→ target.port
→ security_result.action
You can move through those dimensions one at a time.
That method provides more than a way to find matching log lines. It gives you a structured method for reconstructing activity across heterogeneous server telemetry.
The real value of UDM searching is therefore not the ability to write increasingly complex queries. It is the ability to start with an uncertain question, identify the relevant normalized evidence, test each assumption, and progressively turn a large collection of server events into a defensible sequence of observations.