自动发现
编辑自动发现
编辑当你在容器上运行应用程序时,它们会成为监控系统的移动目标。自动发现允许你跟踪它们并在发生更改时调整设置。通过定义配置模板,自动发现子系统可以在服务开始运行时对其进行监控。
你可以在 metricbeat.yml
配置文件的 metricbeat.autodiscover
部分定义自动发现设置。要启用自动发现,你需要指定一个提供程序列表。
提供程序
编辑自动发现提供程序的工作原理是监视系统上的事件,并将这些事件转换为具有通用格式的内部自动发现事件。配置提供程序时,你可以选择使用自动发现事件中的字段来设置条件,当满足条件时,将启动特定的配置。
在启动时,Metricbeat 将扫描现有的容器并为其启动适当的配置。然后它将监视新的启动/停止事件。这确保你无需担心状态,只需定义所需的配置即可。
Docker
编辑Docker 自动发现提供程序会监视 Docker 容器的启动和停止。
它具有以下设置
-
host
- (可选)Docker 套接字(UNIX 或 TCP 套接字)。默认使用
unix:///var/run/docker.sock
。 -
ssl
- (可选)连接到 Docker 套接字时要使用的 SSL 配置。
-
cleanup_timeout
- (可选)指定在停止容器的正在运行的配置之前的不活动时间,默认情况下禁用。
-
labels.dedot
- (可选)默认为 false。如果设置为 true,则将标签中的点替换为
_
。
以下是可在配置模板中使用的字段。 docker.*
字段将在每个发出的事件中可用。event
- host
- port
- docker.container.id
- docker.container.image
- docker.container.name
- docker.container.labels
例如
{ "host": "10.4.15.9", "port": 6379, "docker": { "container": { "id": "382184ecdb385cfd5d1f1a65f78911054c8511ae009635300ac28b4fc357ce51" "name": "redis", "image": "redis:3.2.11", "labels": { "io.kubernetes.pod.namespace": "default" ... } } } }
你可以定义一组配置模板,当条件与事件匹配时应用这些模板。模板定义了一个与自动发现事件匹配的条件,以及当此条件发生时要启动的配置列表。
条件匹配来自提供程序的事件。提供程序使用与处理器使用的 条件 相同的格式。
配置模板可以包含来自自动发现事件的变量。可以通过 data
命名空间访问它们。例如,使用示例事件,“${data.port}
” 解析为 6379
。
Metricbeat 支持模块的模板
metricbeat.autodiscover: providers: - type: docker labels.dedot: true templates: - condition: contains: docker.container.image: redis config: - module: redis metricsets: ["info", "keyspace"] hosts: "${data.host}:6379"
此配置为所有运行名称中包含 redis
的映像的容器启动 redis
模块。对于 Docker 自动发现,labels.dedot
默认为 true
,这意味着 Docker 标签中的点默认替换为 _。
此外,Metricbeat 自动发现支持利用 密钥库 来检索密码等敏感数据。以下是使用密钥库的配置示例
metricbeat.autodiscover: providers: - type: docker labels.dedot: true templates: - condition: contains: docker.container.image: redis config: - module: redis metricsets: ["info", "keyspace"] hosts: "${data.host}:6379" password: "${REDIS_PASSWORD}"
其中 REDIS_PASSWORD
是存储在 Metricbeat 本地密钥库中的密钥。
Kubernetes
编辑Kubernetes 自动发现提供程序监视 Kubernetes 节点、Pod、服务的启动、更新和停止。
kubernetes
自动发现提供程序具有以下配置设置
-
node
- (可选)指定 metricbeat 的范围节点,以防无法准确检测到,例如在主机网络模式下运行 metricbeat 时。
-
namespace
- (可选)选择要从中收集资源事件的命名空间。如果未设置,则提供程序将从所有命名空间中收集事件。默认情况下未设置。命名空间配置仅适用于命名空间范围的 Kubernetes 资源,并且如果
unique
字段设置为false
。 -
cleanup_timeout
- (可选)指定在停止容器的正在运行的配置之前的不活动时间,默认情况下禁用。
-
kube_config
- (可选)使用给定的配置文件作为 Kubernetes 客户端的配置。如果未设置 kube_config,则将检查 KUBECONFIG 环境变量,如果不存在,则将回退到 InCluster。
-
kube_client_options
- (可选)可以为 Kubernetes 客户端配置其他选项。目前支持客户端 QPS 和突发,如果未设置,将使用 Kubernetes 客户端的默认 QPS 和突发。示例
kube_client_options: qps: 5 burst: 10
-
resource
- (可选)选择要执行发现的资源。当前支持的 Kubernetes 资源有
pod
、service
和node
。如果未配置,则resource
默认为pod
。 -
scope
- (可选)指定需要在哪个级别进行自动发现。
scope
可以采用node
或cluster
作为值。node
范围允许发现指定节点中的资源。cluster
范围允许集群范围的发现。只有pod
和node
资源可以在节点范围内发现。 -
add_resource_metadata
-
(可选)为将添加到事件的额外元数据指定过滤器和配置。配置参数
-
node
或namespace
:为来自节点和命名空间的额外元数据指定标签和注释过滤器。默认情况下,包含所有标签,而不包含注释。要更改默认行为,可以定义include_labels
、exclude_labels
和include_annotations
。这些设置在存储需要特殊处理以避免存储输出过载的标签和注释时非常有用。注意:这些设置不支持通配符。可以通过设置enabled: false
来单独禁用node
或namespace
元数据的丰富。 -
deployment
:如果资源是pod
并且是从deployment
创建的,则默认情况下不会添加部署名称,可以通过设置deployment: true
来启用此项。 -
cronjob
:如果资源是pod
并且是从cronjob
创建的,则默认情况下不会添加 cronjob 名称,可以通过设置cronjob: true
来启用此项。示例
-
add_resource_metadata: namespace: include_labels: ["namespacelabel1"] node: include_labels: ["nodelabel2"] include_annotations: ["nodeannotation1"] # deployment: false # cronjob: false
-
unique
- (可选)默认为
false
。将自动发现提供程序标记为唯一会导致提供程序仅在其获得领导者租约时才启用提供的模板。此设置只能与cluster
范围结合使用。启用unique
时,将不考虑resource
和add_resource_metadata
设置。 -
leader_lease
- (可选)默认为
metricbeat-cluster-leader
。这将是锁租约的名称。可以使用kubectl describe lease beats-cluster-leader
监视租约的状态。引用同一领导者租约的不同 Beats 将成为争夺租约的竞争者,并且每次只会选出一个作为领导者。 -
leader_leaseduration
- (可选)非领导者候选人将等待强制获取租约领导权的持续时间。默认为
15s
。 -
leader_renewdeadline
- (可选)领导者在放弃之前重试刷新其领导权的持续时间。默认为
10s
。 -
leader_retryperiod
- (可选)运行以获取租约的 metricbeat 实例在尝试操作之间应等待的持续时间。默认为
2s
。
配置模板可以包含来自自动发现事件的变量。这些变量可以在 data
命名空间下访问,例如,要访问 Pod IP:${data.kubernetes.pod.ip}
。
以下是可在配置模板中使用的字段。kubernetes.*
字段将在每个发出的事件中可用
通用字段
编辑- host
Pod 特定
编辑键 | 类型 | 描述 |
---|---|---|
|
|
Pod 端口。如果 Pod 有多个暴露的端口,则应使用 |
|
|
Pod 运行所在的命名空间 |
|
|
Pod 运行所在的命名空间的 UUID |
|
|
Pod 运行所在的命名空间的注释。注释应以未去点格式使用,例如 |
|
|
Pod 的名称 |
|
|
Pod 的 UID |
|
|
Pod 的 IP |
|
|
Pod 标签的对象。标签应以未去点格式使用,例如 |
|
|
Pod 注释的对象。注释应以未去点格式使用,例如 |
|
|
容器的名称 |
|
|
容器的运行时 |
|
|
容器的 ID |
|
|
容器的映像 |
|
|
节点的名称 |
|
|
节点的 UID |
|
|
节点的主机名 |
节点特定
编辑键 | 类型 | 描述 |
---|---|---|
|
|
节点标签的对象 |
|
|
节点注释的对象 |
|
|
节点的名称 |
|
|
节点的 UID |
|
|
节点的主机名 |
服务特定
编辑键 | 类型 | 描述 |
---|---|---|
|
|
服务端口 |
|
|
服务的命名空间 |
|
|
服务命名空间的 UUID |
|
|
服务命名空间的注释。注释应以未去点格式使用,例如 |
|
|
服务标签的对象 |
|
|
服务注释的对象 |
|
|
服务的名称 |
|
|
服务的 UID |
如果将 include_annotations
配置添加到提供程序配置中,则配置中存在的注释列表将添加到事件中。
如果将 include_labels
配置添加到提供程序配置中,则配置中存在的标签列表将添加到事件中。
如果将 exclude_labels
配置添加到提供程序配置中,则配置中存在的标签列表将从事件中排除。
如果提供程序配置中将 labels.dedot
配置设置为 true
,则标签中的 .
将被替换为 _
。默认情况下为 true
。
如果提供程序配置中将 annotations.dedot
配置设置为 true
,则注释中的 .
将被替换为 _
。默认情况下为 true
。
从 8.6 版本开始,配置模板中使用的 kubernetes.labels.*
不会去除点,无论 labels.dedot
的值如何。此配置参数仅影响添加到最终 Elasticsearch 文档中的字段。例如,对于带有标签 app.kubernetes.io/name=ingress-nginx
的 Pod,匹配条件应为 condition.equals: kubernetes.labels.app.kubernetes.io/name: "ingress-nginx"
。如果 labels.dedot
设置为 true
(默认值),则标签将作为 kubernetes.labels.app_kubernetes_io/name
存储在 Elasticsearch 中。同样适用于 Kubernetes 注释。
例如
{ "host": "172.17.0.21", "port": 9090, "kubernetes": { "container": { "id": "bb3a50625c01b16a88aa224779c39262a9ad14264c3034669a50cd9a90af1527", "image": "prom/prometheus", "name": "prometheus" }, "labels": { "project": "prometheus", ... }, "namespace": "default", "node": { "name": "minikube" }, "pod": { "name": "prometheus-2657348378-k1pnh" } }, }
示例
metricbeat.autodiscover: providers: - type: kubernetes scope: cluster node: ${NODE_NAME} unique: true identifier: leader-election-metricbeat templates: - config: - module: kubernetes hosts: ["kube-state-metrics:8080"] period: 10s add_metadata: true metricsets: - state_node
上述配置在部署到一个或多个 Metribceat 实例上时,将仅为获得领导者租约/锁定的 Metricbeat 实例启用 state_node
度量集。通过这种部署策略,我们可以确保在将 Beat 作为 DaemonSet 部署时,集群范围的度量集仅由一个 Beat 实例启用。
Metricbeat 支持模块的模板
metricbeat.autodiscover: providers: - type: kubernetes include_annotations: ["prometheus.io.scrape"] templates: - condition: contains: kubernetes.annotations.prometheus.io/scrape: "true" config: - module: prometheus metricsets: ["collector"] hosts: "${data.host}:${data.port}"
此配置为注释了 prometheus.io/scrape=true
的 Pod 的所有容器启动一个 prometheus
模块。
使用 Kubernetes 手动定义端口
编辑如果可能,请在 Pod 规范中声明公开的端口。否则,您将需要使用带有复杂过滤规则的多个模板。 {port} 变量将不存在,您将需要硬编码端口。示例: {data.host}:1234
当未声明端口时,自动发现会为每个 Pod 和每个容器生成一个使用您提供的模板的配置。这些生成的配置在生成后会进行去重。如果多个容器生成的配置相同,则它们将合并为一个配置。
Pod 共享一个相同的主机。如果仅插值 {data.host}
变量,则每个主机将生成一个配置。这些配置将是相同的。在它们去重后,只会使用一个。
为了定位一个特定的公开端口,可以在模板配置中使用 {data.host}:{data.ports.web}
,其中 web
是公开的容器端口的名称。
Metricbeat 自动发现 Secret 管理
编辑本地密钥库
编辑Metricbeat 自动发现支持利用密钥库来检索敏感数据,例如密码。以下是使用密钥库的配置示例
metricbeat.autodiscover: providers: - type: kubernetes templates: - condition: contains: kubernetes.labels.app: "redis" config: - module: redis metricsets: ["info", "keyspace"] hosts: "${data.host}:6379" password: "${REDIS_PASSWORD}"
其中 REDIS_PASSWORD
是存储在 Metricbeat 本地密钥库中的密钥。
Kubernetes Secrets
编辑Metricbeat 自动发现支持利用Kubernetes Secrets来检索敏感数据,例如密码。为了启用此功能,请在 Metricbeat 的 ClusterRole
规则中添加以下部分
- apiGroups: [""] resources: - secrets verbs: ["get"]
上述规则将授予 Metricbeat Pod 访问 Kubernetes Secrets API 的权限。这意味着任何有权访问 Metricbeat Pod(例如 kubectl exec
)的人都将能够访问 Kubernetes Secrets API 并获取特定的 secret,无论它属于哪个命名空间。应仔细考虑此选项,尤其是在与提示一起使用时。
一种只为一个命名空间授予权限,而不是集群范围的方法是为目标命名空间使用特定的 Role,以便更好地控制访问
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: marketing-team name: secret-reader rules: - apiGroups: [""] # "" indicates the core API group resources: ["secrets"] verbs: ["get"]
可以在官方 Kubernetes 文档中找到有关 Role 和 ClusterRole 的更多信息。
以下是使用 Kubernetes secrets 的配置示例
metricbeat.autodiscover: providers: - type: kubernetes templates: - condition: contains: kubernetes.labels.app: "redis" config: - module: redis metricsets: ["info", "keyspace"] hosts: "${data.host}:6379" password: "${kubernetes.default.somesecret.value}"
其中 kubernetes.default.somesecret.value
指定一个作为 Kubernetes secret 存储的密钥,如下所示
- Kubernetes 命名空间:
default
- Kubernetes Secret 名称:
somesecret
- Secret 数据密钥:
value
可以使用以下命令在 Kubernetes 环境中创建此 secret
cat << EOF | kubectl apply -f - apiVersion: v1 kind: Secret metadata: name: somesecret type: Opaque data: value: $(echo -n "passpass" | base64) EOF
请注意,Pod 只能使用属于同一 Kubernetes 命名空间的 secret。例如,如果 Pod my-redis
在 staging
命名空间下运行,则它无法访问 testing
命名空间下的 secret,例如 kubernetes.testing.xxx.yyy
。
Jolokia
编辑Jolokia 自动发现提供程序使用 Jolokia Discovery 来查找在您的主机或网络中运行的代理。
此提供程序的配置由一组网络接口以及与其他提供程序相同的模板组成。网络接口将是用于发现探测的接口,interfaces
的每个项目都具有以下设置
-
名称
- 接口的名称(例如
br0
),它可以包含一个通配符作为后缀,以将相同的设置应用于多个相同类型的网络接口(例如br*
)。 -
间隔
- 探测之间的时间(默认为 10 秒)
-
宽限期
- 自上次回复以来被认为实例已停止的时间(默认为 30 秒)
-
探测超时
- 自发送探测以来等待响应的最大时间(默认为 1 秒)
任何 1.2.0 版本之后的 Jolokia 代理都支持 Jolokia Discovery 机制,当 Jolokia 作为 JVM 代理包含在应用程序中时,默认情况下会启用它,但在其他情况下(例如 OSGI 或 WAR (Java EE) 代理)则会禁用它。在任何情况下,此功能都由两个属性控制
-
discoveryEnabled
,用于启用该功能 -
discoveryAgentUrl
,如果设置,这是代理在被发现时宣布的 URL,设置此参数会隐式启用该功能
有多种设置这些属性的方法,并且它们可能因应用程序而异,请参阅您的应用程序的文档以找到在您的案例中设置它们的更合适的方法。
Jolokia Discovery 基于 UDP 多播请求。代理加入多播组 239.192.48.84,端口 24884,并通过向该组发送查询来完成发现。您必须考虑到必须允许 Metricbeat 和 Jolokia 代理之间的 UDP 流量。另请注意,此多播地址在 239.0.0.0/8 范围内,该范围保留供组织内部私用,因此它只能在专用网络中使用。
以下是在配置模板中可用的字段。jolokia.*
字段将在每个发出的事件中可用。
- jolokia.agent.id
- jolokia.agent.version
- jolokia.secured
- jolokia.server.product
- jolokia.server.vendor
- jolokia.server.version
- jolokia.url
Metricbeat 支持模块的模板
metricbeat.autodiscover: providers: - type: jolokia interfaces: - name: br* interval: 5s grace_period: 10s - name: en* templates: - condition: contains: jolokia.server.product: "tomcat" config: - module: jolokia metricsets: ["jmx"] hosts: "${data.jolokia.url}" namespace: test jmx.mappings: - mbean: "java.lang:type=Runtime" attributes: - attr: Uptime field: uptime
此配置启动一个 jolokia 模块,该模块收集每个发现的 tomcat
实例的正常运行时间。使用所有以 br
和 en
开头的接口发送发现探测,对于 br
接口,interval
和 grace_period
分别减少到 5 秒和 10 秒。
Amazon EC2
编辑此功能处于技术预览阶段,可能会在未来的版本中更改或删除。Elastic 将努力修复任何问题,但技术预览中的功能不受官方 GA 功能的支持 SLA 的约束。
Amazon EC2 自动发现提供程序发现 EC2 实例。这对于用户启动 Metricbeat 模块以监视在 AWS EC2 实例上运行的服务非常有用。
例如,您可以使用此提供程序从具有特定标签 service: mysql
的 EC2 实例上运行的 MySQL 服务器收集 MySQL 度量。
此提供程序将使用标准的 AWS 环境变量和共享凭证文件加载 AWS 凭证,有关更多信息,请参阅 管理 AWS 访问密钥的最佳实践。如果您不想使用这些,则可以显式设置 access_key_id
和 secret_access_key
变量。
以下是在配置模板中可用的字段。aws.ec2.*
字段和 cloud.*
字段将在每个发出的事件中可用。
- cloud.availability_zone
- cloud.instance.id
- cloud.machine.type
- cloud.provider
- cloud.region
- aws.ec2.architecture
- aws.ec2.image.id
- aws.ec2.kernel.id
- aws.ec2.monitoring.state
- aws.ec2.private.dns_name
- aws.ec2.private.ip
- aws.ec2.public.dns_name
- aws.ec2.public.ip
- aws.ec2.root_device_name
- aws.ec2.state.code
- aws.ec2.state.name
- aws.ec2.subnet.id
- aws.ec2.tags
- aws.ec2.vpc.id
Metricbeat 支持模块的模板
metricbeat.autodiscover: providers: - type: aws_ec2 period: 1m credential_profile_name: elastic-beats templates: - condition: equals: aws.ec2.tags.service: "mysql" config: - module: mysql metricsets: ["status", "galera_status"] period: 10s hosts: ["root:password@tcp(${data.aws.ec2.public.ip}:3306)/"] username: root password: password
此自动发现提供程序采用我们标准的 AWS 凭证选项。使用此配置,将为所有具有 service: mysql
标签的 EC2 实例启动 mysql
metricbeat 模块。
此自动发现提供程序采用我们标准的 AWS 凭证选项。