‧
阅读时间：4分钟
设置一个用于日志分析的基本管道
Metabase 团队
‧ 阅读时间：4分钟
分享这篇文章
选择用于清理、解析和组织日志数据的工具可能令人望而生畏（且价格昂贵）。但是，当您刚开始时，可以使用一个简单的设置，通过 Metabase 这样的 BI 工具进行即席分析。以下是设置用于分析日志的基本管道的一些最佳实践。
使用数据连接器工具作为摄取数据的快捷方式
像 Airbyte 这样的工具可以快速连接到您的数据库并为您组织日志。选择您的日志源，例如 AWS CloudTrail，并将其连接到数据库，例如 Snowflake（一种相对简单、可扩展、成本合理的解决方案），或 AWS Aurora Serverless Postgres（一种简单、有些可扩展、低成本的解决方案）。
其他 ETL 工具，如 Fivetran 或 Stitch，工作原理类似。它们使用连接器将日志数据从源（如 CloudTrail）移动到您的数据库。您还可以 同时使用 ETL 工具并执行数据建模，为您完成一些繁重的工作。
使用单一云服务提供商来集中管理
Google Cloud Logging 可以连接到 BigQuery，以便您可以将日志自动摄取到数据仓库中。AWS 有多种日志选项，如 CloudTrail 或 CloudWatch，您可以将它们连接到他们的数据库选项之一，如 用于 RDS 的 Postgres。Azure Monitor 也具有日志记录和存储功能。
高级用例：将来自多个 AWS 服务的日志转储到 S3 存储桶并通过 Athena 查询
如果您对 AWS 等云服务有一定的经验，您可以使用一整套云服务将来自不同服务的日志推送到一个集中位置，为分析做准备。
例如，将来自 EC2 实例的 Web 服务器或应用程序日志以及 CloudTrail 日志推送到 S3 存储桶中。将您的 S3 存储桶连接到 Athena 等查询工具，以便您可以创建一些表用于分析。一旦有了表，您可以连接到您的分析工具并创建故障排除仪表盘，例如一个将 EC2 事件映射到 CloudTrail 事件以进行根本原因分析的仪表盘。
以下是一些您可以与 S3 和 Athena 结合使用的其他 AWS 日志选项
- CloudWatch：存储应用程序、系统或自定义日志
- RDS：存储错误、慢查询或事务日志
- Lambda：存储包含执行详细信息、错误消息和自定义日志语句的 Lambda 日志
- 弹性负载均衡器（ELB）：存储包含客户端 IP 地址、请求时间、响应状态代码的 ELB 日志
如果您想更进一步，可以将 Athena 连接到 dbt，并学习如何在 SQL 中编写自己的数据转换。dbt 简化了版本控制、部署和测试，而无需运行单独的工具。但是，我们只建议您在熟悉数据建模和开发者工具的情况下使用此设置。
批量加载日志以提高效率
您应该将日志直接批量加载到数据仓库或 S3 等存储选项中，以避免延迟和资源消耗。大多数云服务都提供批量服务，您可以在其中安排和排队作业。请注意，如果您为数据库或日志存储付费，请先仔细检查批量加载的价格，因为某些云服务按批量上传收费。
使用数据库客户端库或连接器进行摄取
无法访问连接器工具不是问题，但这可能需要更多的开发工作。使用现有的数据库客户端库或驱动程序可以帮助您在日志记录时直接将日志摄取到存储/数据仓库中。
例如，Postgres 有驱动程序，而 MySQL 有连接器。使用其中之一来连接到您的数据库，而无需重新发明轮子。
确保您的日志包含时间戳、来源、消息和日志级别
我们建议在日志文件中添加以下四个区域，以使日志分析更顺畅
- 时间戳：这将更容易建立事件序列。如果您使用分析工具创建用于性能监控或审计和合规性的仪表盘，时间戳尤其重要。
- 来源：例如创建日志的服务，还包括日志来自的地点/文件/子服务。您可以使用服务字段进行故障排除，或者只是为了衡量分配给每个服务的资源。
- 日志消息：保持消息清晰简洁，以便您能够理解每个事件。重复使用关键词，以便在文本分析期间更容易过滤和查找您需要的内容。
- 日志级别：您可以根据
ALERT和CRITICAL等级别进行过滤，以找出哪些日志需要立即调查和响应。
日志分析的其他最佳实践和想法
如果您旨在进行实时日志分析，或高级或频繁的日志分析，日志专用工具往往更适合。如果您的团队已经在使用 ELK 堆栈，那么像 Grafana 这样的工具可能很合适。
以下是一些可用于在构建小型日志管道时做出决策的额外资源
