Skip to main content
Version: 1.3.0

Case

Control Flow Conditional Logic

Assigns values to a field based on conditional case statements, similar to switch-case logic or SQL CASE expressions.

Schema​

- case:
    field: <ident>
    cases:
      - condition: <script>
        value: <any>
    default: <any>
    description: <text>
    if: <script>
    ignore_failure: <boolean>
    ignore_missing: <boolean>
    on_failure: <processor[]>
    on_success: <processor[]>
    tag: <string>

Configuration​

The following fields are used to define the processor:

FieldRequiredDefaultDescription
fieldY-Target field to set the result value
casesY-Array of condition-value pairs to evaluate
cases.conditionY-Condition expression to evaluate
cases.valueY-Value to set if condition is true (supports templates)
defaultN-Default value if no cases match (supports templates)
descriptionN-Explanatory note
ifN-Condition to run processor
ignore_failureNfalseContinue if processor fails
ignore_missingNfalseContinue if source fields don't exist
on_failureN-Processors to run on failure
on_successN-Processors to run on success
tagN-Processor identifier

Details​

Cases are evaluated in the order they appear, with the first matching condition winning and processing stopping at that point (short-circuit evaluation). Both case values and default values support template expressions, allowing for dynamic value assignment based on other fields.

Values can be strings, numbers, booleans, or complex objects, providing flexibility in the types of data that can be assigned. If no cases match and no default is provided, the target field is not set. Conditions use the same expression syntax as other conditional processors in the system.

This processor is particularly effective for log classification, categorizing log entries based on severity, type, or content characteristics. It excels at status mapping by converting numeric codes to descriptive text and supports risk assessment by assigning risk scores based on multiple factors.

The processor is also valuable for user classification, categorizing users based on roles, departments, or permissions, and enables alert prioritization by setting alert levels based on event characteristics. Additionally, it supports data normalization by standardizing field values across different log sources, ensuring consistency in data processing pipelines.

Examples​

Log Levels​

Mapping log levels to severity categories...

{
  "log": {
    "level": "ERROR"
  }
}
- case:
    field: severity
    cases:
      - condition: "log.level == 'ERROR' || log.level == 'FATAL'"
        value: "high"
      - condition: "log.level == 'WARN'"
        value: "medium"
      - condition: "log.level == 'INFO' || log.level == 'DEBUG'"
        value: "low"
    default: "unknown"

assigns appropriate severity level:

{
  "log": {
    "level": "ERROR"
  },
  "severity": "high"
}

Status Codes​

Categorizing HTTP response codes by range...

- case:
    field: response_category
    cases:
      - condition: "http.response.status_code >= 200 && http.response.status_code < 300"
        value: "success"
      - condition: "http.response.status_code >= 300 && http.response.status_code < 400"
        value: "redirect"
      - condition: "http.response.status_code >= 400 && http.response.status_code < 500"
        value: "client_error"
      - condition: "http.response.status_code >= 500"
        value: "server_error"
    default: "invalid"

Template Values​

Using template expressions in case values for dynamic messages...

{
  "event": {
    "severity": "critical",
    "description": "High CPU usage",
    "type": "system"
  },
  "host": {
    "name": "web-server-01"
  }
}
- case:
    field: alert_message
    cases:
      - condition: "event.severity == 'critical'"
        value: "CRITICAL ALERT: {{event.description}} from {{host.name}}"
      - condition: "event.severity == 'warning'"
        value: "Warning: {{event.description}}"
      - condition: "event.severity == 'info'"
        value: "Info: {{event.type}}"
    default: "Unknown event: {{event.type}}"

generates formatted alert message:

{
  "event": {
    "severity": "critical",
    "description": "High CPU usage",
    "type": "system"
  },
  "host": {
    "name": "web-server-01"
  },
  "alert_message": "CRITICAL ALERT: High CPU usage from web-server-01"
}

Complex Logic​

Multi-factor risk scoring with complex conditions...

- case:
    field: risk_score
    cases:
      - condition: "threat.score > 80 && user.is_admin == true"
        value: 100
      - condition: "threat.score > 80"
        value: 90
      - condition: "threat.score > 50 && network.external == true"
        value: 75
      - condition: "threat.score > 50"
        value: 60
      - condition: "threat.score > 20"
        value: 30
    default: 10

User Types​

Categorizing users based on roles and attributes...

- case:
    field: user_category
    cases:
      - condition: "user.roles contains 'admin'"
        value: "administrator"
      - condition: "user.roles contains 'developer' || user.roles contains 'engineer'"
        value: "technical"
      - condition: "user.department == 'security'"
        value: "security_team"
      - condition: "user.is_external == true"
        value: "external_user"
    default: "standard_user"