spark日志收集

在很多情况下，我们需要查看driver和executors在运行 Spark 应用程序时候产生的日志，这些日志对于我们调试和查找问题是很重要的。

Spark 日志确切的存放路径和部署模式相关：

（1）、 如果是Spark Standalone模式 ，我们可以直接在Master UI界面查看应用程序的日志，在默认情况下这些日志是存储在worker节点的work目录下，这个目录可以通过 SPARK_WORKER_DIR 参数进行配置。

（2）、 如果是Mesos模式 ，我们同样可以通过Mesos的Master UI界面上看到相关应用程序的日志，这些日志是存储在Mesos slave的work目录下。

（3）、 如果是YARN模式 ，最简单地收集日志的方式是使用YARN的日志收集工具（ yarn logs -applicationId ），这个工具可以收集你应用程序相关的运行日志，但是这个工具是有限制的：应用程序必须运行完，因为YARN必须首先聚合这些日志；而且你必须开启日志聚合功能（ yarn.log-aggregation-enable ，在默认情况下，这个参数是false）。

如果你运行在YARN模式，你可以在ResourceManager节点的WEB UI页面选择相关的应用程序，在页面点击表格中 Tracking UI 列的 ApplicationMaster ，这时候你可以进入到Spark作业监控的WEB UI界面，这个页面就是你Spark应用程序的proxy界面，比如 http://www.iteblog.com:9981/proxy/application_1430820074800_0322 ，当然你也可以通过访问Driver所在节点开启的4040端口，同样可以看到这个界面。

到这个界面之后，可以点击 Executors 菜单，这时候你可以进入到Spark程序的 Executors 界面，里面列出所有Executor信息，以表格的形式展示，在表格中有 Logs 这列，里面就是你Spark应用程序运行的日志。如果你在程序中使用了 println(....) 输出语句，这些信息会在stdout文件里面显示；其余的Spark运行日志会在stderr文件里面显示。

在默认情况下，Spark应用程序的日志级别是INFO的，我们可以自定义Spark应用程序的日志输出级别，可以到 $SPARK_HOME/conf/log4j.properties 文件里面进行修改，比如：

| 01 | # User: 过往记忆 |

| 02 | # Date: 2015-05-015 |

| 03 | # Time: 上午07:26 |

| 04 | # bolg: [http://www.iteblog.com](http://www.iteblog.com/) |

| 05 | # 本文地址：[http://www.iteblog.com/archives/1353](http://www.iteblog.com/archives/1353) |

| 06 | # 过往记忆博客，专注于hadoop、hive、spark、shark、flume的技术博客，大量的干货 |

| 07 | # 过往记忆博客微信公共帐号：iteblog_hadoop |

| 08 | spark.root.logger=WARN,console |

| 09 | |

| 10 | log4j.rootLogger=${spark.root.logger} |

| 11 | |

| 12 | log4j.appender.console=org.apache.log4j.ConsoleAppender |

| 13 | log4j.appender.console.target=System.err |

| 14 | log4j.appender.console.layout=org.apache.log4j.PatternLayout |

| 15 | log4j.appender.console.layout.ConversionPattern=%d (%t) [%p - %l] %m%n |

这样Spark应用程序在运行的时候会打出WARN级别的日志，然后在提交Spark应用程序的时候使用 --files 参数指定上面的 log4j.properties 文件路径即可使用这个配置打印应用程序的日志。

stdio（standard input &output）(标准输入输出)。iOS中，我们可以使用stdio类的方法来实现日志采集功能。

1.日志收集

logFilePath为自定义的文件名称路径，在保存文件时，因判断目录中是否存在同名文件，存在则先删除，以防重名。freopen函数用于重定向输入输出流，stdout（Standardoutput）表示标准输出，stderr（Standarderror）表示标准错误。

2.自定义打印日志的NSLog

3使用DSLog打印日志

4.在AppDelegate.m的didFinishLaunchingWithOptions方法里调用logcollection方法，运行程序，则工程里的所有运行到的DSLog打印日志都会自动写入创建的.log文件中

5.获取log日志文件

#容器方便的同时带来的挑战

1. 如果日志还放在容器内部，会随着容器删除而删除

2. 容器多按照传统的仓库日志方式 显然不现实

#本身特性

1. 容器日志输出到控制台 本身docker提供了一种日志采集能力 如果落地到了本地文件 目前还没有一种比较好的动态采集方式

2. 新扩容的pod属性信息(日志文件路径 日志源 可能发生的变化)

#需要收集那些日志

1. k8s 系统组件日志 部署在k8s应用的日志

#当我们执行docker logs查看日志的时候是调用了docker守护进程去查看他接管的这个日志 在本地的文件系统中去读这个日志

#cd /var/lib/docker/找到容器ID进入里面 有一个已json文件已容器id命名的里面就是日志

#/var/lib/kubelet/pods/08ec113c8abdf4544

方案一：Node上部署一个日志收集程序

• DaemonSet方式部署日志收集程序

• 对本节点/var/log/kubelet/pods和

/var/lib/docker/containers/两个目录下的日志进

行采集

• Pod中容器日志目录挂载到宿主机统一目录上

方案二：Pod中附加专用日志收集的容器

• 每个运行应用程序的Pod中增加一个日志

收集容器，使用emtyDir共享日志目录让

日志收集程序读取到。

方案一：Node上部署一个日志收集程序 每个Node仅需部署一个日志收集程序，

资源消耗少，对应用无侵入 应用程序日志如果写到标准输出和标准错误输出，

那就不支持多行日志。

方案二：Pod中附加专用日志收集的容器 低耦合

每个Pod启动一个日志收集代理，增加资源消耗，

并增加运维维护成本

#匹配目录收集规则

方案(1)：DaemonSet方式部署日志收集程序

/var/lib/docker/containers/*/*-json.log

/var/lib/kubelet/pods/*/volumes/kubermetes.io~emtpdir/

/var/lib/kubelet/pods/*/

方式2: 挂载到统一的目录 解决日志覆盖的方法  推荐方法让开发根据容器名称命名日志文件

保持唯一性就可以了 这种方法维护起来比较好 也比较简单 但是缺点可能消耗资源多一点

data:

  kubernetes.yml: |-

    - type: docker

      containers.ids:

      - "*"

https://www.cnblogs.com/Dev0ps/p/10778962.html

#传统日志配置采集工具重要设置什么

1. 日志路径

2. 写正则 格式化日志

3. 日志源(命名空间 容器 service 项目)

阿里云日志采集工具:log-pilot

---