如何利用CoreOS服务器对常见问题进行故障排查

提供：ZStack云计算

系列教程

本教程为CoreOS上手指南系列九篇中的第八篇。

内容简介

CoreOS提供一系列强大的技术成果，能够显著简化分布式系统的构建流程。然而，新人用户们对这些工具往往并不熟悉。由于其中存在众多抽象层，因此我们往往很难确定问题的具体根源。

在本教程中，我们将了解与CoreOS主机、Docker容器以及各服务管理工具相关的故障排查知识。

对Cloud-Config文件进行调试

CoreOS新人们最常见的问题就是集群无法正确验证cloud-config文件。

在服务器创建时，CoreOS会要求我们为其提供一个cloud-config文件。其会使用文件中的信息以引导自身并初始化或者加入现有集群。其同时亦会启动多项基本服务，并配置用户及群组等系统基本元素。

下面是cloud-config文件的几项检查重点：

• 其是否以“#cloud-config”开头？：每个cloud-config文件都必须以“#cloud-config”作为第一行。尽管在YAML中这经常被作为注释行而被忽略，但在本示例中这行其实代表其属于cloud init系统且包含配置数据。
• 文件中是否包含有效YAML？：Cloud-config文件以YAML编写而成，这是一种数据排序格式且高度关注可读性。如果大家发生了问题，请将自己的cloud-config内容复制到YAML在线验证器当中。文件中不可存在任何错误。CoreOS提供一款工具以检查cloud-config中的语法，即Cloud-Config验证器。
• 是否使用了样报发现令牌？：发现地址会始终与设备数据保持一致——即使集群整体发生宕机。这意味着如果使用旧令牌进行引导，则发现注册将发生错误，特别是在我们此前已经使用同一IP地址进行过注册的情况下。确保每次启动集群时使用更新的发现令牌，从而避免这一问题。
• 是否启动了fleet与etcd服务？：要让集群正常启动并运作，我们必须首先启动fleet与etcd两项服务。具体请参阅如何在DigitalOcean上运行CoreOS集群一文，以了解如何确保cloud-config文件满足这几项基本要求。

大家只能在设备创建时传递cloud-config文件，因此一旦犯下错误，则只能关闭该服务器实例并重新启动（大多需要使用新令牌）。

在保证cloud-config文件不睁大眼睛问题后，下一步是登录至主机以确保该文件得到正确处理。

这项工作在DigitalOcean上很好实现，大家只需要在服务器创建时向其添加ssh密钥即可。这意味着我们能够ssh至服务器中以进行故障排查，而不会引起任何问题。

通过DigitalOcean控制面板进行登录

然而，cloud-config还有可能在服务器启动时对网络可用性造成影响。在这种情况下，大家需要通过DigitalOcean控制面板进行登录。这就引发了新的问题，因为CoreOS镜像在默认情况下并未设置密码。

为解决这个问题，我们必须利用新的cloud-config文件重新创建该服务器，并在其中包含面向core用户的密码输入环节。由于需要重新创建，因此这种方式只适用于不断发现此问题且希望获取更多信息的情况。大家在检查时可向全部cloud-config文件添加密码信息，并在完成后以手动方式撤销密码。

密码内容必须采用哈希格式。根据具体软件选择，大家可以通过多种方式实现。以下几种皆可，各位可选择适合自己的一种：

mkpasswd --method=SHA-512 --rounds=4096openssl passwd -1python -c "import crypt, getpass, pwd; print crypt.crypt('password', '\$6\$SALT\$')"perl -e 'print crypt("password","\$6\$SALT\$") . "\n"'

完成之后，向cloud-config文件中添加一个名为users的新区段（注意不要与‘coreos’区段重叠），并添加以下信息：

#cloud-configusers:- name: corepasswd: hashed_passwordcoreos:. . .

验证YAML语法, 而后使用这一新cloud-config文件以创建服务器。这样我们就能够通过DigitalOcean控制面板利用密码完成登录了。

检查各主机

登录完成后，利用以下几种方式检查cloud-config是否得到正确处理。

检查基本服务中的错误

最简单的方式就是向fleetctl询问其已知设备。如果返回结果没有错误，则意味着fleet与etcd都已经正常启动，且能够与其它主机进行通信。

fleetctl list-machines

如果发现错误，则应该会看到对应的输出结果。常见的错误信息应如下所示：

2014/09/18 17:10:50 INFO client.go:278: Failed getting response from http://127.0.0.1:4001/: dial tcp 127.0.0.1:4001: connection refused2014/09/18 17:10:50 ERROR client.go:200: Unable to get result for {Get /_coreos.com/fleet/machines}, retrying in 100ms2014/09/18 17:10:50 INFO client.go:278: Failed getting response from http://127.0.0.1:4001/: dial tcp 127.0.0.1:4001: connection refused2014/09/18 17:10:50 ERROR client.go:200: Unable to get result for {Get /_coreos.com/fleet/machines}, retrying in 200ms

这意味着不同组件彼此堆叠，因此我们需要自上而下进行梳理。检查fleet服务以获取错误信息：

systemctl status -l fleet● fleet.service - fleet daemonLoaded: loaded (/usr/lib64/systemd/system/fleet.service; static)Drop-In: /run/systemd/system/fleet.service.d       └─20-cloudinit.confActive: active (running) since Thu 2014-09-18 17:10:50 UTC; 2min 26s agoMain PID: 634 (fleetd)CGroup: /system.slice/fleet.service       └─634 /usr/bin/fleetdSep 18 17:13:07 dumb1 fleetd[634]: INFO client.go:278: Failed getting response from http://localhost:4001/: dial tcp 127.0.0.1:4001: connection refusedSep 18 17:13:07 dumb1 fleetd[634]: ERROR client.go:200: Unable to get result for {Update /_coreos.com/fleet/machines/795de101bcd24a3a96aa698f770f0074/object}, retrying in 800msSep 18 17:13:08 dumb1 fleetd[634]: INFO client.go:278: Failed getting response from http://localhost:4001/: dial tcp 127.0.0.1:4001: connection refused

如大家所见，该服务正在运行，但却无法接入端口4001，也就是etcd端口。这意味着该问题可能与etcd有关。

我们需要逐一检查每项基本服务的状态与日志。常见的实现方式如下：

systemctl status -l servicejournalctl -b -u service

其中“status”命令负责提供该服务的状态及最后几行日志记录。而journal命令则可访问全部日志内容。

接下来利用同样的操作检查etcd，在本示例中我们发现etcd服务并未运行：

systemctl status -l etcd● etcd.service - etcdLoaded: loaded (/usr/lib64/systemd/system/etcd.service; static)Drop-In: /run/systemd/system/etcd.service.d       └─20-cloudinit.confActive: activating (auto-restart) (Result: exit-code) since Thu 2014-09-18 17:17:03 UTC; 9s agoProcess: 938 ExecStart=/usr/bin/etcd (code=exited, status=1/FAILURE)Main PID: 938 (code=exited, status=1/FAILURE)Sep 18 17:17:03 dumb1 systemd[1]: etcd.service: main process exited, code=exited, status=1/FAILURESep 18 17:17:03 dumb1 systemd[1]: Unit etcd.service entered failed state.

如果检查etcd日志，则会看到：

journalctl -b -u etcdSep 18 17:21:27 dumb1 systemd[1]: Starting etcd...Sep 18 17:21:27 dumb1 systemd[1]: Started etcd.Sep 18 17:21:27 dumb1 etcd[1160]: [etcd] Sep 18 17:21:27.966 INFO      | The path /var/lib/etcd/log is in btrfsSep 18 17:21:27 dumb1 etcd[1160]: [etcd] Sep 18 17:21:27.967 INFO      | Set NOCOW to path /var/lib/etcd/log succeededSep 18 17:21:27 dumb1 etcd[1160]: [etcd] Sep 18 17:21:27.967 INFO      | Discovery via https://discovery.etcd.io using prefix /.Sep 18 17:21:28 dumb1 etcd[1160]: [etcd] Sep 18 17:21:28.422 WARNING   | Discovery encountered an error: invalid character 'p' after top-level valueSep 18 17:21:28 dumb1 etcd[1160]: [etcd] Sep 18 17:21:28.423 WARNING   | 795de101bcd24a3a96aa698f770f0074 failed to connect discovery service[https://discovery.etcd.io/]: invalid character 'p' after top-level valueSep 18 17:21:28 dumb1 etcd[1160]: [etcd] Sep 18 17:21:28.423 CRITICAL  | 795de101bcd24a3a96aa698f770f0074, the new instance, must register itself to discovery service as requiredSep 18 17:21:28 dumb1 systemd[1]: etcd.service: main process exited, code=exited, status=1/FAILURESep 18 17:21:28 dumb1 systemd[1]: Unit etcd.service entered failed state.

其中高亮部分代表此特定示例缺少发现令牌。

检查文件系统以查找由Cloud-Config生成的配置文件

下面检查由cloud-config生成的各服务文件。

CoreOS设备在处理cloud-config文件时，其会生成存根systemd单元文件，其用于启动fleet与etcd。检查由此创建的systemd配置文件同时变更其所在目录：

cd /run/systemd/systemls -Fetcd.service.d/  fleet.service.d/  oem-cloudinit.service

这里我们可以看到生成的oem-cloudinit.service文件，其由CoreOS自动处理，外加存放服务信息的各目录。我们可以使用以下命令查看etcd服务的启动信息：

cat etcd.servicd.d/20-cloudinit.conf[Service]Environment="ETCD_ADDR=10.132.247.162:4001"Environment="ETCD_DISCOVERY=https://discovery.etcd.io/"Environment="ETCD_NAME=795de101bcd24a3a96aa698f770f0074"Environment="ETCD_PEER_ADDR=10.132.247.162:7001"

这个存根systemd单元文件用于将其它信息在启动时添加到该服务当中。如大家所见，其中ETCD_DISCOVERY地址符合我们之前在logs: there is no discovery token处发现的信息。我们需要利用包含有效发现令牌的cloud-config文件重新创建设备。

利用以下命令获取同样的fleet信息：

cat fleet.service.d/20-cloudinit.conf[Service]Environment="FLEET_METADATA=region=nyc,public_ip=104.131.1.89"Environment="FLEET_PUBLIC_IP=10.132.247.162"

在这里，大家可以看到cloud-config向fleet提供了部分元数据信息。其可用于在创建服务单元文件时执行相关调度工作。

检查元数据服务访问

CoreOS服务器创建时所使用的cloud-config文件是利用一项元数据服务进行存储的。如果我们无法在服务器上找到该cloud-config，那么其也许未能从DigitalOcean元数据服务处提取相关信息。

在主机设备上输入：

curl -L 169.254.169.254/metadata/v1idhostnameuser-datavendor-datapublic-keysregioninterfaces/dns/

注意，-L参数用于实现重新定向追踪。其中169.254.169.254地址将被用于每一台服务器，因此我们不应对其进行修改。结果所示为我们的元数据字段以及容纳服务器相关信息的各个目录。如果我们无法获取以上表单，则可能需要向技术人员求助。

大家可以查询此URL以获取服务器相关信息。利用curl命令检查其中的每个条目，其中包含有cloud-config文件的为user-data字段：

curl -L 169.254.169.254/metadata/v1/user-data#cloud-configusers:- name: corepasswd: $6$CeKTMyfClO/CPSHB$02scg00.FnwlEYdq/oXiXoohzvvlY6ykUck1enMod7VKJrzyGRAtZGziZh48LNcECu/mtgPZpY6aGCoj.h4bV1coreos:etcd:# generated token from https://discovery.etcd.io/newdiscovery: https://discovery.etcd.io/# multi-region and multi-cloud deployments need to use $public_ipv4addr: $private_ipv4:4001peer-addr: $private_ipv4:7001fleet:public-ip: $private_ipv4metadata: region=nyc,public_ip=$public_ipv4units:- name: etcd.service  command: start- name: fleet.service  command: start

如果大家能够从这一位置找到cloud-config文件，则意味着我们的服务器同样有能力读取该cloud-config数据，并在服务器引导过程中执行相关指令。

利用CoreOS主机设备对其它问题者故障排查

如果大家需要进行进一步调试，则可将注意力转向包含最低安装库的CoreOS版本。其中包含容器中所运行的全部软件，但排除了其它大部分不必要的基础性工具程序。

幸运的是，CoreOS开发人员们提供了另一种更为可行的解决办法。大家可以在每台主机上使用“toolbox”脚本，从而启动一套Fedora容器以访问各主机系统。在此容器当中，大家可以安装主机调试所必需的各类工具。

利用以下toolbox命令：

toolbox

其会提取最新版本Fedora镜像并在容器中打开命令行。经过快速检查，大家会发现自己已经接入该主机系统的网络：

ip addr show1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00inet 127.0.0.1/8 scope host lo   valid_lft forever preferred_lft foreverinet6 ::1/128 scope host    valid_lft forever preferred_lft forever2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000link/ether 04:01:28:7c:39:01 brd ff:ff:ff:ff:ff:ffinet 169.254.180.43/16 brd 169.254.255.255 scope link eth0   valid_lft forever preferred_lft forever. . .

大家也可以访问全部主机进程：

ps auxUSER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMANDroot         1  0.0  0.1 106024  4912 ?        Ss   17:10   0:04 /usr/lib/systemd/systemd --switched-root --system --deserialize 19root         2  0.0  0.0      0     0 ?        S    17:10   0:00 [kthreadd]root         3  0.0  0.0      0     0 ?        S    17:10   0:00 [ksoftirqd/0]root         5  0.0  0.0      0     0 ?        S<   17:10   0:00 [kworker/0:0H]root         6  0.0  0.0      0     0 ?        S    17:10   0:00 [kworker/u4:0]root         7  0.0  0.0      0     0 ?        S    17:10   0:00 [rcu_sched]root         8  0.0  0.0      0     0 ?        S    17:10   0:00 [rcu_bh]. . .

大家可以在此环境中安装任意工具。举例来说，我们可以利用Fedora软件包管理器安装htop：

yum install htop -y && htop

该进程监控器会导入全部当前主机的已加载进程：

要退出该容器环境，输入“exit”或者快速按三次CTRL-]。这样我们就会退出到主机的shell会话。

立足任意主机对服务进行故障排查

我们可能还需要对服务实际运行所在的主机进行故障排查。由于fleet与fleetctl能够管理整套集群中的全部服务，因此我们可以在集群内任意主机上执行这两款工具。

首先要做的是了解服务的运行状态，包括fleet与被分配以执行各服务的个别主机。我们可以使用fleetctl工具提供的命令以轻松获取这部分信息。

首先利用以下命令查看fleet中的服务状态：

fleetctl list-unit-filesUNIT                HASH    DSTATE      STATE       [e-mail]   06d78fb loaded      loaded      04856ec4.../[e-mail]   06d78fb loaded      loaded      197a1662.../[e-mail]   06d78fb loaded      loaded      e3ca8fd3.../[e-mail]     0f7f53b launched    launched    04856ec4.../[e-mail]     0f7f53b launched    launched    197a1662.../[e-mail]     0f7f53b launched    launched    e3ca8fd3.../10.132.252.37nginx_lb.service        c8541af launched    launched    96ec72cf.../10.132.248.177

在这里我们可以对fleet掌握的服务状态进行浏览。输出结果中包含几条重要信息，下面分别来看。

• UNIT: 此处为该单元名称。在本示例中，前六项服务皆为实例单元（可参阅模板与实例一文），而结尾处则为静态实例。我们可以在命令中使用这些名称以影响各项服务。
• HASH: 此处为该单元文件用于控制此服务的哈希。如大家所见，全部apache-discovery实例都源自同一模板文件。其中各apache实例拥有共同的来源，我们可以据此查看自己的服务是否由于使用了过期单元文件而发生异常。
• DSTATE: 此处为该单元的理想状态。在向fleetctl发送命令以变更该单元状态时，此列亦会变化以反响该单元的理想状态。
• STATE: 此处为fleet所掌握的该单元的实际状态。如果其与DSTATE有所不同，则意味着操作失败。
• TARGET: 被调度以运行此服务的设备。这一项会在单元启动或者加载时显示可用信息。其中包含设备ID以及对应设备的IP地址。

如大家所见，我们可以根据多种信息进行问题调试。

然而，这并不是检查的重点所在。真正重要的是意识fleet与设备本地systemd实例之间在何时发生服务状态冲突。这种问题的发生原因多种多样，例如某单元在内部启动或者停止其它单元。

要获取每项服务的状态信息，则可使用以下命令从运行该服务的主机systemd实例中提取：

fleetctl list-unitsUNIT                MACHINE             ACTIVE  [e-mail]   04856ec4.../10.132.249.212  active  [e-mail]   197a1662.../10.132.249.206  active  [e-mail]   e3ca8fd3.../10.132.252.37   active  [e-mail]     04856ec4.../10.132.249.212  active  [e-mail]     197a1662.../10.132.249.206  active  [e-mail]     e3ca8fd3.../10.132.252.37   active  runningnginx_lb.service        96ec72cf.../10.132.248.177  active  running

这里，我们可以看到全部列出服务皆处于运行状态。这显然与list-unit-files的显示结果不同。这是因为其中每项apache service都会启动相关apache-discovery服务，而不会单独通知fleet。这并不是错误，但却可能导致服务的实际状态发生冲突。

为了获取更多与服务相关的信息，大家可以使用fleetctl访问目标主机系统的systemctl状态及journalctl -u信息。命令如下：

fleetctl status service_name● [e-mail] - Apache web server service on port 4444Loaded: loaded (/run/fleet/units/[e-mail]; linked-runtime)Active: active (running) since Thu 2014-09-18 18:50:00 UTC; 7min agoProcess: 3535 ExecStartPre=/usr/bin/docker pull imchairmanm/apache (code=exited, status=0/SUCCESS)Process: 3526 ExecStartPre=/usr/bin/docker rm apache.%i (code=exited, status=0/SUCCESS)Process: 3518 ExecStartPre=/usr/bin/docker kill apache.%i (code=exited, status=0/SUCCESS)Main PID: 3543 (docker)CGroup: /system.slice/system-apache.slice/[e-mail]       └─3543 /usr/bin/docker run -t --name apache.4444 -p 10.132.249.212:4444:80 imchairmanm/apache /usr/sbin/apache2ctl -D FOREGROUND

或者使用以下命令查阅journal：

fleetctl journal service_name-- Logs begin at Mon 2014-09-15 14:54:12 UTC, end at Thu 2014-09-18 18:57:51 UTC. --Sep 17 14:33:20 lala2 systemd[1]: Started Apache web server service on port 4444.Sep 17 14:33:20 lala2 docker[21045]: AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.10. Set the 'ServerName' directive globally to suppress this messageSep 18 18:49:29 lala2 systemd[1]: Stopping Apache web server service on port 4444...Sep 18 18:49:39 lala2 docker[3500]: apache.4444Sep 18 18:49:39 lala2 systemd[1]: Stopped Apache web server service on port 4444.Sep 18 18:49:58 lala2 systemd[1]: Starting Apache web server service on port 4444...Sep 18 18:49:58 lala2 docker[3518]: apache.4444Sep 18 18:49:58 lala2 docker[3526]: apache.4444Sep 18 18:49:58 lala2 docker[3535]: Pulling repository imchairmanm/apacheSep 18 18:50:00 lala2 systemd[1]: Started Apache web server service on port 4444.

我们可以借此了解服务的失败原因。例如，如果我们的单元文件声明了一项不可用的关联性，则其将被显示于此（这可能是因为该关联未被加载至fleet当中）。

使用上述命令的一类常见错误如下：

Error running remote command: SSH_ AUTH _SOCK environment variable is not set. Verify ssh-agent is running. See https://github.com/coreos/fleet/blob/master/Documentation/using-the-client.md for help.

这意味着我们在接入该主机时，并没有转发自己的ssh用户代理。为了让fleet获取集群内其它设备的信息，其会利用我们保存在本地计算机上的SSH证书进行接入。

这时，大家需要在本地计算机上运行一套ssh代理并添加自己的专有密钥。本地计算机上的ssh代理运行方式如下：

eval $(ssh-agent)ssh-addIdentity added: /home/username/.ssh/id_rsa (/home/username/.ssh/id_rsa)

完成之后，我们应当利用-A选项接入自己的CoreOS主机并转发此信息：

ssh -A core@coreos_host

这样设备就能够利用ssh证书接入集群内的其它设备了，我们亦可以立足于远程集群成员读取systemd信息。

立足于运行该服务的主机进行容器故障排查

尽管我们单纯利用fleetctl即可获得大量重要信息，但有时候也必须前往运行该服务的主机以完成排查工作。

如上所述，我们可以通过转发SSH信息以轻松实现接入。在接入的主机上，我们可以利用fleetctl “hop”至其它设备。我们也可以指定一个设备ID或者直接使用服务名称。Fleetctl进程非常智能，足以了解我们所指的具体主机：

fleetctl ssh service_name

运行后，我们将获得被分配运行该服务的主机的ssh连接。当然，查询的服务必须处于“已载入”或者“已启动”状态。

在这里，大家需要访问全部本地故障排查工具。例如，大家可以通过journalctl标记那些可能并未显示在fleetctl journal命令中的条目：

journalctl -b --no-pager -u apache@4444

现在，大家可能希望对Docker问题进行故障排查。利用以下命令查看当前正在运行的容器列表：

docker psCONTAINER ID        IMAGE                       COMMAND                CREATED             STATUS              PORTS                         NAMESb68139630337        imchairmanm/apache:latest   "/usr/sbin/apache2ct   30 minutes ago      Up 30 minutes       10.132.249.212:4444->80/tcp   apache.4444

可以看到，目前只有一套容器正在运行。其中高亮部分的容器ID可用于更多Docker操作。

如果我们的服务未能启动，则容器自然也无法运行。要查看全部容器列表，其中包含现有及未能运行的容器，则可添加-a标记：

docker ps -aCONTAINER ID        IMAGE                       COMMAND                CREATED             STATUS                     PORTS                         NAMESb68139630337        imchairmanm/apache:latest   "/usr/sbin/apache2ct   31 minutes ago      Up 31 minutes              10.132.249.212:4444->80/tcp   apache.4444         4389108bff1a        imchairmanm/apache:latest   "/usr/sbin/apache2ct   28 hours ago        Exited (-1) 28 hours ago                                 apache.8888         5af6e4f95642        imchairmanm/lalala:latest   "/usr/sbin/apache2ct   3 days ago          Exited (-1) 3 days ago                                   apache.7777

而要查看新近启动的容器，而不管其具体状态，则可使用-l标记：

docker ps -lCONTAINER ID        IMAGE                       COMMAND                CREATED             STATUS              PORTS                         NAMESb68139630337        imchairmanm/apache:latest   "/usr/sbin/apache2ct   33 minutes ago      Up 33 minutes       10.132.249.212:4444->80/tcp   apache.4444

在找到了目标容器的ID之后，则可立足于Docker层面进行调查了。首先，查看相关日志：

docker logs container_id

由此可获得收集自该容器的日志信息，无论该容器当前是否处于运行状态。如果该容器以交互方式运行（包含-i与-t标记及一套shell会话），则可在此日志中对该会话进行操作。

大家也可以利用以下命令获取任意活动容器的运行进程列表：

docker top container_id

在容器内生成Shell会话

在运行中容器内开启一套shell会话的作法非常常见，而CoreOS则专门提供nsenter工具来实现这一效果。

Docker容器需要设置内核命名空间才能正常运行，而此工具能够在此类环境下启动该工具。第一步是获得该容器的PID，命令如下：

PID=$(docker inspect --format {{.State.Pid}} container_id)

现在，我们可以通过以下命令在目标容器环境下开启一套shell会话：

sudo nsenter -t $PID -m -u -i -n -p

容器环境下将出现一套shell会话。在这里，我们可以查看日志或者进行各类必要的故障排查操作。

根据容器的具体构建方式，大家可能会收到提示称无法找到bash。在这种情况下，我们可以在命令结尾处使用sh：

sudo nsenter -t $PID -m -u -i -n -p /bin/sh

总结

当然，这些只是在CoreOS集群内实现故障排查的一小部分可行方案。通过今天的教程，大家应该已经了解了如何对cloud-config文件、集群内设备以及服务启动状态进行故障排查。顺带一提，对Docker容器及服务自身的问题进行追踪将在其它教程中另行介绍。

作为一种前提性思路，我们掌握的系统信息越多，故障排查工作就越易于实现。我们应当清晰掌握每款组件的功能角色，各组件之间的交互作用以及对系统功能的影响。如果在追踪问题的时候发现无处下手，那么复习一下CoreOS基础知识往往能起到意料之外的良好效果。

本文来源自DigitalOcean Community。英文原文：How To Troubleshoot Common Issues with your CoreOS Servers By Justin Ellingwood

翻译：diradw