Graylog provides answers to your team’s security, application, and IT infrastructure questions by enabling you to combine, enrich, correlate, query, and visualize all your log data in one place.
MySQLのインデックスの代わりにElasticsearchを使おうと思い立っていろいろやってみた結果、Elastic社のホスティングけっこうオススメなんじゃないかってなった話です。これです: www.elastic.co 経緯としては、AWSにのっけたサービス、とりあえずMySQLとRedisだけでやってきた仕組みが、そろそろノーキャッシュ新規クエリ単発で1秒以上かかる場合が出てきたというのがあります。 アプリケーションで決まったパターンの問い合わせだけやってるぶんには、問い合わせのパターン数だけ複合インデックを作ればいいし、負荷分散したければリードレプリカが簡単、ということでほとんどの場合MySQLでいいのですが... MySQLは個別のインデックス勝手に組み合わせてくれない、全パターン定義しないといけない 管理者が使う検索機能のよっては、想定したインデックスにうまくヒットしない条件に
この記事は MySQL Casual Advent Calendar 2015 - Qiita Elasticsearch Advent Calendar 2015 - Qiita Hamee Advent Calendar 2015 - Qiita の第4日目です。 TL;DR 開発者の皆さんに、CasualにMySQLスローログを分析しもらうために、Fluentd + Elasticsearch + Kibana でMySQLスロークエリを下図のようにビジュアライズしました。(Kibana上で EXPLAIN の結果も確認できるようにしてあります) ついでに、以下の Fluentd の filter plugin を作成しました。 kikumoto/fluent-plugin-sql_fingerprint · GitHub kikumoto/fluent-plugin-mysql_e
今回は Elasticsearch + Sudachi でユーザー辞書を使う Dockerfile を作ったので作り方を共有します。 Elasticsearchのバージョンは現行の最新(v7.4.0)ですがv6.8あたりでも動くことを確認済みです。 Sudachi とは Sudachi は日本語形態素解析器です。株式会社ワークスアプリケーションズ下の機関であるワークス徳島人工知能NLP研究所が開発しています。複数の分割単位をサポートしているなどの特徴があります。 ドキュメントはこちら https://github.com/WorksApplications/Sudachi/#sudachi-%E6%97%A5%E6%9C%AC%E8%AA%9Ereadme 今回のハンズオンの最終構成 最終的に下記のような構成を目指します。 . ├── docker-compose.yml └── elas
概要 時雨堂が求めている人材について書き出してみた。 現状 技術の募集は常にしているので、興味がある方は申込必要事項を読んで応募してきてほしい、 管理の募集は現在行っていない 総務の募集は現在行っていない 注意 給与については社員全員が同じ事もあり、社員のプライバシーを考慮して公開はしていない。 ただし、最初の @voluntas との雑談時に今までの実績、今期の想定などを隠さず伝えるので安心して頂きたい。 給与 時雨堂の月収は高くはなく、さらに賞与の保証はない。 まずは、この点を理解した上で応募してきてほしい。 賞与 実績として 0 円もあるし、1 人 1200 万円以上もある。 ここ数年は 1 人 1200 万以上を継続しているが、保証は無い。 連絡手段 もし興味があるという人は時雨堂関係者または関係者と繋がっている人を捕まえてほしい。 雇用条件や会社概要については以下を読めば一通り書
2.2. システム処理イメージ ログを解析する仕組みとして、こんなフローを考えてみました。 (1) OpenStackが出力するログを、ログ中継サーバーへ集約する。 (2) 集約したログをElasticsearchとNorikraへ送信する。 (3) Norikraへ送られたログを、SQLストリーミング解析にかける。 (4) 解析の結果は問題の有無に関わらずElasticsearchへ格納し、異常が検出された場合はZabbixへ通知する。 (5) 通常のサーバー監視はZabbixが行う。 (6) (2)、(4)でElasticsearchへ送られたデータはKibanaを使用して可視化する。 図 1 システム処理イメージ 3. ログを収集してグラフ化してみる。 まずは、OpenStackの各コンポーネントが出力するログ量の推移と、API実行数の推移のグラフ化してみました。ログメッセージの内容
こんにちは。はてなチーフエンジニアの id:Songmu です。 去る、6月16日(火)にHatena Engineer Seminar #5をはてな東京オフィス、イベントスペースにて開催いたしました。火曜の夜という時間帯にも関わらず、多数のご参加誠にありがとうございました。 今回は、全文検索やレコメンドエンジン、機械学習などコアな技術について、はてなならではの取り組みをお伝えできたのではないかと思います。 それぞれ短いながらボリュームのある内容であったので、参加者の皆様の頭も疲れたのではないかとも思いますが、その後の懇親会も非常に盛り上がっていたのも開催者として非常に嬉しく思いました。 これからも、定期的にEngineer Seminarを開催し、皆様にはてな内での技術的取り組みをお伝えしていきます。また、アンケートにも皆様熱心にお答えいただきましてありがとうございました。頂きましたフィ
大学外にポートが空いている研究室のサーバに対して,不正なSSHのアクセスが結構来ています. 今回は以下のステップで,不正アクセス元の国をKibana mapで可視化してみました. fluentdでSSHのログから不正アクセスのIPアドレスを解析 GeoIPを使ってIPアドレスから国を特定 Elasticsearchにログを収集 Kibanaのmap panelを使って可視化 GeoIPとは サイトアクセス者の位置情報を取得するGeoIP | SourceForge.JP Magazineより引用. GeoIPとは、IPアドレスを国、都市、インターネットサービスプロバイダ(ISP)にマッピングしたデータベース群である。 そうしたデータとともにC、PHP、Javaその他いくつかの言語を使ってデータベースにアクセスするためのLGPLライセンスのAPIも用意されている。 fluentdでSSHログ
リーガルテック領域のリーディングカンパニーである株式会社LegalForceが、「検索インフラTechTalk!」を開催しました。インフラ領域の中でも「検索インフラ」にフォーカスした今回は、検索インフラに関する具体的な事例や取り組みについて各スピーカーから発表がありました。浜地亮輔氏は、LegalForce社における全文検索インフラ活用事例について話しました。 株式会社LegalForceのSREチームメンバー 浜地亮輔氏(以下、浜地):浜地から発表します。最近風邪気味で、咳き込むことがあるかもしれません。お聞き苦しいところ大変恐縮なんですが、ご了承ください。 まず自己紹介です。浜地亮輔と申します。2020年9月に株式会社LegalForceにジョインして、SRE(サイト・リライアビリティ・エンジニアリング)で仕事をしています。Twitterでは、@aibouというIDで日々活動しています
インメモリデータストアRedisの開発元であるRedis社は、これまでオープンソースとして開発してきたRedis 7.4ソースコードのライセンスを、Redis Source Available License (RSALv2)とServer Side Public License (SSPLv1)のデュアルライセンスに変更すると発表しました。 このライセンス変更により、同社の許可なくRedisを用いたマネージドサービスなどを提供することができなくなります。 下記はライセンス変更を発表した同社ブログ「Redis Adopts Dual Source-Available Licensing」からの引用です。 Under the new license, cloud service providers hosting Redis offerings will no longer be permi
サジェストは、優れた検索エクスペリエンスにおける重要な要素です。一方で、この機能は一部の言語では実装が難しい場合があり、日本語もそのような言語の1つです。このブログでは、日本語のサジェスト機能を実装する際の課題と、Elasticsearchを使用してこれらの課題を克服する方法をご紹介します。 日本語のサジェストの特徴次の図にはGoogleの日本語サジェスト候補を表示しています。この例では、キーワードは「日本」です。 日本語のサジェスト機能の実装が英語よりも困難であることには、いくつかの要因があります。 単語の区切りがわかりにくいサジェストの機能を実装するには、単語を分割するためのアナライザーが必要です。英語を含む大半のヨーロッパ言語では、単語がホワイトスペースで区切られるため、容易に文章を単語に分割できます。しかし、日本語では個々の単語をホワイトスペースで分割することはありません。そのため
0. ログやデータを取得した後は? ログやデータの分析には、様々なアプローチが考えられるが、Apache Solrやelasticsearchといった全文検索エンジン製品にデータを蓄積し、その機能を用いて検索・集計・分析を行う方法がある。その際、データをそのまま蓄積するのではなく、各ツイート・各行に属性を付与(エンリッチメント)することにより、分析の幅は大きく広がる。 全文検索エンジンへのデータの投入では、Flume-ngやfluentdといったデータ収集製品を利用する実例が多い。しかし、リアルタイムにデータに対してエンリッチメントの前処理を行おうとした場合、処理が複雑になるにつれ、単体サーバーで動作するFlume-ngやfluentdでは処理能力が頭打ちになってくる。そこで、登場するのが、リアルタイムに大量のデータを処理することができるストリーミング処理系のビッグデータ関連技術である。
こんにちは。ZOZO研究所の山﨑です。 ZOZO研究所では、検索クエリのサジェスト(以下、サジェスト)や検索後のアイテムの並び順といったZOZOTOWNでの検索改善にも取り組んでいます。 本記事では、ZOZOTOWNにおける実例を交えながら、サジェストの改善方針についてご説明します。 目次 目次 一般的なサジェストの概要 サジェストの分類 サジェストの評価指標 ZOZOTOWNでのサジェストの改善 サジェスト改善のサイクル 1. サジェスト改善方針の仮説 2. KPIの策定 3. サジェストの改善施策 4. ABテストの実施 まとめと今後の改善案 おわりに 一般的なサジェストの概要 はじめに、一般的なサジェストの分類や評価指標を説明します。 サジェストの分類 サジェストとは、検索窓にキーワードが入力された際に関連するクエリを表示する機能を指します。また、本記事ではサジェストに候補として表れ
iPad Air 3(かな?)が楽しみな竹永です。洗濯機はまだ無い。 このところElasticsearchとかKibanaとかばっかり触っていましたが たまには別のツールを触るのも良いと思うのです。 と、いうことで可視化ツールの Grafana を触ってみます。 Grafanaってなに? 可視化ツールです。ダッシュボードを作ってヒャッハーできます。 プラグインの追加でいろいろなところからデータを持ってこれるので簡単にいろいろなデータを可視化することができます。 今のところプラグイン無しで対応しているのは下記のソース。 Graphite Elasticsearch CloudWatch InfluxDB OpenTSDB KairosDB Prometheus プラグイン を入れて試してみたのは下記。 Zabbix …対応しているデータソースがなかなか尖っています。 CloudWatchにひ
割と遊びのつもりで書き始めたら意外と注目が集まってしまって遊びじゃない感じになってきましたが、前回の続きでelasticsearchの運用情報を書いていきます。 @johtani さんにTwitterでElasticSearchのアップグレード情報などを色々と教えていただいたので、また後日検証してまとめてみようと思います。ありがとうございました。 今回は設定周りの情報になります。 そういえば後から見直すことを考えるとどの投稿にどういう情報が乗っているか探すのが大変になりそうだから、索引を作る必要がある気がする。そのうち考えるかも。 JVMのバージョンについて java7を使う場合、特定のバージョンでindexが壊れる問題がLuceneで発生するので避ける必要がある。 Apache Lucene - Welcome to Apache Lucene 具体的にはjava7u25以下またはjav
nazoです。 Elasticsearchを運用する際に、マスタデータはMySQLで持ちたいという場合にどうやって同期をするかというのが問題になります。また、Elasticsearchはバージョンの互換性が厳しく、別バージョンをクラスタに混ぜることは基本的にできず、さらに辞書の更新などを行う場合はインデックスを全て更新しなくてはいけないなどの運用上の課題があります。 今回は社内向けに使っているElasticsearchを、これらの問題を解決しつつどのように運用するかを考えてみましたので、紹介したいと思います。 簡単に MySQLとElasitcsearchの同期は go-mysql-elasticsearch を使います。 無停止のためのデータコピーは elasticsearch-dump を使います。 MySQLとElasitcsearchの同期 go-mysql-elasticsear
Java / Lucene / Elasticsearch Elasticsearchを理解するためにLuceneを使った検索エンジン構築に入門してみた Elasticsearchを理解する為にLuceneに入門しました。今回は簡単な検索エンジンを構築します Overview こんにちは pon です。Elasticsearchで思わぬ挙動にでくわすと、Javaすらやったことのない僕に出来ることはネットの海を彷徨うだけでした。これはよくないと思い、Elasticsearchの仕組みをある程度理解できるように Lucene に入門しました。今回はLuceneのパッケージを利用して簡単な検索エンジンを動かしてみようと思います。Elasticsearch内部でどのようにLuceneを使っているのか知りたい人は必見です。 Lucene とは https://lucene.apache.org/ E
記事の概要を3行でまとめ検索システムの移行や導入は組織化しましょう 指標に気を取られすぎないようにしましょう 検索を見ると様々なドメインに触れるので知識が増えてお得 はじめにnote株式会社で検索エンジニアをしているchovです。 早速ですが、noteでは全文検索エンジンを以下の箇所で利用しています。 ハッシュタグの検索 ユーザの検索 マガジンの検索 記事の検索 メンバーシップの検索 CloudSearchを利用した検索結果これまではCloudSearchを利用していましたが、2022年の4月ごろからElasticsearchへの移行プロジェクトを始め、この記事が公開される2023年2月時点でほとんどの検索をElasticsearchに移行するところまで進みました。 本稿では移行プロジェクトの進め方や検証の手法について解説しますが、これから全文検索エンジンの導入・移行を行う方の参考になれば
こんにちは、 @snuffkin です。 こちらはElastic stack Advent Calendarの5日目の記事となります。 qiita.com 当社では、Elastic StackとX-Packの導入支援サービスを行っていますが、様々な事例に触れるにつれ、「この設定を知っていれば。。。」と思うことがあります。 Elastic Stackの設定が一覧化された資料は存在しないため、詳しく知るには公式ドキュメントをちゃんと読む必要があります。 自分の周囲に話を聞いてもあまり知られていなかったり、ネットで調べてもあまり載っていない設定もあったります。 そこで、重要な設定だけれど意外と知られていないものを中心に、5つほどご紹介します。 Elastic Stackのバージョンは5.6をベースに記述していますが、最近のバージョンであればあまり変わらないと思います。 1. シャード設計 インデ
Amazon Web Services ブログ Amazon Elasticsearch Service をはじめよう: シャード数の算出方法 Dr. Jon Handler (@_searchgeek) は検索技術にスペシャライズした Amazon Web Services のプリンシパルソリューションアーキテクトです。 Elasticsearch および Amazon Elasticsearch Service(Amazon ES) のブログポストシリーズへようこそ。ここでは今後もAWS上でElasticsearchをはじめるにあたって必要な情報を提供していく予定です。 いくつのシャードが必要? Elasticsearchは、大量のデータを、シャードと呼ばれる細かいユニットに分割し、それらのシャードを複数のインスタンスに分散して保持します。Elasticsearchではインデックス作成
Hello world, @cero_t です。 少し肌寒い日が続きますが、皆さんいかがお過ごしでしょうか。 寒いのは決して僕のせいではないからね、そう周りに言い聞かせながら生き抜く日々です。 さて、 ついにElastic Stack 5.0.0のGA版がリリースされました!! https://www.elastic.co/jp/blog/elastic-stack-5-0-0-released 既にリリースされたalpha版やRC版などを触っていますが、2.x系から新機能が追加されただけでなく、性能や安定性、またユーザビリティが向上している体感があり、積極的にこの新版を使っていきたいと思っているところです。 Elastic Stack 5.0.0の新機能 公式ブログでもいくつか紹介されていますが、2.xから5.0ではピックアップしきれないほどの変更点があります。私なりに重要だと思っている
docker環境で開発を行っていると、いろんなログをコンテナに入って閲覧したりするのがめんどくさいし、見ずらいので、どこか一箇所で見れるようにしたいと思い、docker作ってみました。 一式をGitHubに公開してますので、是非。 https://github.com/yuya-sega/log-viewer/ 構成 apache 2.4 postgres 12 fluentd 1.6.2-1.0 elasticsearch 7.3.2 kibana 7.3.2 まずは起動してみる $ git clone https://github.com/yuya-sega/log-viewer.git $ cd log-viewer/ $ docker-compose build && docker-compose up ~~ 略 ~~ kibana_1 | {"type":"log","@time
※ 5系は2016/02/20時点ではまだ開発中のフェーズです。 はじめに 藤本@シアトルです。Airbnbの宿がなかなか見つからず、深夜0時過ぎのシアトルを30分ほど彷徨いました。。一桁気温の中の野宿がよぎり怖かったです。 さて、Elastic{ON}2016でELKBスタックの次期バージョンが5系になると発表がありました。 Opening Keynoteや各プロダクトのOverviewセッションで度々新しい機能が紹介され、ワクワクさせられました。 現在はまだα版を準備中の段階で、触ることができません。 と思っていたら、Githubを覗いたところ、5.0.0-SNAPSHOTが公開されていました。まだα版にもなっていないので機能的には不完全かもしれませんが、雰囲気だけ味わってみました。 Kibanaインストール Githubからコードを取得します。 # git clone https:/
マッピングタイプを使いすぎないようにする Elasticsearchでは1つのインデックスの中に複数の異なるスキーマ定義を持つことができる。このスキーマ定義をマッピングタイプという。単に「タイプ」と呼ばれる事もある。フィールドのデータタイプとは別の概念。インデックスはデータベースに、マッピングタイプはその中のテーブルに例えられる事が多いが、同じ名前のフィールドはマッピングタイプが異なっていても定義が共有されたりして、データベースのテーブルほど互いに独立していない中途半端なものになっている。(2.0より前のバージョンではタイプごとにフィールド定義が異なっていても多少使えたりしたが、2.0以降は厳密に禁止されるようになった. 参照:Conflicting field mappings) タイプが異なっていてもデータは同じLuceneインデックスの中に混ざって入ってしまうため、タイプ間で互いに影
※この記事は、"Blog Series of Introduction of Developer Productivity Engineering at Mercariの一環で書かれています。 はじめに こんにちは、メルカリ、サーチインフラチームのshinpeiです。今回はメルカリの検索基盤の裏側について、そのアーキテクチャ変遷について書こうと思います。2018~2021年の4年間で、大きく3回、変化をしました。設計の段階では希望と期待にあふれているアーキテクチャでも、問題は後からやってきます。設計には良し悪しがあり、変化することで知見を得ながら、改善を続けています。え、これだと危ないのでは?、、あぁ、やはりそうなるのね。などと、ご笑覧いただければ幸いです。 前回までのお話 メルカリの検索は、創業時から、Solrをベースにしたシステムで組まれてました。その変遷はこちらのスライドにまとめてあ
これは Elasticsearch Advent Calendar 2014 22日目の記事です。 今回は、プロダクション環境で、流行りのFluentd+Elasticsearch+Kibanaでログ可視化というのを数ヶ月やった中で苦労した点とかはまった点を書いてみます。 というか、書き終えて思うとこれからやる人はここに気をつけた方がいいというような内容になってしまったので、既に運用されている方にはあまり役に立たないかもです。。 内容は、大きく下記3つです。 ①集計(検索)の条件を考えてtemplateでnot_analyzeを指定しておく ②スキーマ変更があるindexは、日単位でindex作るべし ③数値型フィールドの罠(Fluentd寄りの話) 前提として、この流れで収集しているのは下記4パターンのログ達。 ・Apache accesslog ・Apache errorlog ・Ap
はじめに 藤本です。 Elasticsearchにデータ投入する方法を調べる機会がありましたので、今回はいくつかのファイルをデータソースにElasticsearchへデータ投入する方法をご紹介します。 概要 Elasticsearchはリアルタイムデータ分析、ログ解析、全文検索など様々なユースケースで活用することができます。例えば、Excelでデータ蓄積して、グラフ化・集計を行っているのであれば、Elasticsearchにデータ投入して、Kibanaで可視化することができます。ログをSyslogで集約して、grepやawkを駆使してパフォーマンス解析しているのであれば、logstashやfluentdなどでメッセージ解析し、Elasticsearchに集約、Kibanaで可視化することができます。ブログサイトの記事をDBに投入していてアプリケーションによって検索処理ロジックを実装している
こんにちは、アプリケーション基盤チームの渡辺です。IntelliJのコード補完はCtrl+;にバインドしています。 アプリケーション基盤チームでは、Necoプロジェクト(アーキテクチャ刷新プロジェクト)の一環として、 次世代の検索基盤を検討していて、その候補としてElasticsearchを調査しています。 先月の記事で再インデクシングと絡めてingest pluginの話をして、 びっくりするぐらい需要が低く、自分のテーマ選択のセンスのなさを痛感したのですが、 こじらせた感じで今日も再インデクシングの話をしたいと思います。 想定読者は、Elasticsearchにある程度慣れている方として、用語やAPI(インデックス, シャード, ScrollAPI, BulkAPIなど)の説明は最小限にします。 利用したElasticsearchのバージョンは5.0.0-alpha4です。2.X系だと
こんにちは。kimukimuです。 AWS re:Invent 2013 で Amazon Kinesis が発表されるなど、 ストリームデータ処理に対するニーズの高まりを感じますね。 (Amazon Kinesis は、Stormとも連携できるようになっているようです)。 さて、先日、Storm 0.9.0 が正式リリースされたり、Apache Kafka 0.8.0 が正式リリースされたりしたので、 それらを連携して、ストリームデータの可視化を行うプロトタイプを作ってみました。 1. はじめに まず、「ストリームデータ」とは、連続的に発生し続けるデータのことを指します。 システムが出力するログやセンサーが発生するデータ、SNSなどで常時発生するメッセージなどが該当します。 今回は、Apacheが出力するログを、ストリームデータとして収集・可視化することを行ってみます。 1-1.やりたい
はじめに Elasticsearchの公式チュートリアルやってみました。 公式ドキュメント以外にも色々調べながら進めたのですが、「7.0系(type新規作成廃止後)」×「Docker」の記事が少なかったので、備忘も兼ねたまとめです。 Elasticsearchとは Elasticsearchは、オープソースの高スケーラブルな全文検索および分析エンジンです。大容量のデータをすばやく、ほぼリアルタイムで保存、検索、分析できます。通常、検索の機能と要件が複雑なアプリケーションを強化する基礎となるエンジン/技術として使用されます。 (Elasticsearchリファレンスより) つまり、めっちゃ検索ができるすごいミドルウェアです。 座学 実際に触る前にお勉強です。 用語とイメージ 論理構成 点線で囲った部分がElasticsearchの外側から見た構成(論理構成)です。 cluster > ind
Wantedly インフラチームエンジニアの藤田 (@dtan4) です。今回は、社内で運用している PaaS である Paus の紹介をします。 社内 PaaS の必要性Wantedly ではデプロイ環境として本番環境とステージング環境が用意されていました。ここで、エンジニアが増えるに連れステージング環境の順番待ちが起こるようになってきました。原則として、フィーチャブランチはステージング環境で動作確認をした後本番環境にデプロイすることになっています。そのため、ステージング環境での確認が遅れることは新機能 / 修正のリリース速度低下につながっていました。 また、新サービスを開発する際の動作基盤構築にかかる工数も問題になってきました。従来だと新しいサービス向けの動作基盤を構築するのに丸1日費やしていました。これはリリース前の検証環境においても同様です。このため、メインサービスの www.wa
これは Elasticsearch Advent Calendar 2015 8日目の記事です。 ログの可視化ツールとしてKibanaを使っている中で、Elasticsearch運用として色々と得られた知見を書きたいと思います。 Elasticsearchは、ライトな環境だったら特にチューニングなく安定してますがある程度ドキュメント数が積まれてくると、色々苦労があるなという印象です。 ここに書かれているのは、事情がありシングル構成で頑張った話なので、クラスタ組んでスケールするとこんな悩みはないのかもです。 でも、ログは運用系に入るのでそんなにコストかけれるとこはないのではという個人的な所感。 ラインナップとしては、下記のような感じです。 Kibana経由で重たいクエリが投げられると負荷高すぎて泣いた話 高負荷対策として、fielddata_cacheをディスクに逃がす方法 fluentdの
システム障害の原因調査や、稼働状況の確認のためにログの中身を確認することがよくあります。しかし、ログが大量に出力されていたり、複数の場所に分散して出力されていたりすると、それを確認するために多くの手間と時間がかかってしまいます。 これらの課題解決の方法として、ここ最近主流となっているのが、複数のOSS(オープンソースソフトウェア)ツールを組み合わせてログの収集や検索、可視化ができる基盤(ログ基盤)を構築することです。 その中で特に代表的なものが、「Fluentd」(ログの集約)、「Elasticsearch」(ログの検索)、「Kibana」(ログの可視化)であり、本連載では、これらのログ基盤を実現するツールについて、構築方法や利用方法、実際の案件で使ったときの事例、さらにはログ基盤に関連する最新の情報を紹介していきます。 連載第1回の本稿では、Fluentd、Elasticsearch、K
※この記事は次のブログを翻訳したものになります。 原文:kibana 4. literally. Kibana 4は現在、文字通り、抽象的に、概念的に、精神的に、そしてとても楽しく、プロダクションレディになりました。 1週間前に準備はできていましたが、満足できるものであるという確信を得たいと思っていました。 そして、Kibana 4.0.0 GAをリリースしました。 次のものはサンプルのスクリーンショットと前日譚です。 これらに興奮してしまった方のために、2ステップのプランを用意しました。 ダウンロードする:Kibana 4 downloadsページからダウンロードします。 理解する:Kibana 4 docsページを読んで理解します。 Tip : もし、まだ、あなたのクラスタがElasticsearch 1.4.4でない場合は、アップグレードする必要があります。 Tip2 : Kiban
はじめに 当エントリはDevelopers.IOで弊社AWSチームによる2015年アドベントカレンダー 『AWS サービス別 再入門アドベントカレンダー 2015』の17日目のエントリです。昨日16日目のエントリは鈴木の『Amazoon Kinesis』でした。 このアドベントカレンダーの企画は、普段AWSサービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。 本日18日目のテーマは『Amazon Elasticsearch Service』です。2015/10/1にリリースと約2ヶ月半前にリリースされたサービスなので再入門と呼ぶには少し微妙な感じはありますが。。。 目次 サービスの基本的な説明 Elasticsearchとは Amazon Elastic
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く