# 概要
これまで:
- ロググレップによるエラー監視
- メールベースのアラート
やったこと:
- ログの集約機能の対応(Elastick Stack)
- APMの導入(New Relic採用, Datadogと比較検証)
- 障害発生時確認フローを作成
# 業務内容
### ログの集約機能
- 各アプリケーションサーバのログデータを集約するサーバの構築補助
- セキュリティ部門にてSIEM運用をしていたElasticSearch + Kibanaに相乗りする形でfilebeat及びLogstashを構築してデータを投入。
- エラー発生状況確認用のダッシュボードを作成
### APMの導入
- パフォーマンス問題の調査などに限界が来ていたためAPMの導入を検討
- New RelicとDatadogでPoCを行い比較検討しNew Relicを採用
* 主観ではDatadogのほうが自由度は高いがNew Relicのほうが属人化する可能性が低かった。
* また、Java関連の機能が手厚く、いきなりソースコードに設定のためのコードを入れるのに抵抗があった中、configのみでトレーシングの細かい対応ができる点を評価
- New Relic導入 + Ansibleを利用して構成管理
- 社内での利用啓蒙及びアラート、ダッシュボードの検討/整備
### 障害発生時確認フローの作成
- 開発チーム以外でも障害の原因等の一時調査ができるようログ、APM、DBをどのツールを使ってどのように見れば良いかのフローマニュアルを作成
- それぞれのツールで視認性がよくなるようダッシュボードを作成。
- 主な目的
- 開発チーム以外の障害一時対応チームで確認できる情報量を増やし、原因特定までのリードタイムを縮める。
- 前述のAPIゲートウェイシステムについて属人化傾向があったためもっともクリティカルな障害対応についてスピード感を持って対応できる人員を増やすため(個人的な目標)。
# 発揮したバリューや学んだこと
- 各種モニタリング及びアラートの設定により、定期的な性能チェックで後手後手となっていたアプリケーションエラー以外のパフォーマンス面などの課題に対してのリードタイムを大幅に短縮した。
- レイテンシに対してのアラート整備ができたことによりネットワーク影響の遅延障害などに気付きやすく。
- 月次のパフォーマンス統計MTGでの確認 -> 常時以上パフォーマンスを検知の上原因特定
- New Relic導入の中で社外登壇も行い広報活動へも貢献(https://dev.classmethod.jp/articles/202001-report-new-relic-meetup-3-gmo-pg/)
# 反省点
- New Relic上の設定についてTerraform等でIaC化を進め、管理性を上げるべきだった。