总结：
该API与Fabric网络服务无关, 但由Fabric提供HTTP服务、RESTful API。
yaml文件中设置参数，通过http://listenAddress:port/healthz 进行某个节点的健康状态检查
yaml文件中设置参数，通过URL:PORT进行日志管理层级查看，设置，能管理细分的层级。（如何查看细分的层级，有待实验）
TLS控制设置是否是独立，有待实验。
The peer and the orderer host an HTTP server that offers a RESTful “operations” API. This API is unrelated to the Fabric network services and is intended to be used by operators, not administrators or “users” of the network.
peer对等节点和排序节点托管一个HTTP服务器，该服务器提供RESTful API。该API与Fabric网络服务无关，旨在供网络的运营商而非网络管理员或“用户”使用。
The API exposes the following capabilities:
API提供了如下功能：
Log level management
日志级别管理
Health checks
网络运行情况检查【翻译有待商榷】
Prometheus target for operational metrics (when configured)
操作指标的普罗米修斯（配置时）【X】
The operations service requires two basic pieces of configuration:
运营服务需要两个基本的配置：
The address and port to listen on.
监听的地址和端口
The TLS certificates and keys to use for authentication and encryption. Note, these certificates should be generated by a separate and dedicated CA. Do not use a CA that has generated certificates for any organizations in any channels.
TLS证书和私钥被用于身份认证和加密。提示，这些证书应该由分开的、专门的CA来生成。该CA机构能为任一通道的所有的组织生成证书。
For each peer, the operations server can be configured in the operations section of core.yaml:
对于每一个peer节点，可以在core.yaml文件的operations部分进行配置运营服务：
operations:
# host and port for the operations server
listenAddress: 127.0.0.1:9443
# TLS configuration for the operations endpoint
tls:
# TLS enabled
enabled: true
# path to PEM encoded server certificate for the operations server
cert:
file: tls/server.crt
# path to PEM encoded server key for the operations server
key:
file: tls/server.key
# most operations service endpoints require client authentication when TLS
# is enabled. clientAuthRequired requires client certificate authentication
# at the TLS layer to access all resources.
clientAuthRequired: false
# paths to PEM encoded ca certificates to trust for client authentication
clientRootCAs:
files: []
The listenAddress key defines the host and port that the operation server will listen on. If the server should listen on all addresses, the host portion can be omitted.
listenAddress配置定义了运营服务将要监听的主机和端口。如果服务需要监听所有地址，则主机部分可以省略。
The tls section is used to indicate whether or not TLS is enabled for the operations service, the location of the service’s certificate and private key, and the locations of certificate authority root certificates that should be trusted for client authentication. When enabled is true, most of the operations service endpoints require client authentication, therefore clientRootCAs.files must be set. When clientAuthRequired is true, the TLS layer will require clients to provide a certificate for authentication on every request. See Operations Security section below for more details.
tls配置用来表示运营服务是否启用TLS，服务的证书和私钥的存放位置，能被客户端信任的CA根证书所在的位置。当enable为true的时候，大多数的运营服务端需要客户端认证，因此clientRootCAs.files属性必须配置。当clientAuthRequired为true的时候，TLS层需要客户端提供证书，用于每次请求的时候进行认证。通过Operations Security章节了解更多细节。
For each orderer, the operations server can be configured in the Operations section of orderer.yaml:
对每个orderer节点，运营服务能够在orderer.yaml文件中的Operations部分进行配置。
Operations:
# host and port for the operations server
ListenAddress: 127.0.0.1:8443
# TLS configuration for the operations endpoint
TLS:
# TLS enabled
Enabled: true
# PrivateKey: PEM-encoded tls key for the operations endpoint
PrivateKey: tls/server.key
# Certificate governs the file location of the server TLS certificate.
Certificate: tls/server.crt
# Paths to PEM encoded ca certificates to trust for client authentication
ClientRootCAs: []
# Most operations service endpoints require client authentication when TLS
# is enabled. ClientAuthRequired requires client certificate authentication
# at the TLS layer to access all resources.
ClientAuthRequired: false
The ListenAddress key defines the host and port that the operations server will listen on. If the server should listen on all addresses, the host portion can be omitted.
listenAddress配置定义了运营服务将要监听的主机和端口。如果服务需要监听所有地址，则主机部分可以省略。
The TLS section is used to indicate whether or not TLS is enabled for the operations service, the location of the service’s certificate and private key, and the locations of certificate authority root certificates that should be trusted for client authentication. When Enabled is true, most of the operations service endpoints require client authentication, therefore RootCAs must be set. When ClientAuthRequired is true, the TLS layer will require clients to provide a certificate for authentication on every request. See Operations Security section below for more details.
tls配置用来表示运营服务是否启用TLS，服务的证书和私钥的存放位置，能被客户端信任的CA根证书所在的位置。当enable为true的时候，大多数的运营服务端需要客户端认证，因此RootCAs属性必须配置。当clientAuthRequired为true的时候，TLS层需要客户端提供证书，用于每次请求的时候进行认证。通过Operations Security章节了解更多细节。
As the operations service is focused on operations and intentionally unrelated to the Fabric network, it does not use the Membership Services Provider for access control. Instead, the operations service relies entirely on mutual TLS with client certificate authentication.
由于运营服务关注与其运营情况并且有意识的不与Fabric网络相关，因此，不要用Membership Services Provider来访问控制。相反，运营服务完全依赖于同证书认证客户端之间的TLS。
When TLS is disabled, authorization is bypassed and any client that can connect to the operations endpoint will be able to use the API.
当TLS被禁用，认证工作将被撇开不管，任何能连接到运营服务端的客户端都能够对其使用API访问。
When TLS is enabled, a valid client certificate must be provided in order to access all resources unless explicitly noted otherwise below.
当启用TLS时，必须提供有效的客户端证书来访问所有资源，除非下面另有明确说明。
When clientAuthRequired is also enabled, the TLS layer will require a valid client certificate regardless of the resource being accessed.
当clientAuthRequired 也被启用时，TLS层也需要有效的客户端证书，不管资源会不会被访问。
The operations service provides a /logspec resource that operators can use to manage the active logging spec for a peer or orderer. The resource is a conventional REST resource and supports GET and PUT requests.
运营服务提供一个/logspec选项让操作者能管理peer节点或orderer节点活跃的日志配置。
When a GET /logspec request is received by the operations service, it will respond with a JSON payload that contains the current logging specification:
当运营服务接收到GET /logspec请求时，他会回应一个包含当前日志的类型的JSON数据。
{"spec":"info"}
When a PUT /logspec request is received by the operations service, it will read the body as a JSON payload. The payload must consist of a single attribute named spec.
当运营服务接收到GET /logspec请时，他将读取一个JSON数据，该数据中必须包含一个属性spec。
{"spec":"chaincode=debug:info"}
If the spec is activated successfully, the service will respond with a 204 "No Content" response. If an error occurs, the service will respond with a 400 "Bad Request" and an error payload:
如果spec被成功激活，服务端将会回一条204 "No Content"响应。如果发生了错误，服务端将会回应400 "Bad Request" 并且有一条JSON的payload如下所示。
{"error":"error message"}
The operations service provides a /healthz resource that operators can use to help determine the liveness and health of peers and orderers. The resource is a conventional REST resource that supports GET requests. The implementation is intended to be compatible with the liveness probe model used by Kubernetes but can be used in other contexts.
排序服务提供一个 /healthz配置，来使运营商能使用它来查明peer节点和orderer节点的活跃度或健康状态。
When a GET /healthz request is received, the operations service will call all registered health checkers for the process. When all of the health checkers return successfully, the operations service will respond with a 200 "OK" and a JSON body:
当接收到一条GET /healthz请求时，运营服务将会调用进程中所有注册过的健康检查器。当所有检查器都返回成功时，运营服务将会返回一条200 "OK", 并且JSON中包含如下数据：
{
"status": "OK",
"time": "2009-11-10T23:00:00Z"
}
If one or more of the health checkers returns an error, the operations service will respond with a 503 "Service Unavailable" and a JSON body that includes information about which health checker failed:
入股一条或多条健康检查器返回错误，运营服务将返回一条503 "Service Unavailable" 并且JSON中包含如下关于哪一个健康检查器失败的信息。
{
"status": "Service Unavailable",
"time": "2009-11-10T23:00:00Z",
"failed_checks": [
{
"component": "docker",
"reason": "failed to connect to Docker daemon: invalid endpoint"
}
]
}
In the current version, the only health check that is registered is for Docker. Future versions will be enhanced to add additional health checks.
在当前版本（2020/5/11的latest）中，只有为Docker注册的一条健康检查，在将来的版本将会增加额外的健康检查。
When TLS is enabled, a valid client certificate is not required to use this service unless clientAuthRequired is set to true.
当TLS被启用时，不需要一个有效的客户端证书来使用这项服务，除非clientAuthRequired被设置为true。
//度量
Some components of the Fabric peer and orderer expose metrics that can help provide insight into the behavior of the system. Operators and administrators can use this information to better understand how the system is performing over time.
一些Fabric peer和orderer组件会暴露出一些指标，这些指标将有助于提供对系统内部的行为的观察、了解。
配置指标
Fabric provides two ways to expose metrics: a pull model based on Prometheus and a push model based on StatsD.
Fabric提供两种方式来暴露这些指标: 一种是基于Prometheus的pull模型、一种是基于StatsD的push模型。
A typical Prometheus deployment scrapes metrics by requesting them from an HTTP endpoint exposed by instrumented targets. As Prometheus is responsible for requesting the metrics, it is considered a pull system.
一种典型的Prometheus部署方式，通过请求测试目标暴露的HTTP端点来抓取这些指标数据。
When configured, a Fabric peer or orderer will present a /metrics resource on the operations service.
当配置完成，一个Fabric的peer或者orderer将会在运营服务中呈现一个/metrics资源。
A peer can be configured to expose a /metrics endpoint for Prometheus to scrape by setting the metrics provider to prometheus in the metrics section of core.yaml.
一个peer可以配置/metrics终端用于Prometheus抓取信息。在core.yaml文件中的metrics部分设置provider为prometheus。
metrics:
provider: prometheus
An orderer can be configured to expose a /metrics endpoint for Prometheus to scrape by setting the metrics provider to prometheus in the Metrics section of orderer.yaml.
一个peer可以配置/metrics终端用于Prometheus抓取信息。在orderer.yaml文件中的Metrics部分设置Provider为prometheus。
Metrics:
Provider: prometheus
StatsD is a simple statistics aggregation daemon. Metrics are sent to a statsd daemon where they are collected, aggregated, and pushed to a backend for visualization and alerting. As this model requires instrumented processes to send metrics data to StatsD, this is considered a push system.
StatsD 是一种简单的统计聚合的守护进程。指标将被发送到一个statsd进程中，在这里他们将被收集，统计，推送到一个可视化和监视报警的后端。因为这个模型需要被测试进程发送数据到StatsD，因此被认为是一个推送系统。
A peer can be configured to send metrics to StatsD by setting the metrics provider to statsd in the metrics section of core.yaml. The statsd subsection must also be configured with the address of the StatsD daemon, the network type to use (tcp or udp), and how often to send the metrics. An optional prefix may be specified to help differentiate the source of the metrics — for example, differentiating metrics coming from separate peers — that would be prepended to all generated metrics.
通过在core.yaml的metrics部分设置metrics的provider为statsd，peer就能够被配置成发送metrics到StatsD。statsd的子章节也同样需要配置，StatsD进程的地址（ip+端口），网络类型（TCP 或 UDP），发送metrics的频率。一个可选的prefix或许可以被用作区分不同资源的指标，例如区分不同指标来自不同的peer节点，这将预备生成所有的指标。
metrics:
provider: statsd
statsd:
network: udp
address: 127.0.0.1:8125
writeInterval: 10s
prefix: peer-0
An orderer can be configured to send metrics to StatsD by setting the metrics provider to statsd in the Metrics section of orderer.yaml. The Statsd subsection must also be configured with the address of the StatsD daemon, the network type to use (tcp or udp), and how often to send the metrics. An optional prefix may be specified to help differentiate the source of the metrics.
一个Orderer节点可以通过设置orderer.yaml中Metrics部分的Provider为statsd来将其配置成发送指标到StatsD。statsd的子模块也同样需要配置：StatsD进程的地址（ip+端口），网络类型（TCP 或 UDP），发送metrics的频率。一个可选的prefix或许可以被用作区分不同资源的指标。
Metrics:
Provider: statsd
Statsd:
Network: udp
Address: 127.0.0.1:8125
WriteInterval: 30s
Prefix: org-orderer
For a look at the different metrics that are generated, check out Metrics Reference.