cmd/log-parser: Add containerID to list of standard fields

[jodh-intel]

Once kata-containers/runtime#453 lands, we should be able to add containerID as a standard field in the kata-log-parser tool.

The complication will be ensuring it handles the proxy which will not provide the containerID for all log entries (namely, the logs coming direct from the proxy as opposed to the agent output it also handles).

[jodh-intel]

Hi @bergwolf, @sboeuf, @grahamwhaley - I've got a branch that captures the containerID [1], but I'm wondering whether the log parser should also capture the sandboxID. If it did, we would be closer to being able to associate a group of log entries with an individual container (as the group would contain all the container-specific log entries + log entries associated with the containers "parent" sandbox).

There are of course quite a few log entries across the system that are not associated with any container/sandbox. But looking through https://github.com/kata-containers/agent/blob/master/protocols/grpc/agent.proto I noticed a few points:

• All container-related APIs specify a container_id field (which is useful :)
• None (well neither strictly :) of the sandbox APIs specify a corresponding sandbox_id field
• None of the networking/CPU/Memory API calls specify a sandbox_id field.

To summarise, the following gRPC services are not associated with a container or a sandbox (from the perspective of the logs):

// networking
rpc AddInterface(AddInterfaceRequest) returns(Interface);
rpc UpdateInterface(UpdateInterfaceRequest) returns (Interface);
rpc RemoveInterface(RemoveInterfaceRequest) returns (Interface);
rpc UpdateRoutes(UpdateRoutesRequest) returns (Routes);

// misc (TODO: some rpcs can be replaced by hyperstart-exec)
rpc CreateSandbox(CreateSandboxRequest) returns (google.protobuf.Empty);
rpc DestroySandbox(DestroySandboxRequest) returns (google.protobuf.Empty);
rpc OnlineCPUMem(OznlineCPUMemRequest) returns (google.protobuf.Empty);

Clearly, they don't strictly need to be (as the system works :). However, for consistency and to allow us to improve our tracing, I wonder if we should consider adding a sandbox_id to each of the above?

---

[1] - It also picks out the container ID from the agent gRPC trace generated by https://github.com/kata-containers/agent/blob/master/agent.go#L585.

[grahamwhaley]

+1 from me. I think being able to associate actions and commands in the logs with the relevant container and/or sandbox is pretty critical to our debug - particularly when we start to run in to multi-pod and parallelism bugs.

[sboeuf]

+1 from me !

[jodh-intel]

I've just realised that we don't need to pass the sandbox ID over the wire as we can tell the agent the sandboxID at agent startup by adding something like a kata-sandbox=$sandbox kernel command-line option.

[jodh-intel]

#453 (comment) is resolved by
kata-containers/agent#292 and kata-containers/runtime#466.