PHPerKaigi 2019

## PHP監視 ## サービスを守る為に行う ## 不測の事態への努力 ### PHPerKaigi 2019 清家史郎(@seike460)

###### Who? Fusic Co., Ltd.  清家史郎  @seike460 [](https://twitter.com/seike460) [](https://www.facebook.com/seike460) [](https://github.com/seike460)

### tech - Program Language - PHP - Go - infrastructure - Server, Network - IaC - Cloud - AWS SA Professional - Other - Serverless - Vue.js、React

### OSS products - AWS Tools (Go) - [s3ry](https://github.com/seike460/s3ry) (s3 prompt cli) - S3を使いやすくしたCLI - [utakata](https://github.com/seike460/utakata) (Serverless Slack Notificatier) - iCalイベントをSlack通知する

このスライドは公開済みです https://slide.seike460.com/slides/phperkaigi2019#/ ### フィードバックください！！！ [クリックするとfortee.jpに移動します](https://fortee.jp/phperkaigi-2019/

# 10秒告知

### PHPカンファレンス福岡2019 #phpconfuk - 2019.6.29(sat) 10:00 - 18:00  みなさまお待ちしております！！！

#### Agenda - 監視を学ぶ <!-- .element: class="fragment" --> - 監視ツールの選定 <!-- .element: class="fragment" --> - ふたつのOSS <!-- .element: class="fragment" --> - まとめ <!-- .element: class="fragment" -->

# 監視を学ぶ

### なぜ監視を行うのか ### Webサービスを提供し続ける為 <!-- .element: class="fragment" -->

Webサービスを提供する上での品質保証の基準「SLA」 - SLA(Service Level Agreement)100%は幻想 - 現実世界において「止まらないシステム」非現実的である - サービスの正常性担保するには「監視」を行う必要がある - 規模感にもよるが24時間365日、人が監視を続けるのは現実解ではない

### 監視ツールの選定 要件に応じた適切な監視ツールが必要 雰囲気での監視では無くて、明確な意思を持つ - 「なにを」 what - 「なぜ」 why - 「どのようにして」 how ### 監視を知る必要がある <!-- .element: class="fragment" -->

#### 入門監視  ##### 監視のデザインパターン

### 監視のデザインパターン 1 #### 組み合わせ可能な監視 - Unix哲学 ~Doug Mcilroy~ `1つのことを行い、またそれをうまくやるプログラムを書け。` `協調して動くプログラムを書け` - 監視サービスのコンポーネント - データ収集 - データストレージ - 可視化 - 分析とレポート - アラート

### 監視のデザインパターン 2 #### 作るのではなく買う - 安いから - 人件費 - 仕組み作り - メンテナンス費用 - あなたは(恐らく)監視ツールを設計する専門家ではないから - SaaSを使うとプロダクトにフォーカスできるから - 実際のところSaaSの方がいいから

### 監視のデザインパターン 3 #### 継続的改善 変わりゆく技術に追随して監視の仕組みを改善

### 監視のデザインパターン 4 #### ユーザー視点での監視 - ユーザーはサーバーやアプリの詳細など気にしていない - できるだけユーザーに近いところから監視を始める - サービスが利用できるのか - サービスが正しく動作してるか(HTTPレスポンスコード) - サービスが快適に使えるのか - メトリクスが教えてくれることを常に自問自答すべき

### ユーザー目線での監視が鍵 ユーザー目線からWEBサービスを見る時 `「なにを」「なぜ」「どのようにして」監視すべきなのかを思考する`

### ユーザーは目的を持ってサイトに訪れる - その目的を常に達成させる - 目的を達成出来ない状況を思考する - 「なにを」監視するかを決める

##### サイトが見れない  - 目的のサイトなのか、エラーが発生しているのかすらわからない - ドメインに対する信頼性の低下 ### 死活監視 <!-- .element: class="fragment" -->

##### 目的のコンテンツが見れない  - 404,500等ユーザーが期待しているものが見えない - 意図したコンテンツが見えない - サイトに対する信頼性の低下 ### HTTPステータス監視 <!-- .element: class="fragment" -->

##### 快適にコンテンツが見れない  - サイトの表示が遅い - モチベーションが低い層の離脱 - モチベーションが高い層への信頼性の低下 ### レイテンシー監視 <!-- .element: class="fragment" -->

### 監視すべき対象 「なにを」「なぜ」は見えてきた - 死活監視 - HTTPステータス監視 - レイテンシー監視 それぞれ監視する動機も、要求も違う 「どのように」監視すべきなのか

# 監視ツール選定

### 監視ツールに求めるもの - ダウンタイムの最小化 - 影響ユーザー数にダイレクトに反映される - 最速で復帰がしたい - 正確なアラート - 意味のないアラートはオオカミ少年化を招く - アラートのチューニングがしたい - コスト感 - あくまでメインコンテンツではない - 可能な限り費用を抑えたい

### メジャーな監視ツール - OSS - Nagios <!-- .element: class="fragment" --> - Zabbix <!-- .element: class="fragment" --> - Prometheus <!-- .element: class="fragment" --> - サービス - New Relic <!-- .element: class="fragment" --> - Mackerel <!-- .element: class="fragment" --> - Datadog <!-- .element: class="fragment" --> 今回は上記に関して説明しません <!-- .element: class="fragment" -->

### 別のツールを検討する理由 - `作るのではなく買う` - 金の弾丸 - サービスの利用料 - OSS管理コスト 受託開発において確実に利用できる訳ではない <!-- .element: class="fragment" --> 確実にサービスを提供したい <!-- .element: class="fragment" -->

### じゃあどうするのか `~手を動かした者だけが世界を変える~ はてな 大西様` <!-- .element: class="fragment" --> `自分の世界を少しでも変えよう` <!-- .element: class="fragment" -->

### アンチパターンを選択 `買うのではなく作る` 自分の求める世界を思考する - コスト削減 <!-- .element: class="fragment" --> - `自分の武器であるServerlessを使いたい` <!-- .element: class="fragment" --> - 最速で気付く <!-- .element: class="fragment" --> - `アプリケーションからアプローチしたい` <!-- .element: class="fragment" -->

# ２つのOSS

２つのServerlessなOSS - faultline <!-- .element: class="fragment" --> - FictionBase <!-- .element: class="fragment" -->

### faultline  `Error tracking tool on AWS managed services` [@k1low](https://twitter.com/k1LoW)さんが作成したOSS https://github.com/faultline

以下の機能を提供 - アプリケーションエラーの検知 - エラーをマネージドサービスに保存 - WebUiにてエラーを可視化 - Github等へのインシデント(issue)登録 - Slack通知

### 監視サービスコンポーネント - データ収集 - アプリケーションエラーの検知 - データストレージ - エラー情報をマネージドサービスに保存 - 可視化 - WebUiにてエラーを可視化 - 分析とレポート - Github等へのインシデント(issue)登録 - アラート - Slack通知

### faultline対応言語 - `PHP` - Go - Ruby - Node

### Architecture 

### Slack通知 

### WebUi 

### エラーの `根本` を監視 - 復帰する為の価値の高い情報 - Host - StackTrace - User Agent(ブラウザ) ### 最速で気付きと復帰 <!-- .element: class="fragment" -->

### faultlineで出来ない事 - ミドルウェアの監視 - ユーザー視点での監視 - 死活監視 - HTTPステータス監視 - レスポンス監視 ### Serverlessでフルマネージド監視を行いたい <!-- .element: class="fragment" -->

### FictionBase `AWS managed Runtime Base` https://github.com/fictionbase

### FictionBase Architecture 

### 監視サービスのコンポーネント - データ収集 - agent - monitor - endpoint - データストレージ - router - 可視化 - 分析とレポート - Amazon CloudWatch - アラート - fictionbase - Slack

### fictionbase-agent  - Serverの情報をendpointに伝える - リソース情報 - プロセス情報 - 実装 - Go実装 goroutineで各種情報取得、endpointへの送信

### fictionbase-monitor  - http/https - 外形死活監視 - HTTPステータス監視 - レスポンスタイム監視 - 実装 - AWS lambdaの定期処理でサービス外部からユーザーへの影響を監視

### fictionbase-endpoint  - agentとmonitorからのデータを受け取る - 実装 - API Gateway To SQSのendpointの提供

### fictionbase-router  - SQSから各種ストレージにデータを保存 - CloudWatch - 実装 - 定期処理でSQSよりデータ取得して各種ストレージに保存

### fictionbase  - 集めた情報から自由に処理を組める - 監視通知 - Slack - 実装 - 自由 定期処理でストレージの情報を元に各種処理を実行

### フルマネージド監視 - faultline - エラー監視 - FictionBase - ミドルウェア監視 僕が思考した監視に一つ近付けた 思考した監視を実現出来た訳ではない まだ自分の世界を変えたい

### まとめ - 監視とは何かを学んだ - `ユーザー視点での監視` - `作るのではなく買う` - 手元にある状況と武器を踏まえて、 あえてアンチパターンを踏む抜く

## 誰にとってもベストな監視などない

## なんとなく -> 目的意識

## 監視と向き合いましょう ## そして健全なシステムを運用しましょう

Thank you! Fusicは技術が大好きなエンジニアを募集しています  https://fusic.github.io