A:抱歉,我们比较关注的是云平台服务器端的日志,移动设备的日志没有研究过.如果是移动设备日志通过服务器的API上传到服务器了,那么就是一样的处理.一般我们的理解,移动设备的日志是通过应用自己的一些日志程序,定期压缩发送到服务器或者第三方的日志手机平台,然后在服务器端,当作普通的服务器应用日志来处理,只不过要打上移动设备和用户的相关Tag.
Q:ElasticSearch是可以设置备份周期的时间吧?如果我想保留一个月的日志来进行查询?
A:可以设置.但是要通过自己的脚本或者crontab任务来实现.ES目前主要提供的是通过REST API创建、删除备份和通过保留的备份恢复某个集群.
Q:Fluentd可否设置收集容器应用指定目录日志(非标准输出目录),怎么设置?
A:容器应用目录在容器内,Fluentd是收集不到的,除非你的输出目录也是外部挂载的的共享目录.如果是一个单纯Docker Engine管理的节点,可以通过–volumn-from访问另一个容器存储的数据,当然这也是在那个容器-v声明的volumn而不是任意目录;这种方式对Kubernetes集群没什么帮助.
Q:ElasticSearch日志的保留策略,怎么设置呢,是调API删除还是ElasticSearch自带呢?
A:我们现在用的方式是用时间做索引,然后脚本定时删除.
Q:数据节点PVC/PV 挂载的文件系统是那种呢?实际使用上遇到什么问题没有?
A:我们用过的主要是NFS和GlusterFS.最初实现的PV比较弱,PVC不能通过Label与PV匹配,只能通过size和访问类型匹配,无法准确选择PV存储.现在最新Kubernetes支持PVC的selector支持选择带有特定Label的PV了.
Q:请问Kubernetes宿主机的日志是如何收集的?
A:用相应的不同的Fluentd插件,类似的mount到相应的主机日志目录即可.现在容器的日志也是通过主机收集的.
Q:日志包括容器的捕获的标准输出日志和应用打到日志文件中的日志.对于这两类场景,如何用Fluentd实现新启动容器的日志自动发现和收集?
A:对于打到日志文件中的日志,原则上建议日志目录是主机绑定上的或是共享目录.日志的自动发现和收集需要通过fluentd的插件,将指定的目录的文件过滤出来,例如标准输出日志肯定在主机的/var/lib/docker/containers/container-id/下.我们集成的Fluentd镜像,已经打包配置好了相应的的插件https://github.com/fabric8io/fluent-plugin-kubernetes_metadata_filter,可以参考.
Q:我们目前也使用了Fluentd收集容器日志,收集容器写到log文件中的日志比收集从标准输出的日志要慢,请问你们有什么调优的方法吗?
A:文件日志比标准输出慢是正常的,调优Fluentd的性能可能要根据Fluentd的说明逐渐积累经验先定位哪里慢,再试验加快方法,跟各种系统的性能调优是同样的思路.下面这个链接有些调优建议.http://docs.fluentd.org/articles/performance-tuning
Q:请问如何处理集群自我恢复机制,比如elasticsearch-master、elasticsearch-client 挂了?
A:我们在Kubernetes集群中,elasticsearch-master和elasticsearch-client都是以Relication Controller或Replication Set方式启动的,系统会自动保证服务的高可用.其他集群也是类似的机制,和一般Web应用的高可用是一样,要有机制保证重启服务,要有机制做服务发现和负载均衡,在K8s集群是靠Relication Controller和Kube-proxy.
Q:请问,在Kubernetes集群中的每个节点上运行一个Fluentd的容器,这个节点是容器还是部署Docker的节点?
A:这个是主机节点(可能是物理机或虚拟机),就是Kubernetes的Node,部署Docker的节点.推荐的官方方法,是通过Kubernetes的DaemonSet做部署.当然也可以自己在每个节点上维持自动的启动脚本,运行一些每个节点都要启动的Pod服务.
Q:请问,Kubernetes的master是单点的,你们是否有优化过,现在1.3了,你们平台升级是否是热部署?
A:我们是用podmaster做至少3节点master高可用部署,api-server是多活的,controllermanager 和schedule是1活2备.平台升级现在是手动的,不会影响运行中的服务.但是现在平台升级需要工程师小心翼翼的手动操作,还不是自动化的.
Q:请问Fluentd和Flume除了开发语言不一样,有什么本质上的区别?以及ES日索引的分片数量建议是?
A:Fluentd和Flume的设计理念是类似的,一个用CRuby,一个用JRuby,与Fluentd和Logstash的情况类似,Fluentd的镜像会小一些,运行时内存消耗会小一些,而Flume的镜像因为要打包JDK差不多要几百兆.在围绕容器的Linux环境中,Java的跨平台性本身带来不了特别大优势,反而Fluentd镜像小的优势更加明显.另外一个对我们的系统实践意义比较大,就是fluentd跟Kubernetes集群的方案做的简单明了.ES默认的shards数是5,一般的集群情况要根据使用情况测一下,对于不同的index,这个shards数可以是不一样的.Shards的个数尽量不设1吧,设1的话,将来想要增加分片时,移动的数据量太大了.在没有很充分的生产测试经验之前,设置2到5比较好.
文/王昕
文章出处:Docker
(编辑:ASP站长网)
|