微博 https://www.weibo.com/huang007
分类： 大数据
2018-03-09 16:13:15
实体本质上由手动录入的标题、key-value键值对组成，键值对分为别名（alias）和信息域（info field）两类。这两类的区别是：Alias用于唯一标识实体也就是用于分组和搜索。info用于补充实体的属性。Alias和info均可能用作参数输入到后续的实体展示中。实体的建立如下图：
实体的展示如下：
实体输入的时候如果重复了，splunk好像不负责去重。这样会导致分组的时候，只会关联第一个实体。
每一个实体会生成一个唯一id。
实体跟服务的关联是非常松散的，并且实体在Service中是optional的。即使定义了实体，服务也不一定局限于这些实体。（Entity Rules allow for the optional, dynamic filtering of KPIs and can help in root cause analysis. A service need not define any Entity Rules and is not limited to only the entities matching Entity Rules.）简言之，服务主要跟KPI相关，一个KPI可以设置是否由定义的实体所约束，这个后面再展开。
一个服务里面包含多少实体，主要由RULEs来过滤。RULEs如下所示：
配置KPI，可以按照实体分组，还可以按照alias过滤。
1. KPI的名称
2. 通过spl语句描述的数据源
3. 定时周期，计算窗口，监控lag（把数据从发生到入库的延迟也考虑进去，否则kpi算不准）
4. 聚合
a) 是否根据Entity分组，只能定义
b) 是否filter Entity、是否
l 例子：aggregate_raw_into_service(count, host)
l 参数：
1. 聚合模式
2. 目标字段
l 输出字段：
1. 聚合结果alert_value
2. 聚合时间_time
3. 定义实体的字段名entity_key（因为没有定义实体，所以是static值service_aggregate）
4. 定义实体的字段名entity_title（static值service_aggregate）
5. is_entity_defined 0
6. is_service_aggregate 1
l 记录条数 1条
l 例子：aggregate_raw_into_entity(count, 4xx_error, application_server)
l 参数
1. 聚合模式
2. 目标字段
3. 分组字段
l 输出字段
1. 聚合结果alert_value
2. 聚合时间_time
3. 分组字段名（本例中就是application_server）
l 跟在aggregate_raw_into_entity后面，例子：match_entities(application_server)
l 参数
n 唯一标识实体的字段
l 输出字段
1. entity_id
2. entity_title
3. is_entity_defined 1
4. is_service_aggregate 0
5. serviceid
l 例子：aggregate_raw_into_service(avg)
l 参数
1. 聚合模式
l 输出字段
1. aggregate_raw_into_service和aggregate_raw_into_entity输出字段和结果的累加
2. is_all_entities_in_maintenance
l 严重性评估，例子：assess_severity(bc8f2697-39f0-4d8e-ac77-91a2999b2a9c, d938af27a490feac9955f338, true, true)
l 参数
1. serviceid
2. Kpiid
l 输出字段
1. aggregate_entity_into_service的输出字段与结果
2. Alert_color
3. Alert_error
4. Alert_level
5. Alert_period
6. Alert_serverity
选择多个指标，根据每个指标的权重进行加权。
这种搜索又称为correlation search。
GlassTable的概念相对简单，KPI的集合
根据搜索产生统计指标
根据搜索产生event指标
直接选择已经定义好的kpi指标
