タグ

運用に関するinoshirouのブックマーク (12)

  • 運用を見える化することでDevOpsを前進させよう(後編)~DevOps Day Tokyo 2013

    世界中でDevOpsのムーブメントを広げているイベントDevOps Daysが今年も東京で「DevOps Day Tokyo 2013」として9月28日に都内で開催されました。 (記事は「運用を見える化することでDevOpsを前進させよう(前編)~DevOps Day Tokyo 2013」の続きです) 自分1人で、1台のマシンで1日でデータを公開してみる 今日は「1台、1日、1人」で運用データの公開をしてみるというチャレンジをしたいと思います。 すべてのメトリクスをまとめて、自動的にデータを共有できるようにし、自分は手間がかからないように自動化してみましょう。 使うのはGraphiteというツールです。RRDtoolやGanglia、Cactiなどに似ています。 ドキュメントは貧弱だったりしますが、エコシステムはすばらしいと思います。入出力が簡単で、REST APIで簡単にグラフを作る

    運用を見える化することでDevOpsを前進させよう(後編)~DevOps Day Tokyo 2013
    inoshirou
    inoshirou 2014/08/31
    graphite + statsd こんな感じか
  • 「3分でわかる(気になれる)AWS OpsWorks」のLT資料を公開します - 元RX-7乗りの適当な日々

    Engine Yardさんのオフィスで開催された「初めてのChefの教室」に主催者の@yandoさんからお誘いいただきまして、タイトル通りのLTをしてきました。 いつも運用事例的な話をしているのと、LT(5分)ということもあって、思い切って旬な話題を取り上げようと、公開されたばかりの「AWS OpsWorks」の紹介をしてきました。 駄菓子菓子! 僕の完全な調査不足だったのですが、前段でAWSの中の人がまさかの「AWS OpsWorks」のデモをやってくださったので、おおとりをつとめた僕の発表は、完全にダイジェスト版&デモの補足という笑いの種で終わりましたwすいませんでしたw (質問で普段の運用の話とかもしましたが。昨日の時点でAWS OpsWorksのLTエントリはなかったはずw) 3分でわかる(気になれる) AWS OpsWorks from Yuuki Namikawa 一昨日に2時

    「3分でわかる(気になれる)AWS OpsWorks」のLT資料を公開します - 元RX-7乗りの適当な日々
  • AWS News Blog

    Add your Ruby gems to AWS CodeArtifact Ruby developers can now use AWS CodeArtifact to securely store and retrieve their gems. CodeArtifact integrates with standard developer tools like gem and bundler. Applications often use numerous packages to speed up development by providing reusable code for common tasks like network access, cryptography, or data manipulation. Developers also embed SDKs–such

  • RHEL6のマルチキューで効率的なネットワークの付加分散

    TechCenterから移行されたテクニカル リソース 2018年8月時点で、アクティブなTechCenterのコンテンツが移行され、Dell.com のDellサポートの一部になり、フォーラムがDellコミュニティに移行されました。 概要: 2018年8月時点で、アクティブなTechCenterのコンテンツが移行され、Dell.com のDellサポートの一部になり、フォーラムがDellコミュニティに移行されました。

  • Fluentdで始めるリアルタイムでのログ有効活用

    はじめに Fluentdは、ログを収集し格納するためのログ収集基盤ソフトウェアです。Fluentdにインプットされた、すべてのログをJSONに変換し、アウトプットします。インプットとアウトプットはモジュール化されており、モジュールを追加することでインプット元とアウトプット先を追加できるようになっています。 Fluentdは急速に知名度を高め、多くのWebサービス会社で実際に使用されるようになりました。従来のログが抱えていた問題も、Fluentdが適切な解決策となっていると認知され、かつ簡単に導入・スモールスタートできるミドルウェアであったことが大きかったと思います。 稿では、Fluentdの簡単な仕組みと導入方法、シンプルな動作事例について紹介します。 対象読者 システム管理者 データサイエンティスト 必要な環境 UNIX系OS Ruby 1.9 ログを出力する理由 システム運用を始める

    Fluentdで始めるリアルタイムでのログ有効活用
  • @ITイベントカレンダー

    平素よりイベントカレンダー+ログをご利用いただき、誠にありがとうございます。 イベントカレンダー+ログは「IT・製造業・ビジネス関係のイベント(セミナー・展示会・勉強会・コンテスト・Webイベントなど)を開催する企業・コミュニティが登録したイベント情報のポータルサイト」として約7年間運営をしてきました。これまでサービスを続けることができたのは、イベントカレンダー+ログのコンセプトに共感をいただき、適切なイベント情報をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、イベント情報の入手方法の多様化やイベント紹介サービス市場の状況、@ITの今後のメディア運営方針などを検討した結果、2020年6月30日(火)15:00をもちましてイベントカレンダー+ログのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知ら

    @ITイベントカレンダー
  • Labeled Tab Separated Values (LTSV) ノススメ - stanaka's blog

    追記(2/8 11:30) id:naoyaによる一連のまとめが【今北産業】3分で分かるLTSV業界のまとめ【LTSV】 - naoyaのはてなダイアリーにあります。 また、仕様などをまとめるために http://ltsv.org/ を立ち上げました。 追記ここまで Labeled Tab Separated Values (LTSV) というのは、はてなで使っているログフォーマットのことで、広く使われているTSV(Tab Separated Value)フォーマットにラベルを付けて扱い易くしたものです。はてなでは、もう3年以上、このフォーマットでログを残していて、one-linerからfluentd、Apache Hiveまで幅広く便利に使えています。 ログフォーマットに期待されることは、 フォーマットが統一されている → 共通のツールで集計し易い 新しいフィールドの追加が容易 → サー

    Labeled Tab Separated Values (LTSV) ノススメ - stanaka's blog
  • 特定のサーバを踏み台にして別のsshサーバに接続する (ProxyCommand) | maeda.log

    2010-01-21 23:08 | tag: linux インターネット上のサーバのsshdの設定で、接続できるホストIPアドレスを限定するという運用は多いと思います。このような運用を行っている場合、目的のサーバに接続するためには、以下のように一旦プロキシ(踏み台)サーバに接続して、あらためて目的のサーバに接続するという操作となり、やや煩雑です。 ■概念図 |クライアント| --(ssh)--> |プロキシサーバ| --(ssh)--> |目的のサーバ| ■手順 1. クライアントからプロキシサーバに対してsshで接続、ログイン。 (user_proxyはプロキシサーバ上のユーザー) $ ssh user_proxy@proxy.example.jp 2. プロキシサーバからクライアントに対してsshで接続、ログイン。 (user_destは目的のサーバ上のユーザー) $ ssh us

  • Webアプリケーションのログレベルについて考える - Beautiful World

    Java開発の次のデファクトになると思われるSLF4Jのログレベルの説明を見てみます。 * FATAL - アプリケーションを異常終了させるような非常に深刻なイベントを指定します。 * ERROR - アプリケーションの稼働が継続できる程度のエラーを指定します。 * WARN - 潜在的に害を及ぼすような状況を指定します。 * INFO - アプリケーションの進捗の概要が分かるメッセージを指定します。 * DEBUG - アプリケーションをデバッグすのに役立つ詳細なイベント情報を指定します。 * TRACE - DEBUGより詳細なイベント情報を指定します。 エラーに関するログレベルとそれ以外で分けてみます。 * エラーに関するログレベル - FATAL、ERROR、WARN * それ以外 - INFO、DEBUG、TRACE 次に、トランザクションごと、WEBアプリケーションでいうとアク

    Webアプリケーションのログレベルについて考える - Beautiful World
  • はてなブログ | 無料ブログを作成しよう

    うまくいかない日に仕込むラペ 「あぁ、今日のわたしダメダメだ…」 そういう日は何かで取り返したくなる。長々と夜更かししてを読んだり、刺繍をしたり…日中の自分のミスを取り戻すが如く、意味のあることをしたくなるのです。 うまくいかなかった日のわたしの最近のリベンジ方法。美味しいラペを…

    はてなブログ | 無料ブログを作成しよう
  • うさぎとSEのブログ: ログに対する認識の甘さ

    ソフトウェアを開発する方ならば、多くの方はログをプログラムから出力しているかと思います。 ログは例えばリリースした後に客先で動作しないなどの何らかの不具合が発生した際に、原因等を探るとても重要な情報源です。そのため、ログを適切に出力、保存されなければ、そのログはただ要領が大きいだけのゴミにしかなりません。 ただ、ログを出力するということは、 1. 何を出力するべきなのか? 2. いつ、だれが、何に利用するのか? 3. いつ出力するのか? 4. 何を出力してはいけないのか? 等を考えながら出力している方は少ないように思います。 ログを出力するときに、ログに対してもみなさんは設計書を作成していますか? ばかばかしい、ログなんてメインの業務処理から考えればオプションのような位置づけだと思うかもしれません。 ですが、ログ出力を正しく行わないと、私の周りでは、今までこういった問題が発生してきました。

  • 1