如果提供telemetry选项，ContainerPilot将公开可用于刮擦性能telemetry的 HTTP客户端界面。 telemetry接口被公告为consul服务。 telemetry服务的每个metric为配置收集器。 然后，Prometheus服务器可以向telemetry终端发出HTTP请求。
配置细节如下，但 。
顶级telemetry配置定义了telemetryHTTP端点。 正如一个典型的ContainerPilot service块一样，这个端点将被通告给Consul（或其他发现服务）。 该服务将被称为containerpilot ，并将在路径/metrics 。 telemetry服务将定期向发现服务发送心跳信号，以确定其仍在运行。 telemetry服务端点没有用户定义的运行状况检查，您不需要配置poll / TTL; 它每5秒钟会发出15秒的心跳。
ContainerPilot的最小配置包括telemetry可能如下所示：
{ consul: "consul:8500", telemetry: { port: 9090, interfaces: ["eth0"], tags: ["tag1"], metrics: [ { namespace: "my_namespace", subsystem: "my_subsystem", name: "my_events_count", help: "help text", type: "counter" } ] }, jobs: [ { name: "sensor", exec: "/bin/sensor.sh", timeout: "5s", when: { interval: "5s" } } ] } 字段如下： -
port是telemetry服务将向发现服务通告的端口。 （默认值为9090.） -
interfaces是可选的单个或数组接口规范。 如果给出，服务的IP将从匹配的第一个接口规范获得。 （默认值为["eth0:inet"]） -
tags是可选的标签数组。 如果发现服务支持（Consul），服务将注册自己的这些标签。 -
metrics是可选的收集器配置数组（见下文）。 如果没有提供传感器，那么telemetry端点仍将被暴露，并且将只显示关于ContainerPilot内部的telemetry。
Collector configuration
metrics字段是telemetry服务将用于配置Prometheus收集器的用户定义指标的列表。
-
namespace，subsystem和name是Prometheus客户端库将用于构建telemetry名称的名称。 这三个名称与下划线_连接成为Prometheus记录的最终名字。 在上面的示例中，记录的度量将被命名为my_namespace_my_subsystem_my_event_count。 你可以离开namespace和subsystem值，如果需要，将所有内容放在name字段中; 提供这些其他字段的选项只是为了方便那些以编程方式生成ContainerPilot配置的用户。 请参阅有关如何命名telemetry的最佳做法的 。 -
help是与Prometheus记录的指标相关联的帮助文本。 这通过给出更详细的描述对于调试非常有用。 -
type是Prometheus将使用的收集器的类型（counter，gauge，histogram或summary）。 详见 。
Sensor configuration
收集器可以记录通过发送的指标。 如果您的应用程序不能containerpilot -putmetric使用此端点，则可以使用周期性作业记录度量值并调用containerpilot-putmetric 。 一个很好的工作脚本的例子可能是：
#!/bin/bash# check free memoryval=$(free | awk -F' +' '/Mem/{print $3}') ./containerpilot -putmetric "free_memory=$val" Collector types
ContainerPilot支持Prometheus API中可用的四种 。 简单来说，这些是：
Counter
累积度量，表示只有一个数字值才能上升。 Counter的典型用例是某些事件数量的计数。 传感器返回的值将被添加到该度量的Counter中。
Gauge
表示可以任意上下移动的单个数值的度量。 仪表的典型用例可能是当前内存使用情况的Gauge。 传感器脚本返回的值将被设置为Gauge仪度量值的新值。
Histogram
“count”中的观察次数以及所有观察值的总和。 典型的用例可能是请求持续时间或响应大小。 当Prometheus服务器刮掉这个telemetry终端时，它会收到count和列表。 例如：
namespace_subsystem_response_bucket{ le="1"} 0 namespace_subsystem_response_bucket{ le="2.5"} 0 namespace_subsystem_response_bucket{ le="5"} 1 namespace_subsystem_response_bucket{ le="10"} 2 namespace_subsystem_response_bucket{ le="+Inf"} 2 这表明收藏家总共看到了2个事件。 一个事件的值小于5（ le="5" ），而第二个小于10。 summary
总结类似于Histogram，但是它也提供了观察总数和所有观察值的总和，它在滑动时间窗口上计算分位数。 例如：
namespace_subsystem_response_seconds_summary{ quantile="0.5"} 0.3 namespace_subsystem_response_seconds_summary{ quantile="0.9"} 0.5 namespace_subsystem_response_seconds_summary{ quantile="0.99"} 2 这表示第50百分位数响应时间为0.3秒，第90百分位数为0.5秒，第99百分位数为2秒。 有关何时应选择Histogram与摘要的最佳做法，请参阅关于的Prometheus文档。
======================================================================================================================
{ "consul": "{ { .CONSUL }}:8500", "logging": { "level": "INFO", "format": "default", "output": "stdout" }, "jobs": [ { "name": '{ { .SERVICE_NAME|default "app"}}', "exec": "/root/test/containerpilot/app.sh", "when":{ "source":"prestart", "once":"exitSuccess", "timeout":"60s" }, "restarts": "unlimited", "port": 80, "health": { "exec": "/root/test/containerpilot/manage.sh health", "interval": 5, "ttl": 10, "timeout": "5s" }, "tags": [ "app", "prod" ], "interfaces":["enp3s0:inet"] }, { "name": "prestart", "exec": "/root/test/containerpilot/manage.sh prestart", "restarts": "never" }, { "name": "backup_task", "exec": "/root/test/containerpilot/manage.sh backup", "timeout": "1m", "when": { "interval": "1500ms" } }, { "name": "mysql_connections", "exec": "/root/test/containerpilot/sensor.sh measureStuff", "timeout": "5s", "when": { "interval": "5s" } } ], "telemetry": { "port": 9090, "interfaces":["enp3s0:inet"], "metrics": [ { "namespace": "dbaas", "subsystem": "mysql", "name": "connections", "help": "mysql connections", "type": "gauge" }, { "namespace": "dbaas", "subsystem": "mysql", "name": "disk", "help": "mysql disk", "type": "gauge" } ] } } ====================================== #!/bin/bash trap 'exit 2' SIGTERM usage() { cat <