在容器见解中筛选日志收集
本文介绍了容器见解中提供的不同筛选选项。 Kubernetes 群集生成容器见解收集的大量数据。 由于为引入和保留此数据付费,因此可以筛选出不需要的数据以显著降低监视成本。
重要
本文介绍了需要修改受监视群集的 DCR 或 ConfigMap 的不同筛选选项。 有关执行此配置的详细信息,请参阅在容器见解中配置日志收集。
筛选容器日志
容器日志是由 Kubernetes 群集中的容器生成的 stderr 和 stdout 日志。 这些日志存储在 Log Analytics 工作区的ContainerLogV2 表中。 默认情况下,收集所有容器日志,但可以从特定命名空间中筛选出日志或完全禁用容器日志收集。
使用数据收集规则 (DCR),可以启用或禁用 stdout 和 stderr 日志,并筛选每个日志中的特定命名空间。 容器日志和命名空间筛选的设置包含在 Azure 门户中配置的成本预设中,可以使用其他 DCR 配置方法单独设置这些值。
使用ConfigMap,可以单独为群集配置stderr
和stdout
日志的集合,以便选择启用一个日志而不是另一个日志。
以下示例显示了用于收集 stdout 和 stderr 的 ConfigMap 设置,不包括kube-system
和gatekeeper-system
命名空间。
[log_collection_settings]
[log_collection_settings.stdout]
enabled = true
exclude_namespaces = ["kube-system","gatekeeper-system"]
[log_collection_settings.stderr]
enabled = true
exclude_namespaces = ["kube-system","gatekeeper-system"]
[log_collection_settings.enrich_container_logs]
enabled = true
平台日志筛选(系统 Kubernetes 命名空间)
默认情况下,系统命名空间中的容器日志从集合中排除,以最大程度地降低 Log Analytics 成本。 但是,在特定的故障排除场景中,系统容器的容器日志可能至关重要。 此功能仅限于以下系统命名空间:kube-system
、gatekeeper-system
、calico-system
、 azure-arc
、kube-public
和kube-node-lease
。
通过collect_system_pod_logs
设置使用ConfigMap启用平台日志。 还必须确保系统命名空间不在exclude_namespaces
设置中。
以下示例演示了用于收集kube-system
命名空间中coredns
容器的 stdout 和 stderr 日志的 ConfigMap 设置。
[log_collection_settings]
[log_collection_settings.stdout]
enabled = true
exclude_namespaces = ["gatekeeper-system"]
collect_system_pod_logs = ["kube-system:coredns"]
[log_collection_settings.stderr]
enabled = true
exclude_namespaces = ["kube-system","gatekeeper-system"]
collect_system_pod_logs = ["kube-system:coredns"]
基于注释的工作负载筛选
基于注释的筛选使你能够通过注释 Pod 来排除某些 Pod 和容器的日志收集。 这可以显著降低日志引入成本,并允许专注于相关信息,而无需筛选干扰。
通过以下设置使用ConfigMap启用基于注释的筛选。
[log_collection_settings.filter_using_annotations]
enabled = true
还必须在工作负载 Pod 规范上添加所需的注释。下表突出显示了不同的可能的 Pod 批注。
注释 | 说明 |
---|---|
fluentbit.io/exclude: "true" |
排除 Pod 中所有容器上的 stdout 和 stderr 流 |
fluentbit.io/exclude_stdout: "true" |
仅排除 Pod 中所有容器上的 stdout 流 |
fluentbit.io/exclude_stderr: "true" |
仅排除 Pod 中所有容器上的 stderr 流 |
fluentbit.io/exclude_container1: "true" |
仅针对 Pod 中的 container1 排除 stdout 和 stderr 流 |
fluentbit.io/exclude_stdout_container1: "true" |
仅针对 pod 中 container1 排除 stdout |
注意
这些注释是基于 fluent bit 的。 如果将你自己的基于 fluent-bit 的日志收集解决方案与 Kubernetes 插件筛选器和基于注释的排除结合使用,它将停止从 Container Insights 和你的解决方案收集日志。
下面是 Pod 规范中fluentbit.io/exclude: "true"
注释的示例:
apiVersion: v1
kind: Pod
metadata:
name: apache-logs
labels:
app: apache-logs
annotations:
fluentbit.io/exclude: "true"
spec:
containers:
- name: apache
image: edsiper/apache_logs
筛选环境变量
通过以下设置使用ConfigMap,跨群集中的所有 Pod 和节点启用环境变量集合。
[log_collection_settings.env_var]
enabled = true
如果环境变量集合已全局启用,则可对特定容器禁用它,方法是将环境变量 AZMON_COLLECT_ENV
设置为 False
,可以在 Dockerfile 设置中这样做,也可以在 Pod 的配置文件(位于 env:
部分下)中这样做。 如果环境变量集合已全局启用,则无法为特定容器启用集合。 唯一可在容器级别应用的替代是在已全局启用集合的情况下禁用集合。
对可视化效果和警报的影响
如果有任何使用容器见解数据的自定义警报或工作簿,则修改数据收集设置可能会导致这些体验降级。。 如果你要排除命名空间或降低数据收集频率,请查看使用此数据的现有警报、仪表板和工作簿。
若要扫描引用这些表的警报,请运行以下 Azure Resource Graph 查询:
resources
| where type in~ ('microsoft.insights/scheduledqueryrules') and ['kind'] !in~ ('LogToMetric')
| extend severity = strcat("Sev", properties["severity"])
| extend enabled = tobool(properties["enabled"])
| where enabled in~ ('true')
| where tolower(properties["targetResourceTypes"]) matches regex 'microsoft.operationalinsights/workspaces($|/.*)?' or tolower(properties["targetResourceType"]) matches regex 'microsoft.operationalinsights/workspaces($|/.*)?' or tolower(properties["scopes"]) matches regex 'providers/microsoft.operationalinsights/workspaces($|/.*)?'
| where properties contains "Perf" or properties contains "InsightsMetrics" or properties contains "ContainerInventory" or properties contains "ContainerNodeInventory" or properties contains "KubeNodeInventory" or properties contains"KubePodInventory" or properties contains "KubePVInventory" or properties contains "KubeServices" or properties contains "KubeEvents"
| project id,name,type,properties,enabled,severity,subscriptionId
| order by tolower(name) asc
后续步骤
- 请参阅容器见解中的数据转换,以向 DCR 添加转换,以便根据详细条件进一步筛选数据。