4. OCI日志高级配置
OCI Logging 的基础能力是采集平台日志，但生产环境真正需要的是“把业务自己产生的日志也纳入统一可观测体系”。这就涉及四个关键能力：自定义日志（Custom Log）、日志搜索语法、日志保存与归档策略，以及日志转发到 Object Storage 或 Streaming。它们分别解决“采什么”“怎么查”“存多久”“往哪送”的问题。
一、自定义日志：把应用日志接入 OCI Logging
OCI 自定义日志用于采集非平台原生的日志，典型来源包括：运行在 Compute 实例上的应用日志文件、容器标准输出、以及通过 API 写入的自定义日志。以 Compute 上的应用日志为例，配置路径是：Logging → Logs → Create Custom Log → 选择 Log Group → 选择资源类型为 Compute Instance → 指定日志源。
日志源有两种模式：文件路径采集和API 写入。文件路径采集需要指定绝对路径，例如 /var/log/myapp/app.log，并配置解析器（Parser）。解析器决定日志如何被结构化，常见类型有：
- 无解析（None）：整行作为 message，适合纯文本日志。
- Syslog：解析时间戳、主机、进程等字段。
- JSON：按 JSON 键拆分为字段，适合结构化应用日志。
- CSV / 正则：按分隔符或正则表达式提取字段。
如果应用输出 JSON，例如：
{"ts":"2025-03-11T08:12:33Z","level":"ERROR","svc":"order","msg":"payment timeout","orderId":"A10293"}选择 JSON 解析器后，level、svc、orderId 都会成为可搜索字段，后续就能用 level = 'ERROR' 精确过滤。这一步是自定义日志能否被高效检索的前提——解析器选错，字段就查不出来。
二、日志搜索语法：从“能查”到“查得准”
OCI Logging 的搜索基于查询语句，基本结构是“时间范围 + 过滤条件 + 关键字”。常用语法要点如下：
- 字段过滤：
data.level = 'ERROR'、data.svc = 'order'。 - 全文关键字：直接写
payment timeout，匹配 message 内容。 - 逻辑组合：
and、or、not，例如data.level = 'ERROR' and data.svc = 'order'。 - 模糊匹配：使用
*通配，例如data.orderId = 'A10*'。 - 时间范围：在控制台选择相对时间（最近 1 小时、24 小时）或自定义区间。
一个实用的排障查询示例：
search "payment timeout" | data.level = 'ERROR' and data.svc = 'order'它的含义是：在最近时间窗口内，查找 message 含 “payment timeout”、且 level 为 ERROR、服务为 order 的日志。搜索结果会按时间倒序展示，点击单条可展开完整字段。需要注意的是，搜索字段名取决于解析器输出的结构，JSON 解析后字段通常位于 data 下，因此写查询时不要漏掉前缀。
三、日志保存与归档策略
日志不能无限期保留在可搜索状态，否则存储成本会持续上升。OCI Logging 通过 Log Group 的保留策略控制日志在 Logging 中的保存时长，常见可选值为 1、7、14、30、60、90、180、365 天，或永久保留。超过保留期的日志会被自动删除。
因此生产上通常采用“热—温—冷”分层：
- 热数据：最近 7～30 天留在 Logging，供实时搜索与告警。
- 温/冷数据：通过 Service Connector 或日志转发，把日志持续写入 Object Storage，长期保存。
- 合规归档：Object Storage 可再配合生命周期规则，把对象从标准层转为归档层，进一步降低成本。
四、转发到 Object Storage 或 Streaming
OCI 提供两种主要转发方式，选择取决于下游用途：
| 目标 | 适用场景 | 特点 |
|---|---|---|
| Object Storage | 长期归档、离线分析、合规留存 | 低成本、批量写入、按对象存储 |
| Streaming | 实时消费、对接 SIEM、流式分析 | 低延迟、按分区消费、可多消费者 |
转发通常通过 Service Connector Hub 实现：源选择 Logging，目标选择 Object Storage 或 Streaming，中间可加过滤条件。例如只转发 ERROR 级别日志：
Source: Logging (Log Group = prod-app-logs)
Filter: data.level = 'ERROR'
Target: Object Storage (Bucket = prod-log-archive, Prefix = app/error/)
Batch: 5 MB 或 300 秒写入 Object Storage 时，日志会按时间分片成对象，路径类似 app/error/2025/03/11/08/xxx.json.gz。若目标是 Streaming，则日志进入指定 Stream 的分区，下游可用 Kafka 兼容接口或 OCI SDK 消费。
五、配置要点与常见问题
实际配置时，有几个容易踩坑的点值得注意。第一，IAM 权限：Service Connector 需要具备读取 Logging、写入 Object Storage 或 Streaming 的策略，否则连接器会创建成功但转发失败。第二，解析器与字段一致性：如果应用日志格式变更（例如从纯文本改为 JSON），必须同步更新解析器，否则新字段无法被搜索。第三，批量参数：Object Storage 目标通常按大小或时间触发写入，批量过小会产生大量小对象，批量过大则延迟升高，5 MB / 300 秒是常见起点。第四，成本：Logging 按摄取量计费，Object Storage 按存储和请求计费，Streaming 按吞吐计费，转发前应评估日志量，避免把调试日志全量长期保留。
综合来看，自定义日志解决采集入口，解析器决定字段结构，搜索语法决定排障效率，保留策略控制热数据窗口，Service Connector 负责把日志送往 Object Storage 或 Streaming。把这五者串起来，才能形成一条从产生到归档的完整日志链路。