openshift/eventrouter

A simple introspective kubernetes service that forwards events to a specified sink.

View on GitHub ↗Jump to charts ↓

Summary Information

Updated 29 minutes ago
Added to GitGenius on June 23rd, 2023
Created on September 5th, 2017
Open Issues & Pull Requests: 1 (+0)
Number of forks: 42
Total Stargazers: 68 (+0)
Total Subscribers: 178 (+0)

Repository Insights (GitGenius)

Most active contributors

Sign in to see contributor activity.

Related repositories by overlapping contributors

No overlapping-contributor repos identified yet.

Charts & Analytics

Fetching additional details & charts...

Issue Activity (beta)

Open issues: 0
New in 7 days: 0
Closed in 7 days: 0
Avg open age: N/A days
Stale 30+ days: 0
Stale 90+ days: 0

Recent activity

Opened in 7 days: 0
Closed in 7 days: 0
Comments in 7 days: 0
Events in 7 days: 0

Top labels

No label distribution available yet.

Most active issues this week

No issue events were indexed in the last 7 days.

Detailed Description

Eventrouter is a Kubernetes service that forwards cluster events to a specified sink.

The tool solves the problem of event persistence and analysis in Kubernetes clusters. By default, Kubernetes only retains events for a limited time, making it difficult to perform long-term behavioral analysis or debugging of workloads. Eventrouter actively watches the event resource in the Kubernetes system and pushes those events to a user-specified sink, enabling operators to forward events to external systems for archiving, machine learning, introspection, or other purposes. The service is designed to be relatively low overhead and supports configuration of multiple sinks.

Eventrouter suits operators who need to retain and analyze Kubernetes events beyond the cluster's default retention window. It works well for teams using existing EFK (Elasticsearch, Fluentd, Kibana) stacks, as it outputs wrapped JSON objects designed for easy indexing in Elasticsearch. The tool is appropriate for any cluster where long-term event analysis, debugging, or integration with external monitoring and logging systems is required. The project explicitly does not provide query capabilities or serve as a storage layer; those responsibilities belong to the sink system receiving the forwarded events.

The project maintains a straightforward, focused codebase written in Go. Development activity shows consistent engagement with the core functionality of event watching and forwarding, with attention to supporting multiple sink configurations and maintaining low operational overhead.