サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
夏の料理
kobitosan.hatenablog.com
年末で、ちょうどアドベントカレンダーの枠があったので今年一年の活動を振り返っていこうと思う。 この記事はコネヒト Advent Calendar 2019 21日目の記事です。 2019年は結構自分の働き方が変わった一年でもあったので、下記2点を中心に書いていく。 機械学習の世界に足を踏み入れた アウトプット中心の活動ログ 機械学習の世界に足を踏み入れた 組織の大きな変化もあり、今年から業務として機械学習に取り組んでいる。(元々興味はあったのでチャレンジするいい機会に恵まれたというのが正直なところ) ここでは、機械学習関連のものだけに絞って時系列でどんなことをやっていたのかを振り返ろうと思う。 1〜3月 当時のCTOの @tatsushim がPythonによるはじめての機械学習 という本を執筆しており、そのレビュワーとしてこの本を通じて機械学習を学び始めた。 この本は、機械学習の初学者が
ansibleよりChef派でしたが、エージェント要らなかったり気軽という評判を聞きつけて、今度リリース要件にはansibleがよさそうなのでとりあえず使ってみた。 環境 Mac上にVagrantでCent0S6.6を2台 ansibleサーバ:192.168.50.5 プロビジョン対象:192.168.50.6 EPELのリポジトリを追加してインストール $ sudo rpm -ivh http://ftp.iij.ad.jp/pub/linux/fedora/epel/6/i386/epel-release-6-8.noarch.rpm http://ftp.iij.ad.jp/pub/linux/fedora/epel/6/i386/epel-release-6-8.noarch.rpm を取得中 警告: /var/tmp/rpm-tmp.sZnYCN: ヘッダ V3 RSA/SHA
elasticsearchをローカル内で、別のマウントポイントに移動したいというシーンがあり、すごく簡単にデータ移動が行えたので一応メモとして備忘録 基本的には、elasticsearchのサービスを停止し、データを旧dirから新dirにコピーし、/etc/sysconfig/elasticsearchのDATA_DIRを新dirに向けてサービス再開するだけ。 感覚的には、上記方法でいけると思ったけど不安だったので、@johtaniに質問させていただいて多分いけるとの回答を得たのでいざGO! @shnagai クラスタ名とか変更してなければ、それで行けると思います。(手元で動作させずに回答してます)— Jun Ohtani (@johtani) 2014, 7月 29 ざっくり手順↓ サービス停止 $ sudo /etc/init.d/elasticsearch stop コピー $ pw
久々に面白いイベントだったので、メモを公開。 感想 メモったことそのままで長くなるので最初に感想だけ。 かなり釣り気味のタイトルでしたが、インフラエンジニアがいっぱいいて楽しいイベントでした。 トークしてた人たちが、有名とこの人達だったのでオンプレを否定するような空気は全くなかった。 印象に残ったのは下記の部分 インフラエンジニアという括りはもうない(得意な技術領域の異なるエンジニアがいるだけ) クラウドで環境作るのは簡単だけど、中身を知らないと存在価値ない(裏がどういう仕組みかを知っているかとか中身を知っているのは強みになる) 世間的にアプリエンジニア・インフラエンジニアと言われている人の日常業務を比較すると実はあまり変わらなくて得意な領域が違うだけという世界 インフラの仕事(サーバ構築,適切な監視,必要な検証,障害対応)は変わらないが、ツールのコモディティ化(Chef,Fabricとか
プロダクション環境でElasticsearch+kibana(fluentd)でログ可視化運用をしてみてわかった事でElasticsearchのマッピングについて記事を書いたところ、下記のようなツッコミをいただいたので実際に試してみた。 @johtani ありがとうございます。試してみましたが、APIでindexに対してマッピング追加出来ました。テンプレート+APIで当日分のマッピング追加すれば無駄データは出来ないですね!後で追記しときます。— shnagai (@shnagai) December 22, 2014 内容は、新しいフィールドが追加される時に、事前にスキーマ定義しないと型がStiringのanalyze(分かち書きあり)にされるので、事前にテンプレート作りましょという内容を書いたのですが、既存のインデックスについてもフィールドのスキーマ変更出来るという事でした。 今回の例で
これは Elasticsearch Advent Calendar 2014 22日目の記事です。 今回は、プロダクション環境で、流行りのFluentd+Elasticsearch+Kibanaでログ可視化というのを数ヶ月やった中で苦労した点とかはまった点を書いてみます。 というか、書き終えて思うとこれからやる人はここに気をつけた方がいいというような内容になってしまったので、既に運用されている方にはあまり役に立たないかもです。。 内容は、大きく下記3つです。 ①集計(検索)の条件を考えてtemplateでnot_analyzeを指定しておく ②スキーマ変更があるindexは、日単位でindex作るべし ③数値型フィールドの罠(Fluentd寄りの話) 前提として、この流れで収集しているのは下記4パターンのログ達。 ・Apache accesslog ・Apache errorlog ・Ap
このページを最初にブックマークしてみませんか?
『kobitosan.hatenablog.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く