GREE Tech Conference 2021 で発表された資料です。 https://techcon.gree.jp/2021/session/Session-3
![grasysの仕組み解説](https://cdn-ak-scissors.b.st-hatena.com/image/square/5446057bb2ccb5c134567c1df311a8842192162f/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fgrasys-150202012658-conversion-gate01-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
Perlの開発者であるLarry Wall氏が、ブリュッセルで開催中のオープンソース開発者カンファレンス「FOSDEM」において、2月1日(現地時間)に、同氏が2015年に61歳の誕生日を迎えることを明らかにするとともに、Perl 6.0のバージョン1.0を2015年のクリスマスにリリースすると発言した。 Perlは現在、最新バージョンであるPerl 5系列と、開発中のPerl 6系列に分岐しており、Perl 6の開発は2000年のスタート以来、難航している。なお、Perl 6では言語仕様の大幅な変更が行われており、Perl 4やPerl 5との後方互換性が失われる。 今回のLarry Wall氏の発言について、Perl開発者の中には懐疑的な見方もあり、今回の発言によって、2015年のクリスマスにPerl 6のバージョン1.0が確実にリリースされるわけではないが、バージョン1.0について語
https://developers.soundcloud.com/blog/prometheus-monitoring-at-soundcloud 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 Prometheusは、SoundCloudが中心となって開発を進めているオープンソースのプロジェクト。Dockerの社内でもメインのモニタリングシステムとして利用されているようです。 各社のブログのエントリーから、その特徴をまとめると。 多元データモデルとそれを活かす柔軟なクエリ言語 全てのデータにタイムスタンプのある、OpenTSDBに準じたデータモデル。 http_response_500_totalやhttp_response_403_totalなどHTTPレスポンスのステータスごとに用意しなくても
前のブログの続きで、もにかじ7で話した小ネタその2。 実際にサービスでなんかやったというのじゃなく、こういうこと考えてるんだけどみんなどうしてます?って話です。 まずオンプレ時代はサーバのスペックダウンはけっこう大変だったし、頑張ってメモリやCPU引っこ抜いてもそんなに節約にならなかった。 ※CPUやメモリはサーバ価格の一部でしかないし、ラック費用(消費電力)もあるし。 でもクラウド前提だとスペックダウンはとても簡単で、スペック半分にすると価格も半分になる。 そうすると、 『イベントで一時的にc4.4xlarge(8万/月)にして、そのまま最大CPU使用率10%とかで数ヶ月放置されている』 みたいなのはビジネス的な損失という意味で明らかに障害で、監視すべきじゃないだろうか? みんななんかやってますか? というようなことを参加者に聞いてみました。 参加者の中では、AutoScalingしてい
昨日、Monitoring Casual Talks #7に参加してきました。 もにかじは2年ぶりに参加したのでまず感想 2年前はサーバ監視はだいたいZabbixかnagios+muninのどっちかだったけど、今回はDataDog、Mackerel、PagerDutyみたいな外部サービス使ってますって事例が多かった。 そしてPacker+AutoScaling、Docker、ConsolやSensuみたいなものを使って、動的に変化するインフラをどう管理していくかという議論が多かった。 この辺りはみんな絶賛試行錯誤中でぜんぜん話まとまらないんだけど、いろんな技術や考え方がバンバン出てカオスってて面白い。 長いことぜんぜん追えてなかったので、いろいろ話が聞けて良かった。 そして若い人が増えたなー。平均年齢すんごい下がってる。クラウド化と並行してこの傾向も進んでいきそう。 自分はというと、こうい
Monitoring Casual #7に参加し、「30days Albumの裏側〜監視・インフラCI事情〜」というタイトルで発表しました。 主に監視周りの話で、ふっつーにNagios・Muninを使ってるんですけど、Muninについてはちょっと変わってるのでそれの紹介。 あと、インフラCIは、モニカジに間に合わせようと奮闘してたんですが間に合わなかったので、出来たところまでを紹介する感じになってます。 発表中にいただいた意見・コメント munin muninが黒背景になってる理由を説明している時の様子。 (導入した本人である)黒田さんに変わって、背景を黒くした中二ムニンの紹介をしてました。 Kibanaみたいな色にしたい #monitoringcasual — Taichi Nakashima ☕️ (@deeeet) 2015, 1月 30 魔改造muninだ… #monitoring
All slide content and descriptions are owned by their creators.
最近悩んでいることを解決する小さいアプリケーションを書いたので、monitoring casual talks #7 で発表してきました。 モニカジは毎回全員発表で濃い話がいろいろできて楽しいですね! Consul KV Dashboard // Speaker Deck GitHub - fujiwara/consul-kv-dashboard: Consul KVS based dashboard web application. 概要はスライドにありますが、Consul KVS に保存された値をいい感じにまとめて(リアルタイム更新で)見せることのできる、Go + React.js でできた小さな Web application です。 ConsulのREST APIに値を送る(curlで十分)だけで、現在の各ホストで発生した値を画面でリアルタイムに更新しつつ閲覧できます。 Consu
http://monkey.org/~marius/checklist.pdf 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 TwitterのMarius Eriksenは分散システムのエキスパートであり、モジュール化され、安全でかつ効率よく機能するサーバソフトの構築のノウハウは、「Your Server as a Function」という論文にまとめられています。 また、分散システム設計における留意点も、下記の内容のチェックリストというかたちで紹介してくれています。 1. 障害耐性 もし依存先が障害を起こしたらどうなるか?その障害がゆっくりと起きたらどうか? システムをどのようにスムーズにデグレードさせることができるか? システムは想定以上の負荷にどう対処するようになっているか? 大きな障害が起き
"reptyr PID" will grab the process with id PID and attach it to your current terminal. After attaching, the process will take input from and write output to the new terminal, including ^C and ^Z. (Unfortunately, if you background it, you will still have to run "bg" or "fg" in the old terminal. This is likely impossible to fix in a reasonable way without patching your shell.) Typical usage pattern
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く