涅槃を目指す @ryotarokobayashi - Tumblr Blog

Posts

久しぶりに投稿

ネガティブなことばかり言う人が多い職場は嫌だな

もう精神的に限界な気がする

SRE Lounge #11 に行ってきた

2019/10/29 にサイボウズ東京オフィスで開かれた SRE Lounge #11 に参加しました。

eureka さん、サイボウズさん、Repro さん、各社SREの取り組みの話を伺う事が出来ました。

eurekaのパフォーマンス定点観測会の取り組み紹介2019 @dharada1/@kai_ten_sushi さん

パフォ会っていうのをやっている

APIチームとSREチームのパフォ会

可用性やパフォーマンス向上を目的とした週次MTG

SREとAPIチームでやってる

基本的にDatadogのメトリクスを集めてて、それを見る回

この会で発生するタスクは3つまでという制限

事業から見た優先度が低く、枝葉のタスクに集中しないような仕組み

SLIとSLO

SLIは（総リクエスト-500系エラーリクエスト）/総リクエスト数

SLO：99.5%

エンドポイントごとのレスポンスタイム

nginxのログをBigqueryにいれてLambdaで集計

DBパフォーマンスも見てる

スロークエリ

デッドロック

Toil

Oncall対応とかを棚卸

SREだけのパフォ会

従量課金のコスト監視

バジェット

インフラのメトリクス

断捨離とキャパプラ

パフォーマンスの異常検知

コストパフォーマンスは悪化してないか

アラートの断捨離

なり続けているalertはないか

どのアラートが何回なったか

曜日×時間のヒートマップ

週ごとのアラート件数

パフォ会で得た知見

指標化は大事

SLI

SLIからブレイクダウン可能な形でメトリクスを可視化

何を見るか/意識するか

KPI Treeとかを作ってもいいかも

SLO

合意された目標

目標・会議体を常に澪直していく

課題感は常に変わる

指標化と目標設定、注力する部分の見直しが必要

ツールに集約するのは大事

Datadogは扱いやすい

本質的な仕事に集約

質問

ただの閲覧と決済系では、同じ500エラーでも重みが違う場合があるがその辺の考慮はしているか

課題として認識してる。考慮中

Cybozuにおける大規模インフラ基盤の移行プロジェクトManekiの紹介 Cybozu @_a0i さん

サービス成長に伴って、データ量も大きくなってるので、基盤移行プロジェクト（Neco)が動き出した

k8s、Ceph、Rookが中心

移行プロジェクトがManeki

Necoチームと移行専門のManekiチームがいる

検索基盤の移行

Elasticsearchが1つで、Diskが複数だった構成から、マルチノードのElasticsearchに移行

Elastic Cloud on Kubernetes

indexのサイズ制限をしなかったので1TB級のindexが生まれた

indexをshardに分割しようにも、分けすぎたり大きすぎたりすると遅くな

k8sの課題

yamlの管理

ArgoCDを使ってる、Gitにpushするとデプロイしてくれる

環境ごとにymlを書き換えたい

kustomizeつかう。ベースのYAMLをカスタマイズする

ArgoCDと組み合わせ

監視

PromethuesとGrafana、pagerdutyも使ってる

質問

ログ基盤はどうする予定なのか

Lokiを考えている

安定・安価な ECS auto scaling を目指して Repro @a_bicky さん

ECS使ってautoscalingしたい

ECSの基礎

Task Definitions

1つ以上のコンテナの定義

Tasks

Task Definitionsから生まれたコンテナ群

Task Definitions=クラス、Tasks=インスタンス

Services

Task をdesired countの数だけ起動する

Clusters

taskを動かすためのハコ

ECS Autoscaler

Cloudwatchのalermの状態をもとに、ECSのdesired countを増減する

Spot instanceのinterruption warningをうけとったらdrainingする

Fargateは起動が遅かったり割高なので不採用。バッチでは使ってる

ECS autoscalingの課題

やみくもにdesired countを増やすと起動に時間がかかる時がある

AZの均衡が崩れるとtaskが動いているインスタンスでも落とされる

これからの課題

解像度1分のCloudwatch Metricsだとautoscalingが間に合わないことがある

明らかに異常なリクエストがあっても許容している

Fargateやk8sの検証をやりたい

SREの守備範囲が広がりすぎている

感想

作って終わりではないSaaS型サービスが主流の今、SREのようなRoleはますます重要度を増すと思います。

目的をしっかりと捉えつつ、SLIやSLOといった指標の定義、k8sやprometheus、ECS Autoscalingといった流行りの手段を用いて解決に向かっている姿勢が印象的でした。

当日の様子は togetter にもあるので合わせてご参照ください。

また来年にはSREが主体の大型イベント SRE NEXT が開催されます。

登壇者＆運営のみなさんありがとうございました。

#sre #srelounge

nixcraft

Kubernetes networking ;)

JAWS-UG コンテナ支部 #13 に行ってきた

JAWS-UG コンテナ支部 #13 に行ってました。JAWSのイベントは今回が初めてです。

その想い出をWillgate Advent Calendar 2018 の22日目として書きます。

AWS サービスアップデート @toricls

ECSとFargateにタグ付け可能になってコストやリソースの用途把握が簡単になった

ECSでタスクに対してより安全に秘密情報を渡せるように

AWS Cloud Map

すべてのクラウドリソースの動的な地図を作れる

DNSのようにサービスを名前で管理する

属性情報を持てるのでバージョンも表現可能！変更後の伝搬は5秒くらい

Cloud MapはAWSサービスだけじゃなくk8sやIstioとも喋れる

App Mesh

App MeshはEnvoyを使ってる。サイドカーコンテナに共通処理をやらせてる

今はプレビュー版。コンソールはなくてCLIとかSDK経由でAPIたたく

Fargate

ログドライバー追加予定（fluentd,syslog）

EKSでは同時に3バーションのKubernetesをサポート

Kubernetes on AWS ベストプラクティス @mumoshu

EKSの特徴

Masterの無停止バージョンアップ

AWSによる自動セキュリティパッチ

VPC、IAM、CloudMapとの統合

kub-aws、kopsのスコープの違い

kops：terraformで様々なホストOSに対応

kube-aws：Cloudformationでクラスタ作成

EKSとは何か

kubernetes control plane のマネージドサービス

今日から始める場合

小さく始める。トライアルならManagedで始める

CloudWatch Logs や CloudWatch Metrics などと組み合わせる

Lambda・EKS・ECSの選択

単発のものならLambda

シンプルにコンテナ使いたいならECSやFargate

k8sの高い拡張性やPaaS基盤的なものが欲しいならEKSやk8s

初心者はkubectl,ubedns,eksctl あたりから始めるとよさそう

運用のコツ

EC2メタデータサービスは無効にしないとセキュリティホールに

PersistentVolumeは使わず、RDSやS3のようなもマネージドなものを検討する

Ingress と ELBみたいな機能重複が多いのでよく考える。AWSにロックインされた方がいいのでは

クラスタを分けて全部落ちるのを防ぐ（AZ単位とか）。爆発半径を小さく

Firecracker とは何か - AWS はなぜ軽量 VM を作り私たちはそこから何を享受できるのか @pottava

AWSはなぜ作ったのか

Lambdaは現在EC2ベース

次世代のサーバーレス基盤が欲しい

もっと高速で軽量なhyper-visorが欲しい

Firecracker とは何か

コンテナのためのQEMU代替

VM内でinitプロセスが走るまで125ms以内

firecracker-containerd というランタイムも開発中

以下はLTです

envoyをわかりやすく伝える @_mpon

雰囲気でEnvoyを理解していた僕には非常にありがたいお話でした。 Nginxと比較して語ってくれたのでとても分かりやすかったです。

詳細な解説はre:Invent 2018 で発表されたAWS App Meshの仕組みを解説しますを見てください。

EKSとExternalDNSとACMを利用して、いい感じにHTTPSでサービス公開をしてみた @sugimount

EKSとExternalDNSとACMを使ってHTTPSサービスを公開するまでのチュートリアルを紹介してくれました。ハマりどころがいくつかあったそうですが、これを見ればスムーズに作れそうだと感じました。

GameDay @ re:Invent のこと

英語があまりしゃべれないけど AWS re:Invent でGameDay で外国人と協力して頑張ったお話。つたない英語でも役に立つアピールで頑張って優勝したそうです！なんというメンタル…

Virtual Kubelet + Fargate + EKSでノードレスKubernetesを夢見た話 @bbrfkr

kubernetes外のAPIにPOD作成を依頼できる Virtual Kubelet を使ってノードレス Kubernetes を作成するデモを見せてくれました。

感想

初めてのJAWSだったのですが、量、質ともの凄くレベルが高くて勉強になりました。僕は普段 Rancher JPの運営をやってるのですが、負けないように頑張ろうと思いました。

個人的には @mumoshu さんの発表が衝撃で、内容の濃さもさることなんですが、特にAWSとk8sで競合する機能があればAWSを選ぶという考えはとても新鮮でした。

僕自身、CloudStackやRancherといった特定のクラウドやベンダーに依存しないOSSからこの世界に傾倒していった人間なせいか、そういった観点は全くなく、クラウドネイティブに縛られずに、それぞれのクラウドの特性を活かして自分らの欲しいものを作り上げていくという考えは非常に新鮮ででした。僕自身が「クラウドネイティブ」というものにロックインされていたのかもしれませんね。

ただ、そうなってくるとインフラエンジニアと呼ばれる人たちは、非常にたくさんの選択肢の中から自分らの欲しいもの、時には顧客が望むものを作ることになって、これはなかなかシンドイ話ではないのか。とも思いました。

とにかくおなか一杯になった大変有意義な勉強会でした。運営、登壇者の皆様ありがとうございました。

#technology #aws #container #kubernetes

ssmjp 2018/10に参加してきた

ssmjp 2018/10 Ansibleを語る回@dmm.com に参加してきました。

今回はAnsibleのお話です。

Ansible ではじめるサーバー・ネットワークの自動化 (Ansible2.7情報つき)@akira6592さん

Ansibleではじめるサーバー・ネットワークの自動化（2018/10/12） from akira6592

Ansibleの概要としては

シンプル（Playbook）

パワフル（多数のモジュールがあってサーバ、クラウド、NW機器向

エージェントレス

というのがあり、シェルと比較すると

モジュールを利用することでコマンドを直接書かなくてよい

エラーの扱いが楽

冪等性がある

ほかのAnsibleと連携できる

などの特徴がある。動作環境はPython環境があればよい。

Ansibleの構成要素としては

インベントリ：対象のホスト情報（IPアドレス、ホスト名。グループ化も可能）

モジュール：機能単位。利用するモジュールとオプションを利用。yumモジュールやios_configモジュールなど、現在は1900以上ある。（モジュール一覧はコチラ）

Playbook：構成定義。YAMLフォーマット。スペースの数で構造定義をしてる

ansible.cfg：環境設定。Ansibleの動作を決める

2.7アップデート情報は

230以上のモジュール追加(GCP絡みが増えた）

コントロールノードでPython2.6非サポート

pipモジュールで、nameのリスト指定とバージョンが併用可能になった

無効なタスク属性がデフォルトでエラーに（2.6まではWARNING)

CHANGELOGはコチラ

やはり公式文書を参考にして色々なモジュールを探したりしながらやっていくのが基本みたいです。

定期的にもくもく会を開催していたり、Slackもあるので気楽に参加して下さいとのことです。

Ansibleで始めるNW設定の自動化について〜Cisco(VIRL)編〜 (仮)@すがいさん

AnsibleではじめるNW設定の自動化について - Cisco(VIRL)編 - from Yasuyuki Sugai

モジュールを使って色々なNW機器に設定できるんだけど、イマイチ情報が少ないので実演してみるというお話。

まずVIRLの紹介

CiscoのNWシミュレータ。有償だけど便利

環境をVMイメージで配布

スペックは結構求められる

NW構成の作成も自由に簡単にできる

VIRL外のNWにも接続可能

他ベンダーのOS（BigIPとかFortigate）も搭載可能

VIRLはOpenstack構成

最大5ノードでクラスタを組める

次はngrokの紹介

ローカルのPORTをSSHトンネルで公開できるngrok（https://ngrok.com/）が便利

実際にやってみる

モジュールがたくさんあるので公式から探す

モジュールだけではできないことがまだあるので、割り切りが大事

ios_configモジュールというコマンドを直接送り込むこともできる。show run との差分を見てから実行する

playbookを固定化し、動的なものは変数化したい

NW自動化に向けた課題

複雑になり定型化できない

管理するパラメータが多い

問題があった時の切り戻し

質疑応答

Q.初期はipアドレスすらない状態だが、そういったところの自動化はどうするのか。

A.初期設定はどうしても手作業になっちゃうけど、変更の多いNW機器だとメリットがあるのでは。

@akira6592さんからの回答

IP到達性のないネットワーク機器をコンソールサーバー経由Ansibleで操作するというのを、Interopでセイコーソリューションズさんが参考出展されていました。 #ssmjp https://t.co/WijJPg0J6B

— よこち(yokochi) (@akira6592)

2018年10月12日

Q.モジュールの粒度が細かいので、まとまった便利なモジュールないのか。探すのが面倒

A.ないので、機器に対応したものを選ばないとだめ。モジュールはベンダー機器に合わせたものをキャッチアップしていくほうが確実

残念な現場にAnsibleを適応してみた過去と現在と未来@togakushiさん

割と非公開ネタ114ページ

残念な情報は非公開。面倒かつ非効率なことが多く大変なところにAnsible導入

踏み台が複数あるような複雑な環境も工夫してAnsibleで乗り切れた

変化を認めないおっさんたちを理論武装して蹴散らした

#technology #ssmjp

転職日記 - SIerからWebへ -

本日から株式会社ウィルゲートにて働きます！よろしくお願いしまっす！

SIerからWeb系への転身です。

あとはおっさんの転職ポエムが続くので、気になる人だけ見てください。

この道を行けばどうなるものか　危ぶむなかれ　危ぶめば道はなし　踏み出せばその一足が道となり　その一足が道となる　迷わず行けよ　行けばわかるさ - アントニオ猪木 -

転職の動機

僕は40くらいのオッサンで、30まではフラフラと飲食店で働いたりしてました。

30で前職である中小SIerに何とか滑り込んで、そこで最初の2年はCOBOLerで銀行とか信販とかでExcelにお絵かきをしていたのですが、コンピュータサイエンスからかけ離れたこの現状があまりにもおかしいと思ったので、インフラエンジニアに志願して Oracle の資格を取得し、 OracleDatabase の設計構築を2年ほど行いました。

そうこうしてるうちに自社がサーバ室をちゃんと構えられる自社ビルを建て、そこにプライベートクラウドを構築し、自社サービスを展開する事になりました。

「お前ひとりでなんかそういう基盤を作れ」という雑な指示のもと一人で自社サービスの基盤としてのプライベートクラウドを構築し、そのまま自社サービスのインフラ担当兼、開発環境や勤怠管理といった自社システムの管理。いわゆる一人情シス状態を5年くらいやりました。

しかし、このまま下請けSI会社でやって行く不安と、会社として自社サービスに対する投資をちょっと控える動きがあり、自分の手でサービスを作ってお客様に使って頂いたのが凄く嬉しかった僕は転職を考えるようになりました。

やった事

まずエージェントに相談しました。このツイートは去年の12月ですね。

そこで「まぁ確かにオッサンだけど、そんなに糞スキルでもないから何とかなるんじゃない？」とか言われて安心しました。

でも12月からずーっと転職活動してたわけではなく、転職サイトをチラチラ見るくらいの転職活動とは言えないくらいの状態が続き、そして夏に一大決心をして本格的に活動を始めました。

条件としてはこんな感じです。我ながらフワッとしてます。

年収が下がらない

下請けのSIとかじゃなく、自社でビジネスをちゃんと回せてる

インフラエンジニアとして働ける

チャレンジできる土壌がある

ビズリーチに登録しつつ、2社のエージェントに紹介してもらう形を取りました。

エージェントに「自社サービスをやってる会社のインフラ or 社内SE」という条件で探してもらったら90社くらい紹介されて辟易としました。「こういうことをやりたい」とか「この会社に入りたい」みたいなのがハッキリとしない状態で辞めること自体を目的とすると結構悩みそうですね。

それ以外にも「YOU！ウチくる？」みたいな感じで声をかけてもらい、いわゆるリファラル採用での選考もして頂きました。2社とも立派な企業だったので声をかけてもらうだけでも嬉しかったです。

職務経歴書を真面目に書いたのが良かったのか、ビズリーチ経由で企業から直接のスカウトも何社か頂きました。

また、転職日記 -三日目- にも書きましたが、OSSコミュニティ経由で知り合った渋谷の社長に相談に乗って頂いたのも有難かったです。

結果

22社受けて結果としては

書類選考でお祈り：13社

面接でお祈り：5社

面接で辞退：2社

内定：2社

となりました。

実際の転職活動期間は1.5か月くらいです。複数社を受けていたので面接のスケジュール調整をしてくれたエージェントには助けられました。

お祈りの理由で多かったのは「オッサンの癖にこれといった強みがない」でした。一人情シスは守備範囲の広さを要求される場面が多く、その状況に甘え、強みを作ろうとしなかった自分の責任であります。アピールも上手くなかったかなぁ…自己アピールの素振りもっとやっておけばよかったな…

こっちの職務経歴書を半笑いで見たり、自己紹介中に吹き出されたりという屈辱も味わいました。終わったことだからもういいけど、どうか地獄の業火に焼かれるか、親知らずが無限に生え続ける呪いにかかって下さい。

内定貰った時はホントに嬉しくてスタバで変な声出そうでした。

内定のポイントとしては、オンプレからクラウドまでの両環境において非機能要件定義から運用までの経験があるっていうのが良かったみたいです。幅の広さが評価されました。

幸運にも2社から内定頂いて結構悩んだんですけどウィルゲートに決めました。

決め手は以下4点

社長や経営層の描くビジョンが社員まで浸透してる

色々とチャレンジしててなんか面白そう

面接して頂いた方々の感じが良かった

直近3年の決算公告見る限り堅調

ウィルゲートはエージェント経由ではなく、ビズリーチ経由で直接スカウトを頂いた会社でした。

ありがとう！ビズリーチ！ごめんねエージェント

今後

Rancherと私にも書きましたが、 CloudStackユーザ会、Rancher JP、OSPNといったOSSコミュニティの方々と関わるようになってから人生が変わったと思ってます。SIで現場に出てるときより遥かに世界が広がりました。

OUTPUTしろ！とか起業しろ！とまでは言いませんが自分以外の世界を知るのはいい機会だと思うので、なんか煮詰まってる方は、何らかの勉強会とかコミュニティに接してみることをお勧めします。

今後もこういった活動は継続していき、自身の強みを作り社会や会社やいろんな人に貢献していきたいと考えています。

#careerchange

XenServerのinode枯渇事件

XenServer の inode が枯渇したというお話。とっくに解決した問題なんですが、備忘のためにメモします。

調子の悪くなった XenServer を発見。ssh はいいんだけど、API を使った連携もできず、XAPI(管理ツール)の再起動もできない。バージョンは6.2と古くてサポート切れ。

なんだよもーって感じで調べるも、なんでかわからん。本番稼働中なので再起動も許されない。冗長化してるんだけど、VM移動の瞬間停止すら駄目って鬼畜かよ。

なんか変だなー怖いなーって稲川淳二っぽく色々調べてたらこれですよ

# df -i Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sda1 524288 524288 0 100% / none 94257 8 94249 1% /dev/shm /opt/xensource/packages/iso/XenCenter.iso 0 0 0 - /var/xen/xc-install

inodeが枯渇！なんで？

どこのどいつだって調べていったらこいつですわ

# find / -xdev -printf '%h\n' | sort | uniq -c | sort -k 1 -n -r |more 480750 /var/lock/sm/lvm-e2e73bc8-7db3-f061-22e9-0345bacb5229 1056 /var/xapi/blobs/messages/uuids 1056 /var/xapi/blobs/messages/refs 1056 /var/xapi/blobs/messages/gen 777 /usr/share/man/man1 666 /usr/bin 586 /usr/share/man/man3 585 /usr/lib/python2.4 560 /usr/share/locale

/var/lock/sm/lvm-e2e73bc8-7db3-f061-22e9-0345bacb5229 ていうディレクトリに48万個のファイル？

どうも lock ファイルみたいなのがいっぱい入ってる。うかつに消せないしどうしよう。

XenServer 使ってる人あんま居ないし…

なので海外のフォーラム「Citrix Forums - Discussions」で聞いてみました。なんか本家っぽいし強そうだ。

高校の時に取った英検2級を武器にスレ立てました。緊張したなー。

作ったのがこのスレ inode is Almost empty - Command-Line Interface - Discussions

立てて数時間後にはレスが来て嬉しかった。やっぱ本場は違うね。

立てた後に、なんで A だけ大文字なんだとか思ったけど、誰もそんな野暮な突込みはせずに優しく教えてくれた。

2人に回答してもらいました。一人はアーカンソー州ロジャース市の職員？もう一人はCitrix Technology Professional かつ NVIDIA GPU Community Advocacy。NVIDIAのGPUコミュニティの提唱者？エバンジェリスト的な人なのかな？。

2人のアドバイスを要約すると

こんなの始めてみたw

起動後のは触れないけど、古いロックファイルは消えるはずだけどなあ

/var/log の中消すか、他のストレージにvm移せば綺麗になるかもなあ

SR（ストレージリポジトリ）のロックファイルっぽいけど、そんなにinode消費してる理由は知らんわ

てかその XenServer 古くね？セキュリティ的な問題もあるから更新しろよw

ですよねー。更新しろって話ですよね。

このあとおとなしく最新化しました。「df -i」に気づくのに二日かかりました。

ZABBIXとかでinodeもちゃんと監視しないとダメだね。反省。。。

#technology #xenserver

XenServerがハングした思い出

2台構成のpoolのmasterと通信できなくなった… XenServerのバージョンは7.1

xencenterはこんなエラー

サーバのコンソールはこんな感じで操作不能

sshで接続してみよう

# ssh root@ipアドレス ssh_exchange_identification: Connection closed by remote host

え？なんで？

# ssh -v root@ipアドレス OpenSSH_6.6.1, OpenSSL 1.0.1e-fips 11 Feb 2013 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 56: Applying options for * debug1: Connecting to ipアドレス [ipアドレス] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: identity file /root/.ssh/id_rsa type 1 debug1: identity file /root/.ssh/id_rsa-cert type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: identity file /root/.ssh/id_dsa-cert type -1 debug1: identity file /root/.ssh/id_ecdsa type -1 debug1: identity file /root/.ssh/id_ecdsa-cert type -1 debug1: identity file /root/.ssh/id_ed25519 type -1 debug1: identity file /root/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.6.1 ssh_exchange_identification: Connection closed by remote host

なんやのー

~/.ssh/known_hosts 消してもダメ

XenServerは多くの通信で tcp/443 を使う。XenCenterとの通信もだ。curlしてみよう。

マトモなXenServerにつなぐとこうなる

# curl --insecure -D - -o /dev/null https://ipアドレス:443 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0HTTP/1.1 200 OK content-length: 4426 connection:keep-alive content-type:text/html 100 4426 100 4426 0 0 33036 0 --:--:-- --:--:-- --:--:-- 33278

んで、繋がらない方にcurlしてみると

EOFて何でやねん。

slaveにログインしてxeコマンド

# xe pool-list The server failed to handle your request, due to an internal error. The given message may give details useful for debugging the problem. # xe host-list The server failed to handle your request, due to an internal error. The given message may give details useful for debugging the problem. message: INTERNAL_ERROR: [ Cli_protocol.Unmarshal_failure(_, "") ] # xe vm-list The server failed to handle your request, due to an internal error. The given message may give details useful for debugging the problem. message: Xmlrpc_client.Stunnel_connection_fail

まとめると

コンソール：操作不能

ssh：×

tcp/4443：×

xeコマンド：×

なんすかこれ

なんなんすかこれ

どうせっちゅうのよ。。。。マスタ上のvmは稼働してるので、下手に手が出せん。

せめてマスタ上のvmを正常稼働してるslaveにマイグレーションしたい

# xe vm-migrate host=ccndmg01 The server failed to handle your request, due to an internal error. The given message may give details useful for debugging the problem. message: Xmlrpc_client.Stunnel_connection_failed

やっぱ通信できないから無理だよねそりゃ

vmには通信できるから、Dom0に通信できなくなってるんだよな。はぁ

IMMで見てもサーバに異常は起きていない。どー見ても異常なんですけど

Dom0がハングしてるんだろうな。強制再起動しかないか…

24時間たっても状況変わらずなので強制再起動した。なーむー

無事再起動できた！vmも大丈夫！やれやれだぜ

しかしなんでハングしたんだろ？

ログ見てみるか

何も出てねえ…

てか、sarのログなんかは普通に出てるんだよな…NICだけハング？

何だったんだ一体…

#xenserver #technology

nokoto55

例えばですが、長年使っていた靴が古くなってしまったので、そろそろ買い換えようというお客様がいたとします。こういうお客様がいらっしゃった場合、先の話しかしない販売員は、新しい靴を手にしながら、「この靴は歩きやすいんですよ」「このブランドは今人気なんですよ」的なお話をたくさんしてくれます。これはこれで良いことなのですが、お客様に信頼してもらえる販売員は、まず、お客様が使ってきた商品の話をするわけです。「今まで履かれていたお靴は、どこで買われたんですか？」「お気に入りだったんですか？」「どのくらい履かれていたんですか？」など、その靴との付き合いについて聞いてくれます。すると、お客様によっては、本当にその商品との思い出を持っている人もいます。「そうなんです。お気に入りだったんですけど、さすがにもう限界かなと思って…」「主人にプレゼントしてもらった靴で…」みたいな思い出が実際にあったりするんですね。そんな話を聞いてくれて、共感してくれる販売員には、お客様は心を開いてくれますし、「この人の言うことなら信用できる」と思ってくれる可能性も高まります。

「それ、どこで買われたんですか？」デキる販売員は思い出を聞く - まぐまぐニュース！ (via nokoto55)

XenOrchestraの紹介

XenServer界を震撼させた前回の投稿ですが、前回の結びで

XenCenterをダウングレード

心臓に優しいアイコンに仕様変更するのを待つ

という提起をしていました。

ところが、XenCenterとXenServerは互換性の問題があって、

XenCenterのバージョンがXenServerより古いと接続できないという仕様があってですね、こんなエラーが出ます。

さー困った。最新のXenServerを使うには最新のXenCenterが必要だけど、Unlicensedって出ちゃう。

そこで登場したのが Xen Orchestra です。

Xen Orchestra とは

Vatesという会社が作っている、XenServerをWebGUIで管理できるツールです。公式Doc

Free版と有償版があって、Free版は、OVA/XVAのexport/importが出来なかったりします。（Xen Orchestra Pricing）

アーキテクチャとしては、クライアントにインストールするXenCenterとは違い、XOA（Xen Orchestra Applianceかな？）というVMをXenServerにimportし、XOAのWebインターフェースに接続して使います。詳しくはこっち見てください。

XOAのインストール

すっごい簡単でコマンド1発で入ります。XenServerのDom0にログインして以下のコマンドを打つだけです。

bash -c "$(curl -s http://xoa.io/deploy)"

そうすると、VMのimportとセットアップが始まります。

Welcome to the XOA auto-deploy script!

Network settings: IP address? [dhcp] xxx.xxx.xxx.xxx Netmask? [255.255.255.0] 255.255.255.0 Gateway? xxx.xxx.xxx.xxx dns? [8.8.8.8] xxx.xxx.xxx.xxx Importing XOA VM… Booting XOA VM… Waiting for your XOA to be ready…

Your XOA is ready on https://IP or Hostname/

Default UI credentials: [email protected]/admin Default console credentials: xoa/xoa

VM UUID: 1fe0788b-cc63-1efa-359f-705c950d0034

しばらく待ってhttps://IP or Hostname/にアクセスすると Xen OrchestraのUIに接続できます。XOA自体は

2 vCPUs

2GB of RAM

15GB of disk (10GB for / and 5GB for /var)

が必要なリソースです。

無事VMが出来ると以下の様なログイン画面が出るので

あとは、Hostを追加していって下さい。

そうすると、VM一覧やらHost一覧を見ることができるようなります。

画面はVM一覧です。

各バージョンのXenServerを見ても"Unlisenced"なんか出ません。

7.4がFree！

6.2もFree！

また色々分かったら書きます。とりあえずこれにしようかなー。

#xenserver #xencenter

XenCenter 7.4のFreeライセンスについて

弊社、5年くらい前からXenServerを愛用しております。バージョンは5.xあたりからかな？

新しく環境を作ろうとして最新のXenServer7.4のisoを落として、ついでにクライアントツールのXenCenter（vCenter的なものです）も最新のを落として起動し、ホスト一覧見たらこの有様ですよ。

今まで無かったのに、急にビックリマークが勢ぞろい！

本番機もあるので情シスとしては「ハイ死んだ！」と思うわけですよ。

でも、「クライアントツールのバージョン上げただけで死ぬわけないじゃないか」と冷静になってよく見ると、Statusが「Unlicensed」になってる。画面に出ているXenServerのバージョンは全て6.5です。

たしかに結構前のバージョン（6.2より前だったかな？）だと、Free版であってもライセンスキーを入れる作業が必要で、1年の有効期限が切れるとVMの操作ができなくなるとかだったんですが、6.２以降（だったかな？）をFreeで使うときはライセンス関連の操作が全て不要になって、便利になったと感心しました。

でも最新のXenCenterが「ライセンスがねーよ！」と怒ってるわけですよ。

うーん、困ったなー。なんで前のような挙動に戻すのよー。ググっても90日間の試用ライセンスしかないし、画面的に気持ち悪いので色々調べてみるとcitrixのforumで以下のようなやり取りがありました。7.3でも同様みたいですね。

俺は今7.3をテストしてるんだけど、"Unlicensed"がホスト名の近くに出てるんだ。Free版で行きたいんだけど、この表示消す方法ある？

するとこんな回答。

もうライセンス済みじゃない？"Unlicensed"てのはFreeの意味なんだ。これ以上インストールするフリーラインセンスっていうのは俺の知ってる限りは無いね、とにかくfreeとUnlicensedていうのは同じ意味なんだよ。

え？ビックリマーク消せないの？

この後は

このアイコンは気にくわない

改悪だ

そんなにライセンス買わせたいのか

せめて"Free"て書いてある緑のアイコンにしてよ

もうやってられるか！俺はproxmoxに移行したぞ！アバヨ！

みたいなやり取りが続いてます。

確かに嫌ですねコレ。

XenCenterをダウングレード

心臓に優しいアイコンに仕様変更するのを待つ

どっちかかな？

XenServer7.4を古いバージョンのXenCenterで見た時の挙動は今度確認します。

とりあえず困ったなってことで。

#technology #xenserver #xencenter

NW構成図に関する考察

NW構成図と一人情シス

一人情シスには「NW構成図の更新」という神事があります。

これはただのNW構成図の更新作業などではなく、この図を片手に後輩や新人にNW構成を説明する自分を想像しながら「こうした方が分かりやすいかな？」「これじゃ独りよがりかなウフフ」などと考えながら作成するものの、結局誰にも引き継がれる事なく自分でメンテナンスし続けるという、セルフ賽の河原のようなものです。

今回は物理構成図の話をします。論理構成図でも同じ悲しみを味わうのですが、それはまた別の機会に。

今まで

今まではvisioで作成してて、以下の点に気を付けていました。

分かりにくくなるため、なるべく線を交差させない

接続状況が分かりにくくなるため写真やベンダー提供のアイコンを使わず、ハコで書く。

各機器がどのPortで接続しているか把握できるように書く。

で、出来たのが以下の図です。

課題

頑張って書いたけど、以下のような課題がありました。

真ん中の48PortのL2のように、Port数が多い機器のハコがどうしても大きくなり、実際のラック格納状態と乖離してくる。

線が多くて追いかけづらい

結局交差しちゃう

あんまり綺麗じゃない

やってみた

今回は以下の点に気を付けました。visioを止めてdraw.ioでやってみました。

ハコではなく汎用イメージを使い、大きさを揃える

機器同士の接続が複数Portの場合は、線をまとめて1本で表現する

接続Portは線の上に、機器に近づけて記載する

実際のRack格納状態と乖離しないようにする

なるべく線が交差しないようにする。でも多少はしょうがないよ。人間だもの

今回はこんな感じになりました。

箱の大きさがそろったので、Rackの格納状態とも乖離しなくなりました。

レイヤを重ねるとこんな感じです。「Blade System」て書いてますけど、HPEさんの製品とは無関係です。

感想

やっぱ時間がかかる。面倒やね。自動化かなー、CMDBと連携できるいいツールないかな。

#technology

Rancher 用語集 - 1.6 から 2.0 における用語と概念について

（これはRancher Glossary: 1.6 to 2.0 Terms and Conceptsの翻訳記事です。）

Rancher 2.0 の開発プロセスが終わりに近づいてきたので、私たちは Rancher ユーザが Kubernetes や Rancher の基本的な概念を理解するのに役立つ用語集を提供するのが良いでは、と考えるようになりました。

Rancher 1.6 から 2.0 への移行に伴い、 Kubernetes の命名標準に沿ったものに調整しました。この変更は Rancher 1.6 において Cattle のみを使ってきた人たちに混乱を招く可能性があります。

この記事は Rancher 2.0 の新しい概念の理解を手助けする事を目的としていますが、 Cattle と Kubernetes という2つのコンテナオーケストレータの用語や概念の簡単なリファレンスとしても使えます。

Rancher 2.0 Kubernetes と比較した Rancher 1.6 Cattle

Rancher 1.6 は Cattle をコンテナオーケストレータとして提供し、多くのユーザがこれを選択しています。 Cattle においては、管理と計算資源の境界、つまり権限を割り当てることのできる最小レベルの単位として環境（ Environment ）があります。重要なことに、その環境内のホストはその環境専用のものであり、その環境でしか使用できませんでした。そして、コンテナを整理するためにサービスを論理的にまとめたスタック（ Stack ）というものがありました。サービスは特定の実行イメージです。

では、この構造は 2.0 ではどのように見えるのでしょうか。

もしあなたがコンテナ界隈で働いているならば、Pod、namespace、node といった Kubernetes 周りのバズワードを聞いたことがないという事はないでしょう。この記事の目的は Cattle , Kubernetes 両方の用語を整理することで Cattle から Kubernetes への移行を簡単にすることです。いくつかの名前が変更されると共に、いくつかの機能が変更されています。

以下の表は Kubernetes のコアとなる概念を記載してます。

概念定義 Cluster Kubernetesで管理されている、コンテナ化されたアプリケーションを実行するマシンの集合。 Namespace 1つの物理クラスタで複数の仮想クラスタをサポートできる仮想クラスタ。 Node クラスタを構成する物理（仮想）マシンの一つ Pod 最も小さくてシンプルな Kubernetes オブジェクト。Pod はクラスタで実行されるコンテナのセットのこと。 Deployment 複製されたアプリケーションを管理する API オブジェクト Workload クラスタで実行される単位。 pod や deployment にもこれに当てはまります

より詳細な Kubernetes の概念は以下の以下の記事を参考にしてください。https://kubernetes.io/docs/concepts/

環境（ ENVIRONMENT ）

Rancher 1.6 において環境は2つの事を表現していました。

計算資源の境界

管理領域の境界

2.0 では環境という概念はありません、代わりに以下のものに置き換えられます。

Cluster - 計算資源の境界

Project - 管理領域の境界

Project は Kubernetes の管理負担を軽減するために Rancher が導入した管理レイヤです。

ホスト（ HOST ）

Cattle では、ホストは１つの環境にしか所属してないことがありました。それと類似して nodes （ホストの新しい名前！）は1つのクラスタにしか所属していません。以前はホストと環境でしたが、今は nodes と cluster です。

スタック（ STACK ）

Rancher 1.6 のスタックはいくつかのサービスをグループ化する方法です。Rancher 2.0 では、これは namespace によって行われます。

サービス（ SERVICE ）

Rancher 1.6 では、同じコンテナを実行している1つ以上のインスタンスをサービスと定義していました。Rancher 2.0 では同じコンテナを実行している1つ以上のインスタンスを workload と定義しています。workload はコントローラーと実行される Pod(s) で構成されます。

コンテナ（CONTAINER）

コンテナイメージは軽量でスタンドアロンで実行可能なソフトウェアのパッケージです。中にはソフトウェアの実行に必要なコード、ランタイム、システムツール、ライブラリ、設定などが含まれています。Rancher 1.6 では、コンテナはアプリケーションを実行するのに必要な最小の定義でした。Kubernetes においては、Pod が最小の定義です。Pod はシングルイメージでも、複数のイメージにすることもできます。複数の場合は同じストレージ/ネットワーク、そしてそれらがお互いにどのように動くかという定義を共有します。Pod は常に同じように配置、スケジューリングされ、共有されたコンテキストで実行されます。

ロードバランサ（ LOAD BALANCER）

Rancher 1.6 では、ロードバランサは Rancher の環境にあるアプリケーションを外部からアクセス可能にするために使われていました。Rancher 2.0 でもその概念は同じです。サービスを公開するロードバランサーオプションがあります。Kubernetes の用語では、この機能は Ingress を指すことが多いです。要するに、ロードバランサと Ingress は同じ役割を果たします。

まとめ

概念という点においては、Cattle はオーケストレータの中で最も Kubernetes に近いオーケストレータでした。うまくいけば、この記事は Rancher 1.6 から 2.0 に移行する人たちへの簡易リファレンスとなる事でしょう。この2つのオーケストレータの類似性は、より簡単な移行を可能にするはずです。

以下の表は新旧の用語のクイックリファレンスです

Rancher 1.6 Rancher 2.0 Container Pod Services Workload Load Balancer Ingress Stack Namespace Environment Project (Administration)/Cluster (Compute) Host Node Catalog Helm

さらに読み込んだりトレーニングするためには、無料のオンライントレーニングシリーズ：Introduction to Kubernetes and Rancherをご覧ください。

#rancher

flatmountain

・まずは、褒める。・興味を持って、質問する。・嘘をつくときは、相手が気持ち良くなる嘘をつく。・ハッタリを利かせるためには、自分に対する自信も必要。・ロジカル一辺倒だけは、人間はなかなか動かない。人の情感的な部分をくすぐること。・相手と別れるときのタイミングは、会話が一番盛り上がったときが良い。相手があなたに、また会いたくなる。・アイデアをもらったり、人を紹介されたりした場合は、対価（お金、情報）で感謝の心を示すこと。・ひたすら話を聞くことが、年上の人に可愛がられる秘訣。否定や意見は望んではいない。・ちょっとした小さな愛でも、誰かの1日を少しだけ幸せにしてあげることができるもの。・最初に大切なのは外見。いきなり中身は見えない。・自分には何の取り柄もない、人から愛される要素なんてない…と思っている人ほど、優しくされるのに弱い。・人は自分と共通点があって、且つ、個性的な人を好きになる。・その人に対する評価は、かなり早い段階で決まる。最初の１，２ヶ月が勝負。・一方的に押し付けられるのは、嫌なもの。・他人の価値観というのは、基本的に変えることはできない。・もし、説得したいのであれば、相手の価値観に配慮して相手の土壌で口説くこと。・上から目線は、絶対にやってはいけない。・人から押しつけられた意見より、自分で思いついた意見のほうを大切にするもの。つまり、結論は相手に出させるようにしよう。・相手が怒ったときには、口を挟んではいけない。全部聞き終ったあとで、相手が望んでいることを聞こう。・あいさつは、自分からしよう。・相手に重要感をもたせることが、つまらない論争を避ける秘訣。・自分にとって相手がかけがえのない存在だ、ということを上手く悟らせよう。・コミュニケーションが好きな人ほど、自分と同じ意見の人を常に探しているもの。・愚痴をこぼす人には、「でも、その中で頑張っているね」と褒めてあげよう。・自分が悪いと思ったら、すぐに謝ろう。・相手の長所を見つける癖をつければ、人間嫌いにはならない。・陰口は、あなたの評価を下げる。・約束の時間は守ろう。・あなたの笑顔は、あなたが思う以上の価値がある。・ありがとう、という気持ちを行動や態度で表そう。

人たらしになるコツ30箇条 (via genkudo)

勉強になる Tumblr 。

(via radioya)

胸にグサッとくる

p>(via beni81202)

youkoseki

ケンブリッジ・アナリティカ事件は結局なんだったのか問題

事件の概要

2013年、ケンブリッジ大学の教員で、調査会社グローバル・サイエンス・リサーチを名乗るアレクサンダー・コーガン氏が、Facebookで利用できる性格診断アプリを開発した。当時のFacebook連携アプリは、本人の情報だけでなく、友人の情報まで簡単に取得することができた。

2014年、ケンブリッジ・アナリティカ社が、このアプリへの参加者をAmazonのクラウドソーシング（Mechanical Turk）で募集した。27万人が参加し、報酬は1人あたり1ドルから2ドルだった。これによってケンブリッジ・アナリティカは27万人のデータと、その友達も含めた5000万人に及ぶデータをぶっこ抜いた。ちなみにケンブリッジ・アナリティカとケンブリッジ大とは無関係である。

2015年、FacebookはAPIに手を加え、アプリ利用時に友人の情報まで取得する機能を制限した。同年、ガーディアンの報道で、グローバル・サイエンス・リサーチからケンブリッジ・アナリティカへのデータ共有がメディアで話題になったため、Facebookはこのポリシー違反に対して、法的措置をとった。ケンブリッジ・アナリティカはデータを削除したと、証明書を提出した。

2018年、ガーディアンやニューヨーク・タイムズが、問題のデータをケンブリッジ・アナリティカが未だ保持しており、2016年の大統領選でも利用された疑いを報じた。当時ケンブリッジ・アナリティカはトランプ陣営に雇われていた。

なぜこんなことが起きたのか

さて、本件は大規模なデータ流出事件、データ漏洩事件と言われているが、実際のところ明確な問題があったのは一点である。それはリサーチ会社（という建前の）グローバル・サイエンス・リサーチから、選挙コンサルティングを手がけるケンブリッジ・アナリティカにデータが渡ったことだ。繰り返すが、これはFacebookのポリシーに違反している。

Facebookが直接データを流出させたわけではない。性格診断アプリは利用者が同意の上で利用したものだ。クラウドソーシングを使って友人のデータまでぶっこ抜いたことも、当時のFacebookのポリシーでは問題のないことであった。もちろん今となっては、もっと明確で厳格なポリシーがあったほうが良かったと思うべきだし、実際にFacebookはその後でポリシーを改訂している。

そう考えると、本件に対する当たり前の教訓としては、データは取り戻せないということである。何が原因であったにせよ、名前や年齢が第三者の手に渡ったら、それを変えることはできない。住所や交友関係、政治的志向も簡単には変えられないだろう。また、Facebook自身が味わったように、ポリシーを改訂しても、外部に漏れたデータを削除させたつもりでも、一度漏れたデータを追うのは難しい。

個人データにどのような価値があるのか

それはそれとして、5000万人のデータを分析して大統領選に影響を与えた〜という話が、どこまで信憑性があるのかは疑問である。はっきり言ってケンブリッジ・アナリティカの営業トークだったのではないかと思うし、実際のところデータは利用されていなかったという報道もある。

自分のデータが流出していたら気味が悪い。変な話だが、もし自分のデータが流出していたら、それには価値があると思いたくなるだろう。しかし本当にそうだろうか。

大統領選挙に利用されたという話を考えてみる。もしあなたの手元に、有権者の詳細な情報があって、一人一人の名前や年齢、住所、交友関係や政治的志向が分かったとしたら、何に使うだろうか。投票の行方を左右する、浮動層が見つけられるかもしれない。影響力の大きいインフルエンサーも見つけられるかもしれない。そういった層がどういうメディアを信じて、どういうセレブを好むか分かるかもしれない。

でもそれって個々人の詳細なデータが必要なのだろうか。大統領選なんて、どの地域で、どのタイミングで、どの層を狙う必要があるのか、ほとんど解明されている。だから、そこに大量のテレビCMが投下される。真偽不明の醜聞も次々に流れる。その上で、前回の選挙ではさらに、フェイクニュースが大きな役割を果たしたのではないか、と言われている。

そしてフェイクニュースの拡散に細かな個人データは必要ない。Facebookに（あるいはTwitterに、YouTubeに）投稿すれば、いまはアルゴリズムがそれを好みそうな人に自動的に届けてくれる。多く読まれたものは、アルゴリズムによってさらに多くの読者へと拡散されていく。これは誰でも出来ることで、個人の詳細なデータなんて必要ない。

本当の課題はどこにあるか

もちろん流出したデータに価値がない、というわけではない。個人の詳細なデータが手元にあるならば、それはマスを操作することよりも、個人を操るほうに向いているだろう（標的型攻撃、振り込み詐欺とか）。また大統領選のような、誰もが注目して明確な結果が出るものについて世論を誘導するよりは、長期的なトピックについて潜在的に誘導するほうが使いやすいだろう（移民の是非とか）。

ただ、Facebookから抜かれたデータでトランプが大統領に就任した〜というのは、あまりに安直なストーリーである。

EUのデータ保護規制（GDPR）はすでに話題であり、今回の騒動で他国でも強固なデータ規制が必要だと言われている。Facebookはすでに、APIによるデータ共有をますます制限しはじめている。また今回の件に対応したものか分からないが、パートナーカテゴリーという第三者データでFacebook広告を利用する機能も廃止する。

データの移動や共有を規制すると、有利になるのはデータをすでに大量に保有しているプラットフォームで、もちろんFacebookはその一つである。すこし前までは、巨大すぎるプラットフォームが保持するデータのポータビリティを高めようという話だったはずなのに、いつのまにか状況が逆になってる。

そう考えると、今回の事件そのものよりも、なぜこれほどの大騒動になったのほうが興味深い。データ規制にしろ、データポータビリティにしろ、それを求める声があるのは「Facebookはたくさんのデータを持っている」ということに対する漠然とした不安感の裏返しではないか。その大半はユーザー自身がアップロードしたデータなのだが、その対価がターゲティングされた広告というところが、納得を得られていないのかもしれない。

理想的には、データを渡したおかげで自分に関係のある広告が見られて良かったね、ということのはずだ。そもそもFacebookのような多機能プラットフォームを、広告のおかげで無料で使えて良かったね、ということのはずである。しかし、そこが納得されていない。

そしてこうした、データに対する対価はなんなのかという不安こそが、Facebookに限らず、成長を続けるデジタル広告業界がずっと解決できずにいる本当の課題ではないか……という話を書くとさらに長くなるので、元気があったらまた書きます。

LForMを使ってみた

LForMて何？

株式会社エーピーコミュニケーションズさんが公開している、ネットワーク機器のリアルタイムログ解析ツールです。公式サイト

OSSで公開されていてFortiGateに対応しているとのことなので、社内のFortiGateで試してみました。

インストール

LForMダウンロードに必要事項を記入するとマニュアルURLがメールされてくるので、その通りにやってください。簡単でしたよ。

公式にも説明がありますが、fluentdでSNMPやSyslogデータを受け取りelasticsearchに保存し、kibanaで見る仕組みのようです。nginxはbasic認証のために置いたのかな？弊社でも同じような構成でログの監視をしています。

今回の環境

今回は以下の環境で試しました。動作確認済みのファーム（FortiOS）は5.2.3とのことですが、最新の5.6.3でやってみました。

兄さん！最新でも大丈夫だったよ！

サーバ：CentOS 7.2（CPU ２コア、MEM 4G）

FortiGate:FortiGate 60E

ファーム：v5.6.3 build1547 (GA)

設定

複雑な設定はありません。ForiGate側でSNMPとsyslogの設定と、サーバ側でSNMPのポーリング設定くらいで動きだします。

実際の画面

あとはhttp://LForMのIPアドレスでOKです。

デフォルトのダッシュボードがイイ感じなので特に何もしなくてもいいくらいでした。

例えばトラフィックを見ると、突然７M程度の何かを受信したことがすぐわかるんですよ。

あとは時間で選択して深堀りしてSource IPを見ると192.168.80.110が何かしてるのが分かる訳ですよ！まあ俺なんですけどねコレ。

使ってみて便利だなと思ったところ

ぶっちゃけ使う前は「FortiGateのダッシュボードでも近いことできるしなあ…」みたいな感じだったんですが、FortiGateのダッシュボードに比べるとかなり使いやすいです。インタラクティブ性が高いのは気持ちいいです。

デフォルトでも十分なんですが、自分好みのVisualizeやdashboardを簡単に作れるのもいいですね。FortiGateはダッシュボードのカスタマイズはできるんですが、ウィジェット（Visualize的なもの）の作成はできないんですよ。

あとFortiGateはログ保存にFortiCloudっていうクラウドサービスを使えるんですが、保存期間は1年です。LForMはそういう制限がないのもいいですね。

期待するところ

ログの保存期間

デフォで放置するとサーバが死ぬまで保存し続けるので、ログの保存期間の設定ができるといいですね。まあelasticsearchだし、自分でcurator入れればいいんですけどね。

レポート機能

月次や週次でレポート送ってくれると運用にも優しくなりそう。kibanaのx-pack（有償）だとレポート機能あるんですけどやっぱねえ、お高いじゃないですか。

Edgeで見れない問題

FirefoxとChromeはOKですが、Edgeだと表示されませんでした。以下の2画面を無限に繰り返します。（Microsoft Edge 41.16299.248.0）

まとめ

ありそうでなかった感じで好きです。いろんな機器にも対応していく感じっぽいので横断的に見れるようなると面白いかも知れませんね。

息の長いOSSプロダクトになるといいですね。

gkojax-text

“わたしの同僚に、兵法書や戦争論を読むのが好きな男がいる。別に兵器オタクではない。本人はいたって知的で温厚な紳士である。ただ、プロジェクト・マネジメントをどう理解すべきか、その源流をたどっているうちに、そちらの世界に近づいてしまった、ということらしい。事実、彼から聞いた、将軍達や参謀達の名言録のいくつかは、なかなか面白い。たとえばパットン将軍と言えば、戦車隊を率いてドイツと闘った、第二次大戦の米国の英雄だが、こんなことを言ったらしい：・部隊はスパゲッティのようなものだ。押し出すことはできない。前線に立って引っ張る方が動く。・指揮責任の９５％は命令の遂行を確認することだ。正しく遂行されることに、粘り強くこだわらねばならない。・やりかたまで指示するな！　目標だけを伝えよ！　そうすれば相手は、きっと驚くべき方法を考え出すだろう！・一段下の階級に指示し、二段下の階級の状態を把握しろ。・指揮官の第一の使命は自分の目で見ること。そして実地見聞に出かけている姿を兵隊たちにさらすことだ。将軍も危険に身をさらして戦っているのだと態度で示すのは、他ならぬ将軍の仕事だ。・判断は早すぎても遅すぎてもいけない。しかし最大の過ちはなんの判断も下さないことだ！　オールドミスならだれでも知っている！・成功の欠点は、その先に失敗がまっていることだ。成功とは失意の後でどこまで立ち直れるかの問題なのだ！などなど。どれもなかなかいい。とくに最後のフレーズなど、先日亡くなったスティーブ・ジョブズの非凡な生涯を思い起こさせる（本当に惜しい人を亡くしたと思う）。”

— タイム・コンサルタントの日誌から : そんなものを戦略というのですか？ (via ginzuna)

Trending Blogs

Recently Viewed Blogs

涅槃を目指す