有效的管理以及调试应用的关键所在，是去理解Docker容器的日志位置。能够掌握怎样查找以及分析这些日志，这会有助于开发者迅速定位问题、留意监控应用状态进而优化性能。本文会详细讲解介绍Docker日志的存储机制，还展示查看方法以及管理方面的最佳实践。
Docker容器日志默认存储在哪
存储在宿主机特定目录里的，是那个Docker容器日志的默认情况。其具体的路径，一般情形下是 /var/lib/docker/containers/ ，这里可体现为是这样一种特定的存放目录所在之处的路径标注状态了。 。在 / 这个目录下面，每一个容器皆是有着一个与它相对应的 JSON 日志文件，其名称是被叫做 。<容器ID>- 名为-json.log的文件，它是日志文件，它记录了容器的标准输出，它记录了容器的标准错误流 。
通过 docker inspect 命令，你能够找到容器的完整ID，借此定位到日志文件。然而，直接对这些原始日志文件进行操作，通常并非最佳实践，鉴于日志会持续增长。Docker daemon承担着管理这些日志的职责，默认运用 json-file 日志驱动，把所有输出写入该JSON文件。知晓这个默认位置，是展开日志管理的首要步骤 。
<strong>如何通过Docker命令查看容器日志</strong>
有这样一种最为直接的查看方式，那便是运用 docker logs 这一命令。比如说，去执行 docker logs [容器名或ID] 这个操作，能够实现实时查看该容器的全部日志输出。这种方式对于调试正在运行着的应用而言是极为便利的。除此之外docker 容器日志在哪，你还能够额外添加上 -f 这个参数，以此来实时跟踪日志的最新动态，其效果类似于 tail -f 。
docker logs命令有着其他实用选项的支持，它的支持情况是这样的，比如说，使用--tail这个选项能够指定到底显示最后多少行日志，使用--since这个选项可以显示某个时间点之后的日志，使用-t这个选项能够为每行日志加上时间戳。这些命令工具，是在不直接去访问日志文件的情形之下，进行日常查看以及问题诊断的首选方法。
<strong>Docker日志驱动有哪些类型</strong>
Docker对多种日志驱动予以支持，这种支持状况决定了日志的输出目的地，还决定了日志的处理方式。以默认的 json-file 驱动为例，它会把日志写入到宿主机的文件之中。除此之外，存在这样一些常用的驱动，其中 journald 驱动会将日志发送到系统的systemd journal，syslog 驱动会把日志发送到远程syslog服务器，而 none 驱动则是用于禁用任何日志记录的。
于生产环境里，json -- file 会因日志轮转以及清理策略不合适致使磁盘被占满。所以，好多团队会挑选 syslog 或者 journald 去集中管理日志，又或者运用 awslogs、gcplogs 等云服务商所提供的驱动，径直把日志推送到云端日志服务。驱动类型能够在启动容器之际借助 --log -- driver 参数予以指定。
<strong>如何配置Docker容器的日志选项</strong>
可以在容器运行的时候进行配置日志选项，比如说，使用 --log-opt 参数能够设置特定驱动的选项，对于默认的 json-file 驱动而言所具有的重要选项涵盖了 max-size（也就是单个日志文件的最大大小）以及 max-file（是保留的日志文件最大数量），如此这般能够有效地防止日志出现无限增长的情况 。
有一个常见的启动命令示例linux系统命令，它是这样的：docker run --log-driver json-file --log-opt max-size=10m --log-opt max-file=3 my-app。这条命令对每个日志文件的最大大小进行了限定，限定为10MB，并且最多保留3个文件，这里要说明一下，达到上限后会进行轮转操作，也就是删除最旧的文件。依据应用日志量的大小情况，合理地配置这些参数docker 容器日志在哪，这是运维工作的基本内容。
<strong>怎样清理Docker容器占用的磁盘日志</strong>
当因日志文件数量过多致使磁盘空间不够用时，就得手动去清理。直接将 /var/lib/docker/containers/ 下面的日志文件给删除是具有可行性的，不过在进行操作之前应当先把对应的容器停下来，或者要保证应用能够承担日志中断所带来的风险。更为安全的一种做法是对日志驱动作出配置来实现自动轮转，就像前文所提及的 max-size 和 max-file 选项那样。
能够运用 docker system prune 命令，去清除全部处于停止状态的容器，处于未被使用状态的网络，以及悬空着的镜像。把 -a 以及 --volumes 添加进去，则能够清理得更为彻底，不过要慎重。周期性地监视 /var/lib/docker 目录的大小，并且构建日志清理规范，这是维系系统健康运行的必要举措。
<strong>生产环境中如何集中管理容器日志</strong>
于生产环境里，容器规模既庞大又处于动态变化状态，此时集中式日志管理显得极为关键重要。平常常见的方案乃是采用EFK（也就是Elasticsearch、Fluentd、Kibana）或者ELK（也就是Elasticsearch、Logstash、Kibana）技术栈。其核心在于运用一个日志收集器，比如Fluentd，对Docker进行配置linux手机，使之使用 json-file 或者 syslog` 驱动，接着由该收集器从宿主机那边读取日志文件，要么直接接收日志流，最终将其转发至Elasticsearch去进行存储以及索引。
还有一种简便的做法，是运用Docker原本的日志驱动，把日志直接传送到云服务，像AWS CloudWatch这样。这使得自建基础设施的复杂度降低了。不管采用哪一种方案，目标都是达成日志的聚合、搜索、可视化告警，进而提高运维效率以及问题响应速度。
在实际工作期间，你是更倾向于选用Docker原生命令去开展日志调试工作，还是已然构建起了完备的日志集中管理平台？欢迎于评论区对自身经验以及所遭遇的挑战予以分享，要是本文对你具备一定帮助的话，也请进行点赞操作并且分享给更多有相应需求的伙伴。
