夜莺监控系统

架构

夜莺的核心组件包括三个：采集器 categraf、和前端交互的模块 webapi、数据转发和告警引擎模块 server。

• categraf：采集器，用于采集监控数据，比如 OS 的 CPU、内存、IO 相关指标，数据库的指标，中间件的指标等等，都统一使用 categraf 来采集。
• webapi：用于和前端 JavaScript 交互的模块，对数据库做增删改查。
• server：server 模块是随着时序库走的，一套时序库对应一套 server，server 核心有两个作用：
  • 一个是接收监控数据的推送，转发给时序库。
  • 另一个是作为告警引擎，从数据库同步告警规则，然后为每个告警规则启动 goroutine，周期性的查询时序库，判断是否应该生成告警事件。

除了夜莺自身的3个组件，夜莺还依赖 MySQL 和 Redis。

• MySQL 用于存放各类用户配置，比如监控大盘、告警规则、屏蔽规则、订阅规则等。
• Redis 有两个作用：
  • 在 webapi 侧，是存放 jwt token。
  • 另一个是在 server 侧，作为一个注册中心，存放存活的 server 和 ident 列表（之后 server 的心跳放在了 MySQL 中），各个 server 模块就可以从 Redis 这里，知道全局活着的 server 列表，知道有哪些 ident 存活，便于生成 target_up 的指标数据。

Prometheus

Prometheus 是新一代的云原生监控系统，是一个开源的完整监控解决方案，形成了基于中央化的规则计算、统一分析和告警的新模型。

特点

Prometheus 作为一种云原生监控系统，有以下特点：

易于管理

• Prometheus 核心部分只有一个单独的二进制文件，不存在任何的第三方依赖（数据库、缓存等），因此不会存在级联故障。
• Prometheus 基于 Pull 模型的架构方式，可以在任何地方搭建监控系统。
• 对于一些复杂的情况，还可以使用 Prometheus 服务发现功能动态管理监控目标。

监控服务的内部运行状态

• Pometheus 鼓励用户监控服务的内部状态，基于 Prometheus 丰富的 Client 库，用户可以轻松的在应用程序中添加对 Prometheus 的支持，从而让用户可以获取服务和应用内部真正的运行状态。

强大的数据模型

• 所有采集的监控数据均以指标（metric）的形式保存在内置的时间序列数据库当中。所有的样本除了基本的指标名称以外，还包含一组用于描述该样本特征的标签。每一条时间序列由指标名称（Metrics Name）以及一组标签（Labels）唯一标识。如下所示：

1
2

http_request_status{code='200',content_path='/api/path',environment='produment'} => 
[value1@timestamp1,value2@timestamp2...]

其中，http_request_status 为指标名称，code、content_path 等为标签，[value1@timestamp1,value2@timestamp2...] 按照时间的先后顺序存储的值。

强大的查询语言 PromQL

• Prometheus 内置了一个强大的数据查询语言 PromQL。 通过 PromQL 可以实现对监控数据的查询、聚合。同时 PromQL 也被应用于数据可视化（如 Grafana）以及告警当中。

可扩展

• Prometheus 对于联邦集群的支持，可以让多个 Prometheus 实例产生一个逻辑集群，当单实例 Prometheus Server 处理的任务量过大时，通过使用功能分区 + 联邦集群可以对其进行扩展。

架构

Prometheus 整体上可以分为三个模块：

• 采集层
• 存储计算层
• 应用层

HacRED: A Large-Scale Relation Extraction Dataset Toward Hard Cases in Practical Applications

会议：ACL

年份：2021

作者：Qiao Cheng, Juntao Liu, Xiaoye Qu, Jin Zhao, Jiaqing Liang

机构：School of Computer Science, Fudan University, China

motivation：近期的关系抽取模型在公共数据集上取得了非常不错的效果，但是它们很难应用在实际应用中。这种在公共数据集与实际应用之间的表现差距，其根本原因在于实际应用在本质上有更多困难的情况（hard case）。所以论文提出了 Hard Case Relation Extraction Dataset（HacRED），使得关系抽取模型在实际应用中更具有鲁棒性。

• HacRED 数据集中有 65225 个关系三元组，标注来自 9231 个文件，有非常多不同的 hard case。预定义了 26 种关系类型，以及 8 种实体类型。
• HacRED 是最大的中文文档级关系抽取数据集之一，数据集的质量非常高。

GitHub：https://github.com/qiaojiim/HacRED

在 NTY 以及 WebNLG 等公共关系抽取数据集中，对于一个关系三元组有明显的关键词提示。但是在实际情况中，关系是没有明显的关键词的，这种情况就是 hard case。

由于关系抽取应用在不同的场景中存在很大差异，构建针对特定目标的数据集是关系抽取的一个流行趋势。关系抽取数据集的相关研究如下：

• SemEval-2010 Task 8 和 ACE05：人工标注，关系类型和实体类型的数据都非常有限。
• TACRED：通过众包得到的一个大规模的数据集。
• DocRED：为了文档级关系抽取的研究。
• FewRE 和 FewRE 2.0：为了满足 few-shot 关系抽取的场景。
• RELX：是一种跨语言的关系抽取数据集。

HacRED 的目标是促进关系抽取模型从复杂的上下文中提取信息。

IPRE: a Dataset for Inter-Personal Relationship Extraction

年份：2019

作者：Haitao Wang, Zhengqiu He, Jin Ma, Wenliang Chen, Min Zhang

机构：School of Computer Science and Technology, Soochow University, China

贡献：提出了用于人际关系抽取的数据集 Inter-Personal Relationship Extraction，IPRE，这是第一个用于提取人际关系的数据集。

• IPRE 有 41000 个标注的句子，包含 34 个关系类别（其中 9000 条句子是人工进行标注的）。

GitHub：https://github.com/SUDA-HLT/IPRE

GrantRel: Grant Information Extraction via Joint Entity and Relation Extraction

会议：ACL2021

作者：Junyi Bian, Li Huang

机构：School of Computer Science, Fudan University

motivation：资助信息对于学术机构和资助机构都很重要。但是目前对于这一主题的研究有两点挑战：

• 没有高质量的数据集。
• 提取资助者和 grantIDs 之间关系的负责性

贡献：

• 提出了一种 pipeline 的资助信息关系抽取框架 GrantRE，包含了两个部分 funding sentence classifier 和 joint entity and relation extractor。
• 人工标注了两个数据集，Grant-SP 包含 1402 个句子用于训练 funding sentence classifier，Grant-RE 包含 3331 个句子用于 joint entity and relation extractor。

GitHub：https://github.com/Eulring/GrantRel

grant information 作为学术文章的一部分，包含了 funder name，grant number 和它们的关系。分别将 funder name（subject）和 GrantID（object）作为实体，将 grant information 抽取问题转为关系抽取问题。

模型结构

下图的左侧为 GrantRE 的工作流：

• Sentence Classification：用于挑选出可能包含资助信息的句子。
• Relation Extraction：提取资助信息。

Identification of funding sentences

使用 BioBERT 作为预训练模型，将句子输入到预训练模型中，使用 [CLS] 对应的 embedding（[CLS] 包含的句子的 embedding），获取这个句子包含资助信息的可能性。

Joint entity and RE

一个资助关系包含一个 funder（subject）和一个 grantID（object）。

Funder name detection

使用 BIO 去标记实体，将 BioBERT 的输出，送入线性层中去获取 BIO 标签的概率：

Grant relation detection

首先根据 funder name 的推理结果得到 funder name 的 embedding 表示。其中 u_fd 表示一个 funder name 实体的位置边界信息信息（起始位置和结束位置）。因为 funder name 的长度是不一致的，所以 f_fd 为平均池化操作。

对于每一个 token 进行 BIO 标记以获取 funder name 对应的 GrantID，计算 BIO 标记概率的方法如下（e_gr 表示 grant relation feature，即模型结构图中的 addition feature）：

GrantID detection

如果在前一步中未检测到一个资助者的名称，那么将会错过相应的 GrantID。此外，由于句子的分割问题 GrantID 可能会在句子中独立出现而没有相应的 funder。

为了提取出完整的 GantID，使用了一个可训练的向量 e_hat 来表示所有的 funder name。这意味着句子中的所有 GrantID 都应该与这个特殊的 funder 相匹配。

Grant relation feature

为了正确的建立 funder name 和 GrantID 之间的关系，除了使用 funder representation e_fd 之外，还使用了 addition feature e_gr。这个 feature 描述了 token 与 funder 之间的关系，用位置向量和上下文信息生成。

Position embedding

一些 funder name 的跨度相对较长，所以用一个数字来表示所有的距离是不准确的。我们将两个相对距离（与起始位置的距离和与结束位置的距离）的 embedding 作为我们最终的位置 embedding：

Context embedding

一个句子中除了 funder name 和当前的 token 之外的所有其他 token 为上下文，对上下文使用最大池化来获取 context embedding。

Adaptive embedding

位置和上下文的两种嵌入的组合，可以使模型更加健壮。当上下文意义非常清晰时，论文期望所提出的模型可以更多地关注上下文信息。根据这一观点，提出了一种机制，可以平衡两种 embedding，以一种自适应的方式处理不同的情况：

其中，α 是可训练的由上下文 embedding 决定的一个标量：

关系抽取论文 PTR: Prompt Tuning with Rules for Text Classification

年份：2021

作者：Xu Han, Weilin Zhao, Ning Ding, Zhiyuan Liu, Maosong Sun

机构：Department of Computer Science and Technology, Tsinghua University, Beijing

数据集：TACRED，TACREV，ReTACRED，SemEval 2010 Task 8

• TRCRED：通过众包的方式产生的，包含42个关系类别。
• TACREV：纠正了 TACRED 的原始验证集和测试集中的错误，而训练集却保持不变。
• ReTACRED：TACRED 的另一个版本，解决了原始 TACRED 数据集的一些缺点，并对其训练集、开发集和测试集进行了重构。 ReTACRED 还修改了一些关系类型。

motivation：

• pretrain 和 fine-tuning 之间存在着明显的差距，即 pretrain 时采用预测 mask 单词的方法，而在 fine-tuning 时可能做的是多分类任务。这一差距将阻碍预训练模型中的知识对下游任务的适应，prompt 的提出就是为了解决这种差距。
• 目前 prompt 适用于少量分类的场景，对于 many-class 的分类任务依然具有挑战性。

pretrain 和 fine-tuning 之间存在着明显的差距，即 pretrain 时采用预测 mask 单词的方法，而在 fine-tuning 时可能做的是多分类任务。这一差距将阻碍预训练模型中的知识对下游任务的适应，prompt 的提出就是为了解决这种差距。

并且，目前 prompt 适用于少量分类的场景，如情感分析或者自然语言推理：

• 对于情感分析，一个典型的 template 可以是 <S1> was [MASK]，将 label words 作为 MASK 预测的候选集，将预测出的单词映射到相应的情感中，如 great 映射到正面情感、terrible 映射到负面情感，将二分类问题转化为预测下一个单词问题。
• 对于自然语言推理，一个典型的 template 是 <S1>. [MASK], <S2>，label words 可以是 {yes, maybe, no} 来表示两个句子之间的关系。

论文提出了 prompt tuning with rules（PTR），可以应用于 many-class 的多分类任务中，PTR 的优势如下：

• Prior Knowledge Encoding：PTR 可以应用 logic rules 将任务和分类的先验知识编码到 prompt funing 中，预测的结果与实体类型和关系都相关。如对于关系 person:parent 和关系 organization:parent 应用两个 sub-prompt，第一个 sub-prompt 用于确定实体是人还是组织，第二个 sub-prompt 用于确定是否有 parent-child 关系。
• Efficient Prompt Design：根据 logic rules 可以很容易的设计几个简单的 sub-prompt，并且组合这些 sub-prompt 用于形成 task-specific prompt。

模型结构

考虑到设计 prompt 在 many-class 分类的困难性，论文提出了 PTR 合并 logic rules，利用几个简单的 sub-prompt 生成 task-specific prompt。论文将一个分类任务，转换为一系列条件函数的计算任务。

Document-Level Relation Extraction with Adaptive Thresholding and Localized Context Pooling

会议：AAAI 2021

作者：Wenxuan Zhou, Kevin Huang, Tengyu Ma, Jing Huang

机构：Department of Computer Science, University of Southern California, Los Angeles

数据集：DocRED，CDR 和 GDA（CDR 和 GDA 是生物医学领域的数据集）

贡献：提出了一种关系抽取（不包括实体识别）模型 ATLOP（Adaptive Thresholding and Localized cOntext Pooling），这个模型解决了文档级关系抽取中的 multi-entity 问题和 multi-label 问题。

• 为了避免在不同的 entity pair 中，实体 embedding 相同的问题。论文引入了 localized context pooling，这增强了与当前 entity pair 相关的实体 embedding。
• 对于多标签问题，论文引入了 adaptive threshold 机制，提出了 adaptive-thresholding loss，即用一种 rank-based loss 训练，即将正类的 logits 推到阈值以上、负类的 logits 拉到很低。在测试阶段，返回所有高于阈值的类。这种方法不需要人为的对阈值（超参数）进行调优，也可以使阈值适应于不用的实体对。

GitHub：https://github.com/wzhouad/ATLOP

对于 Document-level RE，有两个难题 multi-entity（在文档中出现了多个实体对）和 multi-label（一个特定的实体对之间存在多个关系）。在 DocRED 中如下：

A Frustratingly Easy Approach for Entity and Relation Extraction

会议：NAACL 2021

作者：Zexuan Zhong, Danqi Chen

机构：Department of Computer Science Princeton University

数据集：ACE04，ACE05，SciERC

共享：

• 提出了一种端到端 pipeline 的关系抽取模型 PURE（the Princeton University Relation Extraction system），分别为实体识别和关系分类学习两个独立的 encoder。
• 得到结论，为实体和关系学习不同的 contextual representations 比 joint 更为有效。
• 为了加快模型的推理时间，提出了一种新的有效近似方法。

GitHub：https://github.com/princeton-nlp/PURE

将关系抽取分为实体识别和关系分类两个子任务，分别学习两个模型 entity model 和 relation model，论文发现：

• entity model 和 relation model 的 contextual representations 本质上捕获了不同的信息，所以共享 representations 可能对模型的表现有害（这与当前 Joint 方法的想法是相反的）。
• 在 relation model 的输入层中融合实体信息（边界和类型）是至关重要的。
• 利用跨句子信息在两个子任务中都是有效果的。

论文提出的模型有个缺点：

对每一对实体都会运行一次 relation model。为了缓解这一问题，论文提出了一种新的、有效的替代方法，即在推理时对不同的 groups of entity pairs 进行近似和批量计算。这种近似实现了 8-16 倍的加速，而精度略有降低。

模型结构

PURE 由 entity model 和 relation model 组成（ relation model with batch computations 用于简化计算过程）。

A Partition Filter Network for Joint Entity and Relation Extraction

会议：ACL

年份：2021

作者：Zhiheng Yan, Chong Zhang, Jinlan Fu, Qi Zhang, Zhong yu Wei

机构：School of Computer Science, Shanghai Key Laboratory of Intelligent Information Processing, Fudan University, Shanghai, China

数据集：在六个数据集上进行评价，NYT、WebNLG、ADE、SciERC、ACE04、ACE05

贡献：

• 提出了一种 partition filter network，用于建模任务（NER 和 RE）之间的双向交互。
• 实验表明，关系预测对命名实体预测的贡献是不可忽视的（与 PURE 相反）。

GitHub：https://github.com/Coopercoppers/PFN

根据之前的工作在编码 task-specific features 上的差异，可以将现有的方法分为两种类型：sequential encoding 和 parallel encoding。

• sequential encoding：task-specific features 被顺序的生成，这意味着第一个提取的特征不会被后面提取的特征所影响（任务间特征交互不平衡）。
• parallel encoding：task-specific features 由共享的输入独立的生成，不需要考虑 encoding 的顺序。在这种方法中，虽然编码顺序不再是一个问题，但是交互只存在于共享 input 中。

然而，上述两种编码方式都不能正确的模拟 NER 和 RE 任务之间的双向交互。

论文考虑在 feature encoding 时加入双向交互，采用了一种 joint encoding 的形式：使用一个编码器联合编码 task-specific features，这个编码器应该存在一些用于任务间通信的交互部分。

提出了一种 partition filter encoder，利用 entity gate 和 relation gate 将神经元划分为两个任务分区和一个共享分区。这些分区被被组合生成了 task-specific features（提出了无关当前任务的分区信息）。

模型结构

模型由三个部分组成：

• partition filter encoder：用于生成 task-specific features，作为实体和关系预测的输入。
• NER unit
• RE unit

封装

封装就是隐藏对象内部的复杂性，只对外暴露简单的接口。便于外界调用，从而提高系统的可维护性、可扩展性。

• 高内聚：如果模块有高度的相关职责，除了这些职责在没有其他的工作，那么该模块就有高内聚。
• 低耦合：耦合指模块与模块之间的关系，模块之间不相互依赖。

封装和隐藏

将成员变量声明为 private，再提供 public 的方法 getXxx() 和 setXxx() 实现对该属性的操作。

封装和隐藏有以下作用：

• 隐藏一个类中不需要对外提供的实现细节。
• 使用者只能通过事先定制好的方法来访问数据，可以方便地加入控制逻辑，限制对属性的不合理操作。
• 便于修改，增强代码的可维护性。

修饰符

访问修饰符

封装性的体现需要权限修饰符的配合，体现了类的可见性。

Java 中，可以使用访问控制符来保护对类、变量、方法和构造方法的访问。支持 4 种访问权限：

• private：在同一类内部可见。最严格的访问级别，接口和类不能声明为 private。使用对象：变量、方法。 注意：不能修饰类（外部类）。
• default：在同一包内可见。使用对象：类、接口、变量、方法。
• protected： 对同一包内的类和所有子类可见。使用对象：变量、方法。 注意：不能修饰类（外部类）。
  • 子类与基类在同一包中：被声明为 protected 的变量、方法和构造器能被同一个包中的任何其他类访问。
  • 子类与基类不在同一包中：那么在子类中，子类实例可以访问其从基类继承而来的 protected 方法，而不能访问基类实例的 protected 方法。
• public：对所有类可见。使用对象：类、接口、变量、方法。