vmstat 1 | perl -MPOSIX -pe 'BEGIN{$|=1} print strftime q{%Y/%m/%d %H:%M:%S }, localtime'perlがないなら。 vmstat 1 | while read line; do echo `date +%H:%M:%S` $line; done
主に新人向けとして、Unixサーバで作業をする際の注意点を書いておく。 ここに書いてある内容は絶対的なものではないし、会社や現場ごとにルールがあるので、適宜ルールに合わせて実践すれば良い。 ログを取れ 何をやったか、何をやらなかったか、というエビデンスのためにログは必ず残しておく。SSHクライアントによっては毎回自動的にログ取得する設定が可能なので、設定しておくと良いだろう。 作業後に問題が発生した場合に作業内容を確認するためにも使うため、必ずログは取得しておくこと。 (追記) 当たり前だが、コマンドとその出力をペアで取ることに意味がある。 set -x (set verbose) しろ ログを取得しても、コマンドラインを編集した際には以下のように非常に見づらいものとなってしまう。(がんばれば解析することは出来るが…) ESC[0mESC[27mESC[24mESC[JESC[1myasu
さあ、始めよう オープンソースプロダクトのメッセージを検索できます。あなたが使用しているソフトウェアのエラーメッセージの対処方法が分かります。 調査して欲しいメッセージ 153(ja) [4] Debug: sleeping function called from invalid context at : [1 month ago] 84(ja) [3] request_module: runaway loop modprobe [21 days ago] 5356(ja) [3] : VFS is out of sync with lock manager! [1 month ago] 22473(ja) [3] : dma_timer_expiry: dma status == 0x [3 months ago] 13057(ja) [3] tty_check_change: tty
比較的大きいサイズのファイルをSCPで転送することがあって、できるだけ高速化してみたかったので、色々試してみたメモ。 scpというかsshには、暗号化方式と圧縮有無の指定があるので、それらのベンチマークを。 尚、以下は、SSH v2が対象です。v1はかなり遅かったのと、そもそも使っていないので試していません。 (追記: 2019/11) 本エントリの情報は既に古いため、以下のエントリにて再検証しています。あわせてご覧くださいませ。 ベンチマークで利用した環境 [Server1] <=> [Gigabit Switching Hub] <=> [Server2] Server1 (HP ML115 G5) AMD Phenom 9950, 8GB, RAMディスク使用, Gigabit Ethernet Server2 (HP ML115 G1) AMD Opteron 1210, 4GB,
はじめに 最終回にあたり、iptablesを便利に使うTipsを紹介します。iptablesを1つ1つコマンドラインで実行するのは大変面倒です。そうした煩わしさを軽減できる設定や、実際の運用の手助けになるような工夫を紹介します。 関連リンク： →Linuxで作るファイアウォール［パケットフィルタリング設定編］http://www.atmarkit.co.jp/flinux/rensai/security05/security05a.html →連載記事 「習うより慣れろ！ iptablesテンプレート集」http://www.atmarkit.co.jp/flinux/index/indexfiles/iptablesindex.html →連載記事 「習うより慣れろ！ iptablesテンプレート集 改訂版」http://www.atmarkit.co.jp/flinux/index/i
OutOfMemoryErrorが発生してもスレッドを異空間に葬るだけでJava VMはそのまま動き続ける場合があるけど、当然ながら状態に一貫性のない状態で動いている可能性があるわけで基本的にはとっとと死んで欲しいわけである。一般的に言うところの「不定」状態。OOMEはErrorであってふつうの例外ではなく、致命的なJava VMエラーを示すものである。OOME発生後にプロセス再起動しないでそのままどうこうしようというのは絶対に避けた方が良い。 例えばJDBCのコネクションオープンしてDBからデータを読み込んでるときにOOMEが起きた場合、JDBCコネクションは大抵オープンしっぱなしで回収はされなかったりする。OOMEではfinallyブロックが呼ばれる保証はない。JDBCコネクションリークくらいならまだ良い方だが、これは全てに当てはまる。A-B-Cといったセットになっている処理は例外など
※ CPU を食いつぶしてタスクマネージャが動かない場合のことじゃありません。タスクマネージャの表示する情報だけでは問題解決に役に立たない場合のことです。 タスクマネージャは Windows を管理するうえで最も基本的なツールの一つだと思うんだけど、これ、結構役に立たないことが多い。プロセスという考え方が Un*x と違うからなのか、結局誰が悪さしてるのかが分からないケースが以前より増えているような気がする。1 ということで困ったなと思っていたら以下のようなツールがあることを知った。いやはや、もう Windows のことは分からなくなってきたなぁ。まぁ一人でなんでもできるわけはなく、どこかに力を入れればどこかはもうついていけなくなって当然なんだけど。 話がそれた。 tasklistWindows XP 以降、標準で使えるコマンドラインツール。 ＠IT：Windows TIPS – Know
昨日、hbstudy#8 で話をする機会をいただくことができたので、Nagios や Amanda といった既製品の管理ツールやバックアップツールを使わずに内製したことで「パストラック」の運用コストを下げた、という話をしてきました。 もちろん、「既製品を使わない」というのもひとつの手段にすぎませんから、それを無闇にお勧めするつもりはありません。ただ、小回りの効くツールを組み合わせる手法にも十分な競争力があるという点、あるいはその事例として参考になれば幸いです。 スライドはこちら。hbstudy 運営の皆様、話を聞いてくださった皆様、ありがとうございました。
監視とは継続的なテストである、という話 (もしくは cronlog とテストスクリプトを組み合わせた監視手法について)に続きます 今日ようやく、積ん読状態だった「Software Design 2010年1月号」を手に取ったのですが、特集が「今日から使えるスクリプト満載！ [プロ直伝]お手軽サーバ監視術」。興味深く拝読したのですが、もっと楽ができるのにと思うところも。ちょうど、昨年末に運用しているサービス「パストラック」のサーバを移転し、crontab と perl で書かれたスクリプト群を使った監視環境を構築したところなので、そこで使っているスクリプト cronlog を紹介したいと思います。 特集の前書きにも書かれていることですが、サーバやネットワーク機器が多数ある環境なら、Nagios を始めとする、専ら監視のために作られたソフトウェアを使って、監視システムを構築すべきです。逆に小規
cles::blog 平常心是道 blogs: cles::blog NP_cles() « 著作権はいつから70年が世界標準になったのか :: 家の電話が壊れた » 2009/11/24 再起動時に一度だけ実行されるcron定義 linux 425 4へぇ 先日のcrontab -r とやってしまった時の対処法のアクセスが意外と多くてかなり驚きました。ちなみに僕はクーロンと読む派です。それはそうと、これを機にちゃんとcrontabのmanを読んでみたら、日次の定義に@rebootと書くと再起動時に一度だけ実行されるcron定義がかける事が判明。CentOS 5.3では、日本語のmanにはこの部分が記載されていませんでした。 $ man 5 crontab These special time specification "nicknames" are supported, which
This page provides status information on the services that are part of Google Workspace. Check back here to view the current status of the services listed below. If you are experiencing an issue not listed here, please contact Support. Learn more about what's posted on the dashboard in this FAQ. For additional information on these services, please visit https://workspace.google.com/. For incidents
sudoの環境変数の扱い方が最近になって変わっていることに気付いた。最近といっても一〜二年はたっているかもしれない。 sudoを介してコマンド実行するとき、あらかじめ決められた環境変数以外は消し去されてしまう。このためたとえば次のようなコマンド実行は意図通りには動かない。 $ GEM_HOME=/tmp/GEM sudo gem install rails 従来、このようなときにはenvを使って回避というのが一つのやり方だったように思う。もちろんsudoersでenvの実行が許可されていなければならない。 $ sudo env GEM_HOME=/tmp/GEM gem install rails sudo 1.6.9以降になると以下のような記述が可能となり、わざわざenvを使う必要がなくなった(バージョンは多少違うかもしれないが、少なくともDebian/etchの1.6.8p1
仕事でLinuxサーバのリソースを測定する事がありますが、プロセス毎のCPU使用率やメモリ使用率を取得するためにtopで測定を行っています。プロセス毎のリソース測定はpsでも可能ですが、CPU使用率の値が怪しく、topの方が信頼できそうなのです。SolarisとLinuxではpsの結果が違うっぽい。 さて、topの実行結果は、これまで以下のようにbshスクリプト内で設定して取得していました。 top -d 1 -n 1 > hoge.txt 2>&1この出力ファイルを整形してExcelでグラフにしたりするわけです。 しかしこのスクリプトを実行するとデータは取れるものの、 (standard_in) 1: parse error (standard_in) 1: parse errorというエラーが出力され気持ち悪い結果になっていました。 また、linuxカーネルによっては同梱されているto
logrotateは、Apacheのアクセスログや、syslogなど運用の中で肥大化していくログファイルを定期的に退避してくれるツールです。 logrotateの設定は、/etc/logrotate.confファイルにて全てのログファイルに対しての設定を、/etc/logrotate.d/ディレクトリ以下に個別のログファイルごとの設定を記載して管理します。 ※ /etc/logrotated/ディレクトリ以下の個別の設定ファイルに記載した内容は、logrotate.confファイルに設定した内容より 優先度が高くなります。 - /etc/logrotate.confの設定例 # see "man logrotate" for details # rotate log files weekly weekly # keep 4 weeks worth of backlogs rotate 10
crontabファイル含め、設定ファイルはレポジトリで管理しましょうという話です。 恐怖のcrontab -r crontab -r を安全にする - antipop 間違えて crontab -r してしまい、crontab をふっとばしてしまったので、以下のような zsh 関数を書いて、確認を出すようにした。つか、隣同士にある -e と -r で編集と削除とか、酷いよ＞＜。。。 cronのにジョブを登録する際に、crontabファイルを開きますが、「crontab -e」と間違って「crontab -r」をやると、crontabが消えてしまう。しかも、記事の内容にある通り、「e」と「r」というタイポしてもおかしくない位置にあるというので、これは怖い。 crontabの内容なんてほとんど覚えてない割にはちょくちょく更新するファイル。バックアップとかとってないと大変なことになる。 ytoy
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、ショッピング事業部開発部の吉野と申します。 今回は「アプリケーションログの設計と監視」について、実際にYahoo!ショッピングで採用している方法を少し交えながらお話しさせていただきます。 1.ログ設計のポイント ログ設計は、以下のポイントに注意して行うとよいでしょう。 ・ログ出力のポイントが押さえられているか ⇒セッションの始まりと終わり、処理の過程、例外処理の中など。 フローチャートのような処理フロー図があれば、そこにログ出力ポイントを書き込むとわかりやすくなります。 ・出力する情報に過不足はないか ⇒「いつ(システム時間)」「だれが(プロセスID・IPアドレスなど)」 「どこで(パスなど)」「なにをした(実行コマン
# 運用オペレーションの実務を経験された方は身に染みて分かっているし、 # それぞれのノウハウもあると思うけど、ジブンが経験したことを踏まえ、 # 自戒の念を込めて書いてみる。 本番運用中にもしも障害を起こしたら、その後始末はとても大変です。 関係各所へ連絡をして原因や影響範囲を調べ、障害報告書を書いて…あぁおそろしや。 ですから、本番運用でのオペレーションはできる限り慎重にし、手間をかけるべきです。 手間をかけても障害を起こした後の大変さに比べれば大したものではありません。 (ただ、障害発生後の後始末を通して得られる経験値は高く、さまざまなノウハウや文書作成能力の向上などは特典といえるかもしれません。;-) とはいえ、やはり障害は対外的な信用を低下させ、モチベーションも下がるので起こしたくないもの。 そこで、実際に(運用オペレーション時における)障害を防止するためにはどういう
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
