|
4
|
1 title: ログ取集・管理をメッセージング経由で適切に設定する手法の提案
|
|
|
2 author: Mizuki Kiyama
|
|
|
3 profiles: 琉球大学
|
|
|
4
|
|
|
5 # 本研究での取り組み
|
|
|
6
|
|
|
7
|
|
|
8 * 学科システムへの監視システム提案
|
|
|
9 * 今まではZabbixでシステムを監視していた
|
|
|
10 * Prometheus, Loki, Grafanaに置き換える
|
|
|
11
|
|
|
12 * Mattermostのスラッシュコマンドを用いたアラートルールの編集
|
|
|
13 * 運用を通して必要なログを選択していく仕組みを構築した
|
|
|
14
|
|
|
15
|
|
|
16 # 学科システム
|
|
|
17 * 学科システムは約300人の学生と教員に対して様々なサービスを提供している
|
|
|
18 * 学内ネットワークや、貸出用の仮想マシン (Virutal Machine: VM) など、授業や研究を円滑に進める為のサービスを、24時間365日提供している
|
|
|
19 * 学科システムはシステム管理チームによって管理されている
|
|
6
|
20 * 有志の職員と学生を中心に構成されている．
|
|
|
21 * 教師１名、職員２名、学生11名
|
|
4
|
22
|
|
|
23 # 安定した運用の為の構築
|
|
|
24 * 一般的にシステムを保守・運用する上で障害は必ず発生する
|
|
|
25 * 悪意のある障害：外部からの攻撃
|
|
|
26 * 悪意のない障害：ハードウェアなどの物理故障
|
|
|
27 * 原因追求の為、様々なサービスの死活管理とログ調査が必要である
|
|
|
28 * 問題発生時にアラートを送信する監視システム(Prometherus)
|
|
|
29 * ログの情報を集約する(Loki)
|
|
|
30 * これらの情報を可視化する(Grafana)
|
|
|
31
|
|
|
32 # 学科システムのトラブルの例
|
|
6
|
33 1. クラウドサーバーのHDDが物理故障していた為アクセス不可 (2021/8/2)
|
|
|
34 2. サーバー交換により復旧 (2021/8/6)
|
|
|
35 3. 計画停電によりオンプレサーバーが故障 (2021/8/10)
|
|
|
36 4. 復旧時にファームウェアアップデートによりKVMのIPv4が停止 (2021/8/17)
|
|
4
|
37
|
|
|
38
|
|
6
|
39 1.はHDD故障アラームを処理していれば早期に対応できた可能性がある
|
|
4
|
40
|
|
|
41 # Gitlabトラブルの対処
|
|
|
42 * Gitlabの自動アップデートはメジャーアップデートに対応してなかった
|
|
|
43 * 学生に対しGitlabから不正なアクセスのメールを確認していたが調査しなかった
|
|
|
44 * Gitlabの脆弱性を利用され攻撃に利用された
|
|
|
45 * 新しいバージョンのGitlabを導入しアカウントを移行することで復旧
|
|
|
46
|
|
|
47
|
|
6
|
48 Gitlabのログを監視していれば対応できた
|
|
4
|
49
|
|
|
50 # 監視システムでの問題
|
|
|
51 * アラート送信の機能は運用する中で過不足が無いように調整が必要
|
|
|
52 * 通常の編集方法ではサーバーにログインが必要
|
|
|
53 * 作業内容はScrapboxに記述することになっている
|
|
|
54 * 他のシス管メンバーが変更を見落とす可能性がある
|
|
|
55
|
|
|
56 # アラート編集の問題の解決案
|
|
|
57 * オープンな環境(Mattermost)でアラートを編集できるようにする
|
|
|
58 * アラートルール変更をした際の見落としを防げる
|
|
|
59
|
|
|
60 # 研究目的
|
|
|
61 * システム障害の早期発見・発生時の円滑な対応を目的とした監視システムの提案
|
|
|
62 * 組織としての理解度向上を目的としたアラートルール編集方法の提案
|
|
|
63
|
|
|
64 # 使用するサービス
|
|
|
65 * Prometheus
|
|
|
66 * オープンソースの監視システム
|
|
|
67 * コンポーネントはExporterからデータを取得する
|
|
|
68 * Exporter
|
|
|
69 * 対象となるサービスのデータを Prometheusに送信する
|
|
|
70 * Alertmanager
|
|
|
71 * Prometheusのアラート管理コンポーネントツール
|
|
|
72
|
|
|
73 # 使用するサービス
|
|
|
74 * Grafana
|
|
|
75 * 収集されたデータをダッシュボードを用いて可視化する
|
|
|
76 * Grafana Loki(Loki)
|
|
|
77 * オープンソースのログ収集ツール
|
|
|
78 * 後述するPromtailからログを取得する
|
|
|
79 * Promtail
|
|
|
80 * サービスのログをlokiに対して送信するツール
|
|
|
81
|
|
|
82 # 監視システム（サービス監視）
|
|
|
83 下図のようにサービスの情報を収集しブラウザで確認できる
|
|
|
84
|
|
|
85 <img src="./img/monitoring_system-Page-3.drawio.svg" width="1000px">
|
|
|
86
|
|
|
87
|
|
|
88 # 監視システム（サービス監視）
|
|
6
|
89 grafanaでダッシュボードを用いて可視化
|
|
|
90 nginxの例 サービスの状態、処理された接続の総数、接続の状態
|
|
4
|
91
|
|
|
92 <img src="./img/grafana-prometheus.png" width="1000px">
|
|
|
93 <!--  -->
|
|
|
94
|
|
|
95 # 監視システム（ログ収集）
|
|
|
96 下図がサービスのログを収集しブラウザで確認できるまでの流れである
|
|
|
97
|
|
|
98 <img src="./img/loki-ページ3.drawio.svg" width="1000px">
|
|
|
99
|
|
|
100 # 監視システム（ログ収集）
|
|
6
|
101 grafanaのダッシュボードを用いて可視化
|
|
|
102 sshの例 ログの総数、エラーの総数、単位時間ごとのログ出力の数
|
|
4
|
103 <img src="./img/loki-dashboard.png" width="1000px">
|
|
|
104
|
|
|
105 # 監視システム（アラート送信）
|
|
|
106 右図がログに対しアラートルールを設定しMattermostからアラートを確認出来るまでの流れである
|
|
|
107
|
|
|
108
|
|
|
109 <img src="./img/monitoring_system-Page-1.svg" width="1000px">
|
|
|
110
|
|
|
111 # 監視システム（アラート送信）
|
|
|
112 Mattermostに送信されるアラートは以下のような形式
|
|
|
113
|
|
6
|
114 <img src="./img/Mattermost-alert.png" width="900px">
|
|
4
|
115
|
|
|
116
|
|
|
117 # Mattermostでのアラートルール編集
|
|
|
118 /から始まるコマンドを打つ事で設定したWeb APIにGET/POSTリクエストを送信可能
|
|
|
119 以下がMattermostのスラッシュコマンドからアラートを編集するまでの流れ
|
|
|
120
|
|
|
121
|
|
|
122 <img src="./img/alert-figur.drawio.svg" width="1000px">
|
|
|
123
|
|
|
124
|
|
|
125
|
|
|
126 # スラッシュコマンド一覧
|
|
|
127 以下が今回作成したスラッシュコマンド一覧
|
|
|
128
|
|
|
129 | コマンド | 機能 |
|
|
|
130 | ---- | ---- |
|
|
6
|
131 | /alert add NAME LABEL PATTERN TIME | アラートルールの追加 |
|
|
4
|
132 |||
|
|
6
|
133 | /alert list ALL NAME | アラートルールの表示 |
|
|
4
|
134 |||
|
|
6
|
135 | /alert delete NAME | アラートルールの削除 |
|
|
4
|
136
|
|
|
137
|
|
|
138 # Mattermostでのアラートルール編集
|
|
|
139 以下のようにコマンドを用いることでアラートが編集可能
|
|
|
140 図はaddを実行した結果
|
|
|
141
|
|
|
142 <img src="./img/add2.png" width="1000px">
|
|
|
143
|
|
|
144
|
|
|
145 # Mattermostでのアラートルール編集
|
|
|
146 以下のようにコマンドを用いることでアラートが編集可能
|
|
|
147 図はlist allを実行した際の結果
|
|
|
148
|
|
|
149 <img src="./img/list.png" width="1000px">
|
|
|
150
|
|
|
151
|
|
|
152 # Mattermostでのアラートルール編集
|
|
|
153 以下のようにコマンドを用いることでアラートが編集可能
|
|
|
154 図はdeleteを実行した際の結果
|
|
|
155
|
|
|
156 <img src="./img/delete.png" width="1000px">
|
|
|
157
|
|
|
158 # 設定例
|
|
|
159 * 外部公開されているシステムの攻撃を検知する事が可能だと考える
|
|
6
|
160 * 外部公開されているシステムの脆弱性をついた攻撃はPOSTメソッドで行われる事が多い
|
|
|
161 * 一定時間に大量のPOSTがあった際に検知するよう設定することで攻撃を事前に防げる
|
|
4
|
162
|
|
6
|
163 * 誤ったアラートルールを設定した場合
|
|
|
164 * 必要以上にアラートが発生する
|
|
|
165 * deleteコマンドでMattermostからすぐに削除することができる
|
|
4
|
166
|
|
|
167 # まとめ
|
|
|
168 * 障害対応のための監視システムを提案した
|
|
|
169 * Mattermostからアラートルールを編集できるスラッシュコマンドを作成した
|
|
|
170 * CLI上での変更方法と比べて情報共有にかかる手間や調べる手間が少ない事から第三者が確認しやすいと考える
|
|
|
171
|
|
|
172 # 今後の課題
|
|
|
173 * 収集したデータのバックアップや提案環境の構築場所を運用にするに当たって改善する必要がある
|
|
|
174 * 本研究では監視対象を限定したので稼働しているサービスすべてを監視する必要がある
|
|
|
175 * 現在はオンプレ環境でのみ動作している為クラウドにセカンダリを構築し冗長化する必要がある
|
|
6
|
176 * このアートルール設定では管理者の技量に左右されてしまう為改善する必要がある
|
|
4
|
177 * チャットツールでは過去に遡っての確認が難しい為Gitlab Scrapboxとの連携する必要がある |
