[Feature] Add support for logs via API about faasd

[alexellis]

From @estesp (containerd maintainer):

...this might help.. you could even track this back to a higher level as there is a CRI command to get logs (e.g. crictl logs ..) that I assume ends up being implemented by this feature of attaching writers to the containerd container IO impl. https://github.com/containerd/cri/blob/c23ed3befc08b3b85ea3fb50c6c99330871e9295/pkg/server/io/container_io.go#L204

There is also a logger impl in that same package that is how the CRI plugin actually writes out to log files, which could be done in your client as well: https://github.com/containerd/cri/blob/c23ed3befc08b3b85ea3fb50c6c99330871e9295/pkg/server/io/logger.go

[alexellis]

CRI appears to store logs on disk: https://www.youtube.com/watch?v=cudJotS97zE

[alexellis]

crictl logs -> https://github.com/kubernetes-sigs/cri-tools/blob/86dfb0fd89eeda5e34ee3cb89ded812dc74d5ff0/vendor/k8s.io/kubernetes/pkg/kubelet/kuberuntime/logs/logs.go#L272

[alexellis]

Here's an example of using the CRI logging code to write to a file, from a ping process started outside of a container. It should be possible to hook it up to the container from containerd.

https://gist.github.com/alexellis/f232fe1fd2fe5278d411732af2645d79

The issue I see is that if faasd restarts, we'll lose the logs of the process since the io/copy is done in the parent.

At a guess (I may be wrong) - we need to fork a separate long-running process after starting the container to copy the log streams, or have that process start the container. This feels like a lot of indirection and "janky". I would like to get more input from those in the know.

Is this ☝️ something that containerd can do via options and manage in its daemon?

The lifecycle for cri's log handling isn't entirely clear - https://github.com/containerd/cri/blob/9d60f9c56ea34166660e89c0a811e2869e0dcfeb/pkg/server/container_start.go#L86 (this is part of a package called "server")

[alexellis]

K8s logging architecture - https://kubernetes.io/docs/concepts/cluster-administration/logging/#logging-at-the-node-level "Everything a containerized application writes to stdout and stderr is handled and redirected somewhere by a container engine" 🤔

[alexellis]

Further example (albeit an old one) from @crosbymichael - containerd/containerd#3085

[nanikjava]

If you kill faasd from command using

sudo ps aux | grep -i faas | awk '{print $2}' | sudo xargs kill -9

you will see the containers are still running using the command

sudo ./ctr tasks ls

following is what I see on my machine (Linux Ubuntu 19.04)

TASK                 PID     STATUS    
gateway              3032    RUNNING
queue-worker         3222    RUNNING
basic-auth-plugin    2620    RUNNING
nats                 2728    STOPPED
prometheus           2850    RUNNING

only the nats container is stopped while the rest is running.

Using the command

sudo ./ctr tasks attach gateway

able to attach to the container 'gateway' and the log is streamed.

Is this the behaviour you looking for ?

[alexellis]

We have logs now via #50 - they are recorded via the systemd journal, but not queried back via the API.

This package may be of help/use:

https://github.com/coreos/go-systemd/blob/a4887aeaa186e68961d2d6af7d5fbac6bd6fa79b/sdjournal/read.go#L67

[alexellis]

This issue is about implementing the logs handler for log retrieval (pending) and also for log recording (that part is completed now) cc @LucasRoesler as mentioned on Slack https://openfaas.slack.com/archives/C1D32GFS8/p1582487994062300

[alexellis]

I would like to avoid any dependency on CGO as this will create issues when deploying to different OSes. sdjournal seems to take a hard dependency on it.

[alexellis]

Orbit by @ehazlett execs journalctl, that may be the reason why.

https://github.com/stellarproject/orbit/blob/45483b663600e92c8de516a127c0ed13ec5268be/cmd/ob/log.go

[LucasRoesler]

Does that mean that exec is ok then?

[alexellis]

We used exec here, thank you @LucasRoesler for your work on the feature. Closing the issue.