最近在使用阿里云日志进行“上下文浏览”和“LiveTail”的时候突然发现无法正常过滤。
比如：我要实时查看eureka服务的日志，通过“Pod名称”或者“容器名称”过滤以后，LiveTail还是会显示其他服务的日志内容，如下图：
然后提交工单反馈，过了几个小时，技术说处理好了，我去测了下发现还是一样的问题，最后售后技术只好拉了一个钉钉群，把问题交给后端的技术来处理。
经过反复沟通，最后确认是我采集配置文件的问题。
因为我所有容器采集使用的一个配置，导致所有容器日志在一个上下文中，无法过滤。
要解决这个问题，有两种解决方案：
1、在业务pod yaml 中去增加一些环境变量，这样logtail会根据环境变量自动创建相应配置，可以把每个pod的数据采集到不同的logstore，简化配置代价。
具体文档：https://help.aliyun.com/document_detail/87540.html
也就是一个pod或者一个业务服务一个Logstore，这样会有什么问题呢？
一是日志project下面会有大量的Logstore，我们项目就四十个服务左右，我都觉得非常不方便，如果服务更多呢。
二是无法全局关键词搜索，这样和我远程到服务器或者通过kubernetes控制台直接查看没啥区别了。
也可以通过环境变量 aliyun_logs_{key}_logstore 把所有pod设置为一个Logstore，但是只支持极简模式，也就是按行采集，多行日志就不能使用这种方式了。
因为我们都是java日志，所以只能放弃这个方案。
2、在Logstore里面为每个pod或者业务服务配置一个采集配置，如果有10个服务就10个配置，有100个就配置100个，有N个就配置N个，可以想象有多繁琐，这不是花钱找虐吗。
这个问题在以前未迁移kubernetes集群时未出现过，也是一个project下面一个Logstore，然后一个通用配置采集所有服务的日志，“上下文浏览”和“LiveTail”也正常。
我一度以为这是一个bug，但是我又去看了日志服务采集kubernetes日志的文档，使用限制的确写了。
上下文限制：默认一个采集配置在同一上下文中，若需要每个容器的日志在不同上下文中，请单独为每个容器创建采集配置。
也不知道这个产品在设计这个逻辑的时候，是怎么考虑的，把一个本身繁琐的事情，更加繁琐化了，不知道有没有考虑过操作便利和查询实用。
感觉设计出来没有亲自用过，就发布出来敛钱了。
我相信阿里的技术，不可能实现不了一个配置采集所有容器日志，然后进行“上下文浏览”和“LiveTail”。
我也咨询了几个以前的同事，他们项目也是采用的一个服务一个Logstore，放弃全局搜索。
没办法最终只能采用第三种方案：暂时放弃“上下文浏览”和“LiveTail”功能。
