优化的解决方案:使用 DataFlux 采集 Docker 监控指标并展示

　　优化的解决方案:使用 DataFlux 采集 Docker 监控指标并展示

　　DataFlux是上海住云自主研发的一套统一的大数据分析平台，通过对任意来源、任意类型、任意规模的实时数据进行监测、分析和处理，释放数据价值。

　　DataFlux 包括五个功能模块：

　　- 数据包 采集器

　　- Dataway 数据网关

　　- DataFlux Studio 实时数据洞察平台

　　- DataFlux Admin Console 管理后台

　　- DataFlux.f(x) 实时数据处理开发平台

　　为企业提供全场景数据洞察分析能力，具有实时性、灵活性、易扩展性、易部署性。

　　安装 DataKit

　　PS：以Linux系统为例

　　第一步：执行安装命令

　　DataKit 安装命令：

　　DK_FTDATAWAY=[你的 DataWay 网关地址] bash -c "$(curl https://static.dataflux.cn/datakit/install.sh)"

　　在安装命令中添加DataWay网关地址，然后将安装命令复制到主机执行。

　　例如：如果DataWay网关的IP地址为1.2.3.4，端口为9528（9528为默认端口），则网关地址为：9528/v1/write/metrics，安装命令为：

　　DK_FTDATAWAY=http://1.2.3.4:9528/v1/write/metrics bash -c "$(curl https://static.dataflux.cn/datakit/install.sh)"

　　安装完成后DataKit会默认自动运行，并会在终端提示DataKit状态管理命令

　　Docker 指标采集

　　采集 docker 指标报告给 DataFlux

　　打开DataKit采集源码配置文件夹（默认路径是DataKit安装目录的conf.d文件夹），找到docker文件夹，打开里面的docker.conf。

　　设置：

　　# Read metrics about docker containers

[[inputs.docker]]

## Docker Endpoint

## To use TCP, set endpoint = "tcp://[ip]:[port]"

## To use environment variables (ie, docker-machine), set endpoint = "ENV"

endpoint = "unix:///var/run/docker.sock"

<p>

## Set to true to collect Swarm metrics(desired_replicas, running_replicas)

## Note: configure this in one of the manager nodes in a Swarm cluster.

## configuring in multiple Swarm managers results in duplication of metrics.

gather_services = false

## Only collect metrics for these containers. Values will be appended to

## container_name_include.

## Deprecated (1.4.0), use container_name_include

container_names = []

## Set the source tag for the metrics to the container ID hostname, eg first 12 chars

source_tag = false

## Containers to include and exclude. Collect all if empty. Globs accepted.

container_name_include = []

container_name_exclude = []

## Container states to include and exclude. Globs accepted.

## When empty only containers in the "running" state will be captured.

## example: container_state_include = ["created", "restarting", "running", "removing", "paused", "exited", "dead"]

## example: container_state_exclude = ["created", "restarting", "running", "removing", "paused", "exited", "dead"]

# container_state_include = []

# container_state_exclude = []

## Timeout for docker list, info, and stats commands

timeout = "5s"

## Whether to report for each container per-device blkio (8:0, 8:1...) and

## network (eth0, eth1, ...) stats or not

perdevice = true

　　

## Whether to report for each container total blkio and network stats or not

total = false

## docker labels to include and exclude as tags. Globs accepted.

## Note that an empty array for both will include all labels as tags

docker_label_include = []

docker_label_exclude = []

## Which environment variables should we use as a tag

tag_env = ["JAVA_HOME", "HEAP_SIZE"]

## Optional TLS Config

# tls_ca = "/etc/telegraf/ca.pem"

# tls_cert = "/etc/telegraf/cert.pem"

# tls_key = "/etc/telegraf/key.pem"

## Use TLS but skip chain & host verification

# insecure_skip_verify = false</p>

　　配置好后重启DataKit生效

　　验证数据报告

　　完成数据采集操作后，我们需要验证数据采集是否成功并上报给DataWay，以便日后可以正常分析和展示数据。

　　操作步骤：登录DataFlux-数据管理-指标浏览-验证数据采集是否成功

　　码头工人指标：

　　DataFlux 的数据洞察力

　　根据获得的指标进行数据洞察设计，如：

　　Docker监控视图

　　基于自研DataKit数据（采集器），DataFlux现在可以对接200多种数据协议，包括：云数据采集、应用数据采集、日志数据采集，时序数据上报和常用数据库的数据聚合，帮助企业实现最便捷的IT统一监控。

　　汇总:千万级可观测数据采集器--iLogtail代码完整开源

　　简介：2022年6月29日，阿里云iLogtail迎来开源后的第一次重大更新，正式发布全功能iLogtail社区版。在本次更新中，所有 C++ 核心代码都是开源的。该版本是第一个在内核功能方面与企业版保持一致的版本。开发者可以构建 iLogtail 云原生可观测数据采集器，性能媲美企业版。本次发布增加了日志文件采集、容器文件采集、无锁事件处理、多租户隔离等重要特性，以及基于Pipeline的全新配置方式，全面提升了可用性社区版。和性能，欢迎开发者关注，共同打造。

　　作者 | 讯飞，叶默

　　

　　来源 | 阿里开发者公众号

　　2022年6月29日，阿里云iLogtail迎来开源后的第一次重大更新，正式发布全功能iLogtail社区版。在本次更新中，所有 C++ 核心代码都是开源的。该版本是第一个在内核功能方面与企业版保持一致的版本。开发者可以构建 iLogtail 云原生可观测数据采集器，性能媲美企业版。本次发布增加了日志文件采集、容器文件采集、无锁事件处理、多租户隔离等重要特性，以及基于Pipeline的全新配置方式，全面提升了可用性社区版。和性能，欢迎开发者关注，共同打造。

　　可观测性数据采集挑战

　　

　　可观察性是通过检查系统输出来测量系统内部状态的能力。该术语起源于几十年前的控制理论，由匈牙利出生的工程师鲁道夫卡尔曼首次提出。在分布式 IT 系统中，可观察性通常使用各种类型的遥测数据（日志、指标和跟踪）来测量基础设施、平台和应用程序，以了解它们的运行状态和流程。这些数据的采集通常由一个采集Agent 完成，该Agent 与观察到的对象一起运行。在基于云原生和微服务的现代系统架构下，这些观察对象比以往更加分散、数量更多、变化更快，使得采集Agent面临以下挑战：

　　高性能、低开销：现代应用程序往往运行在数据中心、公共云和边缘的数千台服务器、虚拟机和容器中，采集Agent 的每一点性能开销都会被计入 Zoom在数千次。目前很多开源代理的设计都更注重功能而非性能。单核处理性能一般在2-10M/s左右，我们希望达到100M/s的单核性能。在采集目标增加、数据量增加、采集延迟、服务器端异常等情况下，开源代理的内存将呈现爆发式增长，我们希望即使在各种环境下，内存可以在较低的水位。采集稳定准确，多级故障隔离：可观察性需要至少比被观察系统可靠一个数量级。数据采集Agent的稳定性，除了保证数据本身的准确性采集外，还需要保证不影响业务应用，否则会带来灾难性的后果。另一方面，无论问题如何发生，都需要尽可能地隔离问题。比如一个Agent上有多个采集配置，一个配置问题不能影响其他配置。企业级管控*敏*感*词*配置：可观测数据应用广泛。企业内部通常有大量配置。需要代理支持集中化和自动化的配置管理能力，而不是手动登录机器修改配置，并确保配置期间的数据重新加载。不丢失也不重。当Agent有多个采集配置时，合理安排资源。高优先级配置需要优先分配内存带宽等资源，保证低优先级配置不被“饿死”。之后，就有足够的 Burst 能力快速赶上数据。更原生、更友好的K8s支持：K8s提供强大的运维部署、弹性伸缩、故障恢复能力，极大的方便了分布式系统的开发和管理。但是，日志的问题采集 也来了。K8s多样化的数据输出使得同一个Agent需要同时支持采集主机日志、容器日志、容器stdout等数据源。K8s业务部署的弹性伸缩能力要求Agent具备动态发现和标记容器的能力，同时如何保证数据采集