Consul运维和监控

简介

这个章节中的内容包含一系列运维高级指南，包括高级网络配置、安全设置、中断恢复、监控和故障排除。

Consul集群监控和指标

用户在设置完数据中心之后，需要确保部署正常并建立基准指标。本指南将从两大部分介绍几种类型的指标：Consul健康指标和服务器健康指标。
Consul健康指标：

• 事务时间（Transaction Timing）
• 领导者变更（Leadership Changes）
• 自动驾驶（Autopilot）
• 垃圾回收（Garbage Collection）

服务器健康指标：

• 文件描述符（File Descriptors）
• CPU使用率（CPU Usage）
• 网络活动（Network Activity）
• 磁盘活动（Disk Activity）
• 内存使用情况（Memory Usage）

对于每个指标，我们会阐述其重要性所在，也会确定指标数值，判定健康及不健康状态。
首先，我们需要了解三种收集指标的方法：SIGUSR1、HTTP API、telemetry。在开始阅读本指南前，建议用户已经配置了ACL。

如何收集指标

总共有三种收集指标的方案。第一个，也是最简单的方法是使用SIGUSR1一次性转储当前测量值；第二种方法是使用HTTP API获得类似的一次性转储；第三种方法（也是最常用于长期监视的一种方法）是在Consul配置文件中启用telemetry。

本地使用

为了获得当前指标的一次性转储，我们可以将SIGUSR1信号发送到Consul进程。

kill -USR1 <process_id>

输出内容将发送到系统日志，例如/var/log/messages或journald。如果用户正在通过Consul监听器监控终端中的Consul流程，会在输出中看到指标信息。
尽管这是快速了解单个Consul代理运行状况的最简单方法，但随时间变化查看指标情况更有意义。

API GET请求

接下来，我们使用HTTP API快速收集指标：

curl http://127.0.0.1:8500/v1/agent/metrics

在生产中，用户会使用ACL令牌设置凭据并启用TLS以进行安全通信。一旦配置了ACL，就需要在请求中传递令牌。

curl --header "X-Consul-Token: <YOUR_ACL_TOKEN>" \
    https://127.0.0.1:8500/v1/agent/metrics

这是一种快速收集指标的好方法，除此之外还可以将其添加到脚本中，或者与支持HTTP抓取数据的监控代理（例如Prometheus）一起使用，做到数据可视化。

启用telemetry

最后，我们可以配置Consul将遥测数据发送到远程监控系统。这样，用户就可以在时间维度上监控代理的运行状态，发现指标趋势，并为将来的需求提前进行计划。为此，用户需要监控代理程序和一个控制台。
Consul支持以下遥测（telemetry）代理：

• Circonus
• DataDog（通过 dogstatsd）
• StatsD（通过 statsd、statsite、telegraf等）

如果用户使用的是StatsD，则还需要兼容的数据库和服务器，例如Grafana、Chronograf或Prometheus。
用户可以在配置文件（例如server.hcl）中配置遥测（telemetry），客户端或服务端都支持遥测。通常，用户至少要在所有服务端上启用它（无论有表决权或无表决权），这样可以监控整个数据中心的运行状况。
将遥测发送到DataDog的server.hcl示例片段如下：

telemetry {
  dogstatsd_addr = "localhost:8125"
  disable_hostname = true
}

在现有数据中心上启用遥测时，需要重新加载Consul进程。这可以通过consul reload或kill -HUP <process_id>来完成，建议从非领导者开始，一次重装一台机器。

Consul健康指标

Consul健康指标显示有关Consul数据中心的信息。它们包括键值存储（key value store），事务（transaction），raft协议，领导者变更（leadership changes），自动驾驶调整（autopilot tuning）和垃圾收集（garbage collection）的性能指标。

事务时间（Transaction Timing）

以下指标表示完成各个部分写入操作所花费的时间（包括Consul KV和Consul服务器Raft）。通常，这些值应保持大致一致，且每个值均不超过几毫秒。

指标名	描述
consul.kvs.apply	完成KV Store更新所需的时间
consul.txn.apply	完成事务操作所需的时间
consul.raft.apply	周期时间内发生的Raft事务数
consul.raft.commitTime	提交一条Raft日志到领导者上所需的时间

Consul服务器的负载异常或服务器本身出现问题会造成时间值发生突变。 具体来说，如果这些指标中的任何一个指标，偏离上一个小时内的基线超过50％，则表明存在问题，以下是事务健康指标的示例：

'consul.raft.apply': Count: 1 Sum: 1.000 LastUpdated: 2018-11-16 10:55:03.673805766 -0600 CST m=+97598.238246167
'consul.raft.commitTime': Count: 1 Sum: 0.017 LastUpdated: 2018-11-16 10:55:03.673840104 -0600 CST m=+97598.238280505

领导者变更（Leadership Changes）

在健康的环境中，Consul数据中心应具有稳定的领导者。 除非用户手动更改领导者（比如将服务器从群集中移出），否则不应进行任何领导者更改。 如果发生意外选举或领导者变更，则应调查Consul服务器之间是否存在网络问题，另一个可能的原因是Consul服务器无法跟上事务负载。
注意：下列度量标准来自跟随者节点（follower nodes），而非领导者（leader）：

指标名	描述
consul.raft.leader.lastContact	测量领导者最后一次连接到追随者确认领导者租期（leader lease）的时间
consul.raft.state.candidate	当Consul服务器发起一次选举时累加
consul.raft.state.leader	当Consul服务器变成领导者时累加

如果candidate或leader指标大于0或者lastContact指标大于200ms，则应排除上述可能的原因之一，这是领导者健康指标的示例：

'consul.raft.leader.lastContact': Count: 4 Min: 10.000 Mean: 31.000 Max: 50.000 Stddev: 17.088 Sum: 124.000 LastUpdated: 2018-12-17 22:06:08.872973122 +0000 UTC m=+3553.639379498
'consul.raft.state.leader': Count: 1 Sum: 1.000 LastUpdated: 2018-12-17 22:05:49.104580236 +0000 UTC m=+3533.870986584
'consul.raft.state.candidate': Count: 1 Sum: 1.000 LastUpdated: 2018-12-17 22:05:49.097186444 +0000 UTC m=+3533.863592815

自动驾驶（Autopilot）

有两个自动驾驶指标也可以告知Consul数据中心的运行状况。

指标名	描述
consul.autopilot.healthy	跟踪本地服务器群集的整体运行状况
consul.autopilot.failure_tolerance	跟踪本地服务器群集可能丢失的表决服务器数量

consul.autopilot.healthy指标为布尔值，1表示健康，0表示不健康。返回值为0时应该发出警报，下面是运行状况良好的数据中心的示例：

[2018-12-17 13:03:40 -0500 EST][G] 'consul.autopilot.healthy': 1.000

consul.autopilot.failure_tolerance指标表示数据中心在进入不健康状态前可能会丢失多少个Consul服务器，返回值为0时应该发出警报，以便采取积极措施来保证数据中心正常运行。

垃圾回收（Garbage Collection）

垃圾回收暂停是一个STW事件，所有运行时线程都将被阻塞，直到GC完成。在健康的环境中，这些暂停仅应持续几纳秒。如果内存使用率很高，则Go运行时可能会频繁启动GC进程，以至于减慢Consul的速度。用户可能会观察到领导人选举变得更频繁，写入时间也会变长。

指标名	描述
consul.runtime.total_gc_pause_ns	自Consul启动以来，垃圾收集STW暂停消耗的时间

如果返回值大于2s/min，则需要调查具体原因，如果每分钟超过5秒，则应任务数据中心处于紧急状态，下面是健康的GC暂停时间示例：

'consul.runtime.total_gc_pause_ns': 136603664.000

注意，total_gc_pause_ns是一个累积计数器，因此，为了计算速率（例如每分钟的GC时间），需要使用诸如non_negative_difference之类的函数。

服务器健康指标

服务器指标提供有关数据中心运行状况的信息，包括文件描述符、CPU使用率、网络活动、磁盘活动和内存使用情况。

文件描述符（File Descriptors）

大多数Consul操作都需要文件描述符句柄，包括接收来自另一台主机的连接，在服务器之间发送数据以及将快照写入磁盘。如果Consul用完了句柄，它将停止接受连接。

指标名	描述
linux_sysctl_fs.file-nr	在主机上所有进程中使用的文件句柄数
linux_sysctl_fs.file-max	可用文件句柄的总数

默认情况下，进程和内核的限制是保守的，用户可能希望将限制增加到默认值以外。如果linux_sysctl_fs.file-nr值超过linux_sysctl_fs.file-max的80％，则应增加文件句柄，以下是文件句柄指标的示例：

linux_sysctl_fs, host=statsbox, file-nr=768i, file-max=96763i

CPU使用率（CPU Usage）

Consul无论是服务端或客户端都不是CPU密集型服务，CPU使用率过高表示一次性执行了太多操作。

指标名	描述
cpu.user_cpu	用户进程（例如Vault或Consul）使用CPU的百分比
cpu.iowait_cpu	等待I/O任务花费的CPU时间百分比

如果cpu.iowait_cpu大于10%，对Consul来说是比较严重的问题，表明Consul正在等待将数据写入磁盘，有可能是Raft将快照写入磁盘的频率过于频繁，以下是运行状况良好的CPU指标的示例：

cpu, cpu=cpu-total, usage_idle=99.298, usage_user=0.400, usage_system=0.300, usage_iowait=0, usage_steal=0

网络活动（Network Activity）

网络活动应大体保持一致，Consul网络流量突然激增可能是由于客户端（例如Vault）配置错误而导致请求过多，大多数代理会针对每个网络接口报告单独的指标，因此用户需要确保正在监视正确的指标。

指标名	描述
net.bytes_recv	每个网络接口上收到的字节
net.bytes_sent	每个网络接口上传输的字节

网络指标突然增加，与基线之间的偏差大于50％，表示有太多请求未得到处理，以下是网络活动指标的示例：

net, interface=enp0s5, bytes_sent=6183357i, bytes_recv=262313256i

注意：网络指标是累积计数器，因此如果计算速率（例如字节/秒），用户需要应用诸如non_negative_difference之类的函数。

磁盘活动（Disk Activity）

通常情况下，因为Consul将所有内容保留在内存中，磁盘活动较少。如果Consul主机正在将大量数据写入磁盘，则意味着Consul可能有较重的写入负载，因此经常将Raft快照频繁写入磁盘。也有可能在生产中意外启用了调试/跟踪（debug/trace）日志记录，这可能会影响性能。

指标名	描述
diskio.read_bytes	从块设备读取的字节
diskio.write_bytes	写入块设备的字节
diskio.read_time	读取磁盘花费的时间，单位是毫秒
diskio.write_time	写入磁盘花费的时间，单位为毫秒

磁盘度量指标突然发生较大变化，与基准偏差大于50％或与基准的偏差大于3个标准偏差，表示Consul的磁盘I/O过多。磁盘I/O过多会导致系统其余部分变慢或不可用，因为内核会花费所有时间等待I/O完成。以下是磁盘活动指标的示例：

diskio, name=sda5, read_bytes=522298368i,  write_bytes=1726865408i, read_time=7248i, write_time=133364i

内存使用情况（Memory Usage）

如前所述，Consul将其所有数据（KV存储，目录（catalog）等）均保留在内存中。如果Consul消耗了所有可用内存，系统将崩溃。用户应该监控可用内存，确保某些内存可用于其他系统进程，并且交换使用率（swap usage）应保持在0％，以获得最佳性能。

指标名	描述
consul.runtime.alloc_bytes	Consul进程分配的内存字节数
consul.runtime.sys_bytes	从操作系统获取的内存字节数
mem.total	服务器上可用的内存总量
mem.used_percent	正在使用的内存百分比
swap.used_percent	正在使用的交换空间百分比

如果sys_bytes超过total_bytes的90％，mem.used_percent超过90％或swap.used_percent大于0，则表明Consul服务器的内存不足。如果满足以下三个条件任一，则应增加Consul可用的内存，以下是内存使用情况指标的示例：

'consul.runtime.alloc_bytes': 11199928.000
'consul.runtime.sys_bytes': 24627448.000
mem,  used_percent=31.492,  total=1036312576i
swap, used_percent=1.343

使用Telegraf监控Consul

Consul提供了一系列各式各样的指标，运维人员可以通过它们衡量集群的运行状况和稳定性，诊断或者预测潜在的问题。现实场景中，有许多监控工具可供参考，在这篇指南中，我们将结合使用Telegraf_plugin和Consul支持的StatsD协议。
用户可以阅读telemetry文档，了解Consul可用指标的完整列表。
在本指南中，用户可以看到：

• 配置Telegraf收集StatsD和主机级别指标；
• 配置Consul将指标发送到Telegraf；
• 可视化指标示例；
• 了解重要指标进行汇总并发出警报。

安装Telegraf

Telegraf的安装依赖用户的操作系统，我们建议用户遵循官方的Telegraf安装文档。

配置Telegraf

Telegraf充当StatsD代理，可以收集Consul所在运行机器的其他指标。Telegraf本身附带了各种各样的输入（input）插件，可以收集很多数据源。
我们将启用一些最常用的输入插件来监控CPU，内存，磁盘I/O，网络和进程状态，它们对于调试Consul群集问题很有帮助。
telegraf.conf文件以全局选项（global options）开头：

[agent]
  interval = "10s"
  flush_interval = "10s"
  omit_hostname = false

我们默认将收集间隔时间设置为10秒，并要求Telegraf在每个指标中包含一个主机（host）标签。
如上所述，Telegraf还允许用户在度量标准上设置其他标签。这里，我们将为服务器角色和数据中心名称添加了标签，之后我们可以在Grafana中使用这些标签来过滤查询（例如，创建仅显示具有consul-server角色的服务器或us-east-1数据中心中的服务器的仪表板）。

[global_tags]
  role = "consul-server"
  datacenter = "us-east-1"

接下来，我们在8125端口上使用UDP设置StatsD监听器，传输的信息会解析DogStatsD-compatible标签：

[[inputs.statsd]]
  protocol = "udp"
  service_address = ":8125"
  delete_gauges = true
  delete_counters = true
  delete_sets = true
  delete_timings = true
  percentiles = [90]
  metric_separator = "_"
  parse_data_dog_tags = true
  allowed_pending_messages = 10000
  percentile_limit = 1000

现在，我们可以为CPU，内存，网络I/O和磁盘I/O等配置输入，它们中的大多数不需要任何配置，这里需要确保inputs.net中的interfaces名称与在ifconfig中看到的interfaces名称匹配：

[[inputs.cpu]]
  percpu = true
  totalcpu = true
  collect_cpu_time = false

[[inputs.disk]]
  # mount_points = ["/"]
  # ignore_fs = ["tmpfs", "devtmpfs"]

[[inputs.diskio]]
  # devices = ["sda", "sdb"]
  # skip_serial_number = false

[[inputs.kernel]]
  # no configuration

[[inputs.linux_sysctl_fs]]
  # no configuration

[[inputs.mem]]
  # no configuration

[[inputs.net]]
  interfaces = ["enp0s*"]

[[inputs.netstat]]
  # no configuration

[[inputs.processes]]
  # no configuration

[[inputs.swap]]
  # no configuration

[[inputs.system]]
  # no configuration

另一个实用的插件是procstat插件，它可以报告用户选择的进程的指标：

[[inputs.procstat]]
  pattern = "(consul)"

Telegraf还有一个插件，该插件使用Consul API查询数据，监控Consul代理的运行状况：

[[inputs.consul]]
  address = "localhost:8500"
  scheme = "http"

Consul的Telegraf配置

Consul将遥测数据发送到Telegraf，就像在代理配置中添加遥测部分一样简单：

{
  "telemetry": {
    "dogstatsd_addr": "localhost:8125",
    "disable_hostname": true
  }
}

如上所述，我们只需要指定两个选项。dogstatsd_addr指定StatsD守护程序的主机名和端口号。
这里注意，我们指定了DogStatsD格式，而不是默认的StatsD，这样Consul在发送指标时会携带标签。Grafana可以使用标签来过滤仪表板上的数据（例如，仅显示role=consul-server的数据。）Telegraf与DogStatsD格式兼容，并且允许我们添加自己的标签。
第二个选项告诉Consul不要在发送到StatsD的指标中插入主机名，因为主机名将作为标签发送。如果没有此选项，单个度量指标consul.raft.apply将成为多个度量指标：

consul.server1.raft.apply
consul.server2.raft.apply
consul.server3.raft.apply

如果用户使用其他代理（例如Circonus、Statsite或Plain StatsD），则可能需要更改此配置。

Consul Telegraf指标可视化

用户可以使用Grafana或Chronograf之类的工具对Telegraf中的数据进行可视化，这是Grafana仪表盘示例：

consul-grafana-screenshot.png

多数据中心间的ACL复制

用户可以配置令牌、策略和角色跨多个数据中心工作。ACL复制有以下几个好处：

1. 它支持在多个数据中心之间对节点和服务进行身份验证；
2. 从数据中心可以为在主数据中心中创建的所有ACL组件提供故障转移；
3. 共享策略减少运维人员的冗余操作。

先决条件

在开始本章节之前，每个数据中心都需要启用ACL，使用ACL增强Consul安全性章节中已经详细讲述了配置过程，本章节会覆盖其未涵盖的Consul代理的ACL复制配置。此外，WAN Gossip通信是必须的。

简介

在本指南中，用户将配置ACL复制，其中包含以下过程：

• 在主数据中心中的所有Consul代理上设置primary_datacenter参数；
• 创建复制令牌；
• 在从数据中心中的所有Consul代理上配置primary_datacenter参数；
• 在从数据中心中的服务器上启用令牌复制；
• 将复制令牌应用于从数据中心中的所有服务器。

配置主数据中心

注意，如果主数据中心使用默认数据中心名称dc1，则必须在从数据中心上设置一个不同的数据中心名称。否则，两个数据中心都将被命名为dc1，发生冲突。

Consul服务端和客户端

即使默认情况下主数据中心已经启用了，用户需要在所有服务端和客户端都显式设置primary_datacenter参数，代理配置如下所示：

{
  "datacenter": "primary_dc",
  "primary_datacenter": "primary_dc",
  "acl": {
    "enabled": true,
    "default_policy": "deny",
    "down_policy": "extend-cache",
    "enable_token_persistence": true
  }
}

primary_datacenter参数设置主数据中心具有所有ACL信息权限。客户端也同样需要配置，以便它们将API请求转发到服务端，最后，启动代理：

$ consul agent -config-file=server.json

需要在所有代理上都重复配置，如果用户是首次配置ACL，还需要完成引导（bootstrap）过程。

创建ACL管理的复制令牌

接下来，需要创建拥有如下权限的复制令牌，用于管理ACL：

• acl=“write”：允许用户复制令牌；
• operator =“ write”：用于复制代理默认（proxy-default）配置，并在从数据中心启用CA证书签名；
• service_prefix, policy = "read" and intentions = "read"：用于复制服务默认（service-default）配置、CA和intention。

acl = "write"

operator = "write"

service_prefix "" {
  policy = "read"
  intentions = "read"
}

现在，已经定义好了ACL规则，使用这些规则创建一个策略：

$ consul acl policy create -name replication -rules @replication-policy.hcl
ID: 240f1d01-6517-78d3-ec32-1d237f92ab58
Name: replication
Description: Datacenters:
Rules: acl = "write"

operator = "write"

service_prefix "" { policy = "read"  intentions = "read" }

最后，使用新创建的策略来创建复制令牌：

$ consul acl token create -description "replication token" -policy-name replication
AccessorID: 67d55dc1-b667-1835-42ab-64658d64a2ff
SecretID: fc48e84d-3f4d-3646-4b6a-2bff7c4aaffb
Description: replication token
Local: false
Create Time: 2019-05-09 18:34:23.288392523 +0000 UTC
Policies:
  240f1d01-6517-78d3-ec32-1d237f92ab58 - replication

在从数据中心启用ACL复制

一旦配置了主数据中心并创建了复制令牌，用户就可以设置从数据中心了。

配置服务端

用户需要将所有服务器上的primary_datacenter参数设置为主数据中心的名称，并将enable_token_replication设置为true：

{
  "datacenter": "dc_secondary",
  "primary_datacenter": "primary_dc",
  "acl": {
    "enabled": true,
    "default_policy": "deny",
    "down_policy": "extend-cache",
    "enable_token_persistence": true,
    "enable_token_replication": true
  }
}

启动代理：

$ consul agent -config-file=server.json

对所有服务端机器重复执行上述过程。

将复制令牌应用于服务端

使用命令行指令，将复制令牌应用于所有服务器：

$ consul acl set-agent-token replication <token> 
ACL token "replication" set successfully

在所有服务端机器上重复此过程，如果首次配置ACL，还需要设置代理令牌。

配置客户端

用户需要将所有服务器上的primary_datacenter参数设置为主数据中心的名称，并将enable_token_replication设置为true：

{
  "datacenter": "dc_secondary",
  "primary_datacenter": "primary_dc",
  "acl": {
    "enabled": true,
    "default_policy": "deny",
    "down_policy": "extend-cache",
    "enable_token_persistence": true,
    "enable_token_replication": true
  }
}

启动代理：

$ consul agent -config-file=server.json

对所有客户端机器重复执行上述过程。

检查复制

如果用户已经设置了ACL复制，可以使用HTTP API来检查数据中心的配置：

$ curl http://localhost:8500/v1/acl/replication?pretty
{
  "Enabled":true,
  "Running":true,
  "SourceDatacenter":"primary_dc",
  "ReplicationType":"tokens",
  "ReplicatedIndex":19,
  "ReplicatedTokenIndex":22,
  "LastSuccess":"2019-05-09T18:54:09Z",
  "LastError":"0001-01-01T00:00:00Z"
}

注意：ReplicationType应为令牌，这意味着令牌、策略和角色正在复制。

添加&删除服务器

Consul的设计原则是要求运维人员尽少去操作，但是对Consul集群的任何更改都必须谨慎处理。为了更好地理解原因，阅读consensus协议将很有用。 简而言之，Consul服务器执行领导者选举和复制，在处理更改时，服务器数量必须大于（N/2）+ 1。这意味着如果有3个服务器节点，则至少必须有2个可用。
通常，如果要同时添加和删除节点，最好先添加新节点，然后再删除旧节点。
在本章节中，我们将介绍添加和删除服务器的不同方法。

手动添加一台新服务器

手动添加新服务器通常很简单，请使用-server标志启动新代理。此时，服务器不属于任何一个集群，并且会发出类似以下内容的信息：

$ consul agent -server 
[WARN] raft: EnableSingleNode disabled, and no known peers. Aborting election.

这意味着它与其他节点互不通信，也没有配置为自行选举。这是符合预期的，现在我们可以使用join命令将节点添加到现有集群中。对于一台新服务器，我们可以将它加入任何现有集群：

$ consul join <Existing Node Address> 
Successfully joined cluster by contacting 1 nodes.

需要注意的是，可以指定任何节点（包括非服务端机器）加入集群，通常，此方法适用于测试，但不建议用于生产部署。对于生产集群，用户可能需要使用代理配置项来添加其他服务器。

添加具有代理配置的服务器

在生产环境中，应使用代理配置选项retry_join参数。retry_join可用作命令行标志，或配置在代理配置文件中，使用Consul命令行指令如下：

$ consul agent -retry-join=52.10.110.11 -retry-join=52.10.110.12 -retry-join=52.10.100.13

配置文件内容如下：

{
  "bootstrap": false,
  "bootstrap_expect": 3,
  "server": true,
  "retry_join": ["52.10.110.11", "52.10.110.12", "52.10.100.13"]
}

retry_join将确保如果服务器由于任何原因（包括重新启动节点）而失去与群集的连接，则它可以在返回时重新加入。除了使用静态IP外，它对于其他发现机制（例如基于云元数据的自加入）也很有用。 服务端和客户端都可以使用此方法。

服务器调度

为确保Consul服务器能正确加入群集，应监控服务器调度。Gossip协议用于正确发现集群中的所有节点，加入节点后，集群领导者会记录以下内容：

[INFO] raft: Added peer 127.0.0.2:8300, starting replication

这意味着Raft（底层共识协议）已经添加了节点并开始复制状态，由于现有群集状态可能已经遥遥领先，因此新节点需要一些时间才能同步完信息。 要了解详细信息，可以在领导者服务器上运行info指令：

$ consul info
...
raft:
    applied_index = 47244
    commit_index = 47244
    fsm_pending = 0
    last_log_index = 47244
    last_log_term = 21
    last_snapshot_index = 40966
    last_snapshot_term = 20
    num_peers = 4
    state = Leader
    term = 21
...

这会提供有关Raft的各种信息，特别是last_log_index参数显示磁盘上的最后一个日志。可以在新服务器上运行info命令，查看数据同步的进度。最终，新的服务器同步进度会被赶上。
最好一次添加一台服务器，使数据可以来得及同步。这样可以避免现有服务器出现故障时，新增的服务器同步时发生数据丢失。

手动删除一台服务器

删除服务器必须需要小心，以免造成服务不可用。对于有N个服务器的群集，至少需要（N/2）+ 1个可用，群集才能正常运行。参考下表，如果用户有3台服务器，其中1台出现故障，则再删除任何一台服务器将导致集群不可用。

服务器	仲裁个数	容错能力
1	1	0
2	2	0
3	2	1
4	3	1
5	3	2
6	4	2
7	4	3

为避免这种情况，有必要先将新服务器添加到群集中，以增加群集的故障容忍度，然后再删除旧服务器。 即使所有3个节点都在工作，删除1个节点也会使群集处于崩溃状态。
当用户验证好现有的服务器运行状况良好，就可以删除服务器节点了，操作过程很简单，仅需向服务器发送leave指令即可。

$ consul leave

服务器下线日志如下：

...
[INFO] consul: server starting leave
...
[INFO] raft: Removed ourself, transitioning to follower
...

领导者还会输出各类日志，包括：

...
[INFO] consul: member 'node-10-0-1-8' left, deregistering
[INFO] raft: Removed peer 10.0.1.8:8300, stopping replication
...

此时，节点已经从集群中正常删除，并会关闭。
在服务端上启用consul leave会减少仲裁机器个数。即使集群最初使用bootstrap_expect设置仲裁机器个数，后续也可以执行consul leave命令减少仲裁机器个数，最后仲裁个数可以只剩一个，这时可以继续提交写入请求，但是比起之前仲裁机器个数多的时候，可能会丢失一些写入请求。
在删除错加入集群的服务后，需要清除客户端和服务器节点上数据目录上（-data-dir）的内容，这些删除服务器的方法假定服务器本身是正常的，如果群集由于仲裁丢失或数据损坏而没有领导者，则应计划执行中断恢复（outage recovery）。

手动强制删除服务器

在某些情况下，可能无法正常删除服务器。例如，如果服务器发生故障，无法发出下线请求。 相反，群集将检测到故障，并且还将连续重试复制。
如果服务器可以恢复，则最好先使其恢复联机，然后优雅地下线。但是，如果不能正常下线，则可以使用force-leave命令强制删除服务器。

$ consul force-leave <node>

自动驾驶系统（Autopilot）

自动驾驶（Autopilot）系统可以对Consul服务器进行自动、操作友好的管理，其中包括清理死服务器，监控Raft群集状态以及稳定地引入服务器，这个功能在Consul 0.8.0中引入。
使用自动驾驶系统时（清理死服务器功能除外），必须将所有服务器上Consul代理配置中的raft_protocol参数配置为3或更高。在Consul 0.8版本中，此配置项默认为2；在Consul 1.0中，默认值为3。其它更多信息可以参考Consul 1.0中有关Raft协议版本升级部分。
在本章节，用户将看到Consul如何跟踪服务器的稳定性，如何调整参数，还将了解一下自动驾驶系统的其他细节：

• 服务器保持稳定状态
• 清理死服务器
• 区域冗余（仅适用于Consul企业版）
• 自动升级（仅适用于Consul企业版）

注意，我们使用的示例是基于Consul1.7版本的，默认情况下，我们是启用自动驾驶功能的，Consul企业版的功能我们此处也不做详细介绍。

默认配置

最初引导数据中心时，领导者会加载代理机器的自动驾驶系统配置。由于自动驾驶功能默认是开启的，我们仅需在有必要的时候修改配置禁用它们。
所有Consul服务器都应打开自动驾驶功能，以确保发生故障时，服务器之间状态保持一致性。 此外，必须启用自动驾驶才能使用其下的任何子功能，子功能本身可以独立配置。
用户可以使用Consul命令行指令或/v1/operator/autopilot端点检查默认值：

• 命令行指令

$ consul operator autopilot get-config
CleanupDeadServers = true
LastContactThreshold = 200ms
MaxTrailingLogs = 250
MinQuorum = 0
ServerStabilizationTime = 10s
RedundancyZoneTag = ""
DisableUpgradeMigration = false
UpgradeVersionTag = ""

• 使用API调用

$ curl http://127.0.0.1:8500/v1/operator/autopilot/configuration
{
  "CleanupDeadServers": true,
  "LastContactThreshold": "200ms",
  "MaxTrailingLogs": 250,
  "MinQuorum": 0,
  "ServerStabilizationTime": "10s",
  "RedundancyZoneTag": "",
  "DisableUpgradeMigration": false,
  "UpgradeVersionTag": "",
  "CreateIndex": 5,
  "ModifyIndex": 5
}

服务器健康检查

在领导者内部运行健康状态检查来跟踪服务器的稳定性，如果满足以下所有条件，则表示服务器运行状况良好：

• 健康状态为Alive；
• 自上次与当前领导者联系的时间低于LastContactThreshold（默认200ms）；
• 最新的Raft任期（term）与领导人的任期匹配；
• 领导者落后的Raft日志数目不超过MaxTrailingLogs（默认250）；

可以通过/v1/operator/autopilot/health端点查看这些健康检查的状态，其中顶层的Healthy字段表示数据中心的整体状态：

$ curl localhost:8500/v1/operator/autopilot/health | jq .

{
  "Healthy": true,
  "FailureTolerance": 1,
  "Servers": [
    {
      # ...
      "Name": "server-dc1-1",
      "Address": "10.20.10.11:8300",
      "SerfStatus": "alive",
      "Version": "1.7.2",
      "Leader": false,
            # ...
      "Healthy": true,
      "Voter": true,
      # ...
    },
    {
      # ...
      "Name": "server-2",
      "Address": "10.20.10.12:8300",
      "SerfStatus": "alive",
      "Version": "1.7.2",
      "Leader": false,
      # ...
      "Healthy": true,
      "Voter": true,
      # ...
    },
    {
      # ...
      "Name": "server-3",
      "Address": "10.20.10.13:8300",
      "SerfStatus": "alive",
      "Version": "1.7.2",
      "Leader": false,
      # ...
      "Healthy": true,
      "Voter": false,
      # ...
    }
  ]
}

服务器稳定时间

将新服务器添加到数据中心后，会先经历一段时间的等待期，在这段时间内它必须处于健康状态并保持稳定，然后才能晋升为有表决权的成员，这个由ServerStabilizationTime参数定义，默认情况为10秒。
如果用户需要配置不同的时间来使节点准备就绪，例如，在启动时进行了一些额外的VM检查，这可能会影响节点资源的可用性，此时可以调整参数并为其分配不同的准备时长。

$ consul operator autopilot set-config -server-stabilization-time=15s 
Configuration updated!

使用get-config命令检查配置项：

$ consul operator autopilot get-config
CleanupDeadServers = true
LastContactThreshold = 200ms
MaxTrailingLogs = 250
MinQuorum = 0
ServerStabilizationTime = 15s
RedundancyZoneTag = ""
DisableUpgradeMigration = false
UpgradeVersionTag = ""

清理死服务器

如果禁用了自动驾驶，系统需要72个小时才能自动恢复死服务器，或者需要运维人员编写脚本来强制删除机器。此时如果另一台服务器发生故障，即使故障的Consul服务器已被自动更换，也可能会危及仲裁。当替换的Consul服务器上线后，自动驾驶系统可以通过快速删除发生故障的服务器来帮助防止此类中断。服务器在清理过程中被删除后会进入left状态。
启用自动驾驶的死服务器清理功能后，系统将定期清理死服务器并将其从Raft设备集中删除，以防止它们干扰法定人数和领导者选举。每当将新服务器成功添加到数据中心时，清理过程也会自动触发。
我们建议用户启用该功能，以避免在Consul管理中引入手动操作，以确保有故障的节点不会在Raft池中保留太长时间而无需手动删除。将故障节点移除工作委派给外部工具，或者在环境中，可以使用consul operator命令禁用死服务器清理功能：

$ consul operator autopilot set-config -cleanup-dead-servers=false 
Configuration updated!

使用get-config命令检查配置项：

$ consul operator autopilot get-config
CleanupDeadServers = false
LastContactThreshold = 200ms
MaxTrailingLogs = 250
MinQuorum = 0
ServerStabilizationTime = 10s
RedundancyZoneTag = ""
DisableUpgradeMigration = false
UpgradeVersionTag = ""

中断恢复

在发生服务中断时，不要过于惊慌，这是很关键的一步。
根据用户的部署配置，有可能仅一台机器发生故障就使整个集群不可用。这时需要运维人员操作干预，但是过程很简单。
本章节概述了，由于群集中大多数服务器节点丢失后，Consul从中断中恢复的过程。 中断类型有几种，具体取决于服务器节点的数量和发生故障的服务器节点的数量。我们将概述如何从以下场景恢复服务：

• 单服务器群集发生故障：此时仅有一台Consul服务器，并发生故障；
• 多服务器群集单台服务器发生故障：Consul群集中有三台或更多服务器，仅有一台服务器发生故障；
• 多服务器群集多台服务器发生故障：Consul群集中有三台或更多服务器，有多台服务器发生故障，这种情况可能是最严重的，因为它可能导致数据丢失。

单服务器群集发生故障

如果只有一台服务器，但该服务器发生了故障，只需重新启动它即可，单个服务器配置需要-bootstrap或-bootstrap-expect = 1标志：

$ consul agent -bootstrap-expect=1

如果无法恢复服务器，则需要新启动一台服务器。单服务器群集容易出现不可恢复的服务器故障，且没有数据备份，由于没有将数据复制到任何其他服务器，因此数据丢失难以避免，所以我们不建议部署单服务器集群。

升级Raft协议

将服务器的-raft-protocol参数版本从2升级到3后，服务器将不再允许添加运行较旧版本的服务器。
在单服务器群集方案中，重新启动服务器可能会导致服务器无法选举自己作为领导者，从而群集无法使用。要想服务从故障恢复，可以打开Consul服务器的-data-dir目录，其下有一个raft/子目录，在raft/目录中创建一个raft/peers.json文件。
对于Raft协议版本为3或更高版本，应将其格式化为JSON数组，其中包含Consul服务器的节点ID，地址：端口和选举权信息，如下所示：

[{ "id": "<node-id>", "address": "<node-ip>:8300", "non_voter": false }]

请确保node-id和node-ip配置正确，最后，重新启动Consul服务器。

多服务器群集单台服务器发生故障

如果发生故障的服务器是可恢复的，最好的选择是使用相同IP地址加入集群，使其恢复联机状态。同样，如果用户需要重建新的Consul服务器以替换发生故障的节点，则可能希望立即执行此操作。注意，重建的服务器必须与故障服务器具有相同的IP地址。同样，一旦该服务器联机并重新加入，群集将重新返回到完全正常的状态。

$ consul agent -bootstrap-expect=3 -bind=192.172.2.4 -auto-rejoin=192.172.2.3

这两种策略都可能需要很长时间才能重建故障服务器。如果这不切实际，或者无法选择使用相同IP构建新服务器时，需要删除发生故障的服务器。通常，如果故障服务器仍然是集群的成员，则可以使用consul force-leave命令删除该服务器。

$ consul force-leave <node.name.consul>

如果consul force-leave无法删除服务器，则有另外两种方法可以删除它，具体取决于Consul的版本：

• 对于Consul 0.7或更高版本，如果集群中有领导者，则可以使用consul operator命令立即删除过时的节点服务器，而不会造成停机；
• 对于0.7之前的Consul版本，用户可以使用其他服务器上的raft/peers.json恢复文件手动删除过时的节点服务器。 执行此过程Consul需要停机。

在Consul 0.7或更高版本中，可以使用consul operator命令检查Raft配置：

$ consul operator raft list-peers
Node ID Address State Voter RaftProtocol
alice 10.0.1.8:8300 10.0.1.8:8300 follower true 3
bob 10.0.1.6:8300 10.0.1.6:8300 leader true 3
carol 10.0.1.7:8300 10.0.1.7:8300 follower true 3

多服务器群集多台服务器发生故障

如果有多台服务器发生故障，导致仲裁丢失或者完全中断，则可以使用群集中其余服务器上的数据进行部分恢复（partial recovery）。在这种情况下，可能会因为多个服务器丢失而导致数据丢失，因此有关所提交内容的信息可能不完整。 恢复过程中隐式（implicitly）提交了所有Raft日志条目，因此也可能提交在故障之前未提交的数据。
有关恢复过程的详细信息，请参考以下有关使用peers.json恢复文件手动恢复的部分。用户只需在raft/peers.json恢复文件中添加幸存的服务器即可，一旦所有服务器都使用相同的raft/peers.json配置重新启动，集群就可以选举领导者。
之后用户引入任何新服务器都可以使用完全干净的数据目录来更新数据，并使用Consul的join指令加入集群。

$ consul agent -join=192.172.2.3

在某些极端情况下，可以通过唯一存活的服务器，使用它的raft/peers.json文件恢复集群。
Consul 0.7之前的版本，使用raft/peers.json并不能从所有类型的中断中恢复。在Consul 0.7及其更高的版本中，raft/peers.json恢复文件是最终文件，并且在摄取数据后会打上快照，因此可以确保从用户配置的环境开始开始。这会隐式提交所有Raft日志条目，因此仅应用于从中断中恢复，但当集群中有数据可用时，它允许在任何场景实现恢复。

使用peers.json文件手动恢复

首先，先要关闭所有幸存的服务器，用户可以尝试优雅地关闭机器，但大多数情况下这个会不起作用。如果在关闭服务器时发生错误不用担心，此时群集处于非正常状态，这属于正常情况。
在Consul 0.7及更高版本中，peers.json文件默认不存在，仅在执行恢复时使用。Consul启动时会提取此文件，然后将其删除。Consul 0.7还使用自动创建的新的raft/peers.info文件，以避免在升级后首次启动时提取raft/peers.json文件，确保将raft/peers.info文件放置在正确的位置以供操作。
使用raft/peers.json进行恢复操作时，可能会导致未提交的Raft日志条目被隐式提交，因此，要确保仅在发生中断（且无其他选项可用于恢复丢失的服务器）后才使用此命令
下一步是打开Consul服务器的-data-dir目录，在该目录中，有一个raft/子目录，我们在里面创建raft/peers.json文件，文件格式与Raft版本协议匹配。
对于Raft协议版本为2及更早的版本，应将其格式化为JSON数组，其中包含集群中每个Consul服务器的地址和端口，如下所示：

["10.1.0.1:8300", "10.1.0.2:8300", "10.1.0.3:8300"]

对于Raft协议版本为3及更高的版本，此文件的格式也为JSON数组，其中包含集群中每个Consul服务器的节点ID、地址：端口和选举权信息，如下所示：

[
  {
    "id": "adf4238a-882b-9ddc-4a9d-5b6758e4159e",
    "address": "10.1.0.1:8300",
    "non_voter": false
  },
  {
    "id": "8b6dda82-3103-11e7-93ae-92361f002671",
    "address": "10.1.0.2:8300",
    "non_voter": false
  },
  {
    "id": "97e17742-3103-11e7-93ae-92361f002671",
    "address": "10.1.0.3:8300",
    "non_voter": false
  }
]

• id（字符串，必要字段）：指定服务器节点ID，如果它是自动生成的，可以在服务器启动时在日志中找到它，也可以在服务器的数据目录中的node-id文件中找到它；
• address（字符串，必要字段）：指定服务器的端口和IP，端口用于集群的RPC通信；
• non_voter（布尔类型，非必要字段）：控制服务器是否具有选举权，默认为false。

只需为所有服务器创建该配置项即可，用户必须确认未包含在此处的服务器确实发生了故障，并且以后也不会重新加入群集了，确保其他所有服务器节点上的配置文件均相同。
此时，用户可以重新启动其他所有服务器，在Consul 0.7及更高版本中，用户会看到它们接收恢复文件：

...
2016/08/16 14:39:20 [INFO] consul: found peers.json file,recovering Raft configuration...
2016/08/16 14:39:20 [INFO] consul.fsm:snapshot created in 12.484µs
2016/08/16 14:39:20 [INFO] snapshot: Creating newsnapshot at /tmp/peers/raft/snapshots/2-5-1471383560779.tmp
2016/08/16 14:39:20 [INFO] consul: deleted peers.json file after successful recovery
2016/08/16 14:39:20 [INFO] raft: Restored from snapshot 2-5-1471383560779
2016/08/16 14:39:20 [INFO] raft: Initial configuration (index=1): [{Suffrage:VoterID:10.212.15.121:8300 Address:10.212.15.121:8300}] ...

对任何正常离开集群的服务器执行join命令都可以使它们重新加入集群：

$ consul join <Node Address> Successfully joined cluster by contacting 
1 nodes.

gossip协议将负责发现服务器节点，所有存在的都会加入集群中，此时，集群重新进入可操作状态，某些节点会打印下列日志确认领导者信息：

[INFO] consul: cluster leadership acquired

在Consul 0.7及更高版本中，可以使用consul operator命令检查Raft配置：

$ consul operator raft list-peers
Node ID Address State Voter RaftProtocol
alice 10.0.1.8:8300 10.0.1.8:8300 follower true 3
bob 10.0.1.6:8300 10.0.1.6:8300 leader true 3
carol 10.0.1.7:8300 10.0.1.7:8300 follower true 3

故障排除

故障排除是任何开发人员的一项基本技能，Consul提供了多种工具来帮助用户查看日志消息，验证配置文件，检查服务目录以及进行其他调试。

故障排除步骤

在开始之前，用户应考虑遵循预定的故障排除工作流程，好的工作流程可以帮助用户集中精力来发现和解决问题，我们推荐使用以下流程解决问题：

• 收集资料
• 验证有效性
• 一次解决一个问题
• 提出假设并进行验证
• 重复整个流程

Consul和其他工具会生成日志文件，状态消息，进程列表，数据反馈和其他有用的信息，用户可以在收集数据时使用它们，在本章节中，我们将介绍这些工具。
验证有效性的方法很重要，因为Consul位于其他高度复杂系统的中心。确保核心系统、网络和服务是正常工作的，可以帮助用户缩小问题范围，并防止用户花时间对错误的问题进行故障排除。如果不确定某个组件是如何工作的，或者不确定它是否正常运行，需要把它先列出来，或者花些时间验证其是否正常运行。
由于Consul是高度可配置的，因此用户会发现如果一次解决一个问题会比较容易，验证成功的操作，然后继续进行下一个问题。有必要的话，用户可以构建一个较小的系统，在其中测试不确定的配置项或功能，在验证成功之后，再将这些更改集成到主系统中。
基于假设去测试可以帮助用户专注于所选的某一个问题，用户需要记下什么问题可能导致该问题以及解决方案，然后观察数据并采取行动，看下理论是否正确，问题是否可以解决。
用户可能需要重复此过程中的某些或全部步骤，以找出问题所在，通过遵循一致的解决问题流程，可以高效解决问题。

Consul专用工具

介绍完故障排除流程之后，我们可以看一些定位Consul问题的专用工具，这些工具可以帮助用户收集数据，验证系统运行状态。
注意，下面提到的每个Consul命令都可以在有权访问Consul代理的节点上运行。

查看Consul架构

在与团队中的其他成员或技术支持人员交流时，查看有关Consul体系结构的一些详细信息很有帮助，其中包括：

• 如何查询Consul？（DNS、HTTP）
• Consul Web控制台页面是否可以查询？
• 用户使用什么系统启动微服务？（systemd、kubernetes、upstart、Nomad等）

members指令

consul members指令会列出连接到当前代理的Consul群集中的其他服务器和代理：

$ consul members 
Node    Address         Status  Type    Build  Protocol  DC   Segment 
laptop  127.0.0.1:8301  alive   server  1.4.0  2         dc1  <all>

list-peers指令

如果用户需要除members指令提供的信息之外的详细信息，可以尝试使用list-peers指令，这个指令会提供一些集群的底层信息，其中包括领导者状态、投票状态和Raft协议版本：

$ consul operator raft list-peers 
Node    ID           Address         State   Voter  RaftProtocol 
laptop  abc-def-g12  127.0.0.1:8300  leader  true   3

monitor指令

consul monitor指令会显示Consul代理的日志，使用其他参数可以更改日志级别，比如-log-level debug或者-log-level trace都会打印大量日志：

$ consul monitor
2019/01/25 17:48:33 [INFO] raft: Initial configuration (index=1): [{Suffrage:Voter ID:abcdef Address:127.0.0.1:8300}]
2019/01/25 17:48:33 [INFO] raft: Node at 127.0.0.1:8300 [Follower] entering Follower state (Leader: "")
2019/01/25 17:48:33 [INFO] serf: EventMemberJoin: laptop.dc1 127.0.0.1
2019/01/25 17:48:33 [INFO] serf: EventMemberJoin: laptop 127.0.0.1
2019/01/25 17:48:33 [INFO] consul: Adding LAN server laptop (Addr: tcp/127.0.0.1:8300) (DC: dc1)
2019/01/25 17:48:33 [INFO] consul: Handled member-join event for server "laptop.dc1" in area "wan"
2019/01/25 17:48:33 [ERR] agent: Failed decoding service file "services/.DS_Store": invalid character '\x00' looking for beginning of value
2019/01/25 17:48:33 [INFO] agent: Started DNS server 127.0.0.1:8600 (tcp)
2019/01/25 17:48:33 [INFO] agent: Started DNS server 127.0.0.1:8600 (udp)
2019/01/25 17:48:33 [INFO] agent: Started HTTP server on 127.0.0.1:8500 (tcp)
2019/01/25 17:48:33 [INFO] agent: Started gRPC server on 127.0.0.1:8502 (tcp)

validate指令

consul validate指令可以作用于单个Consul配置文件，更多的是在整个配置文件目录上运行，它会分析配置文件的基本语法和逻辑正确性：

consul validate /etc/consul.d/counting.json
* invalid config key serrrvice

debug指令

在节点上运行consul debug指令，它会在当前目录下记录下两分钟内的系统指标、日志、概要分析数据和其他数据，所有内容均以纯文本格式写入压缩文档，因此请勿在未加密的通道上传输此数据，用户可以将其提供给技术支持人员，帮助调试Consul群集：

$ consul debug
==> Starting debugger and capturing static information...
    Agent Version: '1.4.0'
         Interval: '30s'
         Duration: '2m0s'
           Output: 'consul-debug-1548721978.tar.gz'
          Capture: 'metrics, logs, pprof, host, agent, cluster'
==> Beginning capture interval 2019-01-28 16:32:58.56142 -0800 PST (0)

解压缩：

$ tar xvfz consul-debug-1548721978.tar.gz

显示内容：

$ tree consul-debug-1548721978

健康检查

健康检查是Consul集群非常重要的一个部分，启用之后，不健康的服务将不会被发现。查看初识健康状态最简单的方法访问Consul Web控制台页面，地址是http://localhost:8500/ui。点击特定服务，比如counting服务，可以看见这个服务在每个节点上的状态，包括健康检查的输出信息。
或者，用户也可以使用HTTP API查看整个目录或特定服务，/v1/agent/services端点将返回所有注册在目录中服务的列表：

$ curl "http://127.0.0.1:8500/v1/agent/services"

可以在查询字符串上增加过滤器，仅查询通过健康检查的服务：

$ curl 'http://localhost:8500/v1/health/service/counting?passing'
[
    {
        "Node": {
            "ID": "da8eb9d3-...",
            "Node": "laptop",
            "Address": "127.0.0.1",
            "Datacenter": "dc1",
        },
        "Checks": [
            {
                "Node": "laptop",
                "Output": "Agent alive and reachable"
            },
            {
                "Node": "laptop",
                "Name": "Service 'counting' check",
                "Status": "passing",
                "Output": "HTTP GET http://localhost:9003/health: 200 OK Output: Hello, you've hit /health\n",
                "ServiceName": "counting"
            }
        ]
    }
]

健康检查还有一个很重要的方面是，服务不仅要当下健康，更要保持健康状态，如果某个服务在健康与不健康状态之间波动，我们称之为flapping。这可能是由于服务本身的问题造成的（内部崩溃），这需要检查服务本身，或运行进程的进程启动器，比如systemd。
这里还要考虑使用合适的健康检查方式，推荐使用内置的健康检查工具（如TCP或HTTP），而不是使用外置的Shell脚本。

外部工具

Consul的设计是建立在现有网络生态协议之中的，这意味着用户可以使用现有工具来收集数据，验证哪些服务正在运行以及调试Consul周边的网络，应用程序和安全上下文。

ps指令

Consul服务发现依赖于现有的进程启动工具，例如systemd、upstart或init.d。如果选择使用这些工具，可以参考其文档编写配置文件、启动、停止、重新启动脚本以及监控由这些工具启动的进程的输出。
ps是Unix系统上的常用工具，运行它可以验证服务进程是否按预期运行：

$ ps | grep counting 
79846 ttys001 0:00.07 ./counting-service

或者可以考虑在操作系统中单独安装pstree，它会显示正在运行的父子进程和它们的层次结构。

$ pstree 
| | \-+= 74259 geoffrey -zsh 
| | \--= 79846 geoffrey ./counting-service

dig指令

如果Consul使用DNS协议，则可以使用标准DNS工具，Consul默认情况下在8600端口上运行，而不是DNS默认端口53。
dig工具是一个命令行应用程序，可与各种DNS记录进行交互。我们可以使用@127.0.0.1加上-p 8600参数和Consul服务器的IP地址查询详细的DNS记录。
在此示例中，我们找到了counting服务的IP地址：

$ dig @127.0.0.1 -p 8600 counting.service.consul 
; <<>> DiG 9.10.6 <<>> @127.0.0.1 -p 8600 counting.service.consul ... ;; 
ANSWER SECTION: counting.service.consul. 0 IN A 192.168.0.35

Consul还可以通过SRV（服务）参数提供其他信息，在dig命令中添加SRV参数查看counting服务所使用的端口号（下面显示为9003）：

$ dig @127.0.0.1 -p 8600 counting.service.consul SRV
;; ANSWER SECTION: counting.service.consul. 0 IN SRV 1 1 9003
Machine.local.node.dc1.consul.
;; ADDITIONAL SECTION: Machine.local.node.dc1.consul. 0 IN A
192.168.0.35

如果用户已经配置了DNS转发将系统DNS与Consul集成，则可以省略IP地址和端口号。但是，用户在进行调试时经常需要进行专门的设置，用来验证与Consul代理的直接通信是否按预期进行。

curl指令

curl命令看起来很简单，但它在调试Web服务，或者发现HTTP协议相关的问题时极其有用，用户可以使用curl命令查询健康检查端点验证服务是否处于连接，可以使用IP地址，也可以使用localhost，如果用户配置了DNS转发，则可以使用Consul绑定的域名与服务进行通信，例如http://counting.service.consul：

$ curl http://localhost:9003/health 
Hello, you've hit /health

ping指令

ping命令也是一个简单的工具，用于验证与主机的网络连接（如果它可以响应ping请求），使用IP地址验证一个节点是否可以与另一节点通信。ping命令对于查看节点之间的延迟情况以及它们之间数据包传输的可靠性也非常有用。

$ ping 10.0.1.14 
PING 10.0.1.14 (10.0.1.14): 56 data bytes 
64 bytes from 10.0.1.14: icmp_seq=0 ttl=64 time=0.065 ms 
64 bytes from 10.0.1.14: icmp_seq=1 ttl=64 time=0.068 ms 
64 bytes from 10.0.1.14: icmp_seq=2 ttl=64 time=0.060 ms 
^C 
--- 10.0.1.14 ping statistics --- 
3 packets transmitted, 3 packets received, 0.0% packet loss 
round-trip min/avg/max/stddev = 0.060/0.064/0.068/0.003 ms