jmx client
zabbixのnative jmx監視が使えない時はzabbix agentのUser Parameters
使えばいいじゃないかという事でコマンドラインで確認できそうな物をいくつか探した。
jmxproxy ※ tomcatのみ
tomcatに入ってるやつ。
curl -s -u<jmxusername>:<jmxpassword> 'http://<tomcat_hostname>/manager/jmxproxy/?qry=java.lang:type=Threading'
まあでもmanagerってあんまり使わない。
何も考えずにそのままtomcatを動かしてしまうと何でも出来ちゃうmanagerが認証無しで使えてしまい、とってもセキュリティ的に脆弱にな状態になってしまうので、managerもろとも削除してしまう事が多いんじゃないかなと思う。
この場合は/manager/jmxproxyだけ残しておけばいいのかも。
Command-line JMX Client
あのinternet archivesがjar形式で提供している。0.10.4は404になってしまうので0.10.3を使ってみたが充分機能した。tomcatのmanagerを削除しているところとかhadoopではこれ使ってる。
http://crawler.archive.org/cmdline-jmxclient/
/<pathTo>/java -jar /<pathTo>/cmdline-jmxclient.jar <jmxusername>:<jmxpassword> <jvmhostname>:<jmxport> java.lang:type=Threading PeakThreadCount
ObjectNameが分からない時は引数なしで実行すると一覧が見れて便利。GUIが使えるならjconsoleでも良い。
/usr/local/java/jdk1.6.0_lastest/bin/java -jar cmdline-jmxclient-0.10.3.jar hage:fuga 192.168.0.1:18080
JMX agentでhadoopのNameNodeから値を取得したときのメモ
hadoop 0.20.3
zabbix 2.0.0
結局はJMXがbindするIPを指定するのが難しくJMX agentとリモートホストの疎通がうまくとれなかったので
別の方法(zabbix agentのuserparameter)でモニタリングしてます。
以下、備忘録として。
事前準備としてhadoopのjmxを有効にしておく。zabbixも--enable-javaでビルドしておく。
zabbixではitemを作っていく事になるが、keyの指定はtypeで「JMX agent」を指定してkeyに
jmx[
を記述する。
object name、attribute nameはjconsoleでjmxに接続してとなんとなく分かる。
attribute nameは「属性」となっていることもある。
以下、keyに入れた値。
- BlocksTotal
jmx["hadoop:service=NameNode,name=FSNamesystemState","BlocksTotal"]
- FilesTotal
jmx["hadoop:service=NameNode,name=FSNamesystemState","FilesTotal"]
- CapacityUsed
jmx["hadoop:service=NameNode,name=FSNamesystemState","CapacityUsed"]
- CapacityRemaining
jmx["hadoop:service=NameNode,name=FSNamesystemState","CapacityRemaining"]
- CapacityTotal
jmx["hadoop:service=NameNode,name=FSNamesystemState","CapacityTotal"]
- NumDeadDataNodes
jmx["hadoop:service=NameNode,name=FSNamesystemState","NumDeadDataNodes"]
- NumLiveDataNodes
jmx["hadoop:service=NameNode,name=FSNamesystemState","NumLiveDataNodes"]
トラブル☆しゅーたーずに行った
2012/4/7(土)13:30
チーム員としてはあまり貢献出来ずすんません。個人的には色々考えるきっかけになって良かったです。
障害対応は緊張感と危機感が相まって気持ちが昂りますしその状態が結構楽しかったりしますが、障害報告はあんまり気乗りしません。これは会場の皆さんだいたい同じだったようで、それぞれの暗い過去が呼び起こされたのか、報告会の場の空気は異常にどんよりしてました。後で思ったのは、この状況に置いても前向きに取り組んでお客さんに価値のある提案ができる人こそが自分自身の価値も示す事になるんだろうなぁとぼんやりと思いました。がんばろう。
# 思った事
- ニフクラの操作と鍵の扱いであたふたしてるうちに勘のいい若者たちが復旧させていた。ハートビーツさんはバイトさんも優秀ですね。
- みんな障害対応好きなんだな。ドMですね。
- 人のせいじゃないんだよね。その人に任せた組織の責任。
- 障害のトリガーをひいた人はむしろ積極的にフィードバックして再発防止に努める事で貢献出来るかもしれない。その可能性を潰すような事はあってはならない。
飲み会懇親会が大変楽しくて2次会まで行ってしまった。技術話も聞けて大変参考になったし刺激になりました。
エンジニアサポート新年会2012 CROSS
ニフティさん主催のエンジニア向け新年会がありましたので言ってきましたメモ。
大変楽しかったですー。プレモルが大変おいしゅうございました。
フロントエンドCROSS『UXのイロイロ』 #cross2012 #cross2012d
感想
- WEBデザイナーはこんな事を考えながら仕事してるのか!って言う気づきがあった。徹底してユーザ目線なんだなーと思ったです。
- 渋谷のめいどりーみん行きたい。
NHN
naverまとめ、line
engeneer x designer の架け橋
デザイナーからみた開発者
開発者からみたデザイナー
お互いがお互いを理解してない
デザイナーはサービスをデザインする、ユーザの事を考える。
ログインページ
簡素に作る。煩わしさをなるべく無くす。
マイページ
がっかりされないようにかなり細かく精緻に作る。かなり気合いれて作る。
誕生日 リサーチの日々 ボーリング
リサーチャーの方、ユーザにグルインとかしてる。
石をもらって嬉しかった話、なぜ石をもらってうれしかったのか?
「どんなサービスを提供すればいいんだろう」
「この人は何を嬉しいと思うんだろう。」
という事を常に考えている。ユーザーの望みを知る。
ボーリングはピンを見て投げてもぶれる。途中の床に書いてあるマークを狙うとうまく当たる。
まとめ
ユーザーの嬉しいや不満を精一杯の関心をもってデザインする。
その他のメモ
デザイナー、エンジニア、みんながユーザを見る
でないとスピードが出ない。
ストーリーシンキング、画面だけじゃない。
戦場ヶ原の稲妻を思い出した。
http://blog.gtroc.com/george/2005/03/post_18.php
どういう風にしたら伝わるかを常に考えている。
質問
Q 限られた予算、スケジュールとどう折り合いをつけているか
Aサービスをどうやって成功させるか?
A猪子さんは極限までいいもの作れと言っている
Aニフティはありもので作るときと、気合入れて作るときがあるみたいなことを言ってた。
年間300-400のサービスがある。全部作らなくてはいけない。
メリハリをきかせているようだ
Tech10 CROSS
こっから先は酔っぱらってあんまり覚えてないッス、、、
mongoとnode.jsとhtml5だったかな、、、
発表方法CROSS
完全に酔いが回っていた、、、とりあえず覚えている事
- 結論よりも変化のきっかけを
- 練り物が好き
- 情熱
いじょ
2012年の抱負
一年の計は元旦にありますから、今日のうちになんとか。インフラエンジニアとしての抱負です。
前提
個人的にはインフラ周辺でパラダイムシフトが起きていて、乗り遅れたら結構ヤバいんじゃないかと危機感を持っています。ちょっと前はサーバリソースが必要となると物理サーバを調達し、3年リースまたは5年程度の償却で使う事が多かったように思います。
しかし今や本番環境でも仮想サーバやパブリッククラウドでサーバリソースを調達する事も珍しく無くなってきました。
ここで従来通りの手作業のオペレーションができるかというと非常に難しいんじゃないかなと思った次第です。
そんな感じでぼんやりと3つ考えました。
- システム管理ツールのスキルを身につける
- クラウド管理ソフトのスキルを身につける
- 非同期処理に対応したwebシステムのスキルを身につける
システム管理ツールのスキルを身につける
個人的にはpuppetやchefなどを想定しています。
必要なのコーディング的な所とDSL、rubyの事もちょっと分からないといけないかなと思います。
あとバージョン管理も必須でしょうからsvnやgit,hgの使い方には慣れ親しんでおきたいところ。
クラウド管理ソフトのスキルを身につける
openstackやwakame、cloudstackあたりの事を言ってます。ベースの環境を作ることは滅多にないかもしれませんが
どちらかというとクライアント側での運用方法が結構変わるんじゃないかなと思ってます。これも手作業は無くなって
APIを利用した運用が主流になるんじゃないかと言う気がします。
非同期処理に対応したwebシステムのスキルを身につける
node.js位しか知らないし使い方もよく分かってないですが、クライアントとサーバ間で
ステートの維持を長時間要求する機会が増えてきて、従来のwebapだとすぐにmax connection
になってしまうと言うような事を何かの雑誌で読んでなるほどと思ったのがきっかけです。たしかSDだったか。
今年の暮れにまた振り返りたいと思います。
第1回品川Redmine勉強会
品川Redmine勉強会にいってきましたメモです。
2011/09/08 19:00-21:00
■発表1 @akippieさん
障害管理(BTS)から課題管理(ITS)に至るお話
バグの管理だけじゃなくて、課題も、要望も管理したい。
情報共有もしたいのでwikiもって感じで
そんな要望からTracやredmineが生まれたんだなーと、理解。
- TiDD
- Ticket First
- No Ticket, No Work
- No Ticket, No Commit
- Tickket Tracking
- 三種の神器
- ITS/SCM/CI
- SCM (Software Configuration Management)
- subversion
- mercurial
- git
- ITS (Issue Tracking System)
- CI (Continuous Integration)
- jenkins氏 (hadson)
■発表2 開発してる人のお話
コミッターの丸山さん
redmine開発の現場は結構しんどそうだった
コミッター不足
コントリビューター不足
らしい
■発表3 @yohhatuさん Redmineの実業務における活用事例紹介
RxTstudy(redmineとタスク管理の勉強会)の紹介も挟みつつ
3つの事例で得た良かった事、悪かった事、悪かった所を改善した事などが聞けて
非常に参考になった。自分の感想に書いた、考えるきっかけになる事が多かったです。
それぞれの事例の状況もあって分かり易かった。
■LT
IPA 大和田さん
ITプロジェクトの見える化ツール
本年度末に公開予定とのこと
@tkusukawaさん インフラ運用の現場での使い方
work_time(工数出る奴)作った方、大変お世話になっております。
- 議事録はwikiに書く
- テンプレートをコピペして使う
- 配布資料は添付できる
- 回覧チェックが入れられる
- 履歴持ってる
- 必要に応じてwatch
- 朝会
- 全員がしゃべる
- メンバーの得手不得手が補える
- work_timeのメモwikiが便利
- 工数集計
- チケット間で工数付け替えができる
「開始日 期日を 日時として、分単位で入れられたらよいなあ」とおっしゃってました。
これ凄く同意!メンテナンスやリリース作業など時間単位でいれてガントチャート表示したら
見通し良くなるんじゃないかなーと思ってました。これだけの為にexcel方眼紙使ってますからorz
自分もpatch(pluginじゃない!)を見た事はあるのですが、弊社のredmine老師に
お願いしてみたがうまく動かなくて断念しました。
これ
http://www.redmine.org/issues/5458
■@haru_iidaさん プラグイン開発者への道
r-labsの管理者でありcode reviewプラグイン作った方。r-labs大変お世話になっております。
アイディアさえ浮かべば、プラグイン作ってみたいかもーって思いました。
■資料
togetterが一番良いかも
資料へのリンクもこちらに集約されてます
http://togetter.com/li/185532
■自分の感想
課題管理・進捗管理を考えるきっかけになった。
自分なりに考えてみたうまくやるための秘訣
・管理側の視点
- マネジャーが介入しすぎない
- マネジャーは草葉の陰からこっそり見守るくらいの心構えがちょうどよい
- 進捗はみんなが入力してくれる
- 気になるものはカスタムクエリで拾えばいいよ
- 入力の妨げになってはいけない
- 細かすぎる規約=めんどくさい=さわらなくなる
- とにかく利用者が気軽に入力できる環境を作ることが重要
・利用者の視点
- チケットは大きすぎない方が良い
- WBS=1チケット、は美味くなかったという例
- 1チケットが大きすぎてなかなか終わらない、80%から進まない
- 1チケットは2−3時間くらいで終わるくらいのボリュームが良い。
- 長くなったら新しくチケット切り分けるとか
- WBS=1チケット、は美味くなかったという例
- チケットは自分でどんどん切ればよい
- 割り当てられたチケットを親として、子チケットを自分で切ってつなげるもよし
- あふれたら他の人に押しつけるなどw
- とにかく入力しようぜ
- ケチつけないから、怒らないから、とにかく、何か、、、残し、て、、、
■TiDDと3種の神器
TiDDはすごく良さそうなんだけど、いかんせん自分が開発メインの
人じゃないので実際のところが分からない。
でも自分が開発を始めるのなら3種の神器そろえてTiDDで
やりたいなあと、うっすら思った。
■気になったプラグイン
-
- code review
- Burndown chart
- work time
- どんだけできるかの物差しとして
- redmine graph activities
- 傾向をみる 金曜のコミットはあぶない、とか