Sumo Logicを出展～Japan IT Week 秋

  • On 2021年11月10日
Digital Stacks（本社東京都品川区）は、10月27日～29日まで幕張メッセで 開催された「Japan IT Week 秋」（主催：RX Japan）の「システム運用自動化展」に、マルチクラウドやハイブリッドに対応したログ収集・分析ツールである「Sumo Logic」を出展しました。 Sumo Logicはあらゆるプラットフォームから収集したログのリアルタイム分析・管理、セキュリティ監視を実現するプラットフォームです。当日の弊社ブースには、DXに備えたマルチクラウド・ハイブリッド環境でのセキュリティに強い危機感をお持ちの、金融や公共機関を含むたくさんのお客様が、多数来訪されました。短いお時間でしたが、弊社からはSumo Logicのコンセプトと同時に出展していたPagerDutyやRundeckといったインシデント対応ツールとの連携についてご説明させていただきました。さらなるご説明を要望されたお客様には個別にコンタクトさせていただき詳細をお伝えいたします。 （弊社Facebookページで当日の写真をごらんいただけます。）https://www.facebook.com/DigitalStacksCorporation なお、Digital StacksではSumo Logicの導入の操作を解説した「Sumo Logic スタートガイドブック」を無料プレゼント中です。ご興味のある方はぜひご覧ください。Sumo Logic スタートガイドブックhttps://sumologic.dxable.com/readme-japan-it-week-autumn-2021 ■Sumo Logic:総合ログ管理の自動化オンプレミス＆マルチクラウド対応で各拠点からのログ収集を自動化し、イベントとログの相関分析の結果をダッシュボードに表示します。面倒な収集と分析を自動化することでデータ駆動型の意思決定が可能になり、セキュリティへの脅威や障害を迅速にとらえることができます。既にSIEM（Security information and event management）の要として国内外で2100社を超える企業が採用しています。 Digital Stacksでは、このほかにも企業の方のデジタルトランスフォームを支援する製品・サービスを取り扱っておりますので、ぜひこの機会に海外の新しいテクノロジーにご興味をお持ちの方は弊社までお問い合わせください。 ■展示会情報名称：第12回 Japan IT Week 秋会期：2021年10月27日（水）～29日（金）会場：幕張メッセ主催：RX Japan株式会社 (旧社名: リード エグジビション ジャパン)公式HP：https://www.japan-it-autumn.jp/ja-jp.html ■株式会社Digital Stacksについて株式会社Digital Stacksは、欧米を中心とした世界の最新クラウドテクノロジー製品をいち早く発掘して日本国内の法人のお客様に提供しています。全ての企業と企業人のデジタルトランスフォーメーションの加速をサポートし続けます。 本社所在地: 〒141-0001　東京都品川区北品川5-5-15 大崎ブライトコア4階SHIP 414号室代表取締役CEO: 島田憲治事業開始: 1995年3月URL： https://www.digitalstacks.net/ 本リリースに関するお問い合わせは広報担当：内海彩加 info@digitalstacks.netまでご連絡ください。
Read More

分散システムでのログ収集と分析を自動化するSumo LogicをJapan IT Week秋に出展

  • On 2021年10月22日
Digital Stacks（本社東京都品川区）は、10月27日～29日まで幕張メッセで 開催される「Japan IT Week 秋」の「システム運用自動化展」において、分散システムのログ収集・分析を自動化する Sumo Logicなどを出展します。 当社のブースにお立ち寄りいただくだけで、新世代のソフトウェア開発・運用監視・障害対応・各種業務の自動化ツールとプラットフォームについての情報を得られます。また、来場者限定で、各製品のスタートガイドブックなどを無料でプレゼントいたします。是非ご来場ください。 Sumo Logic:総合ログ管理の自動化オンプレミス＆マルチクラウド対応で各拠点からのログ収集を自動化し、イベントとログの相関分析結果をダッシュボードに表示します。面倒な収集と分析を自動化することでセキュリティへの脅威や障害を迅速にとらえることができます。SIEMの要として国内外の企業に広く使われています。 ■展示会情報『Japan IT Week 秋』（10月27日～29日、幕張メッセ） は日本最大のIT展示会です。今回も400社が出展する予定であり、ITの各分野を幅広く網羅して開催することで、ビジネス拡大を求める出展社、来場者にとって欠かせない展示会となっています。出展ブースでは製品・サービスの販売・受注、課題についての相談、見積り・導入時期の打合せなどが行われ、“実質的な商談の場”となっています。 名称：第12回 Japan IT Week 秋会期：2021年10月27日（水）～29日（金）時間：10:00～17:00会場：幕張メッセ主催：RX Japan株式会社 (旧社名: リード エグジビション ジャパン) 公式HP：https://www.japan-it-autumn.jp/ja-jp.html 入場には招待券が必要です。（招待券をお持ちでない場合、入場料￥5,000/人）弊社から無料の招待券をお配りしていますので、下記URLよりダウンロードしてご利用ください。 e招待券URLhttps://www.japan-it-autumn.jp/ja-jp/exhibit/ex_e_inv/aso.html?co=ml_aso-a-56spqg ■株式会社Digital Stacksについて株式会社Digital Stacksは、欧米を中心とした世界の最新クラウドテクノロジー製品をいち早く発掘して日本国内の法人のお客様に提供しています。全ての企業と企業人のデジタルトランスフォーメーションの加速をサポートし続けます。 本社所在地: 〒141-0001　東京都品川区北品川5-5-15 大崎ブライトコア4階SHIP 414号室代表取締役CEO: 島田憲治事業開始: 1995年3月URL： https://www.digitalstacks.net/ 本リリースに関するお問い合わせは広報担当：内海彩加 info@digitalstacks.netまでご連絡ください。
Read More

Kubernetesとは

  • On 2020年10月5日
Dockerとは Dockerは、ソフトウェアコンテナのコンテナ化プラットフォームとして知られているオープンソースの仮想化テクノロジーです。コンテナは、独自のファイルシステムを含むアプリケーションを単一の複製可能なパッケージに含める手段を提供します。 2013年にソロモン・ハイクスによって開始されたDockerプラットフォームは、Linuxオペレーティングシステム用に特別に構築され、それ以来、コンテナの作成とデプロイを簡素化、自動化できることから、開発者とクラウドサービスプロバイダーの間で広く普及しています。 コンテナテクノロジーを使用すると、アプリケーションとそのすべての依存関係を標準化されたユニットにパッケージ化できるため、コンテナはすぐに仮想化の推奨アプローチになりつつあります。Dockerによる自動化は、その成功に不可欠です。 Dockerコンテナ コンテナは新しいテクノロジーではありません。仮想マシン（VM）と同様に、これらは何年も前から存在している仮想化の形式です。ただし、VMとは異なる点は、フットプリントのサイズです。 VMは仮想オペレーティングシステム全体を作成しますが、コンテナはアプリの実行に必要で、まだホストコンピュータで実行されていないファイルのみを持ち込みます。実行しているシステムのカーネルを共有することで無駄を省き、可能な場合はアプリ間の依存関係も共有します。つまり、パフォーマンスがよりスムーズになり、アプリケーションのサイズが小さくなり、デプロイメントがより速くなります。 Docker Engine Dockerコンテナは効率を提供するコンポーネントであり、Docker Engineはそれを可能にするものです。Dockerコンテナはイメージファイルから実行されます。これは基本的に、特定のオペレーティングシステムで特定のアプリケーションを実行するために作成されるファイルです。Docker Engineはそのイメージファイルを使用してコンテナを構築し、実行します。 軽量のDockerエンジンとそれが提供する簡単な自動化こそが、Dockerを成功したツールにした真の革新的ツールです。コンテナのデプロイを自動化する機能は、Dockerが一躍脚光を浴びるようになった理由です。仮想化環境におけるスケーラビリティの向上という利点を提供し、ビルドとテストの高速化を可能にします。 DockerはDevOps環境にどのように貢献するか DevOpsチームは、Dockerを使用することで多くの利点を得ます。OSリソースの即時起動と信頼性の向上により、このプラットフォームはアジャイル開発の高速な反復に最適です。開発環境は、同じバイナリと言語ランタイムを使用して、チーム全体で一貫しています。 コンテナ化されたアプリケーションはシステム全体でリソースの使用と環境が一貫しているため、DevOpsエンジニアは本番環境でも自分のマシンと同じようにアプリが動作することを確信することができます。また、Dockerコンテナはコンパイルの問題を解決し、開発プロセスにおける複数の言語バージョンの使用を簡素化するのにも役立ちます。 本記事は米国Sumo Logic社のサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
Read More
  • Dockerとは Dockerは、ソフトウェアコンテナのコンテナ化プラットフォームとして知られているオープンソースの仮想化テクノロジーです。コンテナは、独自のファイルシステムを含むアプリケーションを単一の複製可能なパッケージに含める手段を提供します。 2013年にソロモン・ハイクスによって開始されたDockerプラットフォームは、Linuxオペレーティングシステム用に特別に構築され、それ以来、コンテナの作成とデプロイを簡素化、自動化できることから、開発者とクラウドサービスプロバイダーの間で広く普及しています。 コンテナテクノロジーを使用すると、アプリケーションとそのすべての依存関係を標準化されたユニットにパッケージ化できるため、コンテナはすぐに仮想化の推奨アプローチになりつつあります。Dockerによる自動化は、その成功に不可欠です。

    Dockerコンテナ

    コンテナは新しいテクノロジーではありません。仮想マシン（VM）と同様に、これらは何年も前から存在している仮想化の形式です。ただし、VMとは異なる点は、フットプリントのサイズです。 VMは仮想オペレーティングシステム全体を作成しますが、コンテナはアプリの実行に必要で、まだホストコンピュータで実行されていないファイルのみを持ち込みます。実行しているシステムのカーネルを共有することで無駄を省き、可能な場合はアプリ間の依存関係も共有します。つまり、パフォーマンスがよりスムーズになり、アプリケーションのサイズが小さくなり、デプロイメントがより速くなります。

    Docker Engine

    Dockerコンテナは効率を提供するコンポーネントであり、Docker Engineはそれを可能にするものです。Dockerコンテナはイメージファイルから実行されます。これは基本的に、特定のオペレーティングシステムで特定のアプリケーションを実行するために作成されるファイルです。Docker Engineはそのイメージファイルを使用してコンテナを構築し、実行します。 軽量のDockerエンジンとそれが提供する簡単な自動化こそが、Dockerを成功したツールにした真の革新的ツールです。コンテナのデプロイを自動化する機能は、Dockerが一躍脚光を浴びるようになった理由です。仮想化環境におけるスケーラビリティの向上という利点を提供し、ビルドとテストの高速化を可能にします。

    DockerはDevOps環境にどのように貢献するか

    DevOpsチームは、Dockerを使用することで多くの利点を得ます。OSリソースの即時起動と信頼性の向上により、このプラットフォームはアジャイル開発の高速な反復に最適です。開発環境は、同じバイナリと言語ランタイムを使用して、チーム全体で一貫しています。 コンテナ化されたアプリケーションはシステム全体でリソースの使用と環境が一貫しているため、DevOpsエンジニアは本番環境でも自分のマシンと同じようにアプリが動作することを確信することができます。また、Dockerコンテナはコンパイルの問題を解決し、開発プロセスにおける複数の言語バージョンの使用を簡素化するのにも役立ちます。 本記事は米国Sumo Logic社のサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。" target="_blank">

Dockerとは

  • On 2020年10月5日
Dockerは、ソフトウェアコンテナのコンテナ化プラットフォームとして知られているオープンソースの仮想化テクノロジーです。コンテナは、独自のファイルシステムを含むアプリケーションを単一の複製可能なパッケージに含める手段を提供します。 2013年にソロモン・ハイクスによって開始されたDockerプラットフォームは、Linuxオペレーティングシステム用に特別に構築され、それ以来、コンテナの作成とデプロイを簡素化、自動化できることから、開発者とクラウドサービスプロバイダーの間で広く普及しています。 コンテナテクノロジーを使用すると、アプリケーションとそのすべての依存関係を標準化されたユニットにパッケージ化できるため、コンテナはすぐに仮想化の推奨アプローチになりつつあります。Dockerによる自動化は、その成功に不可欠です。 Dockerコンテナ コンテナは新しいテクノロジーではありません。仮想マシン（VM）と同様に、これらは何年も前から存在している仮想化の形式です。ただし、VMとは異なる点は、フットプリントのサイズです。 VMは仮想オペレーティングシステム全体を作成しますが、コンテナはアプリの実行に必要で、まだホストコンピュータで実行されていないファイルのみを持ち込みます。実行しているシステムのカーネルを共有することで無駄を省き、可能な場合はアプリ間の依存関係も共有します。つまり、パフォーマンスがよりスムーズになり、アプリケーションのサイズが小さくなり、デプロイメントがより速くなります。 Docker Engine Dockerコンテナは効率を提供するコンポーネントであり、Docker Engineはそれを可能にするものです。Dockerコンテナはイメージファイルから実行されます。これは基本的に、特定のオペレーティングシステムで特定のアプリケーションを実行するために作成されるファイルです。Docker Engineはそのイメージファイルを使用してコンテナを構築し、実行します。 軽量のDockerエンジンとそれが提供する簡単な自動化こそが、Dockerを成功したツールにした真の革新的ツールです。コンテナのデプロイを自動化する機能は、Dockerが一躍脚光を浴びるようになった理由です。仮想化環境におけるスケーラビリティの向上という利点を提供し、ビルドとテストの高速化を可能にします。 DockerはDevOps環境にどのように貢献するか DevOpsチームは、Dockerを使用することで多くの利点を得ます。OSリソースの即時起動と信頼性の向上により、このプラットフォームはアジャイル開発の高速な反復に最適です。開発環境は、同じバイナリと言語ランタイムを使用して、チーム全体で一貫しています。 コンテナ化されたアプリケーションはシステム全体でリソースの使用と環境が一貫しているため、DevOpsエンジニアは本番環境でも自分のマシンと同じようにアプリが動作することを確信することができます。また、Dockerコンテナはコンパイルの問題を解決し、開発プロセスにおける複数の言語バージョンの使用を簡素化するのにも役立ちます。 本記事は米国Sumo Logic社のサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
Read More
  • コンテナ化プラットフォームとして知られているオープンソースの仮想化テクノロジーです。コンテナは、独自のファイルシステムを含むアプリケーションを単一の複製可能なパッケージに含める手段を提供します。 2013年にソロモン・ハイクスによって開始されたDockerプラットフォームは、Linuxオペレーティングシステム用に特別に構築され、それ以来、コンテナの作成とデプロイを簡素化、自動化できることから、開発者とクラウドサービスプロバイダーの間で広く普及しています。 コンテナテクノロジーを使用すると、アプリケーションとそのすべての依存関係を標準化されたユニットにパッケージ化できるため、コンテナはすぐに仮想化の推奨アプローチになりつつあります。Dockerによる自動化は、その成功に不可欠です。

    Dockerコンテナ

    コンテナは新しいテクノロジーではありません。仮想マシン（VM）と同様に、これらは何年も前から存在している仮想化の形式です。ただし、VMとは異なる点は、フットプリントのサイズです。 VMは仮想オペレーティングシステム全体を作成しますが、コンテナはアプリの実行に必要で、まだホストコンピュータで実行されていないファイルのみを持ち込みます。実行しているシステムのカーネルを共有することで無駄を省き、可能な場合はアプリ間の依存関係も共有します。つまり、パフォーマンスがよりスムーズになり、アプリケーションのサイズが小さくなり、デプロイメントがより速くなります。

    Docker Engine

    Dockerコンテナは効率を提供するコンポーネントであり、Docker Engineはそれを可能にするものです。Dockerコンテナはイメージファイルから実行されます。これは基本的に、特定のオペレーティングシステムで特定のアプリケーションを実行するために作成されるファイルです。Docker Engineはそのイメージファイルを使用してコンテナを構築し、実行します。 軽量のDockerエンジンとそれが提供する簡単な自動化こそが、Dockerを成功したツールにした真の革新的ツールです。コンテナのデプロイを自動化する機能は、Dockerが一躍脚光を浴びるようになった理由です。仮想化環境におけるスケーラビリティの向上という利点を提供し、ビルドとテストの高速化を可能にします。

    DockerはDevOps環境にどのように貢献するか

    DevOpsチームは、Dockerを使用することで多くの利点を得ます。OSリソースの即時起動と信頼性の向上により、このプラットフォームはアジャイル開発の高速な反復に最適です。開発環境は、同じバイナリと言語ランタイムを使用して、チーム全体で一貫しています。 コンテナ化されたアプリケーションはシステム全体でリソースの使用と環境が一貫しているため、DevOpsエンジニアは本番環境でも自分のマシンと同じようにアプリが動作することを確信することができます。また、Dockerコンテナはコンパイルの問題を解決し、開発プロセスにおける複数の言語バージョンの使用を簡素化するのにも役立ちます。 本記事は米国Sumo Logic社のサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。" target="_blank">

SaaS、PaaS、IaaSのメリット、デメリット

  • On 2020年7月2日
By Sumo Logic クラウドを利用して仕事をする組織はますます増えています。どのようなクラウドモデルを採用するかは、企業のビジネスモデルによって異なります。クラウドサービスの最も一般的な導入モデルは、SaaS（Software-as-a-Service）、PaaS（Platform-as-a-Service）、IaaS（Infrastructure-as-a-Service）の3つです。 ここでは、これらのクラウドモデルの違いと、組織に適したモデルを選択する際に考慮すべき点について説明します。また、これらの導入モデルを管理する際に、Sumo Logic がどのように役立つかをご紹介します。 SaaS SaaSとは​ SaaS（Software as a Service）とは、インターネットを利用して、サードパーティのベンダーが管理するアプリケーションをユーザーに提供することです。 提供方法​ SaaSは、サードパーティによりインターネットを介して、すべてのクライアントに直接に機能が提供されます。ソフトウェアのメンテナンスはサードパーティがリモートで行います。 SaaSのメリット ベンダーがリモートでインストール、設定、メンテナンスを行うため、クライアントのIT部門は、事業に関わるより重要な問題に時間を割くことができます。これは時間の節約だけでなく、コストの節約にもつながります。 SaaSの特徴 SaaSアプリケーションは、インターネットを介してアクセスすることができます。これらのアプリケーションは集中管理され、リモートサーバにホストされています。必要なハードウェアとソフトウェアの設定は、ユーザーではなくベンダーが責任を持って行います。 SaaSを利用する理由 第一に、SaaSはソフトウェアを管理する時間がない企業、例えばスタートアップ企業にはメリットがあります。 第二に、SaaSの導入方法は、Webやモバイルからアクセスできるアプリケーションが必要な場合に非常に適しています。また、日常的に使用しないアプリケーションにもお勧めです。 最後に、SaaSはサブスクリプション型のため、短期間だけ特定のアプリケーションが必要な場合に適しています。 制限事項と懸念事項 SaaSの導入モデルを使用する際には、いくつかの制限や懸念事項があります。まず、ベンダーロックインが発生する可能性があります。SaaSアプリの習得は簡単かもしれませんが、他のSaaSアプリに移行する際には、データのポータビリティに大きなコストがかかることに注意してください。また、すべてのSaaSアプリがインテグレーションのためのオープンスタンダードに準拠しているわけではないため、相互運用性の低さにも注意が必要です。そのため、他のアプリと接続する際に問題が発生する可能性があります。 セキュリティについては、パブリッククラウドベースのSaaSアプリは、機密性の高いビジネスデータを転送する際のセキュリティが低く、セキュリティ、コンプライアンス、プライバシーの問題につながる可能性があります。 最後に、SaaSアプリは専門性の高いアプリであるため、万能なソリューションは存在しません。そのため、カスタマイズはオンプレミスのアプリに比べて困難です。 Sumo LogicとSaaSベンダー Sumo Logicは、クラウド規模でアプリケーションを運用し、セキュリティを確保するためのリアルタイムSaaSプラットフォームです。ここでは機械学習が重要な役割を果たします。Salesforceのような他のSaaSプラットフォームと簡単にインテグレーションすることができます。 Sumo Logic Continuous Intelligenceソリューションを使用すると、Salesforceのパフォーマンスをリアルタイムで監視できるだけでなく、セキュリティ侵害の可能性を迅速に特定して修正することができます。これは他のSaaSアプリにも当てはまります。 SaaSの例 Salesforce Google GSuite PaaS PaaSとは Platform as a Service（PaaS）は、開発者がカスタマイズしたアプリケーションを構築できるフレームワークを提供します。 提供方法 PaaSの提供方法はSaaSとほぼ同じです。インターネットでソフトウェア機能を提供する代わりに、PaaSはソフトウェアを作成するためのプラットフォームを提供します。PaaSでは、企業はミドルウェアと呼ばれるソフトウェアコンポーネントを使って、PaaSに組み込まれたアプリケーションを設計・作成することができます。 PaaSのメリット PaaSを利用すると、アプリの開発、デプロイが簡単で低コストでできます。開発されたアプリは拡張性と可用性が高くなります。開発者はミドルウェアを気にすることなくアプリをカスタマイズすることができるため、開発スピードが速くなります。 PaaSの特徴 仮想化技術により、必要に応じてリソースを簡単にスケールアップ／ダウンすることができます。PaaSは基本的にアプリケーションの開発、テスト、デプロイメントを支援するサービス群です。複数のユーザーが同じ開発プラットフォームを介してアクセスでき、Webサービスやデータベースとのスムーズなインテグレーションが可能です。 PaaSを利用する理由 PaaSを使えば、開発のワークフローを効率化することができます。 PaaSは拡張性のあるカスタマイズされたアプリケーションのための素晴らしいプラットフォームを提供します。 PaaSを利用すれば、限られた予算の中でプラットフォームを持つことができ、コストを削減することができます。また、迅速なアプリ開発とデプロイも可能になります。 制限と懸念事項 SaaSと同様に、PaaSにも制限や懸念事項があります。組織はPaaSソリューション上で独自のアプリを実行することができますが、データはPaaSベンダーによって管理されているサードパーティのサーバ上にあります。このため、データのセキュリティやプライバシーのリスクが懸念されます。 ベンダーロックインの可能性があり、ベンダーがしっかりとした移行ポリシーを持っていない場合、PaaSソリューションを切り替えるのは難しいかもしれません。 PaaSソリューションがあなたの選択したフレームワークや言語と互換性がない場合、ランタイムの問題が発生する可能性があります。PaaSソリューションが動作する言語やフレームワークのバージョンにも注意してください。 また、レガシーシステムをお持ちの場合には、レガシーシステム用にカスタマイズできないPaaSソリューションもありますので、注意が必要です。 PaaSの例 Windows Azure Google App Engine Sumo LogicとPaaSベンダー Microsoft Azure Cloud は、Sumo Logic との連携が可能な PaaS ソリューションの一例です。Azure MonitorやEvent Hubとのインテグレーションは簡単です。Sumo Logicは Azure Audit、Network Inspector、SQL、Active Directory などのコンテンツの可視性を高めることもできます。   IaaS IaaSとは IaaS（Infrastructure as a Service）とは、コンピュータやストレージ、ネットワークなどへのアクセスや監視が可能なコンピューティングリソースのことです。追加でハードウェアを購入する必要はありません。 クライアントはIaaSベンダーからハードウェアをリースします。 IaaSの提供方法 提供は仮想化されたクラウドサーバを介して行われます。ダッシュボードやAPIを利用して、クライアントがインフラ全体を完全にコントロールできるようにします。IaaSはクラウド上の「仮想データセンター」をアウトソースしたものです。 SaaSやPaaSとは異なり、IaaSのクライアントはアプリケーションやオペレーティングシステムなどを管理する責任があります。しかし、サーバやハードドライブなどはIaaSプロバイダーが管理します。 IaaSのメリット IaaSは、ストレージ、ネットワーク、サーバ、処理能力をシンプルに配置した非常に柔軟性の高いクラウドコンピューティングモデルです。 IaaSのコストは様々ですが、基本的にはクライアントの利用量に依存します。クライアントはインフラを完全にコントロールすることができ、高いスケーラビリティから利益を得ることができます。 IaaSの特徴 IaaSの特徴は、リソースをサービスとして提供するハードウェアインフラをリースすることです。前述の通り、利用量に応じてコストが変動します。 複数のユーザーが1つのハードウェアで作業することができます。そのため、非常に柔軟で拡張性の高い導入モデルとなっています。 IaaSを利用する理由 スタートアップや小規模企業にとって、IaaSはハードウェアやソフトウェアを購入せずに開発が行える手段です。これにより、時間とコストを節約することができます。大企業や成長企業にとっては、現在のニーズに応じて特定のハードウェアやソフトウェアに切り替える必要があるため、IaaSはメリットがあります。 制限と懸念事項 SaaSやPaaSと同様に、IaaSにも一定の制限や懸念点があります。 IaaSベンダーとクライアントは仮想マシンを介して接続されており、セキュリティが危うくなる可能性があります。複数企業で環境を共有するマルチテナントの場合、IaaSベンダーはクライアントのみが割り当てられたIaaSソリューションにアクセスでき、他のクライアントはアクセスできないようにしなければなりません。 PaaSと同様に、IaaSにもレガシーシステム用にカスタマイズできない可能性があります。 顧客はデータのセキュリティ、バックアップ、事業継続の責任を負うことになります。これには十分なトレーニングが必要であり、費用と時間がかかります。 IaaSの例 Amazon Web […]
Read More

MySQLのログファイル

  • On 2020年6月17日
ログは貴重です。クライアントに重要なデータへのアクセスを提供するバックエンドのリソースによって生成されるログは、単に価値があるだけではありません。ログがどこにあるかを知り、その情報を管理・理解できるかどうかで、スムーズで安全な操作ができるかどうか、パフォーマンスが低下するかどうか、あるいはアプリケーションの致命的な障害が発生するかどうかが決まります。 MySQL サーバは基本的なログを生成します。ここでは、どのログが重要なのか、なぜ重要なのか、どこにあるのか、そしてログを最大限に活用するために何ができるのかを見ていきます。 MySQLのログ 日々のIT運用において最も重要な3つのログは、エラーログ、低速なクエリのログ、（程度は低いですが）一般的なクエリのログです。これらのログのデフォルトフォーマットはテキストで、機能的な問題やセキュリティの問題の検出や診断、パフォーマンスの向上、サーバ操作やサーバへのアクセス履歴を追跡するのに役立ちます。 バイナリログ、リレーログ、DDLログはすべてバイナリ形式で、主にMySQL自身が使用するように設計されており、特にサーバのレプリケーションやデータリカバリなどのタスク用に設計されています。 どこで、どのように まず、様々なMySQLディストリビューションがどのように、どのような状況下でデフォルトのログファイルの場所を設定しているのかを簡単に見てみましょう。 MySQLディストリビューションには、基本的に3つのタイプがあります。Windows、特定のプラットフォーム固有のUNIX/Linux、一般的なUNIX/Linuxです。一般的に、プラットフォーム固有のディストリビューションでは、ログの配置と有効化のためのデフォルト設定がありますが、一般的なUNIX/Linuxディストリビューションでは、手動設定でログを管理することを前提としています。 Windows 公式の MySQL Windows ディストリビューションでは、インストールの各段階でユーザーが選択可能なオプションを備えた MSI インストーラを使用しています。ロギングオプションのページでは、ログの有効化と場所のデフォルトが表示され、必要に応じて調整を行うことができます。 エラー、低速クエリ、バイナリログは、デフォルトで有効になっていますが、一般的なクエリログは有効になっていません。各ログのデフォルトの場所は、MySQL Data ディレクトリ（C:¥ProgramData¥MySQL Server [バージョン]¥Data）で、デフォルトのログ名はコンピュータのデバイス名に基づいています。 一般的なクエリ、低速クエリ、バイナリログはインストーラの GUI を通じて手動で有効／無効にできますが、エラーログはできません。また、各ログの名前とパスを手動で設定することもできます。 インストール後、ログの設定はユーザーが編集可能な C:¥ProgramData¥MySQL¥MySQL Server [バージョン]¥my.ini で管理されます。このファイルでログ名やパス、有効／無効を設定できます。 プラットフォーム固有のUNIX/Linux 特定の UNIX/Linux プラットフォーム用の公式ディストリビューションは、一般的にスクリプトでインストールされ、対話的な設定はほとんど、あるいは全く行われません。いくつかのインストールパッケージ（Yum や APT を含む）は、エラーログを /var/log/ や /var/log/mysql/ に error.log や mysqld.log のような名前で作成します。データディレクトリは通常 /var/lib/mysql/ またはそれに類似したものになり、代わりのパスがなくてもログのデフォルトの保存先として有効に機能します。 ログの設定は /etc/mysql/my.cnf のようなユーザーが編集可能な設定ファイルで管理します。これらの設定には、ログ名やパス、スイッチの有効化／無効化などが含まれます。起動とシャットダウンは通常 mysqld_safe（あるいは一部のディストリビューションでは systemd）によって管理されており、ログ設定オプションを見つけて適用します。 一般的な UNIX/Linux 一般的なインストールは、主に手動で行います。インストールプロセス中に、コマンドライン、スクリプトの実行、または適切な設定ファイルの編集により、ログの有効化と設定を行うことができます。MySQL オンラインリファレンスマニュアル（https://dev.mysql.com/doc/refman/5.7/en/server-logs.html）で、これらのオプションについて詳しく説明しています。 【訳注】MyQL5.6日本語リファレンスマニュアルは、https://dev.mysql.com/doc/refman/5.6/ja/ にあります。 エラーログ エラーログには、起動時やシャットダウン時だけでなく、サーバ操作中に生成されたエラーメッセージ、警告、注意事項が含まれており、起動時間やシャットダウン時間も記録されます。 基本的なエラーログのフォーマットは以下の通りです。   timestamp thread ID [error type] [error code] [MySQL subsystem] Error message text Error types include System, Warning, Note, and ERROR. Typical log entries might look like this: 2020-05-24T11:55:27.611014Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.20) starting as process 36070 2020-05-24T12:14:51.002836Z 2 [Note] [MY-010051] [Server] Event Scheduler: scheduler thread started […]
Read More

Apacheアクセスログを理解する

  • On 2020年6月5日
Apache のアクセスログとは？ 前述したように、Apache のアクセスログは Apache HTTP サーバによって生成されるログファイルの一つです。この特定のログファイルは、Apache サーバによって処理された全てのリクエストのデータが記録されます。ですから、もし誰かがあなたのサイトのWebページを訪問した場合、 アクセスログファイルにはこのイベントに関する詳細が記録されます。 この情報は様々な状況で価値があります。例えば、特定のWebページにアクセスしようとする人が同じリクエストで失敗している場合、リンクはもはや存在しないページを指している可能性があります。サイト上の特定のページの読み込みに時間がかかっている場合、ログエントリはパフォーマンスを改善するためにリファクタリングされたSQLクエリを示している可能性があります。 Apache のアクセスログはどこにある？ Apache アクセスログの場所は Apache HTTP サーバが動作しているシステムに依存します。Apache HTTP サーバのインスタンスの大部分は Linux ディストリビューション上で動作しています。そこで、この記事では、Linux マシン上で Apache のアクセスログがどこにあるのかを詳細に説明します。 例えば、Ubuntu Linux ディストリビューションでは、アクセスログの記録はデフォルトで以下の場所に書き込まれます。 /var/log/apache2/access.log また、CentOSでは以下の場所にあります。 /var/log/httpd/access.log デフォルトの場所は他の Linux ディストリビューションでは多少異なるかもしれませんが、 ほとんどの場合はそれほど遠くを探す必要はありません。最終的には、アクセスログの場所とフォーマット（これについては後述します）は CustomLog ディレクティブで定義されていて、Apache HTTP サーバの設定の中で見たり変更したりすることができます。 Apache のアクセスログの解釈 Apache のアクセスログがどのようなもので、どこにあるのかがわかったところで、開発チームや他の IT 担当者が有効に活用できるように、エントリをどのように解釈するかを説明します。 Apache のアクセスログを読む Apache のアクセスログを理解するには、解析者がアクセスログがどのような形式で記録されているかを理解する必要があります。前述したように、アクセスログのフォーマットは場所と共に CustomLog ディレクティブで定義されています。以下では、Apache のアクセスログでよく利用されている2つの一般的なログフォーマットを見ていきます。 Common Log Format（共通ログフォーマット） Common Log Format は、いろいろなWebサーバがサーバログファイルを生成する際に使用する標準化されたテキストファイル形式です。Apache HTTP サーバでは、Common Log Format を使用して、開発者や管理者が読みやすいアクセスログを生成することができます。さらに、複数のWebサーバで使用されている標準化されたフォーマットなので、Common Log Formatのログファイルは多くのログ解析プラットフォームで簡単に使用することができます。 Common Log Format で書かれたアクセスログレコードは以下のようになります。 127.0.0.1 – Scott [10/Dec/2019:13:55:36 -0700] “GET /server-status HTTP/1.1” 200 2326 上記のサンプルレコードのフィールドは以下を表します。 127.0.0.0.1：要求を行ったクライアントの IP アドレス。 ログファイルの2番目のフィールドを定義するハイフンはクライアントの ID です。このフィールドはハイフンとして返されることが多く、Apache の HTTP サーバのドキュメントでは、制御された内部ネットワークの場合を除いて、この特定のフィールドに頼らないことを推奨しています。 Scott：リソースをリクエストする人の userid です。 [10/Dec/2019:13:55:36 -0700] ：リクエストの日時。 “GET /server-status HTTP/1.1”：リクエストの種類と要求されているリソース。 200：HTTP レスポンスステータスコード。 2326：クライアントに返されるオブジェクトのサイズ。 Combined Log Format（複合ログフォーマット） Apache のアクセスログでよく使われるもう一つのフォーマットは Combined Log Format です。このフォーマットは […]
Read More

マルチクラウドセキュリティの神話 by Sumo Logic

  • On 2019年11月26日
マルチクラウドアーキテクチャの人気が高まるにつれて、マルチクラウド環境を保護する方法を求める組織がますます増えています。マルチクラウドアーキテクチャにはセキュリティに対する根本的に異なるアプローチが必要であると結論付ける人もいます。 これは、マルチクラウドアーキテクチャのセキュリティに関する神話の一例です。マルチクラウドセキュリティに関する他の一般的な神話とともに、この仮定に欠陥がある理由を見てみましょう。 神話1：マルチクラウドにはセキュリティの見直しが必要 マルチクラウドアーキテクチャにはセキュリティ戦略の完全な見直しが必要であるという最初の神話から始めましょう。 実際には、見直しが必要になることはめったにありません。すでにあるクラウドセキュリティツールとプロセスは、シングルクラウドに対応するだけでなく、マルチクラウドアーキテクチャにも対応できるでしょう。 もちろん、クラウドセキュリティ戦略を微調整する必要はあるかもしれません。たとえば、すべてのクラウドの可視性を最大化するために、各クラウド環境から1つの場所にデータを収集し集約しているかを確認する必要があります。ただし、既存のログ集計ツールでもこれを行うことができます。新しいツールセットを作成する必要はありません。 神話2：マルチクラウドは堅牢なセキュリティを必要としない マルチクラウドのセキュリティに関する間違った想定は、マルチクラウドのセットアップでは、セキュリティについてそれほど心配する必要がないということです。 この考えは、マルチクラウドアーキテクチャが、冗長性のあるインフラを提供するため、可用性が向上するという事実に由来しています。「パブリッククラウドは侵入不可能であるという神話」を読んでみても、あなたは一度に使用するクラウドが多ければ多いほど安全であると信じているのかもしれません。 マルチクラウドの利点の1つは、プロバイダーの1つがダウンしても、データとアプリケーションを使用可能に保つことができるということですが、この機能をセキュリティと混同しないでください。可用性とセキュリティは同じものではありません。 したがって、複数のクラウドを採用すれば、堅牢なクラウドセキュリティポリシーに従う必要性はないというのは誤りです。使用しているクラウドの数に関係なく、クラウドセキュリティは重要です。 神話3：そのクラウド専用のセキュリティツールを使用する必要がある 1つのクラウドのみを使用する場合、そのクラウド専用に設計されたセキュリティツールを使っているかもしれません。たとえば、AWSにはInspectorを、AzureではAzure Security Centerを使用するといった具合です。 これらは、そのクラウドをサポートするために設計された便利なツールであり、シングルクラウドアーキテクチャで使うには何も問題もありません。しかし、効果的で合理化されたマルチクラウドセキュリティアプローチは、全てのクラウドをサポートできる分析と可視性ツールに基づいています。マルチクラウドリソースを監視しようとするときには、複数のセキュリティツールを併用することは望ましくありません。 マルチクラウドアーキテクチャを保護する方法：可視性と統合 マルチクラウドアーキテクチャとセキュリティに関する誤解について説明したので、次はマルチクラウドのセキュリティに対する効果的なアプローチについて考えてみましょう。 簡単に言うと、成功するマルチクラウドセキュリティ戦略は、セキュリティに対するプラットフォームレベルのアプローチに基づいた戦略です。複数のツールを使用して各クラウドを保護しようとしたり、マルチクラウド環境に存在するセキュリティリスクを無視したりするのではなく、すべてのクラウドの可視性と統合を最大化することに重点を置きます。 プラットフォーム全体の可視性と統合を最大化することにより、個々のクラウドを個別に処理する必要がないためワークフローを合理化できるだけでなく、異なるクラウド間でワークロードを簡単に移動したり、クラウドプロバイダーを別のものに置き換えたりすることもできます。変更するたびにセキュリティ戦略を調整する必要はありません。 マルチクラウドアーキテクチャの利点の1つは、ベンダーによるロックインを回避することであるため、これは重要です。マルチクラウドアーキテクチャが進化した時にセキュリティ戦略を調整できず、特定のクラウドベンダーとサービスにロックされるセキュリティ戦略は必要ありません。 DevSecOpsの完全な可視性 ダウンタイムを削減し、事後対応型から予防型の監視に移行します。 カテゴリー AWS Azure GCP SecOpsとセキュリティ スポットライト 継続的インテリジェンスレポート
Read More

ログを知る〜IISとApache、NGINXのログ

  • On 2019年10月16日
カテゴリー DevOpsとIT運用 スポットライト DevSecOpsの完全な可視性 IoTボットネットの脅威を軽減するためのセキュリティ戦略 AWS CloudTrailログを読み取り、検索、分析する方法 今日のWebサーバエコシステムには、インターネットインフォメーションサービス（IIS）、Apache、NGINXの3つの大きなプレーヤーがいます。そのうち2つ（Apacheと割合は低いがNGINX）だけがクロスプラットフォームですが、どれもサポートすることを求められる可能性があるので、これらの3つのサーバすべてと連携できることがますます重要になります。 そのため、IIS、Apache、NGINXログの微妙な違いを理解することが重要です。完璧な世界では、これらのサーバはすべて同じログ形式とログデータを持ちますが、実際にはそうではありません。 この記事では、IIS、Apache、NGINXのログの違いと、DevOpsエンジニアが各サーバのログを操作するために知る必要がある重要な情報について説明します。 IIS、Apache、NGINX、の歴史とログ IISとApacheの戦いは20年間続いています。最初は、人々はしっかりと一方の側にいて、それは会社がWindowsのみであるか、UNIX／Linuxシステムが利用可能かによってしばしば決定されました。これらのシステムには、Webサイトにサービスを提供できることを除いて、共通点はありません。ログファイルは、実行されたオペレーティングシステムと同じくらい異なっていました。時が経ち2000年代になると、仮想化とLinuxが主流になってきたため、組織は一般的にApache HTTPとIISの両方のインストールを行いました。 同じ時期に、NGINXはApache HTTPの直接の競争相手になりました。NGINXは、Apache HTTPを凌ぐように設計されましたが、既存のログ管理ソリューションを再利用して、管理者がApacheからNGINXに簡単に移行できるようなログ形式を使用することで、Apache周りに構築されたエコシステムを活用しました。 Apache、NGINX、IISのログはどこに？ IIS IISでWindows 2008とVistaでリリースされたバージョン7でログファイルのデフォルトの場所が変更されました。IIS 6以前はログは％SystemRoot％System32LogFilesの下にありましたが、IIS 7では％SystemDrive％inetpublogs LogFilesに移動しました。 LogFilesディレクトリ内には、IISマネージャー管理コンソールでセットアップされたすべてのWebサイトやアプリケーション用に作成されたフォルダがあります。 デフォルトのサーバログフォルダはW3SVC1です。追加のフォルダは「1」をより長い乱数に置き換えます。デフォルトでは、「formatDDMMYY.log」というファイル名でNCSA、Extended、あるいはIISのフォーマットで新しいアクセスログファイルが毎日作成されます。LogFilesディレクトリ内には、IISマネージャー管理コンソールでセットアップされたすべてのWebサイトまたはアプリケーション用に作成されたフォルダーがあります。 下はWebサイトとログフォルダとファイルの例です。 Apache HTTP Apache HTTPのログはパッケージからインストールされた場合、UNIXやLinuxベースのサーバでは/var/log以下にあります。Windowsでは、ソースからコンパイルする場合、設定ファイルやバイナリと同じディレクトリの下にあります。 *デフォルトのファイル名はaccess_logおよびerror_logですが、例外もあります。 ほとんどのディストリビューションのパッケージ版Apache HTTPを使用する場合、ファイルは/var/log/httpdにあります。デフォルト設定を使用してソースからコンパイルする場合、ログファイルは$PREFIX/logsにあります。$PREFIXはコンパイル中に設定でき、デフォルトの場所は/usr/local/apache2です。 NGINX NGINXはApacheよりも一貫性が高く、すべてのディストリビューションで、/var/log/nginxのベースディレクトリにerror.logとaccess.logのファイル名を使用するパッケージを使用しています。 ソースからコンパイルする場合、またはWindows上で実行する場合、デフォルトの場所はベースインストールディレクトリの下のログディレクトリで、ファイル名はaccess_logとerror_logです。 IISアクセスロギング 前述のように、IISにはログファイルを保存できる複数の形式があります。そのうちの1つは、データベースにも書き込むことができるバイナリ形式ですが、ログのインフラが複雑になるので理想的とはいえません。 テキストベースの形式では、W3C拡張、IIS、NCSAという3つのオプションがあります。 W3C拡張形式は、日付ではなく時刻のみを持つため、デフォルトのDailyのように、実際には時間ベースのファイルローテーションでのみ機能します。 IIS形式は、3つの形式の中で最も情報が多く、時間ベースやサイズベースなど、複数の種類のファイルローテーションをサポートしています。 NCSAはApache HTTP、NGINXや他のいくつかのWebサーバで使用される形式です。他の2つのテキストオプションと比較して、データのバランスが良い構文を持っています。 Apache対NGINXアクセスロギング ApacheとNGINXは両方とも、デフォルトでNCSAフォーマットのアクセスロギングを使用します。 ApacheとNGINXの両方には、アクセスログのデータをカスタマイズして、情報を増やしたり減らしたりする機能があります。一般的に使用されるこの形式は、コンバインドと呼ばれます。 コンバインドは、HTTP_RefererとUser_Agentと呼ばれる2つのデータフィールドが追加されたNCSAフォーマットに基づいています。この2つのフィールドは、ログをWeb分析やキャンペーントラッキングなどのマーケティング活動の基盤として使用する場合に非常に役立ちます。ただし、ほとんどの組織は、マーケティング活動のためにより堅牢なJavaScriptベースの追跡ソリューション（Googleアナリティクスなど）に移行したため、コンバインドは使用しなくなりました。 エラーログ IISとNGINXとApacheのエラーログは、日付、時刻、エラーコード（利用可能な場合）とstderrの出力の形式で、いたって分かりやすくなっています。エラーはファイル内の複数の行にまたがることができるため、ログを正しく理解して処理できる適切なログ収集エンジン（Sumo Logicなど）を用意すると役立ちます。 結論 IIS、Apache、NGINXのログは多くの点で異なります。幸いなことに、Sumo Logicのような最新のログ統合サービスを活用することで、アクティビティの追跡と問題解決の両方について、すべてのプラットフォームで統一されたビューを簡単に取得できます。さらに、アクセスログにNCSAフォーマットを使用するようにIISを構成できることにより、これらの集中ログリポジトリの検索と特定のデータのマイニングが可能になり、ログ統合ツールを使用した日常作業が可能になります。 ヴィンス・パワー Vince Powerはソリューションアーキテクトであり、クラウドの採用とオープンソースベースのテクノロジーの実装にフォーカスしています。彼は、コアコンピューティングとネットワーク（IaaS）、アイデンティティとアクセス管理（IAM）、アプリケーションプラットフォーム（PaaS）、継続的デリバリーなどの幅広い経験を持っています。
Read More
  • カテゴリー

    スポットライト

    今日のWebサーバエコシステムには、インターネットインフォメーションサービス（IIS）、Apache、NGINXの3つの大きなプレーヤーがいます。そのうち2つ（Apacheと割合は低いがNGINX）だけがクロスプラットフォームですが、どれもサポートすることを求められる可能性があるので、これらの3つのサーバすべてと連携できることがますます重要になります。 そのため、IIS、Apache、NGINXログの微妙な違いを理解することが重要です。完璧な世界では、これらのサーバはすべて同じログ形式とログデータを持ちますが、実際にはそうではありません。 この記事では、IIS、Apache、NGINXのログの違いと、DevOpsエンジニアが各サーバのログを操作するために知る必要がある重要な情報について説明します。

    IIS、Apache、NGINX、の歴史とログ

    IISとApacheの戦いは20年間続いています。最初は、人々はしっかりと一方の側にいて、それは会社がWindowsのみであるか、UNIX／Linuxシステムが利用可能かによってしばしば決定されました。これらのシステムには、Webサイトにサービスを提供できることを除いて、共通点はありません。ログファイルは、実行されたオペレーティングシステムと同じくらい異なっていました。時が経ち2000年代になると、仮想化とLinuxが主流になってきたため、組織は一般的にApache HTTPとIISの両方のインストールを行いました。 同じ時期に、NGINXはApache HTTPの直接の競争相手になりました。NGINXは、Apache HTTPを凌ぐように設計されましたが、既存のログ管理ソリューションを再利用して、管理者がApacheからNGINXに簡単に移行できるようなログ形式を使用することで、Apache周りに構築されたエコシステムを活用しました。

    Apache、NGINX、IISのログはどこに？ IIS

    IISでWindows 2008とVistaでリリースされたバージョン7でログファイルのデフォルトの場所が変更されました。IIS 6以前はログは％SystemRoot％System32LogFilesの下にありましたが、IIS 7では％SystemDrive％inetpublogs LogFilesに移動しました。 know-your-logs LogFilesディレクトリ内には、IISマネージャー管理コンソールでセットアップされたすべてのWebサイトやアプリケーション用に作成されたフォルダがあります。 デフォルトのサーバログフォルダはW3SVC1です。追加のフォルダは「1」をより長い乱数に置き換えます。デフォルトでは、「formatDDMMYY.log」というファイル名でNCSA、Extended、あるいはIISのフォーマットで新しいアクセスログファイルが毎日作成されます。LogFilesディレクトリ内には、IISマネージャー管理コンソールでセットアップされたすべてのWebサイトまたはアプリケーション用に作成されたフォルダーがあります。 下はWebサイトとログフォルダとファイルの例です。 Crazy-Cousins

    Apache HTTP

    Apache HTTPのログはパッケージからインストールされた場合、UNIXやLinuxベースのサーバでは/var/log以下にあります。Windowsでは、ソースからコンパイルする場合、設定ファイルやバイナリと同じディレクトリの下にあります。 *デフォルトのファイル名はaccess_logおよびerror_logですが、例外もあります。 know-your-logs know-your-logs ほとんどのディストリビューションのパッケージ版Apache HTTPを使用する場合、ファイルは/var/log/httpdにあります。デフォルト設定を使用してソースからコンパイルする場合、ログファイルは$PREFIX/logsにあります。$PREFIXはコンパイル中に設定でき、デフォルトの場所は/usr/local/apache2です。

    NGINX

    NGINXはApacheよりも一貫性が高く、すべてのディストリビューションで、/var/log/nginxのベースディレクトリにerror.logとaccess.logのファイル名を使用するパッケージを使用しています。 ソースからコンパイルする場合、またはWindows上で実行する場合、デフォルトの場所はベースインストールディレクトリの下のログディレクトリで、ファイル名はaccess_logとerror_logです。

    IISアクセスロギング

    前述のように、IISにはログファイルを保存できる複数の形式があります。そのうちの1つは、データベースにも書き込むことができるバイナリ形式ですが、ログのインフラが複雑になるので理想的とはいえません。 テキストベースの形式では、W3C拡張、IIS、NCSAという3つのオプションがあります。 W3C拡張形式は、日付ではなく時刻のみを持つため、デフォルトのDailyのように、実際には時間ベースのファイルローテーションでのみ機能します。 know-your-logs IIS形式は、3つの形式の中で最も情報が多く、時間ベースやサイズベースなど、複数の種類のファイルローテーションをサポートしています。 know-your-logs NCSAはApache HTTP、NGINXや他のいくつかのWebサーバで使用される形式です。他の2つのテキストオプションと比較して、データのバランスが良い構文を持っています。 know-your-logs

    Apache対NGINXアクセスロギング

    ApacheとNGINXは両方とも、デフォルトでNCSAフォーマットのアクセスロギングを使用します。 ApacheとNGINXの両方には、アクセスログのデータをカスタマイズして、情報を増やしたり減らしたりする機能があります。一般的に使用されるこの形式は、コンバインドと呼ばれます。 コンバインドは、HTTP_RefererとUser_Agentと呼ばれる2つのデータフィールドが追加されたNCSAフォーマットに基づいています。この2つのフィールドは、ログをWeb分析やキャンペーントラッキングなどのマーケティング活動の基盤として使用する場合に非常に役立ちます。ただし、ほとんどの組織は、マーケティング活動のためにより堅牢なJavaScriptベースの追跡ソリューション（Googleアナリティクスなど）に移行したため、コンバインドは使用しなくなりました。

    エラーログ

    IISとNGINXとApacheのエラーログは、日付、時刻、エラーコード（利用可能な場合）とstderrの出力の形式で、いたって分かりやすくなっています。エラーはファイル内の複数の行にまたがることができるため、ログを正しく理解して処理できる適切なログ収集エンジン（Sumo Logicなど）を用意すると役立ちます。

    結論

    IIS、Apache、NGINXのログは多くの点で異なります。幸いなことに、Sumo Logicのような最新のログ統合サービスを活用することで、アクティビティの追跡と問題解決の両方について、すべてのプラットフォームで統一されたビューを簡単に取得できます。さらに、アクセスログにNCSAフォーマットを使用するようにIISを構成できることにより、これらの集中ログリポジトリの検索と特定のデータのマイニングが可能になり、ログ統合ツールを使用した日常作業が可能になります。 vince-power

    ヴィンス・パワー

    Vince Powerはソリューションアーキテクトであり、クラウドの採用とオープンソースベースのテクノロジーの実装にフォーカスしています。彼は、コアコンピューティングとネットワーク（IaaS）、アイデンティティとアクセス管理（IAM）、アプリケーションプラットフォーム（PaaS）、継続的デリバリーなどの幅広い経験を持っています。" target="_blank">

Sumo Logicでsyslogデータを監視する方法

  • On 2019年9月27日
カテゴリー DevOpsとIT運用 スポットライト 継続的インテリジェンスレポート この記事を読んでいる方は、おそらく1980年代から使用されているロギングツールであるsyslogに精通していることでしょう。ほとんどのLinuxベースのオペレーティングシステムに存在するデーモンです。 デフォルトでは、Linuxシステムのsyslog（およびrsyslogなどの派生アプリ）を使用して、ログをsyslogサーバや監視プラットフォームに転送して、さらに分析を行うことができます。これは便利ですが、syslogを最大限に活用するには、ログデータを分析できるようにする必要もあります。 そこで、ここではローカルのシステムログを取得し、Sumo Logicコレクターを使用してSumo Logicに転送するプロセスを説明します。 また、syslogやrsyslogデーモンを使用して、サーバからログを送信する方法も示します。 はじめに ログをSumo Logicにストリーミングできるようにするには、まずパッケージにサインアップする必要があります。有料のオプションもありますが、Sumo Logicのテストとして、ストリーミングするログの量を少なくし、1日最大500Mバイトまでならば無料で使えるオプションがあります。サインアップすると、次のようなページが表示され、ログファイルをアップロードするか、ストリーミングログにすぐにジャンプするかを選択します。ここでは後者のオプションを選択します。 ストリーミングログ 「Set Up Streaming Data」ボタンをクリックすると、Linux、Windows、あるいはMacからAWS環境をすぐに開始できるオプションが表示されます。 コレクターのインストール 今回はLinuxを選択します。これにより、次のような簡単なコマンドでSumo Logicコレクターをデプロイできます。 sudo wget “https://collectors.de.sumologic.com/rest/download/linux/64” -O SumoCollector.sh && sudo chmod + x SumoCollector.sh && sudo ./SumoCollector.sh -q -Vsumo.token_and_url=<unique_token> コマンドを実行すると、コレクターがインストールされ、Sumo Logicに自動的に登録されます。この時点で、「Continue」をクリックできるようになります。 ソースの構成 次に、データのソース情報を設定します。まず、ソースカテゴリーを設定します。これは、収集時に各メトリックの時系列に追加されるメタデータタグです。希望する任意の名前を設定できます。これを使用して、将来このソースからのメトリックを見つけることができます。 プロセスのこの時点で、データを収集するログファイルを設定することもできます。デフォルトでは、/var/log/secure*と/var/log/messages*がスクレイピング用に選択されています。もちろん、収集したい他のログファイルを追加できます。例えば、実行中にアプリが生成するログファイルです。 最後に、ログファイルのタイムゾーンを使用するか、無視して別のタイムゾーンを使用するかを選択できます。これで、「Continue」をクリックする準備ができました。ログのサイズが大きい場合には、Collectorが設定とデータを追加する間にコーヒーが1杯飲めるかもしれません。 完了すると次のように表示されます。 ログを検索する では、楽しい作業に移りましょう。ログを表示して、情報を検索します。「Linux System」という名前のページの上部にあるサンプル検索オプションを使用すると、サーバからストリーミングされたログを表示できます。「sumologic」という名前のログも含めるように検索クエリを修正しました。これがその結果です。 ホスト名、データ取得元のログファイル名、セットアップ中に設定した「linux/system」というカテゴリーが表示されます。 また、ログイン時に一般的な情報を表示できる便利なダッシュボードもあります。もちろん、ログの情報に基づいてこれを変更し、新しいグラフを追加できます。これは、アプリケーションのHTTPエラーの詳細など、さまざまな機能に使用できます。たとえばメールサーバならば、バウンスや拒否されたメールの数を表示できます。 Syslogソースの追加 Syslogソースを追加するには、Sumo Logicコントロールパネルで新しいソースを設定します。これを行うには、「Manage Data」→「Collection」→「Collection」に移動します。次に、「Add」→「Add Source」→「Syslog」をクリックします。ここでは、プロトコル（TCPまたはUDP）とポート番号とともにsyslog名を指定します。この記事では、ポート1514でUDPを選択しました。linux/syslogのソースカテゴリーを使用することにしました。ここで「Save」をクリックします。コレクターがサーバのUDPポート1514をリッスンしているサービスが表示されます。 この時点で、コレクターの新しいリスナーにログを送信するようsyslogを設定する準備が整いました。設定にはsyslogまたはrsyslogの設定ファイルを編集します。この場合、後者は/etc/rsyslog.confです。このログファイルの最後に、コメントアウトされた行があります。 # remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional #*.* @@remote-host:514 # ### end of the forwarding rule ###   この行のコメントを外し、IPアドレスとポートを変更して、rsyslogが保持するすべてのログ（*.*）を新しいリスナーに送信します。 # remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional *.* @127.0.0.1:1514 # ### end of the forwarding rule ###   ログ送信にTCPではなくUDPを使用するようにrsyslogに指示する「@」をIPアドレスの先頭に付加してください。 コレクターに対してこのメ​​ソッドを単独で使用する理由 ここで説明したアプローチを採用する理由は次の通りです。 組織内の中央syslogサーバにコレクターをセットアップし、すべてのログをSumo Logicに転送することができます。このアプローチの利点は、すべてのサーバに個別にコレクターをインストールする必要がないため、非常に多くのソースからのトラフィックを許可するために企業のファイアウォールを開ける必要がないことです。 結論 Sumo Logicは、大規模な組織に存在する可能性のある制限を回避するために、リスナーを独自の環境に拡張できる包括的なクラウドソリューションを提供します。これにインターフェイス、合理化されたセットアッププロセス、ダッシュボードを組み合わせることで、非常に競争力のあるソリューションとなり、ログを積極的に監視し、お客様に影響を与える前に問題を発見できます。 キース・ロジャース キース・ロジャースは、10年以上の経験を持つITプロフェッショナルで、現在は英国の大手放送会社で働いています。彼の長年にわたるコンピューティングへの情熱は、いくつもの業務外の活動をうながし、彼の知識を深め関心を高めることにつながりました。 キースは長年Linux上でApache、MySQL、PHPを使用して完全なWebスタックを構築し、高可用性に適したより複雑な負荷分散と冗長ソリューションを作成してきました。過去2、3年、彼はAWSやAzureが提供する新しいクラウドベースのインフラストラクチャを使用して、同様の目標を達成しています。
Read More
  • カテゴリー

    スポットライト

    • 継続的インテリジェンスレポート

    この記事を読んでいる方は、おそらく1980年代から使用されているロギングツールであるsyslogに精通していることでしょう。ほとんどのLinuxベースのオペレーティングシステムに存在するデーモンです。

    デフォルトでは、Linuxシステムのsyslog（およびrsyslogなどの派生アプリ）を使用して、ログをsyslogサーバや監視プラットフォームに転送して、さらに分析を行うことができます。これは便利ですが、syslogを最大限に活用するには、ログデータを分析できるようにする必要もあります。

    そこで、ここではローカルのシステムログを取得し、Sumo Logicコレクターを使用してSumo Logicに転送するプロセスを説明します。

    また、syslogやrsyslogデーモンを使用して、サーバからログを送信する方法も示します。

    はじめに

    ログをSumo Logicにストリーミングできるようにするには、まずパッケージにサインアップする必要があります。有料のオプションもありますが、Sumo Logicのテストとして、ストリーミングするログの量を少なくし、1日最大500Mバイトまでならば無料で使えるオプションがあります。サインアップすると、次のようなページが表示され、ログファイルをアップロードするか、ストリーミングログにすぐにジャンプするかを選択します。ここでは後者のオプションを選択します。

    image1

    ストリーミングログ

    「Set Up Streaming Data」ボタンをクリックすると、Linux、Windows、あるいはMacからAWS環境をすぐに開始できるオプションが表示されます。

    コレクターのインストール

    今回はLinuxを選択します。これにより、次のような簡単なコマンドでSumo Logicコレクターをデプロイできます。

    sudo wget 'https://collectors.de.sumologic.com/rest/download/linux/64' -O SumoCollector.sh && sudo chmod + x SumoCollector.sh && sudo ./SumoCollector.sh -q -Vsumo.token_and_url=<unique_token>

    コマンドを実行すると、コレクターがインストールされ、Sumo Logicに自動的に登録されます。この時点で、「Continue」をクリックできるようになります。

    ソースの構成

    次に、データのソース情報を設定します。まず、ソースカテゴリーを設定します。これは、収集時に各メトリックの時系列に追加されるメタデータタグです。希望する任意の名前を設定できます。これを使用して、将来このソースからのメトリックを見つけることができます。

    プロセスのこの時点で、データを収集するログファイルを設定することもできます。デフォルトでは、/var/log/secure*と/var/log/messages*がスクレイピング用に選択されています。もちろん、収集したい他のログファイルを追加できます。例えば、実行中にアプリが生成するログファイルです。

    最後に、ログファイルのタイムゾーンを使用するか、無視して別のタイムゾーンを使用するかを選択できます。これで、「Continue」をクリックする準備ができました。ログのサイズが大きい場合には、Collectorが設定とデータを追加する間にコーヒーが1杯飲めるかもしれません。

    完了すると次のように表示されます。

    image3

    ログを検索する

    では、楽しい作業に移りましょう。ログを表示して、情報を検索します。「Linux System」という名前のページの上部にあるサンプル検索オプションを使用すると、サーバからストリーミングされたログを表示できます。「sumologic」という名前のログも含めるように検索クエリを修正しました。これがその結果です。

    ホスト名、データ取得元のログファイル名、セットアップ中に設定した「linux/system」というカテゴリーが表示されます。

    また、ログイン時に一般的な情報を表示できる便利なダッシュボードもあります。もちろん、ログの情報に基づいてこれを変更し、新しいグラフを追加できます。これは、アプリケーションのHTTPエラーの詳細など、さまざまな機能に使用できます。たとえばメールサーバならば、バウンスや拒否されたメールの数を表示できます。

    image2

    Syslogソースの追加

    Syslogソースを追加するには、Sumo Logicコントロールパネルで新しいソースを設定します。これを行うには、「Manage Data」→「Collection」→「Collection」に移動します。次に、「Add」→「Add Source」→「Syslog」をクリックします。ここでは、プロトコル（TCPまたはUDP）とポート番号とともにsyslog名を指定します。この記事では、ポート1514でUDPを選択しました。linux/syslogのソースカテゴリーを使用することにしました。ここで「Save」をクリックします。コレクターがサーバのUDPポート1514をリッスンしているサービスが表示されます。

    この時点で、コレクターの新しいリスナーにログを送信するようsyslogを設定する準備が整いました。設定にはsyslogまたはrsyslogの設定ファイルを編集します。この場合、後者は/etc/rsyslog.confです。このログファイルの最後に、コメントアウトされた行があります。

    # remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional

    #*.* @@remote-host:514

    # ### end of the forwarding rule ###

     

    この行のコメントを外し、IPアドレスとポートを変更して、rsyslogが保持するすべてのログ（*.*）を新しいリスナーに送信します。

    # remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional

    *.* @127.0.0.1:1514

    # ### end of the forwarding rule ###

     

    ログ送信にTCPではなくUDPを使用するようにrsyslogに指示する「@」をIPアドレスの先頭に付加してください。

    コレクターに対してこのメ​​ソッドを単独で使用する理由

    ここで説明したアプローチを採用する理由は次の通りです。

    組織内の中央syslogサーバにコレクターをセットアップし、すべてのログをSumo Logicに転送することができます。このアプローチの利点は、すべてのサーバに個別にコレクターをインストールする必要がないため、非常に多くのソースからのトラフィックを許可するために企業のファイアウォールを開ける必要がないことです。

    結論

    Sumo Logicは、大規模な組織に存在する可能性のある制限を回避するために、リスナーを独自の環境に拡張できる包括的なクラウドソリューションを提供します。これにインターフェイス、合理化されたセットアッププロセス、ダッシュボードを組み合わせることで、非常に競争力のあるソリューションとなり、ログを積極的に監視し、お客様に影響を与える前に問題を発見できます。

    image4

    キース・ロジャース

    キース・ロジャースは、10年以上の経験を持つITプロフェッショナルで、現在は英国の大手放送会社で働いています。彼の長年にわたるコンピューティングへの情熱は、いくつもの業務外の活動をうながし、彼の知識を深め関心を高めることにつながりました。

    キースは長年Linux上でApache、MySQL、PHPを使用して完全なWebスタックを構築し、高可用性に適したより複雑な負荷分散と冗長ソリューションを作成してきました。過去2、3年、彼はAWSやAzureが提供する新しいクラウドベースのインフラストラクチャを使用して、同様の目標を達成しています。

    " target="_blank">