Skip to end of banner
Go to start of banner

opEvents Event Panels

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Overview

opEvents panels are customisable views that allow you to create filtered perspectives of your event data. Each panel appears as an option in the Panels dropdown menu in the opEvents interface, giving users quick access to their specialised event views.

image (1).png

Configuration Location and Structure

Panels are configured in the /usr/local/omk/conf/ConfigPanels.json file. This file contains a JSON object where each key represents a unique panel configuration. You can define multiple panels within this single configuration file, and they will all appear in the Panels dropdown menu in the order they're defined.

This file will not exist on a fresh install.

Basic Structure

{
    "panel-identifier-1": {
        "title": "First Panel",
        "description": "Description of first panel",
        "model": "events",
        "filter": {
            "field": "filter_expression"
        }
    },
    "panel-identifier-2": {
        "title": "Second Panel",
        "description": "Description of second panel",
        "model": "events",
        "filter": {
            "field": "filter_expression"
        }
    }
}

For example a panel with the name panel-identifier-1 will create a /omk/opEvents/panels/panel-identifier-1

Schema Fields Reference

Field

Type

Required

Description

title

string

Yes

The display name of the panel shown as the title

description

string

Yes

Description of the panel shown in navigation

model

string

Yes

Data model to use (currently "events")

filter

object

Yes

Collection of field:filter_expression pairs

table_schema

string

No

If you wish to use custom table schema

Customising Table Schemas

Filter Expressions

The filter object supports several types of matching, giving you flexibility in how you filter your events. You can choose the matching method that best suits your needs:

Simple String Matching

For straightforward matches, simply provide the string you want to match:

{
    "node-down-events": {
        "title": "Node Down Events",
        "description": "Shows all node down events",
        "model": "events",
        "filter": {
            "event": "Node Down"
        }
    }
}

Regular Expression Matching

When you need more complex pattern matching, you can use the regex: or iregex: prefixes:

  • regex: - Case-sensitive regular expression matching

  • iregex: - Case-insensitive regular expression matching

Example combining both simple and regex matching:

{
    "sydney-critical": {
        "title": "Sydney Critical Events",
        "description": "Critical events from Sydney data centres",
        "model": "events",
        "filter": {
            "nodeinfo.configuration_location": "Sydney",       // Simple string match
            "event": "iregex: (error|failure|outage)",         // Case-insensitive pattern match
            "nodeinfo.configuration_role": "regex: server|router|switch"   // Regex match
        }
    }
}

Filter Matching Tips

When to Use Simple String Matching

  • Exact value matches (e.g., state = "Up")

  • Specific locations (e.g., nodeinfo.configuration_location = "Melbourne")

When to Use Regular Expressions

  • Matching multiple possible values (e.g., regex: Error|Warning|Critical)

  • Pattern matching (e.g., regex: Node[0-9]+Down)

  • Case-insensitive searches (e.g., iregex: sydney|melbourne|brisbane)

  • Complex text patterns (e.g., regex: ^SYD-[A-Z]{2}-[0-9]{3}$)

Choose the simplest matching method that meets your needs. Simple string matching is more straightforward to understand and maintain, so use it when possible. Save regular expressions for when you need their pattern-matching power.

  • No labels