Bug 1472060

Are you asking for a link to view logs for a particular project, or a completely top level link that shows all of the projects?

> Are you asking for a link to view logs for a particular project, or a completely top level link that shows all of the projects?

I think later (completely top level link) is better.

Let me explain the reason. Currently if we go to kibana console from "app1" pod in "p1" project, kibana will search:

  'kubernetes.pod_name:"app1" AND kubernetes.namespace_name:"p1"'

and kibana does NOT allow us to view any apps's logs in other project (even same user's). In other words, if same user has a "p2" project, we have to route through a pod in "p2" project. So, I think completely top level link could provide users with more flexible search in kibana.

The link provided from the web UI is simply a convenience to retrieve pod logs.  You can manually select the namespace for a different project to which you have access; there is nothing restricting you from doing that.  You can set up mappings to your indexes through the settings tab of Kibana which will allow you to query any namespace.  The plugins that are included in the logging stack will set up mappings for all your projects by default when you first log in.  The only known issue is trying to query logs from pods in multiple namespaces.  Our design needs to change to allow that to be possible.

> The link provided from the web UI is simply a convenience to retrieve pod logs.  You can manually select the namespace for a different project to which you have access; there is nothing restricting you from doing that.

If we accessed kibana (logs.ded-stage-aws.openshift.com) directory, it does NOT allow me to search *any* logs due to "Discover: [security_exception] no permissions for indices:data/read/msearch". Then, I heard that it is because we have to access to the kibana via OpenShift webconsole as OpenShift set the proper cookies[1]. That's why I am asking you to add link to the OpenShift webconsole.

> You can set up mappings to your indexes through the settings tab of Kibana which will allow you to query any namespace.  The plugins that are included in the logging stack will set up mappings for all your projects by default when you first log in.

So, this will fix the "no permissions for indices:data/read/msearch" error, which I mentioned above? I have tried it, but didn't work. Could you please tell us one of the example index settings which should work?

[1] http://post-office.corp.redhat.com/archives/rhose-prio-list/2017-July/msg00063.html
"Unless OpenShift has set the proper cookies in the browser used to load the Kibana web pages, you won't have proper access to view logs.  The only reliable way to view logs is to go to kibana from the console page."

@Jessica if the logging side issue is that user cannot view multiple namespaces, could you please add a link to view logs for a particular project?

As I mentioned in the first comment, current operation to view kibana console "webconsole->Applications->pod->Logs->View Archive->Kibana" gets admin users frustrated.

Yes, adding a link for logs in a particular project makes sense to me.

Jeff, is it possible for the web console to provide this link? What would the URL need to be?

This is the template we're using currently for pod logs.

https://github.com/openshift/origin-web-console/blob/master/app/scripts/services/logLinks.js#L57-L82

(In reply to Kenjiro Nakayama from comment #4)

> If we accessed kibana (logs.ded-stage-aws.openshift.com) directly, it does
> NOT allow me to search *any* logs due to "Discover: [security_exception] no
> permissions for indices:data/read/msearch". Then, I heard that it is because
> we have to access to the kibana via OpenShift webconsole as OpenShift set
> the proper cookies[1]. That's why I am asking you to add link to the
> OpenShift webconsole.
> 
This exception is misleading and is not really a security exception.  You will see this issue if no logs are available for the project.  This means there are no indices in Elasticsearch that have the pattern 'project.<PROJECTNAME>.<DATEPATTERN>'.  The security plugin we use is unable to find metadata for the index in question and instead of returning a 404 improperly throws a security exception.  This fix was added with https://bugzilla.redhat.com/show_bug.cgi?id=1456413 and is available in v3.6.126-2 or greater. We have additionally backported to previously releases depending upon what version online is using.  



> > You can set up mappings to your indexes through the settings tab of Kibana which will allow you to query any namespace.  The plugins that are included in the logging stack will set up mappings for all your projects by default when you first log in.
> 
> So, this will fix the "no permissions for indices:data/read/msearch" error,
> which I mentioned above? I have tried it, but didn't work. Could you please
> tell us one of the example index settings which should work?

This referance change additionally brings in logic that only creates mappings for your projects which also have at least 1 index in Elasticsearch.  If you are unable to access your logs, it is most likely that there are no logs to access.



(In reply to Samuel Padgett from comment #6)
> Yes, adding a link for logs in a particular project makes sense to me.
> 
> Jeff, is it possible for the web console to provide this link? What would
> the URL need to be?
> 
We need to make this easier since the console is dependent on kibana specific fields.  The URL to my project is like [1].  Looking at your code I think we would need to only remove the 'container' info since we would not have a specific container.

[1] https://kibana.192.168.122.61.nip.io/app/kibana#/discover?_g=(refreshInterval:(display:Off,pause:!f,value:0),time:(from:now-15m,mode:quick,to:now))&_a=(columns:!(_source),index:'project.logging.4e2bc514-7884-11e7-b5af-52540050d5ea.*',interval:auto,query:(query_string:(analyze_wildcard:!t,query:'*')),sort:!('@timestamp',desc))

We have provided a top-level Kibana link since 4.1. I believe this bug has since been addressed. Feel free to reopen if that is not sufficient or you're looking for something else. Thanks!