Bug 1287512 - RFE : Aggregating System Events in the Logging System [NEEDINFO]
RFE : Aggregating System Events in the Logging System
Status: NEW
Product: OpenShift Container Platform
Classification: Red Hat
Component: RFE (Show other bugs)
3.4.1
Unspecified Unspecified
high Severity medium
: ---
: ---
Assigned To: Gregg Tanzillo
Dave Johnson
: FutureFeature, OpsBlocker
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-12-02 04:06 EST by Miheer Salunke
Modified: 2017-08-10 12:49 EDT (History)
23 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
gtanzill: needinfo? (jhardy)


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 2300931 None None None 2017-01-19 20:39 EST

  None (edit)
Description Miheer Salunke 2015-12-02 04:06:33 EST
1. Proposed title of this feature request  
Event console per user

3. What is the nature and description of the request?  
The openshift console does a pretty good job in showing us the events that took place for a given project. However, we need to inspect it to see them and there is no history available.
  
4. Why does the customer need this? (List the business requirements here)  
In order to provide a proper service for a large infrastructure, we need to react to important events. We cannot monitor the console continuously, so a list per user would be helpfull (we don't need to click all projects)

5. How would the customer like to achieve this? (List the functional requirements here)  
* gather the data for all projects a user has access to and list it into a single flow (with indication per project)
* it would be practical as well to have some colors associated with the events (green for things that worked like "pulled image", red for the events signalling things that went wrong "can't pull image")
  
6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.  
* trigger the events and check they are present in the user's view
  
7. Is there already an existing RFE upstream or in Red Hat Bugzilla?

What information can you provide around timeframes and urgency?

8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)?  
OpenshiftEnterprise 3.x
    
10. List any affected packages or components.  
OpenshiftEnterprise 3.x
  
11. Would the customer be able to assist in testing this functionality if implemented? 
Yes.
Comment 2 Jessica Forrester 2016-04-13 14:09:30 EDT
It sounds like there are two things being asked for here:
1) Historical events - Events have a short lifespan today, their default lifespan is 2 hours, and they aren't intended for historical tracking. Having historical events would be more than just a change to the console.

2) Cross-project list of events - There is no roll-up API across projects, we would have to first fetch the list of all projects you have access to, which could be a lot, and then make an api request for each project to get the events for that project.  If you wanted to continuously update the list of events then you could be maintaining quite a few open watch connections if you had a lot of projects.

If the goal is to monitor your projects for problems, I can see a lot of value in having a rollup of warnings occurring across your projects.  But we will need API support for it.
Comment 3 Eric Rich 2016-04-13 16:33:16 EDT
(In reply to Jessica Forrester from comment #2)
> It sounds like there are two things being asked for here:
> 1) Historical events - Events have a short lifespan today, their default
> lifespan is 2 hours, and they aren't intended for historical tracking.
> Having historical events would be more than just a change to the console.
> 
> 2) Cross-project list of events - There is no roll-up API across projects,
> we would have to first fetch the list of all projects you have access to,
> which could be a lot, and then make an api request for each project to get
> the events for that project.  If you wanted to continuously update the list
> of events then you could be maintaining quite a few open watch connections
> if you had a lot of projects.
> 
> If the goal is to monitor your projects for problems, I can see a lot of
> value in having a rollup of warnings occurring across your projects.  But we
> will need API support for it.

Is this something better suited for CloudForms? In short I think its better for Cloudforms to periodically to collect our events (hourly) or listen for events (listen on the message bus - I know v3 does not have such a bus) and record the events, our events as a Timeline (https://access.redhat.com/documentation/en/red-hat-cloudforms/version-4.0/monitoring-alerts-and-reporting/#sect_timelines)
Comment 5 ewolinet 2016-04-27 14:02:27 EDT
It might be worth investigating having Fluentd collect the etcd events in some manner and storing them as part of the Operations logs within Elasticsearch.
Comment 18 Eric Rich 2017-06-30 06:16:55 EDT
Is https://github.com/heptio/eventrouter a solution for this?

Note You need to log in before you can comment on or make changes to this bug.