ARTICLE DETAIL

资讯详情

深耕编程入门与网站建设的一线实战洞察。

Fleet 日志输出目的地配置实战:使用 AWS Kinesis 与 Firehose 对接 Sumo Logic 和 Splunk

Fleet 日志输出目的地配置实战:使用 AWS Kinesis 与 Firehose 对接 Sumo Logic 和 Splunk Fleet 日志输出目的地配置实战使用 AWS Kinesis 与 Firehose 对接 Sumo Logic 和 Splunk【免费下载链接】fleetOpen device management项目地址: https://gitcode.com/GitHub_Trending/fl/fleet在设备规模扩大后把 osquery 状态日志、查询结果日志以及 Fleet 审计日志高效地流出服务器是日志管理与安全分析的关键环节。本指南基于 Fleet 官方文档《How to configure logging destinations》完整讲解如何选择并搭建 AWS Kinesis Data Streams / Kinesis Data Firehose 基础设施配置 IAM 角色与 ExternalId最终把 Fleet 日志流式送达 Sumo Logic、Splunk 等目的地并结合本仓库源码server/logging/kinesis.go、server/logging/firehose.go剖析底层实现原理与限制帮助读者在云端或自托管场景下安全、可靠地落地日志管道。Fleet 支持发送的日志类型在配置目的地之前先明确 Fleet 可以通过 Automation/日志插件发送三类日志详见 articles/log-destinations.mdosquery 状态日志Status logsosquery 进程自身的运行状态、错误与告警信息osquery 结果日志Results logs定时查询schedule与实时查询live query产生的结果数据Fleet 审计日志Audit logsFleet 实例上的管理操作记录用于合规与溯源。默认情况下这三类日志写入每台主机本地文件系统对应filesystem插件。要改为外部日志目的地需要在 Fleet 服务端配置中指定日志插件。注意目前只有自托管用户可以修改这部分配置托管云managed-cloud客户如需调整需联系 Fleet 团队。第一步选择目的地机制Kinesis Data Streams 还是 Data FirehoseAWS 提供两种主流的流式数据传输服务两者的取舍直接决定了日志管道的架构Kinesis Data Streams面向实时低延迟处理适合需要实时处理、对延迟敏感的场景持续捕获来自数十万数据源如网站点击流、数据库事件流、金融交易、社交媒体信息流的数据吞吐可达每秒数 GB且可在毫秒级内被消费与实时分析数据由消费者Consumer主动拉取pull适合需要自行编写流处理逻辑如对接 AWS Lambda、Flink 等的团队。Kinesis Data Firehose面向数据湖与分析服务的托管管道完全托管的服务简化将流数据加载到数据湖、数据存储与分析服务的流程支持捕获、转换transform并加载数据到Amazon S3、Amazon Redshift、Amazon Elasticsearch Service等 AWS 服务以及Splunk、Sumo Logic等第三方服务数据由服务自动推送到目的地push无需维护消费者是低运维、快速对接 SIEM / 数据湖的首选。从架构上看Fleet 到 Firehose 再到下游数据的流向如下原文档流程图值得注意Firehose 在日志无法投递到最终目的地时可以按配置把失败事件备份到 S3S3 backup这正是原文档图中 AWS S3 回退路径的用途。此外Firehose 也很适合与 Snowflake 的 Snowpipe 集成把日志灌入 Snowflake 数仓参见 articles/log-destinations.md。第二步搭建所需基础设施IAM 角色与流资源在开始流式传输前必须先准备好基础设施。这些资源可能由组织内的其他团队或小组如基础设施/安全组持有需要跨团队协调。核心是以下三项Fleet 服务的 IAM Role ARN信任方Fleet 服务自身所使用的 IAM 角色的 ARN。该角色将扮演本模块中定义的 IAM 角色以获取向 Kinesis Data Stream(s) 写入数据所需的权限。例如这个角色可被用于允许 Fleet 向你的 Kinesis 流写入数据。被扮演的 IAM Role ARN受托方Fleet 服务将扮演的角色 ARN用于授予其必要权限。这通常用于委托访问控制使 Fleet 服务代表你执行操作即 STS AssumeRole。ExternalId可选但推荐为 IAM 角色添加额外的信任约束确保只有可信实体才能扮演该角色防止混淆代理confused deputy攻击。更多细节可参考 AWS IAM 用户指南。云端客户Cloud Customers清单对于使用 Fleet 托管云服务的客户协调流程如下选择目的地机制Kinesis / Firehose搭建所需基础设施必需项Fleet 服务的 IAM Role ARN回传给 Fleet 基础设施/CSx 小组Fleet 服务将扮演的 IAM Role ARN可选的 ExternalId目的地配置细节Kinesis / Firehose流名称Stream name(s)区域Region从源码看 IAM 与 STS 的实现Fleet 的 Kinesis 与 Firehose 日志写入器都支持三种凭证来源对应 server/logging/kinesis.go 与 server/logging/firehose.go静态凭证仅当同时提供AccessKeyID与SecretAccessKey时才启用通过 AWS SDK 的静态凭证 Provider 注入默认凭证链当静态凭证未提供时回退到 AWS SDK 的默认凭证提供者链环境变量、实例配置文件、ECS 容器凭证等STS AssumeRole当设置了sts_assume_role_arn时通过 server/aws_common/aws_common.go 中的ConfigureAssumeRoleProvider构造 AssumeRole 凭证提供者并可选注入ExternalID。从代码结构可以推断配置优先级为静态凭证 默认凭证链而一旦设置sts_assume_role_arn则会覆盖此前任何凭证提供者源码注释明确说明 Overrides any previous aws_config.WithCredentialsProvider set in opts。这与配置文档中设置后 Fleet 改用 IAM 认证替代基本认证的描述一致。第三步配置 Fleet 的日志目的地通用配置方式Fleet 服务端的日志插件配置有三种等价方式命令行 flag、环境变量、YAML 配置文件。以 Firehose 为例配置解析定义在 server/config/config.goKinesis 结构体紧随其后其 YAML 键与 flag/环境变量的对应关系如下配置项环境变量Firehose环境变量Kinesis说明regionFLEET_FIREHOSE_REGIONFLEET_KINESIS_REGIONAWS 区域endpoint_urlFLEET_FIREHOSE_ENDPOINT_URLFLEET_KINESIS_ENDPOINT_URL服务端点已弃用兼容保留access_key_idFLEET_FIREHOSE_ACCESS_KEY_IDFLEET_KINESIS_ACCESS_KEY_IDAWS 访问密钥 IDsecret_access_keyFLEET_FIREHOSE_SECRET_ACCESS_KEYFLEET_KINESIS_SECRET_ACCESS_KEYAWS 秘密访问密钥sts_assume_role_arnFLEET_FIREHOSE_STS_ASSUME_ROLE_ARNFLEET_KINESIS_STS_ASSUME_ROLE_ARN要扮演的 STS 角色 ARNsts_external_idFLEET_FIREHOSE_STS_EXTERNAL_IDFLEET_KINESIS_STS_EXTERNAL_ID外部 ID第三方托管时使用status_streamFLEET_FIREHOSE_STATUS_STREAMFLEET_KINESIS_STATUS_STREAM状态日志流result_streamFLEET_FIREHOSE_RESULT_STREAMFLEET_KINESIS_RESULT_STREAM结果日志流audit_streamFLEET_FIREHOSE_AUDIT_STREAMFLEET_KINESIS_AUDIT_STREAM审计日志流各日志类型的插件开关对应 docs/Configuration/fleet-server-configuration.md 中的说明osquery_status_log_plugin→ 控制状态日志osquery_result_log_plugin→ 控制结果日志activity_audit_log_plugin配合activity_enable_audit_log: true→ 控制审计日志。支持的插件值包括filesystem、firehose、kinesis、lambda、pubsub、kafkarest、nats、splunk、stdout。插件注册与分发逻辑集中在 server/logging/logging.go 的NewJSONLogger中当插件名无法识别时会直接返回错误。配置 Kinesis Data Streams插件名kinesisosquery: status_log_plugin: kinesis result_log_plugin: kinesis activity: enable_audit_log: true audit_log_plugin: kinesis kinesis: region: ca-central-1 sts_assume_role_arn: arn:aws:iam::1234567890:role/kinesis-role sts_external_id: your_unique_id status_stream: osquery_status result_stream: osquery_result audit_stream: fleet_audit要点与 docs/Configuration/fleet-server-configuration.md 一致若省略access_key_id/secret_access_keyFleet 会尝试使用 AWS STS 临时凭证默认凭证链写入 Kinesis 流所需的 IAM 权限为kinesis:DescribeStream与kinesis:PutRecords启动时 Fleet 会调用DescribeStream验证流存在且状态为Active否则启动失败见 server/logging/kinesis.go。配置 Kinesis Data Firehose插件名firehoseosquery: status_log_plugin: firehose result_log_plugin: firehose activity: enable_audit_log: true audit_log_plugin: firehose firehose: region: ca-central-1 sts_assume_role_arn: arn:aws:iam::1234567890:role/firehose-role sts_external_id: your_unique_id status_stream: osquery_status result_stream: osquery_result audit_stream: fleet_audit要点与 docs/Configuration/fleet-server-configuration.md 一致写入 Firehose 流所需的 IAM 权限为firehose:DescribeDeliveryStream与firehose:PutRecordBatch启动时 Fleet 会调用DescribeDeliveryStream验证投递流状态为Active见 server/logging/firehose.go。第四步把日志送达 Sumo Logic 与 Splunk对接 Sumo LogicSumo Logic 通过 HTTP 接收日志数据是日志管理与分析的可靠选择。将 Sumo Logic 配置为 Firehose 目的地的步骤创建 Sumo Logic 托管收集器/接收器hosted collector/receiver让 Sumo Logic 能够从流中拉取数据配置 Firehose按照 AWS 文档Firehose 创建目的地 → Sumo Logic配置把投递流指向 Sumo Logic 的 HTTP 端点配置 Sumo Logic参考 Sumo Logic 官方文档AWS Kinesis Firehose Logs Source完成源source创建与字段映射。完成上述配置后Fleet 只需把osquery/activity的日志插件指向该 Firehose 投递流即上文的firehose配置日志就会自动流经 Firehose 进入 Sumo Logic。对接 SplunkSplunk 提供两种接入路径方式一Fleet 直连 Splunk HEC插件名splunkSplunk 通过HTTP Event CollectorHEC端点直接接收 Fleet 日志。配置示例见 articles/log-destinations.mdosquery: status_log_plugin: splunk result_log_plugin: splunk splunk: url: https://splunk.example.com:8088 token: your-hec-token index: main source: fleet source_type: fleet:json前置条件与行为均可在源码与文档中验证在 Splunk 实例上启用 HEC 并创建 HEC token事件按批次发送单批上限 1MB超过 1MB 的事件会被丢弃并在 Fleet 服务器日志中输出通知Fleet 会对瞬时错误HTTP 503以指数退避进行重试从 server/logging/logging.go 的校验逻辑可见splunk.url与splunk.token均为必填项缺失时插件创建直接报错。方式二Splunk via Firehose间接路径也可以让日志先进入 Kinesis Data Firehose再由 Firehose 转发给 Splunk按照 Splunk 的 Firehose 集成文档准备 Splunk 侧配置按照 AWS 文档配置 Firehose 直接转发到 Splunkdestination splunk在 Terraform 配置中将默认的 S3 目的地替换为 Splunk 目的地示例摘自 articles/log-destinations.mdresource aws_kinesis_firehose_delivery_stream test_stream { name terraform-kinesis-firehose-test-stream destination splunk splunk_configuration { hec_endpoint https://http-inputs-mydomain.splunkcloud.com:443 hec_token 51D4DA16-C61B-4F5F-8EC7-ED4301342A4A hec_acknowledgment_timeout 600 hec_endpoint_type Event s3_backup_mode FailedEventsOnly s3_configuration { role_arn aws_iam_role.firehose.arn bucket_arn aws_s3_bucket.bucket.arn buffering_size 10 buffering_interval 400 compression_format GZIP } } }这里s3_backup_mode FailedEventsOnly与s3_configuration共同构成失败事件回退到 S3 的备份机制与原文档流程图中的 S3 回退路径对应。底层实现Fleet 如何写入 Kinesis / Firehose深入 server/logging/kinesis.go 与 server/logging/firehose.go可以看到两个写入器在实现上高度对称它们都遵循以下策略批处理与分片均衡NDJSON 输出每条日志后追加\n换行保证下游按行解析Kinesis 与 Firehose 都不会自动为每条记录换行Kinesis 随机分区键为每条记录生成 0-255 的随机分区键rand.Intn(256)将日志均匀分布到各 shard避免热点分片Firehose 顺序写入无分区键概念直接按序追加到PutRecordBatch。大小限制与丢弃策略两个写入器在源码中定义了与 AWS 官方限制对齐的常量见 server/logging/kinesis.go 与 server/logging/firehose.go常量KinesisFirehose单条记录上限1,000 KB1,000 KB单批记录数上限500500单批总大小上限5 MB4 MB当单条日志超过 1MB 上限时Fleet 会将其直接丢弃并在服务器日志中输出通知包含日志前 100 字节用于诊断而不会发送到流中。该行为与 osquery 官方 Kinesis/Firehose 日志插件的处理方式保持一致。达到批次上限500 条或字节数上限时会先冲刷当前批次再继续。重试与退避两个写入器对 AWS API 错误都采用指数退避重试最大重试 8 次退避公式为100ms * 2^try第 1 次约 200ms第 8 次约 25.6 秒Kinesis 对 API 层错误实现smithy.APIError重试Firehose 仅对ServiceUnavailableException重试对PutRecords/PutRecordBatch返回的部分失败FailedRecordCount/FailedPutCount 0会收集失败记录仅对失败子集再次重试重试耗尽后返回包含失败记录数与首个错误信息的错误供运维排查。启动自检两个写入器在构造时都会先执行一次校验KinesisDescribeStream、FirehoseDescribeDeliveryStream确认目标流存在且状态为Active否则直接报错避免配置了错误的流名却在运行期才暴露的问题。这就是为什么文档要求 IAM 角色必须同时具备Describe与写入PutRecords/PutRecordBatch两类权限。本地验证用 LocalStack 测试 Kinesis 日志插件仓库为开发者提供了完整的本地联调方案docs/Contributing/getting-started/testing-and-local-development.md用 LocalStack 在本地模拟 AWS 服务Kinesis/Firehose 均被启用无需真实 AWS 账号即可验证配置。# 1. 启动 LocalStack启用 kinesis # 2. 创建 Kinesis 流 awslocal kinesis create-stream --stream-name sample_status --shard-count 1 awslocal kinesis create-stream --stream-name sample_result --shard-count 1 awslocal kinesis list-streams # 3. 启动 Fleet server指向 LocalStack make fleet \ FLEET_OSQUERY_RESULT_LOG_PLUGINkinesis \ FLEET_OSQUERY_STATUS_LOG_PLUGINkinesis \ FLEET_KINESIS_REGIONus-east-1 \ FLEET_KINESIS_ENDPOINT_URLhttp://localhost:4566 \ FLEET_KINESIS_ACCESS_KEY_IDdefault \ FLEET_KINESIS_SECRET_ACCESS_KEYdefault \ FLEET_KINESIS_STATUS_STREAMsample_status \ FLEET_KINESIS_RESULT_STREAMsample_result \ ./build/fleet serve --dev --dev_license --logging_debug # 4. 读取验证 awslocal kinesis list-shards --stream-name sample_status awslocal kinesis get-shard-iterator --shard-id shardId-000000000000 \ --shard-iterator-type TRIM_HORIZON --stream-name sample_status awslocal kinesis get-records --shard-iterator iteratorFirehose 的本地验证方式类似先通过awslocal firehose create-delivery-stream配合 JSON skeleton 文件指向 S3 桶s3-firehose创建投递流再把FLEET_OSQUERY_*_LOG_PLUGINfirehose指向对应流名之后访问http://localhost:4566/s3-firehose即可在浏览器中查看落到 S3 的结果/状态日志。这一验证路径也印证了Kinesis 与 Firehose 日志插件所需的配置项region、endpoint_url、凭证、流名在运行时是逐一生效的。常见问题与限制日志过大被丢弃单条日志超过 1MBKinesis/Firehose 上限时不会送达目的地仅在 Fleet 服务器日志中留下提示。排查超大结果日志时可结合该提示中的前 100 字节定位产生超大数据的查询。Splunk 直连的 1MB 批上限超过 1MB 的事件被丢弃并在服务器日志中通知瞬时错误503会自动指数退避重试。本地文件系统仍可用若只想快速验证或暂不接外部管道默认的filesystem插件会写在 Fleet 服务器本地文件系统常配合服务器上的日志转发 agent 推送进日志管道articles/log-destinations.md。多服务器负载均衡使用stdout或filesystem插件且部署了多台负载均衡 Fleet 服务器时日志会按负载均衡分发不会重复请确保转发 agent 覆盖所有服务器。托管云客户日志目的地配置仅限自托管用户修改托管云客户需要联系 Fleet 团队协助调整。结语通过谨慎搭建 IAM 角色并正确配置数据流你可以借助 AWS Kinesis Data Firehose 将 Fleet 的 osquery 状态日志、结果日志与审计日志高效流式送达 Sumo Logic、Splunk 等平台也可以在此基础上继续扩展到 S3 数据湖、Snowflake 数仓或其他 SIEM 工具。Fleet 的日志插件在源码层面对批量写入、大小限制、重试退避与流状态自检都做了工程化处理server/logging/kinesis.go、server/logging/firehose.go、server/logging/logging.go理解这些实现细节有助于你在生产环境中做出正确的架构取舍与排障决策。更完整的目的地清单Lambda、Pub/Sub、Kafka、Webhook 等可继续阅读 articles/log-destinations.md 与 docs/Configuration/fleet-server-configuration.md。【免费下载链接】fleetOpen device management项目地址: https://gitcode.com/GitHub_Trending/fl/fleet创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表