comparison slide/slide.md @ 6:02066b6bd6e6 default tip

add 2022
author kiyama <e185758@ie.u-ryukyu.ac.jp>
date Thu, 13 Apr 2023 11:18:26 +0900
parents 22e459299d68
children
comparison
equal deleted inserted replaced
5:c8ffd012e8ab 6:02066b6bd6e6
15 15
16 # 学科システム 16 # 学科システム
17 * 学科システムは約300人の学生と教員に対して様々なサービスを提供している 17 * 学科システムは約300人の学生と教員に対して様々なサービスを提供している
18 * 学内ネットワークや、貸出用の仮想マシン (Virutal Machine: VM) など、授業や研究を円滑に進める為のサービスを、24時間365日提供している 18 * 学内ネットワークや、貸出用の仮想マシン (Virutal Machine: VM) など、授業や研究を円滑に進める為のサービスを、24時間365日提供している
19 * 学科システムはシステム管理チームによって管理されている 19 * 学科システムはシステム管理チームによって管理されている
20 * 有志の職員と学生を中心に結成されている. 20 * 有志の職員と学生を中心に構成されている.
21 * 教師1名、職員2名、学生数名 21 * 教師1名、職員2名、学生11名
22 22
23 # 安定した運用の為の構築 23 # 安定した運用の為の構築
24 * 一般的にシステムを保守・運用する上で障害は必ず発生する 24 * 一般的にシステムを保守・運用する上で障害は必ず発生する
25 * 悪意のある障害:外部からの攻撃 25 * 悪意のある障害:外部からの攻撃
26 * 悪意のない障害:ハードウェアなどの物理故障 26 * 悪意のない障害:ハードウェアなどの物理故障
28 * 問題発生時にアラートを送信する監視システム(Prometherus) 28 * 問題発生時にアラートを送信する監視システム(Prometherus)
29 * ログの情報を集約する(Loki) 29 * ログの情報を集約する(Loki)
30 * これらの情報を可視化する(Grafana) 30 * これらの情報を可視化する(Grafana)
31 31
32 # 学科システムのトラブルの例 32 # 学科システムのトラブルの例
33 1. クラウドサーバーのHDDが物理故障していた為アクセス不可 (8/2) 33 1. クラウドサーバーのHDDが物理故障していた為アクセス不可 (2021/8/2)
34 2. サーバー交換により復旧 (8/6) 34 2. サーバー交換により復旧 (2021/8/6)
35 3. 計画停電によりオンプレサーバーが故障 (8/10) 35 3. 計画停電によりオンプレサーバーが故障 (2021/8/10)
36 4. 復旧時にファームウェアアップデートによりKVMのIPv4が停止 (8/17) 36 4. 復旧時にファームウェアアップデートによりKVMのIPv4が停止 (2021/8/17)
37 37
38 38
39 1.はHDD故障アラームを処理していれば防げた可能性がある 39 1.はHDD故障アラームを処理していれば早期に対応できた可能性がある
40 40
41 # Gitlabトラブルの対処 41 # Gitlabトラブルの対処
42 * Gitlabの自動アップデートはメジャーアップデートに対応してなかった 42 * Gitlabの自動アップデートはメジャーアップデートに対応してなかった
43 * 学生に対しGitlabから不正なアクセスのメールを確認していたが調査しなかった 43 * 学生に対しGitlabから不正なアクセスのメールを確認していたが調査しなかった
44 * Gitlabの脆弱性を利用され攻撃に利用された 44 * Gitlabの脆弱性を利用され攻撃に利用された
45 * 新しいバージョンのGitlabを導入しアカウントを移行することで復旧 45 * 新しいバージョンのGitlabを導入しアカウントを移行することで復旧
46 46
47 47
48 Gitlabのログを監視していれば防げた可能性がある 48 Gitlabのログを監視していれば対応できた
49 49
50 # 監視システムでの問題 50 # 監視システムでの問題
51 * アラート送信の機能は運用する中で過不足が無いように調整が必要 51 * アラート送信の機能は運用する中で過不足が無いように調整が必要
52 * 通常の編集方法ではサーバーにログインが必要 52 * 通常の編集方法ではサーバーにログインが必要
53 * 作業内容はScrapboxに記述することになっている 53 * 作業内容はScrapboxに記述することになっている
84 84
85 <img src="./img/monitoring_system-Page-3.drawio.svg" width="1000px"> 85 <img src="./img/monitoring_system-Page-3.drawio.svg" width="1000px">
86 86
87 87
88 # 監視システム(サービス監視) 88 # 監視システム(サービス監視)
89 grafanaでダッシュボードを用いて可視化 89 grafanaでダッシュボードを用いて可視化
90 nginxの例 サービスの状態、処理された接続の総数、接続の状態
90 91
91 <img src="./img/grafana-prometheus.png" width="1000px"> 92 <img src="./img/grafana-prometheus.png" width="1000px">
92 <!-- ![grafana](./img/grafana-prometheusのコピー.png) --> 93 <!-- ![grafana](./img/grafana-prometheusのコピー.png) -->
93 94
94 # 監視システム(ログ収集) 95 # 監視システム(ログ収集)
95 下図がサービスのログを収集しブラウザで確認できるまでの流れである 96 下図がサービスのログを収集しブラウザで確認できるまでの流れである
96 97
97 <img src="./img/loki-ページ3.drawio.svg" width="1000px"> 98 <img src="./img/loki-ページ3.drawio.svg" width="1000px">
98 99
99 # 監視システム(ログ収集) 100 # 監視システム(ログ収集)
100 grafanaのダッシュボードを用いて可視化 101 grafanaのダッシュボードを用いて可視化
102 sshの例 ログの総数、エラーの総数、単位時間ごとのログ出力の数
101 <img src="./img/loki-dashboard.png" width="1000px"> 103 <img src="./img/loki-dashboard.png" width="1000px">
102 104
103 # 監視システム(アラート送信) 105 # 監視システム(アラート送信)
104 右図がログに対しアラートルールを設定しMattermostからアラートを確認出来るまでの流れである 106 右図がログに対しアラートルールを設定しMattermostからアラートを確認出来るまでの流れである
105 107
107 <img src="./img/monitoring_system-Page-1.svg" width="1000px"> 109 <img src="./img/monitoring_system-Page-1.svg" width="1000px">
108 110
109 # 監視システム(アラート送信) 111 # 監視システム(アラート送信)
110 Mattermostに送信されるアラートは以下のような形式 112 Mattermostに送信されるアラートは以下のような形式
111 113
112 <img src="./img/Mattermost-alert.png" width="1000px"> 114 <img src="./img/Mattermost-alert.png" width="900px">
113 115
114 116
115 # Mattermostでのアラートルール編集 117 # Mattermostでのアラートルール編集
116 /から始まるコマンドを打つ事で設定したWeb APIにGET/POSTリクエストを送信可能 118 /から始まるコマンドを打つ事で設定したWeb APIにGET/POSTリクエストを送信可能
117 以下がMattermostのスラッシュコマンドからアラートを編集するまでの流れ 119 以下がMattermostのスラッシュコマンドからアラートを編集するまでの流れ
124 # スラッシュコマンド一覧 126 # スラッシュコマンド一覧
125 以下が今回作成したスラッシュコマンド一覧 127 以下が今回作成したスラッシュコマンド一覧
126 128
127 | コマンド | 機能 | 129 | コマンド | 機能 |
128 | ---- | ---- | 130 | ---- | ---- |
129 | /alert add $name $label $pattern $time | アラートルールの追加 | 131 | /alert add NAME LABEL PATTERN TIME | アラートルールの追加 |
130 ||| 132 |||
131 | /alert list all $name | アラートルールの表示 | 133 | /alert list ALL NAME | アラートルールの表示 |
132 ||| 134 |||
133 | /alert delete $name | アラートルールの削除 | 135 | /alert delete NAME | アラートルールの削除 |
134 136
135 137
136 # Mattermostでのアラートルール編集 138 # Mattermostでのアラートルール編集
137 以下のようにコマンドを用いることでアラートが編集可能 139 以下のようにコマンドを用いることでアラートが編集可能
138 図はaddを実行した結果 140 図はaddを実行した結果
153 155
154 <img src="./img/delete.png" width="1000px"> 156 <img src="./img/delete.png" width="1000px">
155 157
156 # 設定例 158 # 設定例
157 * 外部公開されているシステムの攻撃を検知する事が可能だと考える 159 * 外部公開されているシステムの攻撃を検知する事が可能だと考える
158 * 外部公開されているシステムの脆弱性をついた攻撃はPODTメソッドで行われる事が多い事から、一定時間に大量のPOSTがあった際に検知するよう設定することで攻撃を事前に防げる 160 * 外部公開されているシステムの脆弱性をついた攻撃はPOSTメソッドで行われる事が多い
161 * 一定時間に大量のPOSTがあった際に検知するよう設定することで攻撃を事前に防げる
159 162
160 * 誤ったアラートルールを設定してしまい必要以上にアラートが発生する場合にはdeleteコマンドを使うことでMattermostからすぐに削除することができる 163 * 誤ったアラートルールを設定した場合
164 * 必要以上にアラートが発生する
165 * deleteコマンドでMattermostからすぐに削除することができる
161 166
162 # まとめ 167 # まとめ
163 * 障害対応のための監視システムを提案した 168 * 障害対応のための監視システムを提案した
164 * Mattermostからアラートルールを編集できるスラッシュコマンドを作成した 169 * Mattermostからアラートルールを編集できるスラッシュコマンドを作成した
165 * CLI上での変更方法と比べて情報共有にかかる手間や調べる手間が少ない事から第三者が確認しやすいと考える 170 * CLI上での変更方法と比べて情報共有にかかる手間や調べる手間が少ない事から第三者が確認しやすいと考える
166 171
167 # 今後の課題 172 # 今後の課題
168 * 収集したデータのバックアップや提案環境の構築場所を運用にするに当たって改善する必要がある 173 * 収集したデータのバックアップや提案環境の構築場所を運用にするに当たって改善する必要がある
169 * 本研究では監視対象を限定したので稼働しているサービスすべてを監視する必要がある 174 * 本研究では監視対象を限定したので稼働しているサービスすべてを監視する必要がある
170 * 現在はオンプレ環境でのみ動作している為クラウドにセカンダリを構築し冗長化する必要がある 175 * 現在はオンプレ環境でのみ動作している為クラウドにセカンダリを構築し冗長化する必要がある
171 * このアラートルール設定では管理者の技量に左右されてしまう為必要なアラートの選択 176 * このアートルール設定では管理者の技量に左右されてしまう為改善する必要がある
172 * チャットツールでは過去に遡っての確認が難しい為Gitlab Scrapboxとの連携する必要がある 177 * チャットツールでは過去に遡っての確認が難しい為Gitlab Scrapboxとの連携する必要がある