数据采集基础：数据源分类与采集协议
大家好，我是老张。今天咱们聊聊数据采集这块硬骨头。
做智能运维，第一步就是搞定数据采集。说白了，没有数据，后面所有的分析、告警、自动化都是空中楼阁。我见过太多团队，算法模型搞得花里胡哨，结果数据质量一塌糊涂——嗯，这就是典型的「地基没打好」。
数据源怎么分？采集协议怎么选？架构怎么搭？咱们一个一个来。
数据源分类：四大金刚
运维数据，我习惯分成四类：日志、指标、事件、告警。这四类数据，各有各的脾气。
| 数据源类型 | 典型特征 | 常见格式 | 采集频率 |
|---|---|---|---|
| 日志 | 文本化、非结构化、量大 | JSON、Syslog、Apache格式 | 实时/准实时 |
| 指标 | 数值型、时序性、结构化 | Prometheus、StatsD、OpenTSDB | 秒级/分钟级 |
| 事件 | 离散、有状态、可关联 | JSON、Avro、Protobuf | 事件驱动 |
| 告警 | 高优先级、需响应、有生命周期 | Alertmanager、PagerDuty格式 | 实时 |
日志：最原始的数据。应用打印的每一行，都是宝藏。我在项目中遇到过，某次线上故障，就是靠一条被忽略的WARN日志定位到的。日志采集，核心是「全量+实时」，别漏，别丢。
指标：CPU、内存、QPS、延迟……这些数字最能反映系统健康度。我个人习惯用Prometheus做指标采集，它的拉模式（Pull）在Kubernetes环境下特别好用。
事件：比如「服务上线」、「配置变更」、「用户登录」。事件是离散的，但往往能串联出完整的故障链路。你想想看，一次宕机，背后可能是一连串事件：代码发布→配置错误→连接池耗尽→服务雪崩。
告警：这是运维最关心的。告警不是越多越好，我曾经见过一个团队，一天收到5000条告警，最后没人看了。告警要「少而精」，能收敛、能降噪。
核心原则：日志要全，指标要准，事件要通，告警要精。
采集协议：三大主流
数据源搞清楚了，接下来就是怎么把数据「拿」回来。我常用的采集协议就三个：Syslog、SNMP、HTTP。
1. Syslog：日志采集的老大哥
Syslog是Unix/Linux世界的标准日志协议。它简单、轻量、广泛支持。几乎所有网络设备、服务器都支持Syslog。
但Syslog有个坑——它默认是UDP传输，会丢包。我曾经在某个金融项目里，因为Syslog丢包，导致审计日志不完整，差点出合规问题。后来我强制要求用TCP模式，或者用Reliable Syslog（RFC 3195）。
# 典型的Syslog配置示例
# 将日志发送到远程采集服务器
*.* @192.168.1.100:514 # UDP模式
*.* @@192.168.1.100:514 # TCP模式（推荐）
避坑指南：我曾经在日志量超过10万条/秒时，Syslog服务器直接扛不住。后来改用Rsyslog+多队列+磁盘缓冲，才算稳住。记住：Syslog适合中小规模，大规模场景请考虑Kafka。
2. SNMP：网络设备的通用语言
SNMP（简单网络管理协议）是网络设备的标配。交换机、路由器、防火墙、UPS……都支持SNMP。
SNMP有v1、v2c、v3三个版本。v1和v2c用明文传输，v3支持加密和认证。我个人建议：生产环境至少用v2c，能上v3就上v3。
采集指标时，你需要知道OID（对象标识符）。比如CPU利用率的OID是.1.3.6.1.4.1.9.9.109.1.1.1.1.7（Cisco设备）。记不住？没关系，用MIB浏览器查。
# 用snmpwalk采集设备信息
snmpwalk -v 2c -c public 192.168.1.1 .1.3.6.1.2.1.1.5.0
# 返回：SNMPv2-MIB::sysName.0 = STRING: core-switch-01
注意：SNMP的Community字符串（比如public/private）是明文传输的。我曾经在客户现场发现，有人把SNMP Community设成了「public」，结果被外部扫描到，差点被攻击。生产环境请务必修改默认Community，并限制SNMP访问来源IP。
3. HTTP：万能的采集通道
HTTP是最灵活的协议。REST API、Webhook、Prometheus Exporter……都是基于HTTP。
我特别喜欢HTTP的一点是：它天然支持结构化数据（JSON/Protobuf），而且可以轻松集成认证、加密、限流。
举个例子，Prometheus的Exporter就是通过HTTP暴露指标数据：
# 一个简单的Prometheus Exporter输出示例
# HELP http_requests_total Total number of HTTP requests
# TYPE http_requests_total counter
http_requests_total{method="GET",code="200"} 1024
http_requests_total{method="POST",code="500"} 12
HTTP采集的缺点也很明显：性能开销比Syslog和SNMP大。如果你每秒要采集百万级指标点，HTTP可能不是最优解。
采集架构设计：分层解耦
数据源和协议都定了，接下来就是架构设计。我习惯用「三层架构」：采集层、传输层、存储层。
下面这张图，是我自己总结的采集架构核心逻辑。你看一眼就明白了。
为什么这么分层？说白了，就是「解耦」。采集层只管拿数据，传输层只管搬数据，存储层只管存数据。每一层都可以独立扩展、独立优化。
采集层：部署在数据源附近。比如在每台服务器上部署Filebeat采集日志，在Kubernetes集群里部署Prometheus Exporter采集指标。我建议采集层尽量「轻量化」，别给业务系统增加负担。
传输层：这是整个架构的「血管」。我强烈推荐用Kafka。为什么？因为它能扛住海量数据，还能做数据缓冲。我曾经在双11大促时，数据量暴增10倍，全靠Kafka的缓冲能力，存储层才没被打垮。
存储层：根据数据类型选择不同的存储。日志用Elasticsearch，指标用Prometheus，事件用ClickHouse。别想着一个数据库搞定所有——那是做梦。
我的经验：采集架构设计时，一定要考虑「数据生命周期」。日志保留7天？指标保留30天？告警永久保留？这些策略要在架构设计阶段就定好，不然后面改起来很痛苦。
避坑指南：我踩过的三个坑
- 采集端压力过大：我曾经在采集层用Python写了个日志采集脚本，结果日志量一上来，CPU直接100%。后来换成Go写的Filebeat，问题解决。记住：采集层要用高性能语言。
- 数据重复采集：同一个指标，多个采集点同时上报，导致存储层数据翻倍。解决方案：在采集层做幂等性设计，或者在传输层做去重。
- 网络带宽打满：日志量太大，把业务网络带宽吃光了。后来我单独拉了「带外管理网络」，采集数据走独立链路，业务网络才恢复正常。
好了，数据采集基础就聊到这儿。记住：数据是运维智能化的「石油」，采集就是「钻井」。井打不好，后面再好的炼油技术也白搭。