・2年で月間10億PVを支えるまで成長した ZenClerkの運用上の工夫を紹介 ・AWSのTipsとあるある話の共有
Zabbixの監視対象サーバのIPアドレス 起動デモ 上記リンクをクリックすると、自分のAWSアカウントのCloudFormationのスタック作成画面に遷移します。 そのまま「Continue」を押すと、スタックパラメータ指定が面に遷移します。「Stack Name」は好きなものに変えても大丈夫です。 ご自分の環境に合わせてパラメータを指定してください。必ずかえる必要があるのは「VpcID」、「SubnetId」、「KeyName」の3つです。 VpcIDとSubnetIdはAWSマネジメントコンソールで「VPC」➡「Subnet」へアクセスし、利用するサブネットを選択すれば確認できます。 下記の例では「VpcID: vpc-71527b19」、「SubnetId: subnet-73527b1b」です スタックパラメータを指定し、あとは「Continue」を選択していくと、スタックの作
7. \ / 私は誰? \ 丶 i. | / ./ / \ ヽ i. .| / / / \ ヽ i | / / / \ -‐ Zembutsu Masahito ー __ わ た し で す -- • 前佛 雅人 @zembutsu 二 / ̄\ = 二  ̄. | ^o^ |  ̄ -‐ \_/ ‐- – Solutions Engineer ( 萌えるSE ) / • インフラエンジニア的な仕事メイン / ヽ \ • 株式会社リンク at+link サービス開発部 ( http://www.at-link.ad.jp/ ) / • “技術者に安心と休息を” 提供するサービス追求(運用/監視/自動化) 丶 \ / / / | i, 丶 \ / / / | i, 丶 \ – オープンソース系・クラウド系コミュニティ活動 • http://pocketstudio.jp/log3/ – 主な職歴
左に寄ってたり、段組崩れたりしてた恥ずかしいレイアウトを直したりとか。 秋葉原で打合せの帰りにHEYの前通ったら『デススマイルズ』稼動してた! 寄りたかった(>_<)
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、ショッピング事業部開発部の吉野と申します。 今回は「アプリケーションログの設計と監視」について、実際にYahoo!ショッピングで採用している方法を少し交えながらお話しさせていただきます。 1.ログ設計のポイント ログ設計は、以下のポイントに注意して行うとよいでしょう。 ・ログ出力のポイントが押さえられているか ⇒セッションの始まりと終わり、処理の過程、例外処理の中など。 フローチャートのような処理フロー図があれば、そこにログ出力ポイントを書き込むとわかりやすくなります。 ・出力する情報に過不足はないか ⇒「いつ(システム時間)」「だれが(プロセスID・IPアドレスなど)」 「どこで(パスなど)」「なにをした(実行コマン
ログを取得しても、監視していなければ意味がない。しかし、常時監視するのは現実的ではない。異常の発生をメールで通知させるなどの対策を行っておこう。(編集局) 前回はログの基本的な設定について説明しました。今回は、出力されたログをサーバの運用に生かす方法を検討します。 本来、ログは常に監視しておくものであって、異常時のみ確認ればよいというものではありません。ただし、常時監視できる管理者はほぼいないでしょうし、大量のログが出力されるサーバを監視するのは不可能でしょう。 であれば、少しでも労力を削減しつつ確実に必要な情報を拾う方法を考えなければいけません。そこで、ツールを利用したログの管理方法を説明します。ツールにはそれぞれ一長一短があるので、どのツールを使用するのか、あるいはツール同士を組み合わせて使用するのかを考えてみてください。 ログチェックの前提条件:時間合わせ 前回も説明したとおり、ログ
Webサーバの24×365監視を実現する ~その1 - 何を監視すればいいのか?~:24×365のシステム管理(4) 昨今のインターネット時代、企業活動におけるWebサイトの重要性は、もはやこの場で説明するまでもないでしょう。そこでは、Webサーバの24時間365日稼働の実現が求められています。今回から数回にわたり、Webサーバ監視におけるポイントを紹介していきます。まずは、Webサーバで監視すべき項目や、監視の前に必要な事項をリストアップすることからはじめていきましょう。(編集局) 「Webサーバを監視しなければらない」と言われて、Webサーバの何を監視すればいいのか即座に思い浮かべられるだろうか。連載の第2回「Webサーバの障害をいかに切り分けるか」では、“Webサーバに障害が発生した場合”の原因を特定する方法を中心に解説したが、定常的な監視(作業の自動化)については、概要のみにとどま
scalaやJavaを始めとした技術情報満載のパテントビューロエンジニアのブログです。様々なログライブラリがあり、それらのAPIが割と統一されているにも関わらず、どのログレベルで出力するかは人によって差があるような気がします。そこで今回はWebアプリケーションのログレベルについて考えてみました。 まずJava開発の次のデファクトになると思われるSLF4Jのログレベルの説明を見てみます。 FATAL - アプリケーションを異常終了させるような非常に深刻なイベントを指定します。 ERROR - アプリケーションの稼働が継続できる程度のエラーを指定します。 WARN - 潜在的に害を及ぼすような状況を指定します。 INFO - アプリケーションの進捗の概要が分かるメッセージを指定します。 DEBUG - アプリケーションをデバッグすのに役立つ詳細なイベント情報を指定します。 TRACE - DE
最近忙しくてなかなかアップできずにいたこのブログですが、久しぶりの更新。MySQL Clusterのバックアップ・リカバリ運用やオープンソースシステム構築など、色々アップしたいネタがたまっているものの、今日は直近でよく使う性能管理系のネタについて書いていきます。(前者のネタ更新をお待ちいただいている方、リクエストも頂いておりますがすみませんorz)。さて、今回は性能管理データを「とにかく簡単に」自動でグラフ化するツールとして、Muninを紹介します。 Muninの特徴 まず製品名ですが、muninと書いて「ムーニン」と読むようです。CPUやメモリ、ネットワークトラフィック、ミドルウェアの性能状況などが取得できます。RPMForgeのリポジトリからyumでインストールでき、導入・設定が非常に簡単。細かな制御ができない部分もありますが、「できるだけ簡単に、ライトに性能グラフを書きたい」「リモー
「クラウド」って言ってみたかった。今は反省していr 上のグラフは前回のエントリーを公開したときの、当blogを配信しているサーバのトラフィックグラフです。記事を公開した17時にぴょーんとトラフィックが伸びています。4時にも増えているけどこちらは謎。 実はこのグラフもCloudForecastを利用して取得しています。CloudForecastはサーバ等のリソース監視を行うツールもしくはフレームワークで、rrdtoolの薄いラッパーとして動作し、小規模から大規模なサーバ群を一括で管理できるように設計してあります。tokuhirom曰く、「perlが書けてrrdtoolがつかえるsysadminの人だったら使いやすいと思われる」というのがもっともしっくりくるような気がします。Perlとrrdtoolが使える運用者によるカスタマイズ前提なのがフレームワークと呼んでいる所以です。 CloudFor
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く