As a user of `kn` I should be able to retrieve the logs from a service

[maximilien]

Current users can access the logs from a service using kubectl logs service-pod-name where service-pod-name is the name for the pod for the service, assuming it has one.

However, since services scale to 0, their pods may no longer exist. This means having a way to access logs as they run and previous recorded logs may be useful.

So to start, I suggest we expose:

kn logs service-name -n namespace
...

That returns the logs from the service's current pod(s), assuming any. I would scope this to services that have not scale to 0 for now since lots of options could be added. Following kubectl, we could contemplate the following additional options:

1. --tail and --tail=n to tail the log and to return the last n lines
2. --since=1h to return logs in the past 1 hour
3. --follow to follow the log as a stream

Thoughts?

[maximilien]

Adding this to separate from #141 which is more for debugging and maintenance.

[rhuss]

I think showing logs make much sense, but wouldn't you look into the revisions logs, not service logs ?

The logs should probably obtained over the provided logUrl, but I have no idea, how these can be routed to the outside. Picking up logs directly from the pods would be difficult as they have to be merged timewise which is probably impossible. For --follow this could be achieved by merging the returned responses as they come in, but not for logging that happened in the past.

Looking into a local Knative installation, I see a logUrl like http://localhost:8001/api/v1/namespaces/knative-monitoring/services/kibana-logging/proxy/app/kibana#/discover?_a=(query:(match:(kubernetes.labels.knative-dev%2FrevisionUID:(query:'358a98 │ f7-8073-11e9-90f3-ba25ff564f41',type:phrase)))), so I wonder how this could be used from the outside of the cluster and not through an Istion service mesh.

[rhuss]

Just thought again. We definitely can't pick up logs from the Pods as we would have to access the K8s API directly to obtain those (and that's not allowed in the context of kn which is agnostic of K8s).

I'm afraid the only solution, for now, is to show that log URL with kn as we don't know anything about the REST API to access the log, and not e.g. how to authenticate.

[maximilien]

Could we --follow the log URL?

[sixolet]

The log URL has no guarantees about what it'll do, right now. For example, in Cloud Run, it's a link to stackdriver, which is a whole log-reading interface.

Furthermore, as @rhuss mentions, the auth to the logs could be completely different from the auth to the k8s master.

If we want a good command line, the serving folks need to do a little definition work about what goes in the URL in question.

[rhuss]

Could we --follow the log URL?

For which Pod ? These are scaled up, down. And we would still need to access the k8s API directly for this (a no go in the context of kn)

[rhuss]

If we want a good command line, the serving folks need to do a little definition work about what goes in the URL in question.

Completely agreed, there needs to be some better API support from serving for getting to the logs.

[duglin]

Yep, I would suggest that there be a "logs" API on KnServices that's pluggable so each provider can figure out how to get the logs from where ever they store the logs (be that in the pods or some persistence).

[rhuss]

There's a discussion over there at https://github.com/knative/observability/issues/32 which is exactly about our use case.

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Reopen the issue with /reopen. Mark the issue as fresh by adding the comment /remove-lifecycle stale.

[maximilien]

Closing this. There are other ways to retrieve and follow logs.