Metrics 作为 Ontology：统一业务指标与运营监控
传统方式：Metrics 和业务数据是两个世界
Coomia发布于 2025年8月14日18 分钟阅读
分享本文Twitter / X
Metrics 作为 Ontology：统一业务指标与运营监控
“系列：S4 本体建模 · 第 10 篇 | 难度：中级 | 阅读时间：18 分钟
#TL;DR
- Metrics 不再是独立系统——coomia-dip 将监控指标（CPU、延迟、错误率）和业务 KPI（收入、转化率、客户满意度）统一纳入 Ontology 模型，成为 ObjectType 的一等公民属性。
- MetricSource 定义了指标的采集、聚合和存储规则——每个指标声明数据来源（Prometheus、业务数据库、事件流）、聚合方式（SUM/AVG/P99）、时间粒度（秒/分/时/天），系统自动完成采集和物化。
- 统一查询接口让用户可以在同一个 API 中同时查询"这个服务的 P99 延迟是多少"和"这个客户的月度消费是多少"，打通技术监控和业务分析的数据孤岛。
#1. 为什么要把 Metrics 纳入 Ontology
#1.1 传统架构的数据孤岛
Code
传统方式：Metrics 和业务数据是两个世界
世界 1：技术监控
Prometheus → Grafana
├── CPU 使用率
├── 内存占用
├── 请求延迟 P99
├── 错误率
└── 存储在时序数据库（独立的数据模型）
世界 2：业务分析
MySQL/PostgreSQL → BI Dashboard
├── 日活用户
├── 订单转化率
├── 客户生命周期价值
├── 收入增长率
└── 存储在关系数据库（另一个数据模型）
问题：
├── "订单系统延迟升高时，转化率下降了多少？"
│ → 需要在两个系统之间手动关联
├── "哪些客户受到了昨天系统故障的影响？"
│ → 需要跨系统查询并手动匹配
├── "服务的错误率和对应业务的退款率有没有相关性？"
│ → 需要导出数据到 Excel 手动分析
└── 每次分析都是一次"数据考古"
#1.2 coomia-dip 的统一模型
Code
coomia-dip 方式：Metrics 是 ObjectType 的属性
ObjectType: OrderService
普通属性：
serviceId: STRING
serviceName: STRING
version: STRING
Metric 属性：
cpuUsage: METRIC(gauge, source=prometheus)
requestLatencyP99: METRIC(histogram, source=prometheus)
errorRate: METRIC(gauge, source=prometheus)
orderCount: METRIC(counter, source=business_db)
conversionRate: METRIC(gauge, source=computed)
revenue: METRIC(counter, source=business_db)
统一查询：
GET /api/v1/objects/OrderService/svc-001
{
"serviceId": "svc-001",
"serviceName": "order-service",
"cpuUsage": 67.3,
"requestLatencyP99": 245,
"errorRate": 0.02,
"orderCount": 15234,
"conversionRate": 0.034,
"revenue": 1523400.00
}
技术监控和业务数据在同一个对象上！
无需跨系统查询，直接关联分析。
#2. MetricSource：指标的定义与采集
#2.1 MetricSource 模型
Code
MetricSource 定义：
┌─────────────────────────────────────────────────────┐
│ MetricSource │
├─────────────────────────────────────────────────────┤
│ metricId: STRING # 指标唯一标识 │
│ name: STRING # 人类可读名称 │
│ description: STRING # 描述 │
│ metricType: ENUM # COUNTER / GAUGE / │
│ # HISTOGRAM / SUMMARY │
│ unit: STRING # 单位（ms, %, bytes） │
│ source: MetricDataSource # 数据来源定义 │
│ aggregation: AggregationRule # 聚合规则 │
│ retention: RetentionPolicy # 数据保留策略 │
│ alertRules: List[AlertRule] # 告警规则 │
└─────────────────────────────────────────────────────┘
MetricDataSource：
├── type: PROMETHEUS / DATABASE / EVENT_STREAM / COMPUTED
├── query: STRING（PromQL / SQL / Expression）
├── refreshInterval: DURATION（采集间隔）
├── timeout: DURATION（采集超时）
└── labels: Map<String, String>（标签映射）
AggregationRule：
├── function: SUM / AVG / MIN / MAX / P50 / P90 / P95 / P99 / COUNT
├── timeWindows: List[DURATION]（1m, 5m, 1h, 1d, 7d, 30d）
├── groupBy: List[STRING]（分组维度）
└── fillPolicy: ZERO / NULL / PREVIOUS / LINEAR_INTERPOLATION
RetentionPolicy：
├── rawRetention: DURATION（原始数据保留时长）
├── minuteRetention: DURATION（分钟粒度保留时长）
├── hourRetention: DURATION（小时粒度保留时长）
├── dayRetention: DURATION（天粒度保留时长）
└── downsampleEnabled: BOOLEAN（是否自动降采样）
#2.2 Prometheus 数据源
Code
从 Prometheus 采集技术指标：
metricSource:
metricId: "order_service_latency_p99"
name: "订单服务 P99 延迟"
metricType: HISTOGRAM
unit: "ms"
source:
type: PROMETHEUS
query: |
histogram_quantile(0.99,
rate(http_request_duration_seconds_bucket{
service="order-service",
instance="{{instanceId}}"
}[5m])
) * 1000
refreshInterval: 15s
timeout: 5s
labels:
instanceId: "{{objectId}}" # 映射到 ObjectType 实例
aggregation:
function: P99
timeWindows: [1m, 5m, 15m, 1h, 6h, 1d]
fillPolicy: PREVIOUS
retention:
rawRetention: 7d
minuteRetention: 30d
hourRetention: 365d
dayRetention: 3y
采集流程：
1. 每 15 秒执行 PromQL 查询
2. 将结果关联到对应的 ObjectType 实例
3. 存储原始值到时序存储
4. 自动聚合到各时间窗口
5. 过期数据自动降采样
#2.3 业务数据库数据源
Code
从业务数据库采集业务指标：
metricSource:
metricId: "customer_monthly_revenue"
name: "客户月度收入"
metricType: COUNTER
unit: "CNY"
source:
type: DATABASE
query: |
SELECT
customer_id,
SUM(total_amount) as monthly_revenue
FROM orders
WHERE customer_id = '{{objectId}}'
AND created_at >= DATE_TRUNC('month', CURRENT_DATE)
AND status = 'COMPLETED'
GROUP BY customer_id
refreshInterval: 5m
timeout: 30s
aggregation:
function: SUM
timeWindows: [1h, 1d, 7d, 30d]
groupBy: ["productCategory"]
fillPolicy: ZERO
retention:
rawRetention: 30d
hourRetention: 365d
dayRetention: 5y
#2.4 计算型数据源
Code
基于其他指标计算的派生指标：
metricSource:
metricId: "order_conversion_rate"
name: "订单转化率"
metricType: GAUGE
unit: "%"
source:
type: COMPUTED
expression: |
(metric("completed_orders", window="1h") /
metric("page_views", window="1h")) * 100
refreshInterval: 1m
dependencies:
- "completed_orders"
- "page_views"
aggregation:
function: AVG
timeWindows: [5m, 15m, 1h, 1d]
fillPolicy: LINEAR_INTERPOLATION
注意：计算型指标与派生属性的区别
├── 派生属性：基于对象属性计算，返回单个值
├── 计算型指标：基于时序数据计算，返回时间序列
├── 派生属性：SUM(LineItem.lineTotal) → 一个数字
└── 计算型指标：completedOrders/pageViews → 每分钟一个数据点
#3. 指标的时序存储
#3.1 多粒度存储架构
Code
时序数据的分层存储：
┌─────────────────────────────────────────────────┐
│ 时序存储架构 │
│ │
│ Hot Storage（最近 24h） │
│ ├── 原始粒度（15s 采样间隔） │
│ ├── 存储：内存 + SSD │
│ └── 查询延迟：< 10ms │
│ │
│ Warm Storage（1d ~ 30d） │
│ ├── 分钟粒度（1m 聚合） │
│ ├── 存储：SSD │
│ └── 查询延迟：< 100ms │
│ │
│ Cold Storage（30d ~ 1y） │
│ ├── 小时粒度（1h 聚合） │
│ ├── 存储：HDD / 对象存储 │
│ └── 查询延迟：< 1s │
│ │
│ Archive Storage（> 1y） │
│ ├── 天粒度（1d 聚合） │
│ ├── 存储：对象存储（S3/MinIO） │
│ └── 查询延迟：< 10s │
└─────────────────────────────────────────────────┘
自动降采样（Downsampling）：
原始 → 分钟：每分钟取 AVG/MIN/MAX/P99
分钟 → 小时：每小时取 AVG/MIN/MAX/P99
小时 → 天：每天取 AVG/MIN/MAX/P99
降采样保留了多个聚合值，支持不同的查询场景：
"过去 1 小时的平均 CPU" → 用分钟粒度的 AVG
"过去 1 小时的最高 CPU" → 用分钟粒度的 MAX
"过去 30 天的 P99 延迟趋势" → 用小时粒度的 P99
#3.2 时序数据模型
Code
时序数据点（TimeSeriesPoint）：
┌─────────────────────────────────────────────────┐
│ TimeSeriesPoint │
├─────────────────────────────────────────────────┤
│ metricId: STRING # 指标标识 │
│ objectId: STRING # 关联的对象实例 │
│ timestamp: TIMESTAMP # 时间戳 │
│ value: DOUBLE # 指标值 │
│ labels: Map # 附加标签 │
│ granularity: ENUM # RAW/MIN/HOUR/DAY │
│ aggregations: Map # 聚合值 │
│ avg: DOUBLE │
│ min: DOUBLE │
│ max: DOUBLE │
│ p50: DOUBLE │
│ p99: DOUBLE │
│ count: LONG │
│ sum: DOUBLE │
└─────────────────────────────────────────────────┘
存储示例：
metricId: "cpu_usage"
objectId: "server-001"
timestamp: "2025-01-15T10:30:00Z"
granularity: MINUTE
aggregations:
avg: 67.3
min: 45.2
max: 89.1
p99: 87.5
count: 4 # 1 分钟内有 4 个原始数据点
sum: 269.2
#4. 统一查询接口
#4.1 单对象指标查询
Code
API: GET /api/v1/objects/{objectTypeId}/{objectId}/metrics
查询参数：
metrics: cpu_usage,request_latency_p99,error_rate
from: 2025-01-15T00:00:00Z
to: 2025-01-15T12:00:00Z
granularity: 1h
aggregation: avg
响应：
{
"objectId": "svc-001",
"objectType": "OrderService",
"timeRange": {
"from": "2025-01-15T00:00:00Z",
"to": "2025-01-15T12:00:00Z"
},
"granularity": "1h",
"metrics": {
"cpu_usage": {
"unit": "percent",
"dataPoints": [
{"timestamp": "2025-01-15T00:00:00Z", "value": 23.5},
{"timestamp": "2025-01-15T01:00:00Z", "value": 21.8},
{"timestamp": "2025-01-15T02:00:00Z", "value": 19.2},
...
]
},
"request_latency_p99": {
"unit": "ms",
"dataPoints": [
{"timestamp": "2025-01-15T00:00:00Z", "value": 145.3},
{"timestamp": "2025-01-15T01:00:00Z", "value": 132.7},
...
]
},
"error_rate": {
"unit": "percent",
"dataPoints": [
{"timestamp": "2025-01-15T00:00:00Z", "value": 0.01},
{"timestamp": "2025-01-15T01:00:00Z", "value": 0.02},
...
]
}
}
}
#4.2 跨对象指标聚合
Code
API: POST /api/v1/objects/{objectTypeId}/metrics/aggregate
请求：
{
"filter": {
"region": "us-east-1",
"environment": "production"
},
"metrics": ["cpu_usage", "request_latency_p99"],
"aggregation": "avg",
"groupBy": ["serviceTeam"],
"from": "2025-01-15T00:00:00Z",
"to": "2025-01-15T12:00:00Z",
"granularity": "1h"
}
响应：
{
"groups": [
{
"key": {"serviceTeam": "payment-team"},
"metrics": {
"cpu_usage": {
"avg": 45.2,
"dataPoints": [...]
},
"request_latency_p99": {
"avg": 234.5,
"dataPoints": [...]
}
}
},
{
"key": {"serviceTeam": "order-team"},
"metrics": {
"cpu_usage": {
"avg": 67.8,
"dataPoints": [...]
},
"request_latency_p99": {
"avg": 189.3,
"dataPoints": [...]
}
}
}
]
}
#4.3 混合查询（属性 + 指标）
Code
API: POST /api/v1/objects/{objectTypeId}/query
请求：
{
"select": ["serviceName", "version", "cpu_usage", "revenue"],
"filter": {
"cpu_usage.avg(1h)": {">": 80},
"environment": "production"
},
"timeRange": {
"from": "2025-01-15T00:00:00Z",
"to": "2025-01-15T12:00:00Z"
},
"orderBy": [{"cpu_usage.avg(1h)": "DESC"}],
"limit": 10
}
响应：
{
"results": [
{
"objectId": "svc-003",
"serviceName": "payment-service",
"version": "2.1.0",
"cpu_usage": {"avg_1h": 92.3, "current": 88.7},
"revenue": {"sum_24h": 234567.89}
},
{
"objectId": "svc-001",
"serviceName": "order-service",
"version": "3.0.1",
"cpu_usage": {"avg_1h": 85.1, "current": 82.4},
"revenue": {"sum_24h": 523456.12}
}
]
}
这个查询的含义：
"找出 CPU 使用率超过 80% 的生产服务，显示它们的收入"
→ 一个查询同时获取技术指标和业务数据
→ 无需跨系统关联
#5. 告警规则与 Ontology 联动
#5.1 基于指标的告警
Code
告警规则定义：
alertRule:
ruleId: "alert-cpu-high"
name: "CPU 使用率过高"
metric: "cpu_usage"
condition:
operator: ">"
threshold: 85
duration: 5m # 持续 5 分钟触发
aggregation: avg
severity: WARNING
actions:
- type: NOTIFY
channels: ["slack:#ops-alerts", "email:oncall@company.com"]
- type: CREATE_ACTION
actionType: "ScaleUpService"
parameters:
targetReplicas: "{{current_replicas + 2}}"
告警与 Ontology 的联动：
传统告警：CPU > 85% → 发通知
coomia-dip 告警：CPU > 85% → 发通知
+ 查询该服务的关联 ObjectType
+ 找到受影响的业务流程
+ 评估业务影响（收入损失估算）
+ 自动触发扩容 Action
告警上下文示例：
┌────────────────────────────────────────────────────┐
│ ALERT: CPU 使用率过高 │
│ │
│ Service: order-service (svc-001) │
│ CPU: 92.3% (avg over 5min) │
│ Duration: 7 minutes │
│ │
│ Business Impact (via Ontology): │
│ ├── Request Latency P99: 450ms (normal: 150ms) │
│ ├── Error Rate: 3.2% (normal: 0.1%) │
│ ├── Affected Orders: ~1,200 in last 5 min │
│ ├── Estimated Revenue Impact: ¥45,000/hour │
│ ├── Affected Customers: 340 (12 VIP) │
│ └── Related Downstream: payment-service, sms-svc │
│ │
│ Auto Action: ScaleUpService triggered │
│ Target: 3 → 5 replicas │
└────────────────────────────────────────────────────┘
#5.2 业务指标告警
Code
不仅技术指标可以设告警，业务 KPI 也可以：
alertRule:
ruleId: "alert-conversion-drop"
name: "转化率异常下降"
metric: "conversion_rate"
condition:
type: ANOMALY_DETECTION
baseline: "same_hour_last_week"
deviationThreshold: -30% # 比上周同期低 30%
duration: 15m
severity: CRITICAL
actions:
- type: NOTIFY
channels: ["slack:#business-alerts"]
- type: CORRELATE
correlateWith: ["error_rate", "latency_p99", "deployment_events"]
timeWindow: 1h
业务告警的自动关联分析：
转化率下降 30%
→ 自动查询同时段的技术指标
→ 发现 error_rate 从 0.1% 上升到 3.2%
→ 发现 30 分钟前有一次部署
→ 自动生成关联报告
关联报告：
"转化率下降可能与 30 分钟前的 order-service v3.0.1 部署有关，
该部署后错误率上升了 32 倍。建议回滚到 v3.0.0。"
#6. 指标驱动的派生属性
#6.1 基于指标的派生属性
Code
指标可以参与派生属性的计算：
ObjectType: Service
metrics:
cpuUsage: METRIC(gauge)
memoryUsage: METRIC(gauge)
errorRate: METRIC(gauge)
latencyP99: METRIC(histogram)
derivedProperties:
healthScore: DERIVED
expression: |
100
- (IF(metric("cpuUsage", "avg", "5m") > 80, 20, 0))
- (IF(metric("memoryUsage", "avg", "5m") > 85, 20, 0))
- (IF(metric("errorRate", "avg", "5m") > 1, 30, 0))
- (IF(metric("latencyP99", "avg", "5m") > 500, 30, 0))
evaluationMode: REALTIME
refreshInterval: 1m
riskLevel: DERIVED
expression: |
CASE
WHEN healthScore >= 80 THEN "LOW"
WHEN healthScore >= 50 THEN "MEDIUM"
WHEN healthScore >= 20 THEN "HIGH"
ELSE "CRITICAL"
END
效果：
Service 的 healthScore 每分钟自动重算
基于 4 个维度的实时健康度评估
riskLevel 随 healthScore 自动更新
所有消费者看到的是统一的健康度视图
#6.2 跨对象的指标聚合派生
Code
高层对象聚合低层对象的指标：
ObjectType: ServiceCluster
derivedProperties:
avgCpuUsage: DERIVED
reducer: AVG
sourceObjectType: Service
sourceMetric: cpuUsage
aggregation: avg
timeWindow: 5m
maxLatencyP99: DERIVED
reducer: MAX
sourceObjectType: Service
sourceMetric: latencyP99
aggregation: p99
timeWindow: 5m
totalErrorCount: DERIVED
reducer: SUM
sourceObjectType: Service
sourceMetric: errorCount
aggregation: sum
timeWindow: 1h
clusterHealthScore: DERIVED
expression: |
100
- (IF(avgCpuUsage > 75, 15, 0))
- (IF(maxLatencyP99 > 300, 25, 0))
- (IF(totalErrorCount > 100, 30, 0))
- (IF(unhealthyServiceCount > 0, 30, 0))
层级关系：
Company
└── ServiceCluster（聚合 Service 指标）
└── Service（聚合 Instance 指标）
└── Instance（原始指标）
每一层都可以看到聚合后的健康度
CEO 看 Company 级别：一个数字
CTO 看 Cluster 级别：各集群健康度
SRE 看 Service 级别：各服务详情
运维看 Instance 级别：各实例详情
#7. Metrics 的访问控制
#7.1 指标级权限
Code
不同角色看到不同的指标：
权限矩阵：
┌──────────────┬─────────┬──────────┬──────────┬──────────┐
│ 角色 │ 技术指标 │ 业务KPI │ 财务指标 │ 用户指标 │
├──────────────┼─────────┼──────────┼──────────┼──────────┤
│ SRE/运维 │ ✓ 全部 │ ✓ 只读 │ ✗ 无 │ ✗ 无 │
│ 产品经理 │ ✓ 摘要 │ ✓ 全部 │ ✓ 只读 │ ✓ 聚合 │
│ 数据分析师 │ ✓ 只读 │ ✓ 全部 │ ✓ 全部 │ ✓ 聚合 │
│ 高管 │ ✓ 摘要 │ ✓ 摘要 │ ✓ 全部 │ ✓ 摘要 │
│ 外部合作伙伴 │ ✗ 无 │ ✓ 受限 │ ✗ 无 │ ✗ 无 │
└──────────────┴─────────┴──────────┴──────────┴──────────┘
权限控制粒度：
├── 指标可见性（能否看到这个指标存在）
├── 时间范围（只能看最近 7 天 vs 全部历史）
├── 粒度限制（只能看小时粒度 vs 原始粒度）
├── 聚合限制（只能看聚合值 vs 明细值）
└── 对象范围（只能看自己团队的 vs 全部）
#8. 指标与 Action 的联动
#8.1 指标触发 Action
Code
指标变化自动触发 Ontology Action：
场景 1：自动扩容
metric: cpuUsage > 80% for 5m
→ Action: ScaleUpService(replicas += 2)
场景 2：自动降级
metric: errorRate > 5% for 2m
→ Action: EnableCircuitBreaker(service=order-service)
→ Action: NotifyOnCall(severity=P1)
场景 3：业务响应
metric: conversionRate < baseline * 0.7 for 15m
→ Action: CreateIncident(type=BUSINESS_ANOMALY)
→ Action: TriggerRCA(correlateMetrics=[errorRate, latency, deployments])
场景 4：成本优化
metric: cpuUsage < 20% for 24h
→ Action: ScaleDownService(replicas -= 1)
→ Action: NotifyOwner("Consider downsizing this service")
这些都是通过 Ontology 的 ActionType 定义的，
享受 ActionType 的所有能力：
├── 审批工作流
├── 前置检查（Guard）
├── 审计日志
├── 回滚机制
└── 权限控制
#9. 实战：构建统一监控模型
#9.1 电商平台监控建模
Code
电商平台的统一 Ontology 监控模型：
ObjectType: EcommerceService
属性：
serviceId, serviceName, team, environment
技术指标：
cpuUsage, memoryUsage, diskUsage
requestCount, requestLatency, errorRate
connectionPoolUsage, threadPoolUsage
gcPauseTime, heapUsage
业务指标：
orderCount, orderValue, conversionRate
cartAbandonRate, paymentSuccessRate
avgOrderValue, returnRate
派生属性：
healthScore（基于技术指标）
businessImpactScore（基于业务指标）
overallScore = healthScore * 0.6 + businessImpactScore * 0.4
ObjectType: EcommerceCluster
派生指标（聚合 Service）：
totalOrderValue = SUM(Service.orderValue)
avgHealthScore = AVG(Service.healthScore)
worstLatency = MAX(Service.requestLatency)
totalErrorCount = SUM(Service.errorCount)
ObjectType: EcommercePlatform（顶层单例）
派生指标（聚合 Cluster）：
platformGMV = SUM(Cluster.totalOrderValue)
platformHealthScore = AVG(Cluster.avgHealthScore)
platformAvailability = 1 - (Cluster.totalErrorCount / Cluster.totalRequestCount)
三层模型的价值：
Platform → "今天平台 GMV 多少？整体健康度如何？"
Cluster → "哪个集群有问题？影响了多少订单？"
Service → "具体哪个服务的 CPU 高？延迟高的原因是什么？"
#9.2 指标仪表板自动生成
Code
基于 Ontology 模型自动生成 Grafana Dashboard：
API: POST /api/v1/ontology/metrics/dashboard/generate
请求：
{
"objectTypeId": "EcommerceService",
"objectId": "svc-001",
"layout": "standard",
"includeMetrics": ["*"],
"includeRelated": true
}
自动生成的 Dashboard 结构：
┌─────────────────────────────────────────────────┐
│ EcommerceService: order-service │
├─────────────────────────────────────────────────┤
│ Overview Row: │
│ [Health Score] [Risk Level] [Uptime] │
│ │
│ Technical Metrics Row: │
│ [CPU] [Memory] [Disk] [GC Pause] │
│ │
│ Request Metrics Row: │
│ [Request Rate] [Latency P99] [Error Rate] │
│ │
│ Business Metrics Row: │
│ [Order Count] [Conversion Rate] [Revenue] │
│ │
│ Related Services Row: │
│ [payment-svc health] [inventory-svc health] │
│ │
│ Alerts Row: │
│ [Active Alerts] [Recent Incidents] │
└─────────────────────────────────────────────────┘
Dashboard 和 Ontology 模型保持同步：
├── ObjectType 新增指标 → Dashboard 自动添加面板
├── ObjectType 删除指标 → Dashboard 自动移除面板
├── 新增 Service 实例 → 自动生成实例 Dashboard
└── 关系变更 → Related Services 面板自动更新
#10. 与传统方案的对比
Code
Metrics-as-Ontology vs 传统监控方案：
┌──────────────┬────────────────────┬──────────────────────┐
│ 特性 │ coomia-dip │ Prometheus + Grafana │
├──────────────┼────────────────────┼──────────────────────┤
│ 技术监控 │ ✓ 内置 │ ✓ 核心能力 │
│ 业务指标 │ ✓ 统一模型 │ ✗ 需要额外系统 │
│ 关联分析 │ ✓ 自动（Ontology） │ ✗ 手动关联 │
│ 告警上下文 │ ✓ 业务影响分析 │ ✗ 纯技术告警 │
│ 权限控制 │ ✓ 属性级别 │ ✗ Dashboard 级别 │
│ 自动 Action │ ✓ ActionType 驱动 │ △ 需要 AlertManager │
│ 历史追溯 │ ✓ 版本化 │ ✗ 覆盖写 │
│ 数据治理 │ ✓ Ontology 治理 │ ✗ 无 │
│ 仪表板 │ ✓ 自动生成 │ ✓ 手动配置 │
│ 学习成本 │ 中等（Ontology） │ 低（PromQL） │
└──────────────┴────────────────────┴──────────────────────┘
coomia-dip 不是要替代 Prometheus：
├── Prometheus 仍然是采集和存储的最佳工具
├── coomia-dip 在 Prometheus 之上建立了 Ontology 模型
├── 将技术指标和业务数据统一到同一个查询接口
├── 通过 Ontology 的关系和派生属性实现自动关联
└── 让"监控"从纯技术视角升级到业务视角
#Key Takeaways
- Metrics 纳入 Ontology 打破了技术监控和业务分析的数据孤岛——同一个 ObjectType 上既有普通属性也有指标属性，一个查询就能获取"服务延迟"和"业务收入"，无需跨系统关联。
- MetricSource 统一了指标的定义和采集——无论数据来自 Prometheus、业务数据库还是计算表达式，都通过相同的模型定义，相同的 API 查询，消费者无需关心数据来源。
- 指标与 Ontology 的联动创造了新价值——告警不再是孤立的"CPU 高了"，而是带有完整业务上下文的"CPU 高了，影响了 1200 个订单，预计损失 ¥45,000/小时"。
- 多层聚合实现了不同角色的视角——Instance → Service → Cluster → Platform，每一层自动聚合下层指标，CEO 看全局健康度，SRE 看具体实例。
- 指标触发 Action 实现了闭环自动化——不只是看到问题（告警），还能自动处理（扩容、降级、创建事件），通过 ActionType 机制享受审批、审计、回滚等完整能力。
#Next Article
下一篇 S4-11 数据接入（Data Onboarding） 将讨论如何将外部数据源的数据映射到 Ontology 模型——CSV 文件、数据库表、API 接口、消息队列，如何定义映射规则，如何处理数据质量问题，如何实现增量同步。
#ontology #metrics #monitoring #time-series #kpi #alerting #observability #business-metrics #unified-model