Improving logging level for "not found" log message

[xinfengliu]

Description

Currently the logging level for for "not found" log message is error level. E.g.

Jan 23 20:33:17 localhost dockerd: time="2022-01-23T20:33:17.023933784Z" level=error msg="Error getting service <service-name>: service <service-name> not found"

This is regarded as spam logs if an application periodically checks the existence of that service to determine the next steps, in this case, "the service does not exist" is not a real error for users.

Is it possible to change the logging level to info for this kind of log messages?

Reproduce

1. docker service inspect non-existing-service
2. check docker daemon logs.

Expected behavior

No response

docker version

Client: Docker Engine - Community
 Version:           20.10.16
 API version:       1.41
 Go version:        go1.17.10
 Git commit:        aa7e414
 Built:             Thu May 12 09:19:22 2022
 OS/Arch:           linux/arm64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.17
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.17.11
  Git commit:       a89b842
  Built:            Mon Jun  6 23:00:41 2022
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          1.6.6
  GitCommit:        10c12954828e7c7c9b6e0ea9b0c02b01407d3ae1
 runc:
  Version:          1.1.2
  GitCommit:        v1.1.2-0-ga916309
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

docker info

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Docker Buildx (Docker Inc., v0.8.2-docker)
  compose: Docker Compose (Docker Inc., v2.5.0)

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 13
 Server Version: 20.10.17
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: active
  NodeID: b1v407d5gvfayxd1w1vrfl628
  Is Manager: true
  ClusterID: zpxv6kidrdhea3s40v5360whs
  Managers: 1
  Nodes: 1
  Default Address Pool: 10.0.0.0/8  
  SubnetSize: 24
  Data Path Port: 4789
  Orchestration:
   Task History Retention Limit: 5
  Raft:
   Snapshot Interval: 10000
   Number of Old Snapshots to Retain: 0
   Heartbeat Tick: 1
   Election Tick: 10
  Dispatcher:
   Heartbeat Period: 5 seconds
  CA Configuration:
   Expiry Duration: 3 months
   Force Rotate: 0
  Autolock Managers: false
  Root Rotation In Progress: false
  Node Address: 192.168.64.3
  Manager Addresses:
   192.168.64.3:2377
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 10c12954828e7c7c9b6e0ea9b0c02b01407d3ae1
 runc version: v1.1.2-0-ga916309
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 5.15.0-27-generic
 Operating System: Ubuntu 22.04 LTS
 OSType: linux
 Architecture: aarch64
 CPUs: 2
 Total Memory: 1.921GiB
 Name: ub2204-1
 ID: NE3Y:POXM:GQW6:PWQZ:36IY:T2K6:DQJM:S4A7:MPVF:NA5E:EZYX:ND44
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
  cicd=true
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

Additional Info

No response

[corhere]

The offending code:

moby/api/server/router/swarm/cluster_routes.go

Lines 195 to 199 in c910e47

	service, err := sr.backend.GetService(vars["id"], insertDefaults)
	if err != nil {
	logrus.Errorf("Error getting service %s: %v", vars["id"], err)
	return err
	}

swarm/cluster_routes.go is the only file in the api/server/router tree which logs errors before returning them to the client. Given that precedent those log messages definitely shouldn't exist, let alone be logged at Error level. If they are kept, I'd go further than Info and demote the logs' level all the way down to Debug.

[thaJeztah]

Yes, debug would probably be fine for this.

Probably quite off-topic (and orthogonal), but I'm almost inclined to remove (some of? haven't looked what other logs there are) these altogether. That said, at times when debugging, I would've loved for an option that logged both requests and responses (or at least status of responses). Wondering if something like that could be part of (or similar to);

moby/api/server/middleware/debug.go

Line 17 in b8b68e6

func DebugRequestMiddleware(handler func(ctx context.Context, w http.ResponseWriter, r *http.Request, vars map[string]string) error) func(ctx context.Context, w http.ResponseWriter, r *http.Request, vars map[string]string) error {