收集日志，并将数据发送到日志服务器，这一动作看起来简单，但其实并不是一件容易的事。比如：容器日志收集，就存在诸多挑战。
日志传输，通常包含两大类：一个是主动方式;一个是被动方式。
主动方式，是指整个进程主动向远程syslog服务器发送日志消息。通常，数据编码的格式是rfc5424。
被动方式，是指部署每个进程的日志路径或文件模式。 LogAgent会定期扫描，并将捕获的日志消息发送到日志服务器。
但是在容器日志收集中，上述方法并不适用。首先，日志收集过程更快。其次，流程部署更加分布式。
具体而言，容器日志收集面临着四大挑战：
一、未能收集所有关键日志
当出现问题时，pods 可能会被删除或重新创建。因此，与pod/container相关联的日志文件将被快速删除/创建。
借助LogAgent(如Fluentd或Logstash)，我们可以定期扫描文件夹，或利用内置模式定义自动检测日志，并且默认扫描间隔为60秒(见下图)。扫描间隔太慢，将无法及时捕捉pod。假如：我们把间隔设得短一些，比如1秒，性能提升要高得多，但是会出现日志丢失现象。
此前，在VM环境下，就不用担心会出现类似问题。当进程以某种方式重新启动时，日志文件可能会被改变，但不会被删除。最多只是感觉到日志收集速度变慢，但不会丢失关键日志。
如何解决这一问题?我们可以通过Kubernetes云控制器功能来监控pod。每当启动pod创建事件时，立即通知LogAgent。honeycomb- kubernetts -agent是一个有机统一体。
值得一提的是，不是所有日志都被重定向到stdout/stderr。如果pod内的进程将日志写入本地文件，而不是stdout/stderr，LogAgent将无法获得日志，系统只监视与pod关联的日志文件，如下所示。该日志文件将只捕获容器的stdout/stderr。
这种日志记录行为是Kubernetes环境下的模式。尽管，云原生移动确实需要时间，但并不是每个应用都是最前沿应用，对于DB服务尤其如此。
与VM环境相比，容器日志收集更灵活，Pod可以经常在不同的工作节点上移动。但是，谁都不希望每当K8s集群有一个pod更改时，就要重新加载或重新启动LogAgent，这绝对是一个新的挑战。
二、Namespaces的多租户问题
Kubernetes工作负载通常运行在vm共享工作站中。由Namespaces来区分来自不同项目的工作负载分。不同的项目可能对日志记录有不同的偏好。日志到哪里，由什么工具管理，都需要提供一种简单的配置方式，而不需要安装其他应用。
在笔者看来，Kubernetes CRD (CustomResourceDefinition自定义资源定义)非常好用。你需要学习的只是标准的kubectl命令。RBAC可以借此应用定制资源。所以，Kubernetes CRD安全并且简单，更容易执行。在PKS中，我们将这个特性称为sink资源。
三、如何在不同的Namespaces下支持SLA
为了让操作更简单，人们通常只部署一个LogAgent作为Kubernetes daemonset。这代表每个Kubernetes工作节点有一个pod。如果这个pod需要重新加载或重新调度，它将影响这个工作节点中的所有pod。
从K8s v1.12开始，每个节点可以运行100个pod。你需要确保LogAgent足够快，可以从所有pod中收集日志。像任何共享环境一样，你可能会遇到错综复杂的关联问题。一个pod的错误行为会损伤同一工作节点中的所有其他pod。
可能每个人都会想到，让有问题的Namespaces禁用禁用日志记录，这样我们可以很容易避免发出日志，不会影响日志收集。但是，缓慢的磁盘处理可能会对日志传输造成明显的延迟。
四、如何处理来自不同层面的日志记录
如下图所示，我们有pod日志、K8s日志和平台日志。即使对于“pod日志”，我们也有来自标准工作负载或K8s附加组件的日志。
而不同类型的日志具有不同的特征。他们可能会有不同优先级别事项。不仅是层对层，而且是同一层的不同SLA。
在K8s解决方案中，我们如何解决这一问题?如何协助项目经理/开发人员迅速找出问题的根源?如何减少安装与部署环节?PKS可能是最佳选择!