DC/OS文档IMPORTANT: Tutorials are intended to give you hands-on experience working with a limited set of DC/OS features with no implied or explicit warranty of any kind. None of the information provided--including sample scripts, commands, or applications--is officially supported by Mesosphere. You should not use this information in a production environment without independent testing and validation.
DC/OS 附带多个与应用程序调试相关的工具：
DC/OS Web 界面
DC/OS 为各种组件提供许多 Web 界面，尤其是在调试应用程序部署问题时：
DC/OS Web 界面
DC/OS Web 界面 是开始调试的绝佳地方，因为它提供了对以下内容的快速访问：
- 群集资源分配，以提供可用群集资源的概述
- 任务日志，以提供对任务故障的深入了解
- 任务调试信息，以提供关于最近任务提供的信息和/或任务未启动的原因
图 1. 任务调试界面
Mesos Web 界面
DC/OS Web 界面显示调试所需的大部分信息。但是，更进一步并访问 Mesos Web 界面可能很有帮助 – 尤其是在检查失败的任务或注册框架时。Mesos Web 界面可以通过 访问。https://<cluster-address>/mesos.
图 2. Mesos Web 界面
ZooKeeper Web 界面
由于大部分群集和框架状态存储在 Zookeeper 中，因此使用 ZooKeeper/Exhibitor Web 界面检查这些状态有时会很有帮助。Marathon、Kafka 和 Cassandra 等框架使用 Zookeeper 存储信息，因此在调试此类框架时，此资源尤为有用。例如，卸载其中一个框架时出现故障可能会留下条目。因此，当然如果您在重新安装之前卸载的框架时遇到困难，检查此 Web 界面可能非常有用。您可以通过 对其进行访问。https://<cluster-address>/exhibitor.
图 3. ZooKeeper/Exhibitor Web 界面
日志
日志是用于查看事件及其出现之前发生的条件的有用工具。通常，日志包含错误消息，可以提供有关错误原因的有用信息。由于日志记录本身就是一个重要的主题，因此我们建议使用 DC/OS 日志文档，以了解更多信息。
DC/OS 有许多不同的日志源。通常，这些是应用程序调试最有用的日志：
- 任务/应用程序日志
- 服务调度程序日志（例如，Marathon）
- Mesos 代理节点日志
- Mesos 管理节点日志
- 系统日志
在 DC/OS 中，有多个选项用于访问这些日志：DC/OS Web 界面 DC/OS CLI 或 HTTP 端点。此外，DC/OS 默认循环日志，以防止利用所有可用磁盘空间。
注意：需要可扩展的方式来管理和搜索日志吗？ 为日志聚合和筛选构建 ELK 堆栈 可能是值得的。
有时它可以帮助提高临时写入日志的详细程度，以为调试获得更详细的故障排除信息。对于大多数组件，可通过访问端点来完成。例如，如果要在服务器接收 API 调用后将 Mesos 代理节点的日志级别 提高 5 分钟，则可以执行以下简单的两步过程：
连接到主节点
$ dcos node ssh --master-proxy --leader
提高 Mesos 代理节点 10.0.2.219 上的日志级别
$ curl -X POST 10.0.2.219:5051/logging/toggle?level=3&duration=5mins
任务/应用程序日志
任务/应用程序日志通常有助于了解有问题的应用程序的状态。默认情况下，应用程序日志将写入（以及执行日志）到任务工作目录中的 STDERR 和 STDOUT 文件。查看 DC/OS Web 界面中的任务时，您只需查看如下所示的日志。
图 4. 任务日志
您也可以从 DC/OS CLI 执行相同操作：
$ dcos task log --follow <service-name>
调度程序/Marathon 日志
马拉松 在启动应用程序时是 DC/OS 的默认计划程序。调度程序日志，特别是 Marathon 日志，是一个很好的信息来源，可帮助您了解哪些节点上安排（或不安排）某些事情的原因或方式。调用调度程序将任务与可用资源匹配。因此，由于调度程序还接收任务状态更新，所以日志还包含任务失败的详细信息。
您可以通过 DC/OS Web 界面中找到的服务列表或通过以下命令检索和查看有关特定服务的调度程序日志：
$ dcos service log --follow <scheduler-service-name>
请注意，由于 Marathon 是 DC/OS 的“Init”系统，因此它作为 SystemD 单元（相对于其他 DC/OS 系统组件是相同的）运行。由于这个原因，您需要 CLI 命令来访问其日志。
Mesos 代理节点日志
Mesos 代理节点日志有助于了解代理节点启动应用程序的方式，以及它可能如何发生故障。您可以通过导航到 https://<cluster_name>/mesos 并检查如下所示的代理节点日志来启动 Mesos Web 界面。
图 5. Mesos 代理节点界面
或者，您可以首先使用 DC/OS CLI 的 dcos node log --mesos-id=<node-id> 查找相应节点 ID.，来查看代理日志。输入：
$ dcos node
您将看到类似于以下输出的内容：
HOSTNAME IP ID TYPE
10.0.1.51 10.0.1.51 ffc913d8-4012-4953-b693-1acc33b400ce-S3 agent
10.0.2.50 10.0.2.50 ffc913d8-4012-4953-b693-1acc33b400ce-S1 agent
10.0.2.68 10.0.2.68 ffc913d8-4012-4953-b693-1acc33b400ce-S2 agent
10.0.3.192 10.0.3.192 ffc913d8-4012-4953-b693-1acc33b400ce-S4 agent
10.0.3.81 10.0.3.81 ffc913d8-4012-4953-b693-1acc33b400ce-S0 agent
master.mesos. 10.0.4.215 ffc913d8-4012-4953-b693-1acc33b400ce master (leader)
然后，在本例中，您可以输入：
$ dcos node log --mesos-id=ffc913d8-4012-4953-b693-1acc33b400ce-S0 --follow
并获取以下日志输出：
2018-04-09 19:04:22: I0410 02:38:22.711650 3709 http.cpp:1185] HTTP GET for /slave(1)/state from 10.0.3.81:56595 with User-Agent='navstar@10.0.3.81 (pid 3168)'
2018-04-09 19:04:24: I0410 02:38:24.752534 3708 logfmt.cpp:178] dstip=10.0.3.81 type=audit timestamp=2018-04-10 02:38:24.752481024+00:00 reason="Valid authorization token" uid="dcos_net_agent" object="/slave(1)/state" agent="navstar@10.0.3.81 (pid 3168)" authorizer="mesos-agent" action="GET" result=allow srcip=10.0.3.81 dstport=5051 srcport=56595
Mesos 管理节点日志
Mesos 管理节点负责将可用资源与调度程序匹配。它还将任务状态更新从 Mesos 代理节点转发到相应的调度程序。这使 Mesos 管理节点日志成为了解群集整体状态的一个很好的资源。
请注意，单个群集通常有多个 Mesos 管理节点。因此，您应该确定当前主导的 Mesos 管理节点以获得最新日志。事实上，在某些情况下，从另一个 Mesos 管理节点检索日志甚至是有意义的：例如，主节点发生故障并且您想要了解原因。
您可以通过 <cluster-name>/mesos、通过 dcos node log --leader，或者对于特定的管理节点使用 ssh master 和 journalctl -u dcos-mesos-master.，从 Mesos Web 界面检索管理日志。
系统日志
我们现在已经介绍了 DC/OS 环境中最重要的日志源，但可用的日志还有很多。每个 DC/OS 组件都写入一个日志。如上所述，每个 DC/OS 组件 作为一个 Systemd 单元运行。您可以在特定节点上通过 SSH 进入节点直接检索日志，然后键入 journalctl -u <systemd-unit-name>. 在调试过程中，（除 Mesos 和 Marathon 之外）需要考虑的两个更常见的系统单元是 docker.service 和 dcos-exhibitor.service.
例如，考虑 Mesos 代理节点ffc913d8-4012-4953-b693-1acc33b400ce-S0上 docker 守护程序的系统单元（重新调用 dcos node 命令检索 Mesos ID）。
首先，我们可以使用相应的 SSH 密钥通过 SSH 进入该代理节点：
$ dcos node ssh --master-proxy --mesos-id=ffc913d8-4012-4953-b693-1acc33b400ce-S0
然后我们可以使用 journatlctl，以查看 Docker 日志：
$ journalctl -u docker
输出类似这样的内容：
-- Logs begin at Mon 2018-04-09 23:50:05 UTC, end at Tue 2018-04-10 02:52:41 UTC. --
Apr 09 23:51:50 ip-10-0-3-81.us-west-2.compute.internal systemd[1]: Starting Docker Application Container Engine...
Apr 09 23:51:51 ip-10-0-3-81.us-west-2.compute.internal dockerd[1262]: time="2018-04-09T23:51:51.293577691Z" level=info msg="Graph migration to content-addressability took 0.00 seconds"
度量标准
度量标准非常有用，因为它们有助于在潜在问题成为实际错误之前识别它们。例如，想象一个容器耗尽所有已分配内存的情况。如果您在容器处仍在运行但尚未被终止时检测到这一点，那么您更有可能及时进行干预。
在 DC/OS 中，度量标准有三个主要端点：
- DC/OS 度量标准
- 端点暴露来自任务/容器、节点和应用程序的组合度量标准
- Mesos metrics
- 端点暴露特定于 Mesos 的度量标准
- Marathon 度量标准
- 端点暴露特定于 Marathon 的度量标准
利用度量标准来帮助调试的一种方法是设置仪表盘。此仪表盘将包括与您要监控的服务相关的最重要度量标准。例如，您可以使用 prometheus 和 grafana 创建度量标准仪表盘。
理想情况下，配置仪表盘并运行后，您可以在潜在问题成为实际错误之前识别它们。此外，当出现问题时，此类仪表盘在确定错误原因方面非常有帮助（例如，可能群集没有可用资源）。上面列出的端点项中的每个链接都提供了您应监控该端点的度量标准建议。
交互式
有时，任务日志提供的帮助不足。在这些情况下，使用您最喜欢的 Linux 工具（例如 curl、cat、ping 等）来获得交互式视角可能是一个值得做的步骤。
例如，如果您使用 Universal Container Runtime (UCR)，则可以使用 dcos task exec，如下所示：
dcos task exec -it <mycontainerid>
并且在该容器内有一个交互式 bash shell。
重要信息：如果您在以上述方式使用 dcos task exec 时更改容器的状态，则必须更新存储的 app-definition 并从更新后的 app-definition. 重新启动容器。如果您未能执行此操作，您的更改将在下次重新启动容器时丢失。
或者，当使用 docker 容器化工具时，您可以通过 SSH 连接到相关节点并运行 docker exec 来调查正在运行的容器。
HTTP 端点
DC/OS 具有大量可用于调试的其他端点：
<cluster>/mesos/master/state-summary
state-summary
state-summary 端点](http://mesos.apache.org/documentation/latest/endpoints/master/state-summary/) 返回 json 编码摘要，汇总集群内的代理、任务和框架。在考虑跨群集分配资源时，这尤其有用，因为它显示是否已为特定角色保留了资源（在下文提供的调试方案之一中有更多详细信息）。
注意：请参阅 Mesos 端点的完整列表.
queue
<cluster>/marathon/v2/queue
Marathon queue 端点 返回队列中要由 Marathon 调度的所有任务的列表。此端点在排除扩展或部署问题时非常重要。
社区
DC/OS 社区是通过 Slack 或 邮寄列表.提出其他问题的好地方。同时记住，除了 DC/OS 社区之外，Mesos 和 Marathon 都有自己的社区。
其他工具
还有其他调试工具 – DC/OS 内部 以及 Sysdig 或 Instana. 等外部工具。这些工具对确定非 DC/OS 特定问题（例如，Linux 内核或网络问题）尤为有用。