目录第一部分 Logs第二部分 操作第三部分 AI 要点只建框架第一部分 Logs1. 一条日志本质上是什么一条日志 带时间戳的事件记录。最小形态时间 谁说的 严重程度 说了什么可观测性里还希望有服务名、实例、请求 ID、错误码、耗时这样才能检索、聚合、和 Trace 关联。日志回答的是「发生了什么」包括业务事件订单创建、库存不足错误与堆栈审计谁在何时改了什么你们有独立流cht_log_aws_audit调试开发期的细节生产要慎打必看文档编辑OTel LogsOpenObserve编辑Logs 概述编辑第一次搜日志编辑SQL 示例编辑SQL Reference先看match_all、str_match2. 三种形态最重要的原理之一非结构化纯文本2026-08-20 17:01:02 ERROR order failed timeout人能读机器很难稳定解析。全文搜索可以但按「服务 错误码」聚合很痛。半结构化time2026-08-20T17:01:02Z levelerror serviceorder msgtimeout traceabc有键值但格式各写各的字段名容易漂。结构化推荐JSON 等{ _timestamp: 2026-08-20T17:01:02Z, level: error, service: order, trace: 4bf9e929d0e0e4736, error: upstream timeout, http_code: 504 }每个键都是列。好处过滤准、聚合快、告警稳、和 Trace 对齐容易。JSON 同时满足几件事字段就是键。level、service、trace、purchase_ordersn不用靠正则从句子里抠。跨语言。 Java、Go、PHP、前端都能直接json.Marshal/json_encode。能嵌套。 采购单、SKU 列表、错误对象可以放在一个对象里不像纯文本只能摊成一长串。采集端好拆。 OpenObserve 看到 JSON就能把键变成cht_log_aws里的列于是能写SELECT * FROM cht_log_aws WHERE trace 4bf9e929d0e0e4736反面教材如cht_log_aws目前大约 192 个字段。同一类意思出现了多套名字例如error/err/errcode/error_msg/errormsg/errmessage/http_code/code。这就是长期半结构化、各服务各打各的结果schema 爆炸查询要写一堆OR索引也变贵。3. 级别level常见级别从低到高级别何时用生产建议TRACE / DEBUG开发细节默认关按需打开INFO关键业务里程碑克制不要每个循环打WARN可恢复异常、降级要能说明风险ERROR这次操作失败必须能定位FATAL进程要死极少原则级别表达「对运维的紧急程度」不要把 INFO 当 DEBUG 用。告警一般盯 ERROR但「ERROR 刷屏」也可能是下游抖动要结合数量和service不能一条 ERROR 就叫人。4. 日志数据模型OTEL 视角日志数据模型就是约定「一条日志长什么样」必须有哪些字段、每个字段什么含义。不是指磁盘怎么存而是双方怎么理解这一条记录。有了模型采集端、OpenObserve、查询 SQL 才说的是同一种东西。没有模型就只是一堆字。OTEL 里一条 Log Record 大致包括Timestamp事件时间注意采集时间 ≠ 事件时间ObservedTimestamp被采集到的时间Severity级别Body正文字符串或结构化体Attributes字段http.status_code等Resource谁在打service.name、主机TraceContexttrace_id、span_id有则能关联链路即使现在很多日志不是 OTLP 进来的模型仍应往这套靠时间、级别、资源、属性、trace 上下文。OpenObserve 里常见还会有_timestamp平台时间列。查询时间范围用的就是它。5. 采集路径应用 logger.info(...) / 写文件 / stdout│▼Agent / 采集器Fluent Bit、Vector、OTEL Collector、云 sidecar│ 解析、加字段、脱敏、丢弃 DEBUG▼管道 / 消息队列可选削峰│▼存储OpenObserve / Elasticsearch / Loki│▼查询 UI、告警、看板每一跳都可能丢数据或改字段。排障时要问日志是应用直接打 OTLP还是先写文件再采集解析规则会不会把 JSON 拆错你们流里有_badkey往往就是解析失败的痕迹时钟是否准容器时区、多机会导致同一请求时间对不齐6. 采样、脱敏、保留成本与合规量日志是三类里通常最贵的。1 亿 QPS 级别的 DEBUG 能把集群打满。手段生产默认 INFO成功请求抽样例如只留 1%错误全量丢弃健康检查、静态资源字段裁剪不要把整段请求体、Token、身份证打进日志脱敏密码、Cookie、证件号、手机号进日志是事故。应在采集器或应用侧打码而不是指望查询的人「注意别看」。保留越久越贵。你们cht_log_aws当前设置为 保留约 20 天单次查询窗口最大约 72 小时。所以查日志先收窄时间不要一上来查 30 天SELECT *审计日志cht_log_aws_audit往往要更长留存、更少字段和业务调试日志分开这就是「日志原理」里和存储绑定的部分不是记越多越好而是记对的、能查的、能留得起的。7. 索引与查询原理操作前要懂日志存储一般会按时间分片对少量列建索引你们service、appcode、trace、traceid全文检索match_all扫的是文本通常比「等值过滤索引列」更重所以查询要先定时间范围优先过滤索引字段service、trace再用match_all(timeout)或str_match(error, timeout)收窄不要无时间范围 全文搜一个很宽的词。第二部分 操作1. 结构化日志最低字段集新日志至少带字段说明时间ISO8601 或平台_timestamplevelinfo / warn / errorservice服务名稳定、短trace或trace_id与 Trace 同一值error或error_msg失败时必填一种名字用到底可选span_id、http_code、duration、appcode、env不要再发明errmessage第五个同义词。已有流字段乱新服务按这一套即可。2. 在 OpenObserve 里检索组织默认default业务日志流cht_log_aws。时间用微秒时间戳查询窗口尽量 ≤ 72h。按服务看最近错误SELECT _timestamp, service, appcode, trace, error, error_msg, http_code, content FROM cht_log_aws WHERE service 某个服务名 AND (level error OR error IS NOT NULL OR error_msg IS NOT NULL) ORDER BY _timestamp DESC全文SELECT _timestamp, service, trace, content FROM cht_log_aws WHERE match_all(timeout)聚合哪个服务错误最多SELECT service, COUNT(*) AS cnt FROM cht_log_aws WHERE error IS NOT NULL OR errcode IS NOT NULL GROUP BY service ORDER BY cnt DESC字段不统一时聚合会不准——这正是结构化没做好的代价。3. 用同一 ID 验证日志 ↔ 链路在test_oteltraces里取一条trace_id。在日志里查SELECT _timestamp, service, appcode, level, error, content, trace, traceid FROM cht_log_aws WHERE trace 这条 trace_id OR trace_id 这条 trace_id OR traceid 这条 trace_id审计流也可查SELECT * FROM cht_log_aws_audit WHERE trace trace_id三种结果都要记进实验两边都有关联成功记下服务名、时间是否接近。只有 Trace 没有日志日志没打关联字段或时间范围/流不对或日志采样丢掉了。只有日志没有 Trace没插桩、Trace 采样丢了或 ID 不是同一套。4. 错误日志告警最小可用最小规则例如条件某service在 5 分钟内levelerror条数 N通知值班人消噪排除健康检查N 按基线调避免一条 ERROR 就叫第三部分 AI 要点只建框架计划里有两条线目前只要分得清不要混主线含义例子AI for Observability用 AI 分析已有日志/链路/指标自然语言转 SQL、错误摘要、日志聚类Observability for AI观测 LLM/Agent 自己token、工具调用 span日志上的 AI 能力聚类 / Pattern把上万条相似 ERROR 收成几种模板NL → 查询你说「查订单超时」模型写出 SQL摘要把堆栈收成几句人话风险幻觉编造不存在的字段或结论。规范是先检索再生成结论必须能指回具体查询和原文。延伸组件定位ELKElasticsearch / Logstash / Kibana经典日志栈倒排检索强成本高Grafana Loki标签索引 日志内容成本往往更低标签基数要控制Fluent Bit / Vector采集与加工解析、脱敏、路由不是存储OpenObserve你们的统一平台日志 链路 指标一起查术语表术语含义Observability由外部遥测推断系统内部状态的能力Logs / Traces / Metrics三大支柱事件、请求链、数字趋势SignalOTEL 对三类遥测的统称OpenTelemetry (OTEL)厂商无关的采集与传输标准OTLPOTEL 的导出协议Collector接收、处理、转发遥测的独立进程Instrumentation插桩在运行路径上采集遥测SLI / SLO / SLA测量指标 / 内部目标 / 对外合同REDRate、Errors、DurationStructured log字段稳定的日志如 JSONSeverity / level日志级别Resource谁在发数据服务名、环境Attribute单条记录上的键值trace_id/trace跨日志与链路的请求 IDCardinality字段取值组合数过高会爆成本和 schemaRetention数据保留时长Sampling只保留一部分数据以控制成本Agent采集侧进程读文件、stdout 或自动插桩AI for Observability用 AI 分析遥测Observability for AI对 AI 应用做遥测日志实验记录怎么写采集说明数据从哪来、流名cht_log_aws、组织default、关联字段trace、保留约 20 天、查询窗口约 72h。典型查询 23 条例如按service过滤、match_all、按服务COUNT聚合贴 SQL 和结果摘要条数、时间范围。一次trace_id关联ID、Trace 是否存在、日志是否命中、时间/服务是否一致、若不命中则分析缺字段还是时间/采样问题。观察例如字段名不统一errorvserror_msg、192 列 schema、索引字段有哪些。总结日志看「发生了什么」链路看「请求怎么走」指标看「整体健不健康」。可观测性靠统一字段把三类数据连起来关键是trace_id你们日志里是trace。结构化日志的价值是可过滤、可聚合、可告警字段名混乱会变成上百列。采集是「应用 → Agent/Collector → 存储 → 查询」查询先锁时间再用索引字段。日志最贵要靠级别、采样、脱敏、保留控制AI 只能辅助结论必须能回溯到查询。
目录第一部分 Logs第二部分 操作第三部分 AI 要点只建框架第一部分 Logs1. 一条日志本质上是什么一条日志 带时间戳的事件记录。最小形态时间 谁说的 严重程度 说了什么可观测性里还希望有服务名、实例、请求 ID、错误码、耗时这样才能检索、聚合、和 Trace 关联。日志回答的是「发生了什么」包括业务事件订单创建、库存不足错误与堆栈审计谁在何时改了什么你们有独立流cht_log_aws_audit调试开发期的细节生产要慎打必看文档编辑OTel LogsOpenObserve编辑Logs 概述编辑第一次搜日志编辑SQL 示例编辑SQL Reference先看match_all、str_match2. 三种形态最重要的原理之一非结构化纯文本2026-08-20 17:01:02 ERROR order failed timeout人能读机器很难稳定解析。全文搜索可以但按「服务 错误码」聚合很痛。半结构化time2026-08-20T17:01:02Z levelerror serviceorder msgtimeout traceabc有键值但格式各写各的字段名容易漂。结构化推荐JSON 等{ _timestamp: 2026-08-20T17:01:02Z, level: error, service: order, trace: 4bf9e929d0e0e4736, error: upstream timeout, http_code: 504 }每个键都是列。好处过滤准、聚合快、告警稳、和 Trace 对齐容易。JSON 同时满足几件事字段就是键。level、service、trace、purchase_ordersn不用靠正则从句子里抠。跨语言。 Java、Go、PHP、前端都能直接json.Marshal/json_encode。能嵌套。 采购单、SKU 列表、错误对象可以放在一个对象里不像纯文本只能摊成一长串。采集端好拆。 OpenObserve 看到 JSON就能把键变成cht_log_aws里的列于是能写SELECT * FROM cht_log_aws WHERE trace 4bf9e929d0e0e4736反面教材如cht_log_aws目前大约 192 个字段。同一类意思出现了多套名字例如error/err/errcode/error_msg/errormsg/errmessage/http_code/code。这就是长期半结构化、各服务各打各的结果schema 爆炸查询要写一堆OR索引也变贵。3. 级别level常见级别从低到高级别何时用生产建议TRACE / DEBUG开发细节默认关按需打开INFO关键业务里程碑克制不要每个循环打WARN可恢复异常、降级要能说明风险ERROR这次操作失败必须能定位FATAL进程要死极少原则级别表达「对运维的紧急程度」不要把 INFO 当 DEBUG 用。告警一般盯 ERROR但「ERROR 刷屏」也可能是下游抖动要结合数量和service不能一条 ERROR 就叫人。4. 日志数据模型OTEL 视角日志数据模型就是约定「一条日志长什么样」必须有哪些字段、每个字段什么含义。不是指磁盘怎么存而是双方怎么理解这一条记录。有了模型采集端、OpenObserve、查询 SQL 才说的是同一种东西。没有模型就只是一堆字。OTEL 里一条 Log Record 大致包括Timestamp事件时间注意采集时间 ≠ 事件时间ObservedTimestamp被采集到的时间Severity级别Body正文字符串或结构化体Attributes字段http.status_code等Resource谁在打service.name、主机TraceContexttrace_id、span_id有则能关联链路即使现在很多日志不是 OTLP 进来的模型仍应往这套靠时间、级别、资源、属性、trace 上下文。OpenObserve 里常见还会有_timestamp平台时间列。查询时间范围用的就是它。5. 采集路径应用 logger.info(...) / 写文件 / stdout│▼Agent / 采集器Fluent Bit、Vector、OTEL Collector、云 sidecar│ 解析、加字段、脱敏、丢弃 DEBUG▼管道 / 消息队列可选削峰│▼存储OpenObserve / Elasticsearch / Loki│▼查询 UI、告警、看板每一跳都可能丢数据或改字段。排障时要问日志是应用直接打 OTLP还是先写文件再采集解析规则会不会把 JSON 拆错你们流里有_badkey往往就是解析失败的痕迹时钟是否准容器时区、多机会导致同一请求时间对不齐6. 采样、脱敏、保留成本与合规量日志是三类里通常最贵的。1 亿 QPS 级别的 DEBUG 能把集群打满。手段生产默认 INFO成功请求抽样例如只留 1%错误全量丢弃健康检查、静态资源字段裁剪不要把整段请求体、Token、身份证打进日志脱敏密码、Cookie、证件号、手机号进日志是事故。应在采集器或应用侧打码而不是指望查询的人「注意别看」。保留越久越贵。你们cht_log_aws当前设置为 保留约 20 天单次查询窗口最大约 72 小时。所以查日志先收窄时间不要一上来查 30 天SELECT *审计日志cht_log_aws_audit往往要更长留存、更少字段和业务调试日志分开这就是「日志原理」里和存储绑定的部分不是记越多越好而是记对的、能查的、能留得起的。7. 索引与查询原理操作前要懂日志存储一般会按时间分片对少量列建索引你们service、appcode、trace、traceid全文检索match_all扫的是文本通常比「等值过滤索引列」更重所以查询要先定时间范围优先过滤索引字段service、trace再用match_all(timeout)或str_match(error, timeout)收窄不要无时间范围 全文搜一个很宽的词。第二部分 操作1. 结构化日志最低字段集新日志至少带字段说明时间ISO8601 或平台_timestamplevelinfo / warn / errorservice服务名稳定、短trace或trace_id与 Trace 同一值error或error_msg失败时必填一种名字用到底可选span_id、http_code、duration、appcode、env不要再发明errmessage第五个同义词。已有流字段乱新服务按这一套即可。2. 在 OpenObserve 里检索组织默认default业务日志流cht_log_aws。时间用微秒时间戳查询窗口尽量 ≤ 72h。按服务看最近错误SELECT _timestamp, service, appcode, trace, error, error_msg, http_code, content FROM cht_log_aws WHERE service 某个服务名 AND (level error OR error IS NOT NULL OR error_msg IS NOT NULL) ORDER BY _timestamp DESC全文SELECT _timestamp, service, trace, content FROM cht_log_aws WHERE match_all(timeout)聚合哪个服务错误最多SELECT service, COUNT(*) AS cnt FROM cht_log_aws WHERE error IS NOT NULL OR errcode IS NOT NULL GROUP BY service ORDER BY cnt DESC字段不统一时聚合会不准——这正是结构化没做好的代价。3. 用同一 ID 验证日志 ↔ 链路在test_oteltraces里取一条trace_id。在日志里查SELECT _timestamp, service, appcode, level, error, content, trace, traceid FROM cht_log_aws WHERE trace 这条 trace_id OR trace_id 这条 trace_id OR traceid 这条 trace_id审计流也可查SELECT * FROM cht_log_aws_audit WHERE trace trace_id三种结果都要记进实验两边都有关联成功记下服务名、时间是否接近。只有 Trace 没有日志日志没打关联字段或时间范围/流不对或日志采样丢掉了。只有日志没有 Trace没插桩、Trace 采样丢了或 ID 不是同一套。4. 错误日志告警最小可用最小规则例如条件某service在 5 分钟内levelerror条数 N通知值班人消噪排除健康检查N 按基线调避免一条 ERROR 就叫第三部分 AI 要点只建框架计划里有两条线目前只要分得清不要混主线含义例子AI for Observability用 AI 分析已有日志/链路/指标自然语言转 SQL、错误摘要、日志聚类Observability for AI观测 LLM/Agent 自己token、工具调用 span日志上的 AI 能力聚类 / Pattern把上万条相似 ERROR 收成几种模板NL → 查询你说「查订单超时」模型写出 SQL摘要把堆栈收成几句人话风险幻觉编造不存在的字段或结论。规范是先检索再生成结论必须能指回具体查询和原文。延伸组件定位ELKElasticsearch / Logstash / Kibana经典日志栈倒排检索强成本高Grafana Loki标签索引 日志内容成本往往更低标签基数要控制Fluent Bit / Vector采集与加工解析、脱敏、路由不是存储OpenObserve你们的统一平台日志 链路 指标一起查术语表术语含义Observability由外部遥测推断系统内部状态的能力Logs / Traces / Metrics三大支柱事件、请求链、数字趋势SignalOTEL 对三类遥测的统称OpenTelemetry (OTEL)厂商无关的采集与传输标准OTLPOTEL 的导出协议Collector接收、处理、转发遥测的独立进程Instrumentation插桩在运行路径上采集遥测SLI / SLO / SLA测量指标 / 内部目标 / 对外合同REDRate、Errors、DurationStructured log字段稳定的日志如 JSONSeverity / level日志级别Resource谁在发数据服务名、环境Attribute单条记录上的键值trace_id/trace跨日志与链路的请求 IDCardinality字段取值组合数过高会爆成本和 schemaRetention数据保留时长Sampling只保留一部分数据以控制成本Agent采集侧进程读文件、stdout 或自动插桩AI for Observability用 AI 分析遥测Observability for AI对 AI 应用做遥测日志实验记录怎么写采集说明数据从哪来、流名cht_log_aws、组织default、关联字段trace、保留约 20 天、查询窗口约 72h。典型查询 23 条例如按service过滤、match_all、按服务COUNT聚合贴 SQL 和结果摘要条数、时间范围。一次trace_id关联ID、Trace 是否存在、日志是否命中、时间/服务是否一致、若不命中则分析缺字段还是时间/采样问题。观察例如字段名不统一errorvserror_msg、192 列 schema、索引字段有哪些。总结日志看「发生了什么」链路看「请求怎么走」指标看「整体健不健康」。可观测性靠统一字段把三类数据连起来关键是trace_id你们日志里是trace。结构化日志的价值是可过滤、可聚合、可告警字段名混乱会变成上百列。采集是「应用 → Agent/Collector → 存储 → 查询」查询先锁时间再用索引字段。日志最贵要靠级别、采样、脱敏、保留控制AI 只能辅助结论必须能回溯到查询。
