アラート起因で調べるベースの運用とログの話を書いておく。 状況確認 状況確認は大事。ひとまず初動で原因が分かると嬉しいので ざっくり状況確認。 ログを読む エラーログを読む なにも出てなかったらWARNを読む メトリクスを見る 5xxエラーを見る どのサービスがダメになってる？ 状況別調査 状況別に自分が見ているところをざっくりメモベースで書いておいた。 変なレスポンスが返っている ログを見る リクエストに紐付いた一意なIDを元にログで処理を追いかける 外部通信した時はこの一意なIDと一緒にログに出力しておきたい レスポンスが遅い レスポンスタイムを見る 特定のリクエストだけ遅い場合があるので、基本的にAverageじゃなくてPercentileを使う 依存先のサービスも見る サービスのCPU使用率見る 特定のインスタンスのCPU使用率を見る RDBやバックエンドのCPU使用率を見る IO
この記事はServerless Advent Calender 2017の16日目の記事です。 ライブラリ開発屋として仕事でAthenaを使ってログの収集分析をやりやすくした話をします。 はじめに 普段は開発者としてiOS/Android両対応のモバイルアプリ向けのライブラリの開発やテストをしています。その業務の中でお問い合わせを受けた際、お客さんの状況を聞いてライブラリを修正したり使い方を提案したりして対応させていただくことがあります*1。 その中で、なかなか言葉で状況の説明が難しい場合があり、そういうときは動作検証時のログをいただいて状況の確認をさせていただきます。しかし、いかんせんそういう状況は再現が難しかったりするもので動作検証のログがとれないか試しているうちに時間が経ってしまってもどかしいことが結構ありました。 そこで、なるべく早くお客様に解決方法の提案ができるように、それらしい
こんにちは、オンラインゲームのバックエンド、KPIシステムを担当していますマサヨシです。 先日に引き続き【DMMオンラインゲームで実際に実装しているログとKPI】に関してご紹介する第2回です。 DMMゲームのログ解析~ログ収集と解析の概要~ 第2回はログを実装する際に利用している"Parquet"についてご紹介します。 Parquetとは？ こちらは"Parquet"と書くのですが、「パーケイ」と読みます。 Parquetは何かというと、CSVやJSONのようにDBのレコードを格納できるデータフォーマットです。 Parquetはデータフォーマットの中でもカラムナーストレージフォーマットと呼ばれるもので、列方向にデータを格納しています。 そのためカラムへのアクセスが速く、特にSELECT,WHERE,GROUP BYの使用時に効果的です。 また、同じカラムには似たようなデータが格納されている
re:invent参加中です。 今は現地で朝4時ですが目が覚めてしまったので、初日のセッション参加レポートを書きます。 参加したのはこちらのセッション。 「ABD302 - Real-Time Data Exploration and Analytics with Amazon Elasticsearch Service and Kibana」 ElasticSearchとKibanaは2年くらい前にハンズオン参加して少し使ってみただけくらいでその後触れることはなかったのですが、今回ちょうど時間と場所が自分の予定と合ったので参加してみることにしてみました。 機能紹介 まずはAWS Elasticsearch Serviceってこんなものですよという紹介から。 次にElasticsearchではprimary shardとreplica shardが作られ、各インスタンスに分散して配置される
この記事は Akatsuki Advent Calendar 2016 の15日目です。 はじめに 今やログ収集ソフトウェアのデファクトスタンダードとなったFluentdですが、オートスケール環境においては思わぬログの重複や欠損が発生する可能性があります。今回は私の所属するプロジェクトで行ったログ重複・欠損対策について紹介したいと思います。 前提 今回前提とするシステムは下図のような構成になっています。 ELB配下にオートスケーリンググループに属するEC2インスタンスのアプリサーバが複数台あり、各インスタンス上では Rails と Fluentd (sender) が動作しています。各アプリサーバから出力されたログは Fluentd (aggregator) により集約され、最終的に DB に保存されます。 Fluentd を利用したログ収集の構成としては一般的なものかと思います。 (バッ
倉嶋です。 最近はすっかりPHPerとしてPHP Stormと戯れる日々です。 頭のいいIDE使うと、知識が足りないところが補完されるので頼りっぱなしです。 AWSはまだまだ補完されない領域が多いので、自分で頭を使う必要がありますね。 ということで、Elastic Beanstalkのログ取得でハマったところをご紹介。 ElasticBeanstalkのログ保存方法 ↑こちらの記事にあるとおり、Elastic Beanstalkのログは設定すれば定期的に勝手にS3へ格納されるのですが、サーバが減った時に消えちゃいます。 コレは困る。 ということで、シャットダウン時にログ書き出しのスクリプトを動かすようにしました。 Linuxでシャットダウン時に想定した処理が実行されない こちらを参考に、ランレベル0と6で動作するスクリプトを書きました。 #!/usr/bin/env bash lock_f
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く