从Kafka读取警报，然后使用配置的通知方式通知客户。
项目描述
团队和存储库标签
通知引擎
此引擎从Kafka读取警报，然后使用配置的通知方式通知客户。可以并行运行多个通知和重试引擎，每个可用Kafka分区一个。
架构
通知引擎通过以下步骤生成通知
从Kafka读取警报，不自动提交。 - monasca_common.kafka.KafkaConsumer类
确定警报的通知类型。通过从mysql读取完成。 - AlarmProcessor类
发送通知。 - NotificationProcessor类
将成功的通知添加到已发送通知主题。 - NotificationEngine类
将失败的通知添加到重试主题。 - NotificationEngine类
提交偏移量到Kafka - KafkaConsumer类
通知引擎使用三个Kafka主题
alarm_topic：警报进入通知引擎。
notification_topic：成功发送的通知。
notification_retry_topic：失败的通知。
重试引擎与通知引擎并行运行，为任何失败的通知提供可配置的额外成功机会。
重试引擎使用以下步骤生成通知
从Kafka读取通知JSON数据，不自动提交。 - KafkaConsumer类
重建失败的通知。 - RetryEngine类
发送通知。 - NotificationProcessor类
将成功通知添加到已发送通知主题。 - RetryEngine类
将未达到重试限制的失败通知重新添加到重试主题。 - RetryEngine类
丢弃已达到重试限制的失败通知。 - RetryEngine类
将偏移量提交到Kafka。 - KafkaConsumer类
重试引擎使用两个Kafka主题
notification_retry_topic: 需要重试的通知。
notification_topic：成功发送的通知。
容错性
在从警报主题读取时，不执行提交。提交只在处理之后进行。这允许即使在某些通知处理缓慢的情况下，处理也可以继续。在发生灾难性故障的情况下，可能会发送一些通知，但警报尚未被确认。这是一种可接受的故障模式，发送通知两次总比一次都不发送要好。
遇到主要错误时的一般处理方法是退出守护进程，这应该允许其他进程重新协商对Kafka分区的访问。还假设通知引擎将由进程监督器运行，在出现故障时会重新启动它。这样，任何不易恢复的错误都会自动通过服务重启和活动守护进程切换到另一个实例来处理。
尽管这应该涵盖所有错误，但存在警报或一组警报可以多次处理并发出通知的风险。为了最小化这种风险，使用了一系列技术
为所有通知类型实现了超时。
使用警报TTL。任何超过TTL的警报都不会被处理。
操作
oslo.config用于处理配置选项。可以通过运行以下命令生成示例配置文件etc/monasca/notification.conf.sample
tox -e genconfig
使用默认配置文件位置/etc/monasca/notification.conf运行服务
monasca-notification
运行服务并显式指定配置文件
monasca-notification --config-file /etc/monasca/monasca-notification.conf
监控
StatsD被整合到守护进程中，并将所有统计信息发送到由monasca-agent启动的StatsD服务器。默认主机和端口指向localhost:8125。
计数器
ConsumedFromKafka
AlarmsFailedParse
AlarmsNoNotification
NotificationsCreated
NotificationsSentSMTP
NotificationsSentWebhook
NotificationsSentPagerduty
NotificationsSentFailed
NotificationsInvalidType
AlarmsFinished
PublishedToKafka
计时器
ConfigDBTime
SendNotificationTime
插件
以下通知插件可用
电子邮件
HipChat
Jira
PagerDuty
Slack
Webhook
可以通过Monasca通知配置文件配置插件。通常，您需要遵循以下步骤来启用插件
确保在配置文件中启用了插件
确保在配置文件中配置了插件
重新启动Monasca通知服务
PagerDuty插件
PagerDuty插件支持PagerDuty v1事件API。第一步是在PagerDuty中配置一个使用此API的服务。配置完毕后，该服务将分配一个集成密钥。此密钥应在创建通知类型时用作ADDRESS字段，例如
monasca notification-create pd_notification pagerduty a30d5560c5ce4239a6f52a01a15850ca
插件的默认设置应足够开始使用，包括 v1 事件 API URL，但检查 PagerDuty 事件 v1 API URL 是否与示例 Monasca 通知配置文件中提供的一致是值得的。
Slack 插件
要使用 Slack 插件，您必须首先配置一个要发布通知的 Slack 频道的入站 webhook。然后可以按如下方式创建通知
monasca notification-create slack_notification slack https://hooks.slack.com/services/MY/SECRET/WEBHOOK/URL
请注意，虽然也可以使用令牌代替 webhook，但这种方法现在已被 弃用。
默认情况下，Slack 通知会将所有可用信息都倒入警报中。例如，一个通知可能以如下方式发布到 Slack
{
"metrics":[
{
"dimensions":{
"hostname":"operator"
},
"id":null,
"name":"cpu.user_perc"
}
],
"alarm_id":"20a54a65-44b8-4ac9-a398-1f2d888827d2",
"state":"ALARM",
"alarm_timestamp":1556703552,
"tenant_id":"62f7a7a314904aa3ab137d569d6b4fde",
"old_state":"OK",
"alarm_description":"Dummy alarm",
"message":"Thresholds were exceeded for the sub-alarms: count(cpu.user_perc, deterministic) >= 1.0 with the values: [1.0]",
"alarm_definition_id":"78ce7b53-f7e6-4b51-88d0-cb741e7dc906",
"alarm_name":"dummy_alarm"
}
上述消息的格式可以使用 Jinja 模板进行自定义。模板中包含所有原始 Slack 消息的字段。例如，您可以按如下方式配置插件
[notification_types] enabled = slack [slack_notifier] message_template = /etc/monasca/slack_template.j2 timeout = 10 ca_certs = /etc/ssl/certs/ca-bundle.crt insecure = False
使用以下内容的 /etc/monasca/slack_template.j2
{{ alarm_name }} has triggered on {% for item in metrics %}host {{ item.dimensions.hostname }}{% if not loop.last %}, {% endif %}{% endfor %}.
使用此配置，上述原始 Slack 消息将转换为
dummy_alarm has triggered on host(s): operator.
未来考虑事项
需要更多广泛的负载测试
mysql 数据库的速度有多快？我们对其施加了多少负载。最初我认为读取每个警报的通知详情最有意义，但最终我可能希望缓存这些信息。
每次读取消息时提交到 Kafka 的成本是多少？我们应该提交每 N 条消息吗？
默认 Kafka 消费者批处理大小有多高效？
目前，每个 NotificationEngine 实例使用 webhook 到本地 http 服务器每秒可以处理大约 200 个通知。这够快吗？
我们在大约每秒 200 次提交的情况下对 Kafka 施加过多负载吗？
