エムスリーテックブログスマートフォン用の表示で見るエムスリーテックブログエムスリー(m3)のエンジニア・開発メンバーによる技術ブログです2018-08-24エムスリーのサービスレベル監視基盤を構築した話SREこんにちは、エンジニアリングGの高橋です。去年の11月にエムスリーにSREとして参画してから、サーバのセットアップ作業などの基本的なインフラ作業に加えて、各サービスのサービスレベルの設定や監視の仕組み作りなども行ってきました。今回はそのサービスレベルを監視する仕組みをご紹介したいと思います。各種メトリクスの収集アラーティング監視ダッシュボードの作成まとめ全体像ざっくりとした全体像としては上図のような感じです。この取り組みを実施した前後で、下のような変化(効果)がありました。Indicator)を何にするかですが、弊社では稼働率とHTTPリクエストのレイテンシを主なターゲットとしました。多すぎると初期設定が大変なので、最低限だけ設定し、必要に応じて後から追加するという方針にしています。最初にどれくらいの値を設定するかは結構悩みどころだと思います。試験的に監視を開始した数サービスでは現在のSLIの値を参考に決めていました......が、それを全サービスに対してやっているとあまりにも時間がかかりすぎるので、とりあえず一律でざっくり決めて、3ヶ月~半年程度の間隔で開発陣とSREでミーティングを設けて修正していくという形をとっています。次にどうやってSLIとして定めた値を収集するかをご紹介します。弊社ではサービスの死活監視ツールとしては下記2つを主に使っています。Nagios各サーバの死活監視用NodePing社外からのURL外形監視用とても安い(いいところ)レスポンスタイムも取れますが、アクセス元によってばらつきがあるので未使用NodePingからの稼働率収集この手のURL外形監視サービスでは大体あるのではないかと思うのですが、uptimeを返してくれるAPIがあるので、取得期間を絞って定期的に取得してElasticsearchに格納していきます。Reportという機能があり各監視対象の稼働率を表示することが出来ます。枯れたツールなのでJSON等の扱いやすい形式でデータを返してくれるAPIがなかったりします。OKのTimeを取得しています。sum(lists)HTTPリクエストのレイテンシ基本的にはNginx/Apache/Play等のアクセスログからリクエストのレイテンシ(レスポンスタイム)を取得しています。各サーバにはログを送付するためのFluentdが導入されており、ltsv形式で出力されたログを中継用のFluentdに送付しています。中継用のFluentdでは各種フィルタリング処理や、長期保存用のインデックスを作成するためのサンプリング処理を実施しています。sampleサンプリングすることで精度は下がりますが下記のメリットがあります。データを長期間保存してもデータ量がそれほど肥大化しない集計時のElasticsearchの負荷軽減(低リソースのVMで動かしているので大事)フィールドが元々のログと同様であるため、グラフを使い回せる一定期間で集約した値を蓄積していく方法もあるとは思いますが、Kibanaでは加重平均のグラフを作成することが困難なため採用しておりません。平均が3000msになってしまったり...(アクセス数に応じた重み付けが必要)アラーティング下記のようなアラートは存在しましたが、Nagios/NodePing/Warder*1/CloudWatch/Prometheus+Grafanaによる障害時アラートメール定期的なレスポンスタイム監視スクリプトによるアラートメールこれらに加えて、過去5日間の範囲でSLOを超過していないか監視するようにしました。WebhookでSlackに通知するようにしています。[任意URL]'各開発側のチームとの連絡用Channelにはサービスごとに通知。SRE用のChannelには超過状況を一覧出来るメッセージを通知します。状況を一覧するために、全サービスのSLO超過状況を横断的に見るダッシュボードをKibanaにて作成しました。Selectorというところでサービスと指標を指定するとグラフが絞り込むことが出来ます。過去情報はひと月ごとに集計した情報をTimelionという機能を使ってグラフ化しています。Kibana赤線がSLOで、青線がSLIの値となっています。下図はMR君というサービスのApacheのレスポンスタイムの値を描画しています。線形回帰トレンドまとめ上記取り組みにより、簡単にではありますが各サービスのサービスレベル監視とアラーティングの仕組みを作ることが出来ました。重要なのはSLOを超過しないようにすばやく改善施策を決めて実行していく体制作りだと思うので、そのあたりを進めていけたらと思っています。Microservice化したサービスでは、単一のアクセスログでは、全体のレイテンシが把握しきれないものが多く、現状としてはあまり細かくSLOを設定できていないです。一部サービスではzipkinやX-Rayを利用して分散トレーシングしていますが、今後はそれらをより強化していきたいと考えています。下記フォームからお気軽にエントリーしてみて下さい。CIの実行時間を15%短縮した話はじめまして、エンジニアリンググループの山口です。9月にjoin...2018-08-21bashスクリプティング研修の資料を公開しますこんにちは、エンジニアリングGの中村です。月別アーカイブ注目記事はてなブログをはじめよう!m3techさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。