가상 머신(VM)에서 서비스 메시 텔레메트리 관찰
가상 머신(VM)에서 서비스 메시 텔레메트리 관찰 (Observe service mesh telemetry on virtual machines)
Consul의 내장 UI에서 서비스 메시 토폴로지 시각화와 메트릭 오버레이를 활성화하는 방법을 설명해요. Prometheus 백엔드의 메트릭을 UI에 표시하고 서비스별 대시보드 URL 템플릿을 구성할 수 있어요.
출처: 문서
본문
"메트릭 대시보드 구성(Configure metrics dashboard)" 또는 "대시보드 구성(Configure dashboard)"에서 왔나요? 대시보드 URL 구성(Configuring Dashboard URLs)을 참조하세요.
Consul 1.9.0부터 Consul의 내장 UI에는 한눈에 서비스의 직접적인 연결 상태를 보여주는 토폴로지 시각화가 포함되어 있습니다. 이는 전용 모니터링 솔루션을 대체하기 위한 것이 아니라 서비스 메시 내 서비스와 연결 상태를 빠르게 파악하기 위한 개요입니다.
토폴로지 시각화는 서비스가 사이드카 프록시를 통해 서비스 메시를 사용해야 합니다.
시각화는 선택적으로 외부 서비스별 대시보드 링크를 포함하도록 구성할 수 있습니다. 이는 각 서비스에 대해 기존 모니터링 또는 애플리케이션 성능 모니터링(APM) 솔루션으로의 편리한 딥 링크를 제공하기 위한 것입니다. 자세한 내용은 대시보드 URL 구성(Configuring Dashboard URLs)에서 확인할 수 있습니다.
아래에 표시된 것처럼 시각화를 보강하기 위해 메트릭 공급자 저장소에서 기본 메트릭을 가져오도록 UI를 구성할 수 있습니다.
Consul에는 Prometheus 백엔드에서 메트릭을 오버레이하는 내장 지원이 있습니다. 새롭고 실험적인 JavaScript API를 사용해 대체 메트릭 공급자도 지원할 수 있습니다. 사용자 정의 메트릭 공급자(Custom Metrics Providers)를 참조하세요.
Kubernetes
Kubernetes에서 Consul을 실행한다면 Helm 차트가 Consul의 UI가 토폴로지 시각화를 표시하도록 자동으로 구성할 수 있습니다. 자세한 내용은 Kubernetes 관측 가능성 문서를 참조하세요.
UI가 메트릭을 표시하도록 구성 (Configuring the UI To Display Metrics)
Consul의 UI가 메트릭을 가져오도록 구성하려면 두 가지 필수 구성 설정이 있습니다.
이 설정은 UI를 제공하는 각 Consul 에이전트에 설정해야 합니다. 데이터센터에서 중복성을 위해 UI가 활성화된 클라이언트가 여러 개 있다면 이러한 구성을 모두 에이전트에 추가해야 합니다.
UI가 에이전트의 구성 파일에서 ui_config.enabled를 true로 설정해 이미 활성화되어 있다고 가정합니다.
내장 Prometheus 공급자를 사용하려면 ui_config.metrics_provider를 prometheus로 설정해야 합니다.
UI는 프록시 엔드포인트를 통해 메트릭 공급자를 쿼리해야 합니다. 이는 Prometheus가 UI 사용자의 브라우저에 외부로 노출되지 않은 배포를 단순화합니다.
이를 설정하려면 Consul 에이전트가 Prometheus 서버에 도달하는 데 사용해야 하는 URL을 ui_config.metrics_proxy.base_url에 제공하세요.
예를 들어 Kubernetes에서 Prometheus Helm 차트는 기본적으로 prometheus-server라는 서비스를 설치하므로 각 Consul 에이전트는 http://prometheus-server(Kubernetes의 DNS 해석 사용)에서 도달할 수 있습니다.
Prometheus를 활성화하는 전체 구성은 아래에 나와 있습니다.
UI 메트릭 구성
agent-config.hclui_config {
enabled = true
metrics_provider = "prometheus"
metrics_proxy {
base_url = "http://prometheus-server"
}
}
helm-values.yamlui:
enabled: true
metrics:
enabled: true # by default, this inherits from the value global.metrics.enabled
provider: "prometheus"
baseURL: http://prometheus-server
agent-config.json{
"ui_config": {
"enabled": true,
"metrics_provider": "prometheus",
"metrics_proxy": {
"base_url": "http://prometheus-server"
}
}
}
참고 : Kubernetes에서 관측 가능성 UI를 구성하는 방법에 대한 자세한 내용은 이 참조를 사용하세요.
대시보드 URL 구성 (Configuring Dashboard URLs)
Consul의 시각화는 메시의 개요이지 포괄적인 모니터링 도구가 아니므로 서비스 대시보드 URL 템플릿을 구성해 사용자가 Grafana나 호스팅 공급자와 같은 외부 도구에서 관련 서비스별 대시보드로 직접 클릭해 이동할 수 있게 할 수 있습니다.
이를 구성하려면 UI가 활성화된 모든 에이전트의 에이전트 구성 파일에 URL 템플릿을 제공해야 합니다. 템플릿은 기본적으로 외부 대시보드의 URL이지만, 관련 정보로의 딥 링크를 허용하기 위해 서비스 이름, 네임스페이스, 데이터센터로 대체될 플레이스홀더 값을 가질 수 있습니다.
Grafana를 사용한 예시는 아래에 나와 있습니다.
UI 시각화를 위한 대시보드 URL 템플릿 구성 예시
agent-config.hclui_config {
enabled = true
dashboard_url_templates {
service = "https://grafana.example.com/d/lDlaj-NGz/service-overview?orgId=1&var-service={{Service.Name}}&var-namespace={{Service.Namespace}}&var-partition={{Service.Partition}}&var-dc={{Datacenter}}"
}
}
helm-values.yaml# The UI is enabled by default so this stanza is not required.
ui:
enabled: true
# This configuration requires version 0.40.0 or later of the Helm chart.
dashboardURLTemplates:
service: "https://grafana.example.com/d/lDlaj-NGz/service-overview?orgId=1&var-service={{Service.Name}}&var-namespace={{Service.Namespace}}&var-dc={{Datacenter}}"
# If you are using a version of the Helm chart older than 0.40.0, you must
# configure the dashboard URL template using the `server.extraConfig` parameter
# in the Helm chart's values file.
server:
extraConfig: |
{
"ui_config": {
"dashboard_url_templates": {
"service": "https://grafana.example.com/d/lDlaj-NGz/service-overview?orgId=1&var-service={{ "{{" }}Service.Name}}&var-namespace={{ "{{" }}Service.Namespace}}&var-dc={{ "{{" }}Datacenter}}"
}
}
}
agent-config.json{
"ui_config": {
"enabled": true,
"dashboard_url_templates": {
"service": "https://grafana.example.com/d/lDlaj-NGz/service-overview?orgId=1\u0026var-service={{Service.Name}}\u0026var-namespace={{Service.Namespace}}\u0026var-partition={{Service.Partition}}\u0026var-dc={{Datacenter}}"
}
}
}
참고 : Kubernetes에서 Helm 구성의
server.extraConfig키에 설정된 Consul 서버 구성은 JSON으로 지정해야 합니다. URL의{{문자는 Helm이 템플릿으로 처리하지 않도록{{ "{{" }}으로 이스케이프해야 합니다.
메트릭 프록시 (Metrics Proxy)
많은 경우 메트릭 백엔드는 UI 사용자의 브라우저에서 액세스할 수 없거나 다른 도메인에 있어 CORS 제한을 받을 수 있습니다. 이러한 경우 메트릭을 UI에 제공하는 것을 더 간단하게 만들기 위해 Consul 에이전트가 UI의 메트릭 요청을 백엔드로 프록시할 수 있습니다.
이는 테스트 및 데모 환경에서 설정을 단순화하기 위한 것입니다. 프로덕션에서 사용할 때는 신중한 고려가 필요합니다.
가장 간단한 구성은 UI가 메트릭을 표시하도록 구성(#configuring-the-ui-to-display-metrics)에 설명되어 있습니다.
메트릭 프록시 보안 (Metrics Proxy Security)
보안 참고 : 프록시를 통해 잠재적으로 인증되지 않은 네트워크 트래픽에 백엔드 메트릭 서비스를 노출하는 것은 프로덕션에서 신중하게 고려해야 합니다.
메트릭 프록시 엔드포인트는 내부 전용이며 UI 전용으로 설계되었습니다. 그러나 이를 활성화하면 에이전트의 API 포트에 네트워크 액세스 권한이 있는 사람은 누구나 백엔드에서 메트릭에 액세스하는 데 사용할 수 있습니다.
ACL이 활성화되지 않은 경우 네트워크의 인증되지 않은 워크로드에 메트릭에 대한 전체 액세스 권한이 노출됩니다.
ACL이 활성화된 경우 프록시 엔드포인트는 모든 노드와 서비스(Enterprise의 모든 네임스페이스)에 대한 읽기 액세스 권한이 있는 유효한 토큰을 요구합니다.
모든 서비스와 노드에 읽기 전용 액세스를 허용하는 예시 정책
service_prefix "" {
policy = "read"
}
node_prefix "" {
policy = "read"
}
{
"service_prefix": {
"": {
"policy": "read"
}
},
"node_prefix": {
"": {
"policy": "read"
}
}
}
모든 네임스페이스의 모든 서비스와 노드에 읽기 전용 액세스를 허용하는 예시 정책
namespace_prefix "" {
service_prefix "" {
policy = "read"
}
node_prefix "" {
policy = "read"
}
}
{
"namespace_prefix": {
"": {
"service_prefix": {
"": {
"policy": "read"
}
},
"node_prefix": {
"": {
"policy": "read"
}
}
}
}
}
대부분의 인증된 사용자가 카탈로그를 보거나 서비스를 발견하는 데 필요하므로 Consul에서 이 수준의 액세스 권한을 가지는 것이 일반적입니다. Single Sign-On 통합(Consul Enterprise)을 사용한다면 UI 사용자에게 위의 권한이 있는 ACL 토큰이 자동으로 발급되어 프록시를 통해 메트릭에 액세스할 수 있습니다.
ACL이 활성화된 경우에도 프록시 엔드포인트는 백엔드의 쿼리 언어를 깊이 이해하지 못하므로 특정 서비스 관련 메트릭에만 최소 권한 액세스를 적용하는 방법이 없습니다.
Consul의 모든 사용자가 메트릭 백엔드에 대한 전체 액세스 권한을 가지는 것이 불편하다면 프록시를 사용하지 말고 메트릭 백엔드를 직접 쿼리할 수 있는 사용자 정의 공급자를 사용하는 것과 같은 대안을 찾아야 합니다.
경로 허용 목록 (Path Allowlist)
메트릭 백엔드의 노출을 제한하려면 API의 의도하지 않은 부분이 노출되지 않도록 경로를 명시적으로 허용 목록에 추가해야 합니다. 예를 들어 Prometheus의 경우 시계열과 개별 통계를 로드하는 데 /api/v1/query_range와 /api/v1/query 엔드포인트가 모두 필요합니다. 프록시의 base_url이 http://prometheus-server로 설정되어 있다면 프록시는 민감한 정보를 포함할 수 있는 모든 Prometheus 구성을 포함하는 /api/v1/status/config와 같은 여러 다른 엔드포인트에 대한 읽기 액세스도 노출합니다.
내장 prometheus 공급자를 사용한다면 프록시는 필수 엔드포인트로 제한됩니다. metrics_proxy.path_allowlist의 기본값은 내장 prometheus 공급자가 요구하는 ["/api/v1/query_range", "/api/v1/query"]입니다.
메트릭 프록시를 사용하는 사용자 정의 공급자를 사용한다면 공급자가 액세스해야 하는 엔드포인트를 기반으로 허용 목록을 명시적으로 설정해야 합니다.
헤더 추가 (Adding Headers)
프록시가 요청이 통과할 때 하나 이상의 헤더를 요청에 추가하도록 구성하는 것도 가능합니다. 이는 메트릭 백엔드가 인증을 요구할 때 유용합니다. 예를 들어 메트릭이 호스팅 공급자로 전송되는 경우 Consul UI 전용 API 토큰을 프로비저닝하고 아래 예시와 같이 프록시가 이를 추가하도록 구성할 수 있습니다. 이렇게 하면 API 토큰이 구성 파일에서 Consul 운영자에게만 표시되고 UI 사용자는 해당 공급자에 대한 토큰을 별도로 얻거나 다른 곳에서 사용할 수 있는 토큰이 노출되지 않고 필요한 메트릭을 쿼리할 수 있습니다.
메트릭 엔드포인트에 추가 HTTP 헤더를 추가하는 구성 예시
agent-config.hclui_config {
enabled = true
metrics_provider = "example-apm"
metrics_proxy {
base_url = "https://example-apm.com/api/v1/metrics"
add_headers = [
{
name = "Authorization"
value = "Bearer <token>"
}
]
}
}
agent-config.json{
"ui_config": {
"enabled": true,
"metrics_provider": "example-apm",
"metrics_proxy": {
"base_url": "https://example-apm.com/api/v1/metrics",
"add_headers": [
{
"name": "Authorization",
"value": "Bearer \u003ctoken\u003e"
}
]
}
}
}
사용자 정의 메트릭 공급자 (Custom Metrics Providers)
Consul 1.9.0에는 Prometheus에서 메트릭을 가져오는 내장 공급자가 포함되어 있습니다. UI 시각화 기능이 다른 기존 메트릭 저장소와 호스팅 서비스와 작동하도록 하기 위해 JavaScript로 "메트릭 공급자" 인터페이스를 만들었습니다. 사용자 정의 공급자를 작성할 수 있으며 JavaScript 파일은 Consul 에이전트가 제공합니다.
참고 : 이 인터페이스는 실험적이며 커뮤니티의 요구를 발견함에 따라 호환성이 깨지는 방식으로 변경되거나 완전히 제거될 수 있습니다. 이 기능을 어떻게 사용하고 싶은지 GitHub 또는 Discuss에서 피드백을 제공하세요.
완전한 공급자 JavaScript 파일 템플릿은 아래에 나와 있습니다.
사용자 정의 메트릭 플러그인용 JavaScript 클래스 템플릿 예시
(function () {
var provider = {
/**
* init is called when the provider is first loaded.
*
* options.providerOptions contains any operator configured parameters
* specified in the `metrics_provider_options_json` field of the Consul
* agent configuration file.
*
* Consul will provide:
*
* 1. A boolean field options.metrics_proxy_enabled to indicate whether the
* agent has a metrics proxy configured.
*
* 2. A function options.fetch which is a thin wrapper around the browser's
* [Fetch API](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API)
* that prefixes any url with the url of Consul's internal metrics proxy
* endpoint and adds your current Consul ACL token to the request
* headers. Otherwise it functions like the browser's native fetch.
*
* The provider should throw an Exception if the options are not valid, for
* example because it requires a metrics proxy and one is not configured.
*/
init: function(options) {},
/**
* serviceRecentSummarySeries should return time series for a recent time
* period summarizing the usage of the named service in the indicated
* datacenter. In Consul Enterprise a non-empty namespace is also provided.
*
* If these metrics aren't available then an empty series array may be
* returned.
*
* The period may (later) be specified in options.startTime and
* options.endTime.
*
* The service's protocol must be given as one of Consul's supported
* protocols e.g. "tcp", "http", "http2", "grpc". If it is empty or the
* provider doesn't recognize the protocol, it should treat it as "tcp" and
* provide basic connection stats.
*
* The expected return value is a JavaScript promise which resolves to an
* object that should look like the following:
*
* {
* // The unitSuffix is shown after the value in tooltips. Values will be
* // rounded and shortened. Larger values will already have a suffix
* // like "10k". The suffix provided here is concatenated directly
* // allowing for suffixes like "mbps/kbps" by using a suffix of "bps".
* // If the unit doesn't make sense in this format, include a
* // leading space for example " rps" would show as "1.2k rps".
* unitSuffix: " rps",
*
* // The set of labels to graph. The key should exactly correspond to a
* // property of every data point in the array below except for the
* // special case "Total" which is used to show the sum of all the
* // stacked graph values. The key is displayed in the tooltip so it
* // should be human-friendly but as concise as possible. The value is a
* // longer description that is displayed in the graph's key on request
* // to explain exactly what the metrics mean.
* labels: {
* "Total": "Total inbound requests per second.",
* "Successes": "Successful responses (with an HTTP response code ...",
* "Errors": "Error responses (with an HTTP response code in the ...",
* },
*
* data: [
* {
* time: 1600944516286, // milliseconds since Unix epoch
* "Successes": 1234.5,
* "Errors": 2.3,
* },
* ...
* ]
* }
*
* Every data point object should have a value for every series label
* (except for "Total") otherwise it will be assumed to be "0".
*/
serviceRecentSummarySeries: function(serviceDC, namespace, serviceName, protocol, options) {},
/**
* serviceRecentSummaryStats should return four summary statistics for a
* recent time period for the named service in the indicated datacenter. In
* Consul Enterprise a non-empty namespace is also provided.
*
* If these metrics aren't available then an empty array may be returned.
*
* The period may (later) be specified in options.startTime and
* options.endTime.
*
* The service's protocol must be given as one of Consul's supported
* protocols e.g. "tcp", "http", "http2", "grpc". If it is empty or the
* provider doesn't recognize it it should treat it as "tcp" and provide
* just basic connection stats.
*
* The expected return value is a JavaScript promise which resolves to an
* object that should look like the following:
*
* {
// stats is an array of stats to show. The first four of these will be
// displayed. Fewer may be returned if not available.
* stats: [
* {
* // label should be 3 chars or fewer as an abbreviation
* label: "SR",
*
* // desc describes the stat in a tooltip
* desc: "Success Rate - the percentage of all requests that were not 5xx status",
*
* // value is a string allowing the provider to format it and add
* // units as appropriate. It should be as compact as possible.
* value: "98%",
* }
* ]
* }
*/
serviceRecentSummaryStats: function(serviceDC, namespace, serviceName, protocol, options) {},
/**
* upstreamRecentSummaryStats should return four summary statistics for each
* upstream service over a recent time period, relative to the named service
* in the indicated datacenter. In Consul Enterprise a non-empty namespace
* is also provided.
*
* Note that the upstreams themselves might be in different datacenters but
* we only pass the target service DC since typically these metrics should
* be from the outbound listener of the target service in this DC even if
* the requests eventually end up in another DC.
*
* If these metrics aren't available then an empty array may be returned.
*
* The period may (later) be specified in options.startTime and
* options.endTime.
*
* The expected return value is a JavaScript promise which resolves to an
* object that should look like the following:
*
* {
* stats: {
* // Each upstream will appear as an entry keyed by the upstream
* // service name. The value is an array of stats with the same
* // format as serviceRecentSummaryStats response.stats. Note that
* // different upstreams might show different stats depending on
* // their protocol.
* "upstream_name": [
* {label: "SR", desc: "...", value: "99%"},
* ...
* ],
* ...
* }
* }
*/
upstreamRecentSummaryStats: function(serviceDC, namespace, serviceName, upstreamName, options) {},
/**
* downstreamRecentSummaryStats should return four summary statistics for
* each downstream service over a recent time period, relative to the named
* service in the indicated datacenter. In Consul Enterprise a non-empty
* namespace is also provided.
*
* Note that the service may have downstreams in different datacenters. For
* some metrics systems which are per-datacenter this makes it hard to query
* for all downstream metrics from one source. For now the UI will only show
* downstreams in the same datacenter as the target service. In the future
* this method may be called multiple times, once for each DC that contains
* downstream services to gather metrics from each. In that case a separate
* option for target datacenter will be used since the target service's DC
* is still needed to correctly identify the outbound clusters that will
* route to it from the remote DC.
*
* If these metrics aren't available then an empty array may be returned.
*
* The period may (later) be specified in options.startTime and
* options.endTime.
*
* The expected return value is a JavaScript promise which resolves to an
* object that should look like the following:
*
* {
* stats: {
* // Each downstream will appear as an entry keyed by the downstream
* // service name. The value is an array of stats with the same
* // format as serviceRecentSummaryStats response.stats. Different
* // downstreams may display different stats if required although the
* // protocol should be the same for all as it is the target
* // service's protocol that matters here.
* "downstream_name": [
* {label: "SR", desc: "...", value: "99%"},
* ...
* ],
* ...
* }
* }
*/
downstreamRecentSummaryStats: function(serviceDC, namespace, serviceName, options) {}
}
// Register the provider with Consul for use. This example would be usable by
// configuring the agent with `ui_config.metrics_provider = "example-provider".
window.consul.registerMetricsProvider("example-provider", provider)
}());
또한 내장 Prometheus 공급자 코드를 참조 자료로 사용할 수 있습니다.
에이전트를 사용자 정의 메트릭 공급자로 구성 (Configuring the Agent With a Custom Metrics Provider)
아래 예시에서는 /usr/local/bin/example-metrics-provider.js에 정의된 example-provider라는 메트릭 공급자를 사용하도록 Consul 에이전트를 구성합니다. example-provider라는 이름은 마지막 섹션의 코드 목록에서와 같이 consul.registerMetricsProvider 호출에 지정되었어야 합니다.
사용자 정의 메트릭 공급자를 사용하는 구성 예시
agent-config.hclui_config {
enabled = true
metrics_provider = "example-provider"
metrics_provider_files = ["/usr/local/bin/example-metrics-provider.js"]
metrics_provider_options_json = <<-EOT
{
"foo": "bar"
}
EOT
}
agent-config.json{
"ui_config": {
"enabled": true,
"metrics_provider": "example-provider",
"metrics_provide_files": ["/usr/local/bin/example-metrics-provider.js"],
"metrics_provider_options_json": "{\"foo\":\"bar\"}"
}
}
metrics_provider_files에는 둘 이상의 JavaScript 파일을 지정할 수 있으며 필요에 따라 종속성을 포함할 수 있도록 모두 제공됩니다.
한 번에 하나의 메트릭 공급자만 구성하고 사용할 수 있습니다.
metrics_provider_options_json 필드는 시작 시 공급자의 init 메서드에 전달되는 선택적 리터럴 JSON 객체입니다. 이를 통해 공급자 자체에 하드코딩하는 대신 구성에서 공급자에 대한 임의의 매개변수를 구성할 수 있어 공급자를 더 재사용할 수 있게 만듭니다.
공급자는 다른 소스에서 메트릭을 직접 가져올 수도 있습니다. 다만 이 경우 에이전트가 브라우저가 이러한 요청을 차단하지 못하도록 올바른 CORS 헤더를 제공해야 할 것입니다. 이는 http_config.response_headers로 구성할 수 있습니다.
또는 공급자는 내장 메트릭 프록시를 사용해 교차 도메인 문제를 피하거나 각 UI 사용자가 메트릭 백엔드에 별도로 인증되지 않아도 추가 권한 부여 헤더를 주입할 수 있습니다.
init 중에 브라우저의 Fetch API처럼 동작하는 함수가 메트릭 공급자 JavaScript에 options.fetch로 제공됩니다. 이는 Consul의 메트릭 프록시 엔드포인트의 URL을 모든 URL 앞에 붙이고 현재 Consul ACL 토큰을 요청 헤더에 추가하는 얇은 래퍼입니다. 그 외에는 브라우저의 네이티브 fetch처럼 동작하며 요청을 메트릭 백엔드로 전달합니다. 응답은 수정 없이 반환되어 공급자가 해석하고 위 인터페이스에서 설명한 형식으로 변환합니다.
공급자 작성자는 사용자가 메트릭 프록시의 경로 허용 목록을 올바르게 구성해 메트릭 백엔드를 필요한 것보다 더 많이 노출하지 않도록 어떤 경로가 필요한지 명확히 알려야 합니다.
사용자 정의 공급자 보안 모델 (Custom Provider Security Model)
JavaScript 파일이 Consul의 UI에 그대로 포함되므로 그 안의 코드는 운영자가 완전히 신뢰해야 하는 것으로 취급해야 합니다. 일반적으로 운영자는 이를 직접 작성했거나 제3자가 작성한 공급자를 주의 깊게 검증해야 합니다.
이는 기존 -ui-dir 플래그를 사용해 대체 버전의 UI를 제공하는 것과 동일합니다. 두 모델 모두 운영자가 제공하는 코드의 출처에 대해 전적인 책임을 집니다. 코드는 ACL 토큰을 가로채거나 Consul UI 도메인에 대한 쿠키와 로컬 저장소에 액세스하는 등을 할 수 있기 때문입니다.
현재 제한 사항 (Current Limitations)
현재 이 기능에는 몇 가지 제한 사항이 있습니다.
- 크로스 데이터센터 지원 없음 : 초기 메트릭 공급자 통합은 하나의 Kubernetes 클러스터 내에서 인기가 있고 설정이 쉬운 Prometheus와 함께입니다. 그러나 멀티 데이터센터 배포에서 Consul UI를 사용할 때 UI는 사용자가 어떤 데이터센터든 선택해 볼 수 있게 합니다. 이는 UI를 제공하는 Consul 에이전트가 액세스할 수 있는 Prometheus 서버가 로컬 데이터센터의 메트릭만 가질 가능성이 높고, 완전한 솔루션은 원격 데이터센터의 네트워크에 있는 원격 Prometheus 서버를 추가로 프록시하거나 노출해야 한다는 것을 의미합니다. 나중에 Consul 서비스 메시를 통해 이를 쉽게 설정하는 방법을 지원할 수 있지만 초기에는 원격 데이터센터를 탐색할 때 UI에서 메트릭을 가져오려고 시도하지 않습니다.
- 내장 공급자는 메트릭 프록시 필요 : 초기에는 내장 prometheus 공급자만 메트릭 프록시를 통해 Prometheus를 쿼리하는 것을 지원합니다. 나중에는 노출된 Prometheus에 직접 액세스하도록 구성하는 것이 가능해질 수 있습니다.