アプリなら、コメントが見やすい！
トップへ戻る
暑さ対策
designetwork.daichi703n.com
Elasticsearchのデータを元にアラート通知できるElastAlertは、X-Pack(Watcher Alert)を導入しない環境において、ログ監視を実装する有用な方法として広く使用されている。 しかし、ElastAlertはコマンド・設定ファイル(YAML)ベースでの動作のみをサポートしており、アラートルール編集・抑止等は(CIなどでの操作は可能だが)サーバ操作が必要となる。アラートを受け取りたいのはKibanaのみを操作する一般ユーザであるケースが多く、ElastAlertのルール運用はやや面倒だ。ElastAlertをKibanaのタブとして組み込める ElastAlert Kibana Pluginはあるが、シンプルなアラート作成のみが可能... そこで、ElastAlertの機能一式をサポートしているPraecoを使用する。 Praecoでは、ElastAlert Ki
OpenStack Queensがリリースされたのでインストールから初期使用までを検証する。 OpenStack環境を簡単に構築できるPackStackで、少しのカスタマイズを加えて実用的なOpenStack検証環境を構築する。 OpenStackバージョン: Queens (Version: 13.0.0) ※あくまで検証環境ですので、セキュリティ、可用性、拡張性、マルチテナント等には課題が残ります。 PackStackインストール環境の課題 PackStackでのOpenStackインストールを試す中で、以下の点が課題と感じた。 Cinderのデフォルト容量が20GBのみ Swiftのデフォルト容量が2GBのみ いずれもストレージの課題で、インスタンスやオブジェクト数が増えてくるとすぐ容量不足となり使用できなくなる。 前提環境 物理サーバ 使用しているサーバはこちらで選定したDell
Webブラウザなしで動作し、サーバーサイドでも使用できるJavaScriptであるNode.js。ExpressなどのWebアプリケーションフレームワークを使用してサービス開発、また、Seleniumやmochaなどのテストフレームワークと組み合わせてテストを自動化することもできる。 手軽に使用することができるため、ちょっとしたAPIアクセスにも便利だ。その際にHTTP GET, POSTするためのrequestモジュールで戻り値を返す方法を記載する。 一般的な方法でコールバック関数を使えばよいのだが、処理速度を求められないプログラムの場合は非同期より同期処理の方が扱いやすい。 結論として、requestモジュールでは一般的なJavaScriptのコールバック関数を使用せずに同期処理をすることはできない。そのため、sync-requestモジュールを使用して同期処理にする。 request
Outlookで振り分けルール設定をする際に、通常の設定だと、AND/ORの組合せがうまくできず、かゆいところに手が届かない。特にOR条件を使いたいときにおすすめの設定を紹介する。 Microsoftコミュニティ Microsoftコミュニティで同様のディスカッションがあるが、最終的に検索の話になっており、期待する回答はない。 answers.microsoft.com メール振り分けにヘッダ情報を使用する 通常の振り分けルールでは、項目間の関係はかつ(AND)になっている。そのため、通常ルールでは差出人がX、または、件名に"Y"を含むという設定はできない。 そこで、振り分けルールのうちヘッダ情報を使用する。 OutlookでのAND/OR組合せ振り分け OutlookでOR条件の振り分けルールを作成する方法を示す。画面はWeb版Outlookだが、クライアント版でも同様箇所で設定ができる
Elasticsearchのデータ・ログ可視化ツールとしてはKibanaが用意されているが、ZABBIXなどのデータを組み合わせてGrafanaでダッシュボードを作りたいときもある。使い始めとして、GrafanaのデータソースとしてElasticsearchを連携させる設定方法を記載する。 KibanaとGrafanaの使い分け はじめに簡単に私のKibanaとGrafanaの使い分け。 Kibana：検索・抽出(詳細) こちらの記事に書いたとおり、Kibanaの拡張版を使用すればDiscoverタブでの検索結果をCSVにエクスポートすることもできる。 Grafana：ダッシュボード(概要) ひと目で現在の稼働状態を監視するためのダッシュボードとしての使用がメインと考えている。また、データソースとしてInfluxDBをはじめ、ZABBIXやPrometheusといった統合監視など多彩なプラ
内部的なドメイン(Internal Domain Name)として使用される.local。 test.local, test.internalといったローカルドメインを使用しているケースが多い。 ローカルドメインを使用している中で発生する問題のひとつである「SSL証明書をどうするか？」という問題の対応を記載する。 .localドメインの証明書の問題 詳細はこちらの通り 概要としては、.local, .internalといったドメインはジェネリックトップレベルドメイン(gTLD: generic Top Level Domain)(.com, .jpなど)ではなく、公的には認められていない。それと合わせて、その認証も公的にはできなくなっており、公的機関から証明書の発行を受けることはできない。 また、セキュリティ的にも、ローカルドメインは各社で独自に使用できるものであるため、インターネット上と
自宅のサーバー(ホームサーバー)を買い替えたいと思い各種選定をしたのでまとめる。現在の環境はこちらの通り。 DELL PowerEdge SC440 CPU：Core 2 quad Q6700 2.66GHz メモリー：8GB DISK：Western Digital(WD) HDD 3TB + Seagate SSD 256GB VMware ESXi (vSphere) 5.5.0 Build1623387 他にもCisco、Juniperのネットワーク機器を持っており、自宅ラボを構成している。 現状で不足している部分は、ネスト仮想化(Nested Virtualization)の対応とメモリー容量。なお、自宅・個人での使用なので基本的に中古の格安で仕上げたい。 前提は仮想化環境 前提としてOSは直接インストールせず、VMware ESXiで仮想化する。選定にあたり、ネスト仮想化(Ne
OSS・無料・フリーで使用できるNetFlow Collector( ネットフローコレクター )・Analyzer(ネットフローアナライザー)をいくつか試験した結果、2016年現在最も採用する価値があるのは「Paessler PRTG」だと考えている。 (2017/5/11 訂正) Fluentdプラグインのfluent-plugin-netflowを使用する価値が高いと考えている。 (2019/3/17 再訂正) ElastiFlow (Elasticsearch + Logstash + Kibana) が有用と考えている。 元々はOSS(オープンソース)で一般公開されているシステムを採用したかったが、そもそもOSSのNetFlow Collectorで現在もアップデートされているシステムは存在していないようだ。OSSの組み合わせで言えば、Fluend＋ElasticSearch＋Ki
無償版のNetFlow CollectorとしてPRTGが現時点で最も有用だという結論を出しているが、有償で高機能なコレクター製品としてCisco Prime InfrastructureをCollector, Analyzerとして使用してみる。 使い勝手や機能に優れるからやはり有償製品を採用するべきか、あるいは、それほど差異がないため無償で十分という判断材料とする。 使い比べてみた結果 結論から言うと、Prime Infrastructureではなく、Cisco Lancope STEALTHWATCH を使用するべきだと実感している。 観点は以下の通り。 Web画面がキレイで見やすい 操作が直感的 フロー詳細をドリルダウンできる(Javaクライアントがネック...) サポートが手厚い Lancope STEALTHWATCH のインストール・評価手順はこちら Lancope-STEA
セキュリティ強化・投資計画に向けたNetFlow/sFlowの活用 NaaS/E (Network as a Sensor / Enforcer) ここ最近NaaS/NaaEというキーワードが生まれている。 字面を見ると、SaaSから始まったPaaS/IaaS/DaaSの類か、と直感的に思う。 しかし、Ciscoではそれぞれ以下のように呼称している。 Network as a Sensor / Enforcer www.cisco.com IoTの普及なども受け、入口/出口対策などの局所的な方法では守れる範囲が限られてしまう。 具体的な例を挙げると、入口/出口のみでは、ウイルス感染した端末があった場合に、その端末が社内の同一LAN上にある端末/サーバ、基幹サーバにアクセスする通信は検知・防御することができない。 基幹サーバとの間にはFWが設置されているのが一般的だが、プロトコル/ポート番号
Redmineを新バージョン並行稼動切り替えすることで、データロスのリスクなくバージョンアップする。 最初は楽をしようとSVNアップデートを実行したが、予定の3.2まで上がらず、再バージョンアップした。 3.1.1 → 3.1.5 → 3.2.2 これでレスポンシブデザインにより、スマートフォンでも快適にチケット管理できる。 前提情報 バージョンアップは基本的にRedmineオフィシャルサイトの情報を元に実行しています。また、当初のインストールもオフィシャルサイトの情報を元にしています。 自分の環境では関係ない部分などは省略しているため、お目通しください。 アップグレード - Redmine Guide 日本語訳 サーバ：CentOS Linux release 7.2.1511 (Core) (VM) ※環境依存要素等の確認ができきっていないため、十分に確認の上、実施願います。失敗時の責
このページを最初にブックマークしてみませんか？
『designetwork』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
