500. That’s an error. There was an error. Please try again later. That’s all we know.
railsのアクセスログは、とても機械的に解析しづらく、運用するにはあまりよろしくない。そこで、Rack::CommonLoggerを使ってアクセスログを別途とったりしようとしていたのですが、(一般的にはNew Rericとかをつかうのが普通なんでしょうか?) ログのローテーションとか考え出すと、あまり良い方法が思いつかない、という関係で、 syslogへ投げる fluentdへ投げる というアイディアを思いついたのですが、syslogだと機械解析しづらいフォーマットになってしまったりあまり詳しい人が意外といなかったりする関係で、流行っているfluentdへ投げちゃえと思いRack::CommonLogger::Fluentというrackのミドルウェアを書いてみた次第。 https://github.com/walf443/rack-common_logger-fluent まだ作り始めで
最もシンプルなプロセス間通信(IPC)の一つである FIFO(named pipe) についてメモ。 unnamed pipe シェルから $ ls | wc -l と実行すると、ls と wc という2つのプロセスが起動され、ls は実行結果をパイプで wc に出力し、wc はパイプで ls の実行結果を入力する。 named pipe named pipe(fifo/first in, first out)を使うと、任意のプロセスは(r/w権限がある限り) 指定したパイプに出力し、指定したパイプから入力することができる。上のコマンドを named pipe を使うと、以下のようになる。 $ mkfifo named_pipe $ ls > named_pipe $ wc -l < named_pipe 上のコマンドを実際に実行するとわかるように、 FIFO はデフォルトでは read
大型のシステム障害の詳細が見えてきた。全日本空輸(ANA)が2016年3月22日に起こした国内線旅客システム「able-D(エーブルディ、以下では便宜上開発コード名のANACore:アナコアと称す)」のシステム障害では全国49の空港で搭乗手続きができなくなり、ANAと提携航空会社5社の合計で719便、7万2100人以上に影響を及ぼした。インターネットや予約センターでの予約などもできなかった。 ANAは障害発生から8日後の3月30日に経緯や原因を公表、さらに4月11日に弊誌のメール取材に応じ、一段詳しい真相が判明した。 4台のSuperdomeをRACでクラスタリング 今回のシステム障害の中身は3月20日のニュースで報じた通り、4台のデータベース(DB)サーバーが停止したというもの(関連記事:ANAシステム障害の原因判明、シスコ製スイッチの「世界初のバグ」でDBサーバーがダウン)。今回、弊誌
Railsアプリを開発していて,時に app/assets/stylesheets/layout.css.scss を書き換えて,ページを更新したときに,「あれっ,スタイルが更新されていないよ〜 (T-T)」というような状況が出る場合があります. 最初からずーっとdevelopment環境で作業していれば,app/assets/stylesheets 配下のスタイルファイルはページが読み込まれるたびに全て読み込む設定にデフォルトでなっているので,常に更新結果が反映されます.でも,ページアクセスの度にこれら複数のファイルが読み込まれるので,本番環境(production)環境では,これらスタイルファイル(css.scss)を結合して1つの application.css として読み込まれる様に,次のようなコマンドで,事前にコンパイルしておくのです. $ bundle exec rake as
先日PHPカンファレンス北海道2016にて「『例えば、PHPを避ける』以降PHPはどれだけ安全になったか」と題して基調講演を担当致しました。その際のスライドはこちら。 そうしたところ、以下のご指摘をいただきました。 @ockeghem スライド拝見しました。39番目のスライドですが、バインドのタイミングでintにキャストするのはちょっと例として良くない気がします。意図的にオーバーフローを起こすことで想定外のレコードの取得を許してしまいそうです。キャストしない方がまだ安全だと思うのですが。 SQLデータベースは、int型よりも大きな桁数を扱える場合があるので、intへのキャストを避けた方がよいという指摘は一般論としてはもっともなものだと考えます。PHPの場合、9223372036854775807を越える数字文字列をint型にキャストすると、9223372036854775807が返ります(
こんにちは、運用部 アプリ運用グループの清水です。モンスト仲間募集中です。 以前、Fedora 8からFedora 17への移行のお話を書きました。Fedora 17ではsystemdがデフォルトで使われています。そのsystemdを本番環境で運用して1年以上が経ち、様々な経験をしてきました。systemdの環境で知っておくと役に立つと思われることについていくつか紹介したいと思います。 まずは、systemdの概要について簡単に紹介します。 systemdの概要と歴史 systemdは、従来のSysVinit/Upstartに代わるもので、Linuxサーバの起動時に初期設定やサービス起動をおこなうことにとどまらず、プロセスやリソースなど様々な管理をおこなうデーモンです。 Fedora 14の頃(2010年11月リリース)にTechnology Previewとして提供され、Fedora 1
Google Compute Engine、全世界のリージョンが同時に外部とのネットワーク接続を失うという深刻な障害が発生。ネットワーク管理ソフトウェアにバグ クラウドのどこかで障害や災害が発生したとしても、その影響はアベイラビリティゾーンを超えることはなく、そのために複数のアベイラビリティゾーン(Google Compute Engineでは「ゾーン」)にシステムを分散して配置することで、クラウドの障害の影響を受けない高い可用性を備えたシステム構築ができる。これはクラウド(IaaS)に対応したシステム構築におけるもっとも基本的な考え方です。 しかし先週、2016年4月11日にGoogle Compute Engineで発生した通信障害は、アベイラビリティゾーンどころかリージョンの境界も越え、世界中にあるすべてのリージョンのインスタンスが同時に外部とのネットワーク接続を18分間に渡って失う
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く