普通容器的日志，采用nas更好还是日志分析平台直接收集更好？

首先，我们应该明确一下理解和认知。

a、普通容器日志，应该是指应用服务本身在容器中运行正常输出的应用自身日志。
b、NAS是给容器做数据持久化的支撑
c、直接收集日志，通常日志平台也是从本地日志文件采集后，转发的日志平台。很少把应用日志直接转发到日志平台上。

下面我们再基于上面的理解来分析看看：

一般来说应用日志都是落盘后，再由日志平台采集端去收集。
项目中采用NAS做数据持久化，落日志占绝大多数。

后续的日志统一管理，一般是日志平台把应用日志采集后统一存放，进行分析查看。
日志的性能，可以从日志平台自身性能、存储和网络性能等维度去考虑，同一般的日志分析方案类似，没有太特别的差异。

业务规模不大且系统稳定问题少的场景可以直接使用NAS
业务规模大，团队多，系统关联复杂的应用建议配置日志分析平台

先从单个容器的角度看日志的持久化存储：
以Containerd容器运行时为例，容器日志会保存至/var/log/pods/$CONTAINER_NAME目录下，该目录默认保存在每个节点的本地盘上。
但是本地存储有很多问题：日志量大会占用大量本地盘空间、日志分散管理难度大、POD漂移后日志找回难等；因此常见的是指定一个外置NFS共享存储路径来挂载该目录。如果对性能有诉求，可以用全闪存的NFS存储或者SSD占比较多的混合闪存。

但解决容器日志的本地存储是第一步，要发挥日志的作用，还要建立日志分析平台。
所以接下来从K8S集群角度看日志存储和分析：
常见的是部署一套日志收集-存储-分析平台，如ELK/EFK平台
其中的L（Logstash）或F（Fluentd）作为logging agent会作为DaemonSet运行在每个节点上用于抽取日志并写入Elastic Search节点；日志会在ES节点上再次持久化，再使用Kibana做分析
ES节点下的存储建议基于混合闪存的NAS：
1． 为什么推荐外置存储：

• 集群产生的日志量较大，本地盘的扩容能力受限于单节点的盘数，扩容困难，一旦日志量突增就需要紧急删日志或转储来释放空间；而使用外置存储可以灵活扩容，不会出现因为盘不够用加服务器的情况
• 本地盘的可靠性不足，单盘故障时数据重构慢，节点故障时只能依靠应用的多副本来保护；而使用外置存储，则把数据可靠性交给专业存储，ES可以单副本部署，即降低成本，也减少了运维的工作量
  2． 为什么推荐混合闪存：
  -  使用SSD作为性能层，保证ES热数据节点的读写效率；使用HDD作为容量层，降低温数据节点（如>30天）日志的成本
  一套存储就可以同时满足高性能、高可靠、低成本的诉求，部署简单。
  3． 为什么推荐NAS：
• 企业级NAS可以提供接近SAN的性能，同时还具备多租户能力、租户配额等能力，可以隔离不同业务的数据，简化容量管理；
• 另外基于NAS可以实现POD更快的漂移，例如某个节点故障导致ES POD需要漂移到另一个节点重启，NAS相对于SAN可以实现跨节点挂载，减少等待时间，进一步提升ES业务的可用性。

关于普通容器的日志，使用NAS或者日志分析平台直接收集都有其优缺点。如果您只是需要简单地存储和查看日志，那么使用NAS可能更为方便。但是，如果您需要对大规模的容器日志进行分析和查询，并从中汇总有用的信息，则使用专门的日志分析平台可能更为适合。这些平台通常提供更强大的查询和可视化工具，以帮助您更好地理解和利用日志数据。

存容器日志目标： 使用 分析 频率来决定吧