首先

这篇文章是富士通云技术的2023年圣诞节日历的第11天文章，介绍了提供了Nifcloud等服务的富士通云技术。
(这篇文章是富士通云技术2023年圣诞日历的第11天文章，介绍了提供Nifcloud等服务的富士通云技术。)

昨天我使用 @ktakaaki 先生的 SwitchBot 的 BLE 功能来获取数据。
“Home Dashboard” 这个词我之前从未听说过，真是令我惊讶。虽然我家也有 Switch Bot 的产品，但是我却一直没有好好利用它们，感觉有点遗憾呢，这次真是学到了不少东西。

好的，今天

• Alertmanager と Gitlab を連携させてチケット発行を自動化する方法

 

Alertmanager と webhook を連携させてアラート対応を自動化する方法

我们将以…为中心进行介绍。

在过去的一年里做过的事情

去年我们所属的团队第一次进行了障碍训练，并在团队中进行了障碍训练的讲述中向大家介绍了这个流程。
今年由于团队成员有所变动，我们也进行了障碍训练。

去年我们致力于进行障碍训练，而今年实施本身顺利进行，因此在训练结束后，我们进行了改进。

回过头来看，我们按照以下的顺序逐步进行。

• 2度目の障害訓練実施

 

• チケット発行の自動化

過去のナレッジを蓄積する場所を用意

ドキュメントの更新

アラートメッセージに応じた対応手順を用意

アラート対応の自動化

本次我们将详细介绍票务发行和警报响应的自动化处理。

票务发行的自动化

在障害训练实施后的反思中，有人提出了一个观点，认为不仅需要改善参考障害发生时使用的文档，还应该有一个地方来储存过去处理警报时积累的知识。由于我们的团队在应对障害时经常在沟通工具上留下信息，因此我们决定要为信息积累提供一个稳定的场所。为了避免手动发行票务的麻烦，我们使得票务自动发行。

我们使用Prometheus进行监视，
使用Alertmanager进行警报管理。
因此，当Alertmanager检测到警报时，我们设置它自动创建Gitlab的incident（ticket）。

与Gitlab的整合

※参考：Gitlab官方文件资料

1. 准备一个项目，在发生警报时生成一个故障单

 

1. 打开项目的Settings > Monitor

 

1. 点击Alerts

 

1. 选择Add new integration

 

1. 在选择集成类型的下拉菜单中选择Prometheus

 

1. 切换到Active

 

1. 输入Prometheus API的基本URL

 

1. 保存设置，点击Save integration

 

打开View credentials选项卡，确认能够查看Webhook URL和Authorization key即可。

2. 与Alertmanager的协作

• alertmanager.yml に以下の設定を追加します

 

• receivers:

 

• – name: gitlab

 

• webhook_configs:

 

• – http_config:

 

• authorization:

 

• bearer_token: 1.9で確認した Authorization key を入力

 

• send_resolved: true

 

url: 1.9で確認した Webhook URL を入力

现在，当发生警报时，将自动创建事件。创建的事件可以从问题列表中进行确认。
由于自动填写了发生时间和警报名称，因此无需手动输入。
还可以设置适用于自动创建事件的模板。
我们准备了一个基本警报处理流程的检查清单模板，并将其应用。
在发生警报时，将打开自动创建的事件，并按照清单中所述的流程进行升级或调查。

自动化报警响应

经过障碍训练后，文档也已更新。以前，根据事件（例如：API响应变慢）准备了相应对策的文档，有时候根据警报消息很难确定属于哪个事件。因此，我们重新整理了根据每个警报消息的处理方法。

因为有人提到，可以将每个警报消息的处理方法重新整理一下，然后尝试自动化处理。

如前所述, 我们使用 Alertmanager 进行警报管理，现在我们决定将 Alertmanager 与 webhook 配合使用，以实现自动化。以下是概述：

Alertmanager
　　↓
 webhook
　　↓
アラートチェックスクリプト
　　↓
自動化用スクリプト

在警报发生时，Alertmanager会调用webhook。
webhook将执行警报检查脚本以判断所发生的警报，然后调用与警报相关的自动化脚本。
通过在自动化脚本中记录希望在警报发生时执行的处理操作，可以实现警报响应的自动化。

具体的的方式如下所示。

1. 准备每个警报的自动化脚本。

• /path/to/script/Alert_A.sh

アラートが発生した際に実施したい内容を記載してください
アラート名毎にスクリプトを作ると見分けやすいです
例ではシェルスクリプトにしていますが、他の言語でも問題ありません

准备警报检查脚本

• /path/to/script/AlertCheck.sh

今回はアラート名のみ取得していますが、必要に応じてほかの情報も同様に取得可能です
アラート名に応じて、対応する自動化用スクリプトを呼び出すように条件分岐させます

#!/bin/bash

# Alertmanager API をリクエストし現在発生しているアラート一覧を取得
api_result=`curl -X GET -G https://AlertmanagerのURL:ポート/api/v2/alerts?receiver=receiver名`
# アラート件数を取得
alert_count=`echo ${api_result} | jq length`

# アラート一覧からアラート情報を取得
for ((i=0; i<=`expr ${alert_count} – 1` i++)) do
# アラート名を取得
alertname=`echo ${api_result} | jq -r “.[$i].labels.alertname”`

# アラート名に応じて自動化用スクリプトを呼び出し
if [ ${alertname} = “Alert_A” ]; then
/path/to/script/Alert_A.sh
fi
done

3. 在Ubuntu上安装webhook。

apt install webhook

创建 webhook.json 文件

• /path/to/script/webhook.json に以下を記載します

 

• [

 

• {

 

• “id”: “alertautomation”,

 

• “execute-command”: “/path/to/script/AlertCheck.sh”,

 

• “command-working-directory”: “/path/to/script”

 

• }

 

]

5. 激活Webhook

webhook -hooks /path/to/script/webhook.json -verbose

Alertmanager 调用 webhook

• alertmanager.yml に以下の設定を追加します

 

• receivers:

 

• – name: ‘webhook’

 

• webhook_configs:

 

– url: ‘http://WebhookのURL:9000/hooks/alertautomation’

※参考：如何在Alertmanager接收到警报时执行Shell脚本

设定自动化脚本在处理完成后通知结果，能够使情况更容易理解，避免成为黑盒子。
此外，即使不能完全自动化处理的警报，也可以部分自动化地进行日志调查，通知结果有助于原因调查。

总结

我们继续今年的障碍训练，并从回顾中提取出以下要点：

• アラート情報を蓄積する場所の用意

 

一部アラート対応の自動化

我能够推进这一点。希望能继续进一步改善！

明天是 @Syuparn 的「利用WASI制作编辑器工具」的课程。如果能够制作出自己喜欢的编辑器，工作似乎也会更顺利呢…！敬请期待！