Spark之Monitor 官网翻译

翻译官网:Monitoring and Instrumentation

在跑Spark作业的时候,或者半夜跑完之后第二天,你常常需要看它运行时的信息,看一下运行情况,以及根据这些信息进行调优等,那么对于Spark作业的运行时监控就显得很重要了。

Monitoring and Instrumentation(监控和仪表化)

有几种方法可以监控Spark应用程序:Web UI,metrics和external instrumentation。

①Web Interfaces(Web 接口)

每一个SparkContext启动一个web UI用来展示应用相关的一些非常有用的信息,默认在4040端口。这些信息包括:

  • task和stage调度的列表
  • RDD大小和内存使用的概要信息
  • 环境信息
  • 正在运行的executor的信息
    在这里插入图片描述
    你可以在浏览器中打开http://<driver-node>:4040网址来访问这些信息。如果在同一台机器上有多个SparkContext正在运行,那么他们的端口从4040开始依次增加(4041,4042等)。

这种方式有一个很严重的弊端就是这个4040 Web UI只在程序运行期间可以看,程序运行完毕后就看不了。所以就有了我们的第二种监控,spark-history-server。

请注意,这些信息默认情况下仅在应用程序的生命周期内可以被访问,比如从你开始启动Spark Context,一直到sc.stop()停掉这个时间范围内可访问。 如果你想在sc.stop()后,就是你的Spark应用程序停掉后,还去访问 web UI ,那么就要在启动应用程序之前,把 spark.eventLog.enabled 这个参数设置成true。用这种方式来配置spark来记录spark事件,这些事件将UI中显示的信息编码为持久存储。

②Viewing After the Fact(通过history server)

程序关闭后查看日志

假定Spark 应用程序事件日志存在,仍然可以通过Spark的 history server来构建Spark 应用程序的UI。你可以通过执行命令来启动history server:
./sbin/start-history-server.sh
默认情况下,它会在http://<server-url>:18080这个地址上创建一个web接口,这个web接口,列举了未完成的和已完成的应用程序和尝试。

使用文件系统提供程序类时(请参阅下面的spark.history.provider),必须在spark.history.fs.logDirectory配置选项中提供基本日志记录目录,并且应包含每个代表应用程序事件日志的子目录。

The spark jobs themselves must be configured to log events, and to log them to the same shared, writable directory. For example, if the server was configured with a log directory of hdfs://namenode/shared/spark-logs, then the client-side options would be:
必须去配置spark作业本身去记录事件,并将事件记录到同一个共享的可写目录中。 例如,如果服务器配置了 hdfs://namenode/shared/spark-logs的日志目录,那么客户端选项将是:

spark.eventLog.enabled true
spark.eventLog.dir hdfs://namenode/shared/spark-logs

   
   
  • 1
  • 2

就是说先会将Spark Application信息写入到spark.eventLog.dir目录下,然后spark-history-server会去这个目录把日志信息渲染到Web UI供开发人员查看。

history server可以按如下参数去配置:

Environment Variables(环境变量)
环境变量意思
SPARK_DAEMON_MEMORY分配给history server的内存(默认1G)
SPARK_DAEMON_JAVA_OPTShistory server的JVM选项(默认值:none)
SPARK_DAEMON_CLASSPATHhistory server的Classpath (默认值:none)
SPARK_PUBLIC_DNShistory server的公共地址,如果没有设置,则指向应用程序历史记录的链接可能只能使用history server的内部地址,从而导致链接断开(默认值:none)
SPARK_HISTORY_OPTS对于history server而言的spark.history.* 配置选项 (默认: none).
Spark History Server Configuration Options(配置选项)

这些配置在Spark-env.sh中配。
下面只列了部分属性。

属性名称默认值意思
spark.history.providerorg.apache.spark.deploy.history.FsHistoryProvider实现应用程序历史后端的类的名称。 目前,Spark只提供了一个实现,用于查找存储在文件系统中的应用程序日志。
spark.history.fs.logDirectoryfile:/tmp/spark-events对于文件系统历史记录提供程序,包含要加载的应用程序事件日志的目录的URL。 这可以是本地file://路径,HDFS路径hdfs:// namenode / shared / spark-logs或Hadoop API支持的备用文件系统。
spark.history.fs.update.interval10s文件系统历史记录提供程序检查日志目录中的新日志或更新日志的时间段。 较短的间隔可以更快地检测新应用程序,代价是更多服务器负载重新读取更新的应用程序。 更新完成后,已完成和未完成的应用程序列表将反映更改。
spark.history.retainedApplications50保留缓存中UI数据的应用程序数。 如果超过此上限,则将从缓存中删除最旧的应用程序。 如果应用程序不在缓存中,则必须从磁盘加载它(如果从UI访问)。
spark.history.ui.port18080history server 的Web界面绑定的端口
spark.history.fs.cleaner.enabledfalse是否周期性的删除storage中的event log(生产必定是true)
spark.history.fs.cleaner.interval1d多久删除一次
spark.history.fs.cleaner.maxAge7d每次删除多久的event log,配合上一个参数就是每天删除前七天的数据

注意,在所有这些web接口可以通过点击“表头”来对这些表格进行排序。这使得鉴别运行速度慢的任务、判别数据倾斜等很容易。

注意事项:

  • 1.history server对于已完成和未完成的Spark作业都会展示出来。 如果应用程序在失败后进行多次尝试,失败后的尝试将会被展示出来,以及任何正在进行的未完成尝试或最终成功尝试也会被展示出来。

  • 2.不完整的应用程序仅间歇性更新。更新间隔的时间由检查被更改文件(spark.history.fs.update.interval)的间隔定义。 在较大的集群上,可以将更新间隔设置为较大的值。 查看正在运行的应用程序的方法实际上是查看自己的Web UI。

  • 3.如果应用程序退出时未将自己注册为已完成,则将被列为未完成-即使它们不再运行。如果应用程序崩溃,就会发生这种情况。

  • 4.Spark作业完成的信号的一种方法是显式停止Spark Context ( sc.stop() ),或者在python中使用with SparkContext() as sc: construct来处理Spark Context 的设置和关闭。

③REST API

如果公司有自己的监控平台,想获取到Spark Application日志信息到平台展示可以通过REST API。这是通过rest ful请求的方式来获取spark的作业的信息,通过这种方式我们可以构建我们自己web界面。

除了在UI界面中查看指标外,它们还可以以JSON格式的方式来提供使用。 这为开发人员提供了一种为Spark创建新的可视化和监视工具的简便方法。 JSON既可用于正在运行的应用程序,也可用于历史记录服务。
端点安装在/api/v1。 例如,对于历史服务器,它们通常可以在http://<server-url>:18080/api/v1访问,对于正在运行的应用程序,可以在http://localhost:4040/api/v1访问。

在这个REST API中,应用程序由其application ID[app-id]引用。当在yarn上运行时,每个应用程序可能有多次尝试,但只有cluster 模式下的应用程序才有attempt ID,在client模式下的应用程序没有attempt ID。可以通过[attempt-id]来识别YARN cluster 模式中的应用程序。在下面列出的API中,当在YARN cluster 模式下运行时,[app-id]实际上是[base-app-id] / [attempt-id],其中[base-app-id]是YARN application ID。

具体API列表,这里不列了,需要去看官网。

举几个例子说明一下如何使用:

  • 获取所有的application的信息:
    http://ip:18080/api/v1/applications
  • 获取正在跑或者完成的application
    http://ip:18080/api/v1/applications/?status=running
    http://ip:18080/api/v1/applications/?status=completed
  • 只获取1条application
    http://hadoop000:18080/api/v1/applications/?limit=1
    获取某一具体的application:
    http://hadoop000:18080/api/v1/applications/local-1678247925731

可以检索的job和stage的数量受standalone Spark UI的相同保留机制的限制;“spark.ui.retainedjobs”定义了触发关于job的垃圾收集(garbage collection 简称GC)的阈值,"spark.ui.retainedstages"定义了触发关于stage的垃圾收集的阈值。意思就是达到了这个阈值就进行垃圾回收。请注意,垃圾收集是在回放时进行的:通过增大这些值并重新启动history server,可以检索更多条目。

Executor Task Metrics(了解)

The REST API exposes the values of the Task Metrics collected by Spark executors with the granularity of task execution. The metrics can be used for performance troubleshooting and workload characterization. A list of the available metrics, with a short description:
REST API 以任务执行的粒度 暴露了Task Metrics的值,Task Metrics它是由Spark executors收集的。这些指标可用于性能故障排除和工作负载描述。
可用指标的比如:executorRunTime、executorCpuTime、jvmGCTime等等,这里不进行描述,请看官网。

API Versioning Policy(API 版本策略)(了解)

这些终端经过了强大的版本控制,可以更轻松地开发应用程序。 尤其是Spark:

  • 不会从一个版本中移除端点
  • 对于任何给定的端点,永远不会删除单个字段
  • 可以添加新的端点
  • 可以将新字段添加到现有端点
  • 可以在将来添加新版本的api作为单独的端点(例如,api / v2)
  • 新版本不需要向后兼容
  • Api版本可能会被删除,但只有在至少一个与新api版本共存的次要版本之后

请注意,即使在检查正在运行的应用程序的UI时,仍然需要 applications / [app-id]部分,尽管只有一个应用程序可用。 例如, 要查看正在运行的应用程序的作业列表,您可以访问http://localhost:4040/api/v1/applications/[app-id]/jobs。 这是为了在两种模式下保持路径一致。

④Metrics(了解)

此方式基本用不到,除非对spark研究很深的人才才可能会用。

Spark基于Coda Hale Metrics库提供一个可配置的 metrics system指标系统。这允许用户向不同的终端发送Spark指标信息,包括HTTP、JMX和CSV文件。指标系统可以通过配置文件来进行配置,Spark默认将配置文件保存在$SPARK_HOME/conf/metrics.properties。一个自定义文件路径可以通过 spark.metrics.conf 这个配置属性来指定。默认情况下,用于driver 或 executor metrics 的root namespace是spark.app.id的值。然而,通常情况下,用户希望能够在驱动程序和执行器的应用程序之间跟踪指标,这对于application ID(即spark.app.id)来说很难做到,因为它会随着应用程序的每次调用而改变。对于此类用例,可以使用spark.metrics.namespace配置属性为指标报告指定自定义命名空间。例如,如果用户希望将metrics命名空间设置为应用程序的名称,则可以将 spark.metrics.namespace属性设置为类似于${spark.app.name}的值。然后,spark适当地扩展该值,并将其用作指标系统的root namespace。Non-driver and executor metrics从不以spark.app.id作为前缀,spark.metrics.namespace属性也不会对此类指标产生任何此类影响。
指标信息配置文件的语法有一个示例文件—$SPARK_HOME/conf/metrics.conf.template.

因为基本用不到这个,这里不再介绍,请看官网。

⑤Advanced Instrumentation(了解)

高级的仪器

有几个外部工具可用来分析Spark作业的性能:

  • 集群范围的监控工具,比如 Ganglia,可以洞察整个集群的利用率和资源瓶颈。例如,Ganglia仪表盘可以迅速揭示出某个特定载荷是磁盘相关,网络相关,还是CPU相关的。
  • OS性能分析工具,比如 dstat, iostat,和 iotop, 可以提供各个节点的细粒度的分析。
  • JVM工具,比如 jstack提供了堆栈跟踪,jmap提供了创建堆转储,jstat提供了时间序列统计报告,还有jconsole提供了各种JVM属性的视觉显示,它们对JVM内部构件的舒适运作都是非常有用的。

另外基于ES的监控可参考:
Spark Streaming + Elasticsearch构建App异常监控平台

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值