はてなブックマーク

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 先日公開したログ情報共有サービスLogCrowの中で、ちょっとしたデータ分析用のバッチ処理を走らせるためにCloud Runを使ってみようとした時の話です。 Cloud Runとは？ Cloud Runとは、任意のコンテナイメージをビルド・デプロイし、HTTPのリクエストや、Cloud PubSubをトリガーとしてコンテナに処理を実行させるサービスです。 中はKnativeベースで構成されています。マネージドKnativeサービスです。 サーバレスシステムの基盤になるサービスの1つです。似たようなサービスとしてCloud Functio

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 先日、Firebase + GAEを使って実装したサービス「LogCrow」に新しい機能として、ログの登録を簡略化するために、ログファイルをアップロードして、ログの各行をクラスタリングし、類似ログ同士をまとめあげた上で、ログ登録できる機能を追加しました。 LogCrowのAnalyzeメニューにアクセスすると、ファイルをアップロードできるフォームがあります。ここに分析にかけたいログファイルをアップロードして実行すると分析処理がサーバサイドで走ります。 分析には多少時間がかかります。 分析が完了すると、分析結果を以下のような感じで確認でき

FirebaseとGoogle App Engineを中心に活用し、Webサービスをローンチしたのでそのアーキテクチャ & サービス概要を紹介します。 LogCrow(ログ情報共有サービス) 背景・動機 私は日頃業務で、システムの保守・運用の効率化・改善について検討しており、いろんな運用者の知見が共有できている状態が作れると運用者が幸せになれるのではないかと考えています。 そんな中で、特に保守・運用時にキーポイントとなるログ情報についてフォーカスし、こういうログが出たときには「原因」として何が考えられ、どういった「対処」が必要となるのかといった情報が幅広く共有されると良いのではないかと思っています。 Google検索はもちろん優秀で、発生したログ文面をキーワードに検索すればある程度情報にたどり着くことはできますが、公開できない情報やログに特化した検索といったことはできないのでそれなりに検索

gRPC-Webも正式リリースされ、ますます便利になりそうな予感のgRPC。 HTTP/2ベースの双方向通信もできるということで面白そうなので試してみました。 試したこと Protocol Buffersの定義からPythonでClient・Server実装 Client→Serverにコネクション Clientからメッセージ送付 Serverから同じコネクションを通してメッセージを複数返す チャットの通信のやり取りみたいなイメージのものをgRPCで実装してみます。 サービス定義を実施 Protocol Bufferの定義を作成。 sample.protoファイルの作成。 syntax = "proto3"; package sample; message HelloMessage{ string name = 1; string msg = 2; } message ReplyMessa

こんな情報必要とする人いないかもしれないですが、Golangでの標準入力、標準出力のストリームデータの扱いが少しややこしかったので備忘のために記録しておきます。 やったこと Linux上のBashに対する標準入力および標準出力・標準エラー出力の内容をGoのプログラムで取り込み、記録とか、その他活用ができるようにしてみました。 Linuxだと、標準入力と標準出力・標準エラー出力の内容を記録するコマンドとして、scriptコマンドがあるのでそれで十分なところもあるかと思いますが、それと近いことをGoのプログラムだけで実現し、自由にデータを操作できるようになるといいことあるかもとの思いから試してみました。 前提知識 GolangでのOSコマンドの実行 Goプログラムでコマンドを実行するには以下のexec.Commandで実行可能です。

Zabbix4.0の新機能の1つとして、HTTPエージェント監視の機能が実装されました。 これは、監視アイテムのタイプの1つとして実装され、Zabbix Serverから指定したURLに対してHTTPリクエストを送付して値を取得するといった機能です。 これまでのZabbixの場合だと、別途HTTPのリクエスト処理を行うスクリプトを作成して外部チェックアイテムで監視したり、Zabbix AgentのUserParameterを用いてZabbix Agentからスクリプトを実行して監視したりといった対応が必要でした。 しかし、4.0からはZabbix Serverが直接HTTPリクエストを呼び出して監視する機能が搭載されています。 さらに、この機能とZabbix3.4以降で実装されている保存前処理のJSONパース、XMLパース機能を組み合わせて活用すると、WebAPIを呼び出して、その応答結果

MLflow MLflowはオープンソースで、機械学習処理のライフサイクル管理を行うソフトウェアです。Kubernetesで管理している環境だとKubeflow、AWSならSageMakerとか、この分野の用途で利用できるものはいろいろあるかと思いますが、OSSでいろんなシーンで適用できそうです。 MLflow 現時点(2018/10/03)でバージョン0.7というのがリリースされており、絶賛開発中のようです。 MLflowは、要素として3つで構成されています。 MLflow Tracking : 学習の実行履歴管理 MLflow Projects　: 学習処理の実行定義 MLflow Models　: 学習モデルを用いたAPIサーバの実行定義 MLflow Tracking 学習モデル生成時に、生成されたモデルの実体や学習モデルの評価結果のスコア情報等を記録し、履歴管理する機能です。 学

今回は「H2O.ai」という機械学習分析プラットフォームを試しに使ってみます。 自分でモデルをプログラム実装しなくても様々なモデルを試せるのでうまく使えると便利そうです。 (H2Oというと、WebサーバソフトウェアのH2Oというのがありますが、これとは別ものなのでご注意ください。) サービスだとDataRobotとか機械学習プラットフォームとして有名ですね。 これと類似のカテゴリのものだと思います。 インストール H2O.aiのサーバをまずは動かします。 Javaで実装されているので以下からjarを落としてきて動かすだけで済むようです。 https://h2o-release.s3.amazonaws.com/h2o/master/4275/index.html 適当にサーバにjdkをインストール後、インストールします。 これでデフォルト54321ポートで管理画面が起動します。 データの準

機械学習が盛り上がる中ではありますが、ルールベースでできることも色々あるのではということで、Pythonのルールベースエンジンの『durable_rules』というのを使ってみたので紹介しておきます。 durable_rules ルールエンジンも色々と実装がありますが、Pythonで使えて最近も開発されてそうなのを探すとヒットしたのがこれです。 日本語情報全然ないので知名度はないかも。。 RedisConf17で発表されているようです。 参考: https://www.slideshare.net/RedisLabs/redisconf17-durablerules Reteアルゴリズムが実装されているとか。 Pythonだけじゃなく、node.js、Rubyでの実装もあるので、用途に応じて活用できそうです。 導入 pipでパッケージ導入 durable_rules自体の導入はかんたん。

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

本記事は備忘のための記事です。なので細かい検証とかまで深くできているわけではないので参考までにとどめてください。 Zabbix3.0系での話です。(おそらく4.0とかでも似たような挙動だとは思います。) ネット上の記事だと、「ValueCacheは危険」的なものをちらほらと見かけるので、改めてValueCacheの挙動について整理しておきます。 ValueCacheは大量の監視データの処理の際に、トリガー評価を非常に高速に行い、DBへの負担を激減させるために有効な仕組みなので、ぜひ仕様を理解して効果的に活用しましょう。 ValueCacheとは ValueCacheとは、Zabbixのトリガー条件を評価する際に活用されるキャッシュです。 Zabbixは監視結果を受信すると、一旦、HistoryCacheと呼ばれるメモリ領域に格納します。 そのHistoryCacheのデータをDBに同期する

API GatewayとかLambdaでサーバレスな話は既にたくさん記事はあるので、詳しくはそちらをご覧ください。 この記事は個人的な備忘録的に記載しています。 試したこと API GatewayとAWS LambdaとDynamoDBだけを使って、コメント登録サイトを作ってみました。 構成は以下のような感じです。 API GatewayにGETリクエストでまずは登録済みのコメント情報を取得してHTML表示をし、その中のFormからAPI GatewayにPOSTリクエストを送り、新たなコメントを新規登録するという流れです。 本来ならS3とか、他のサイト上にFormとか作って、API Gatewayを呼び出すという感じでしょうが、ちょっとAPI Gatewayの機能のお試し用で作ったので、API Gatewayのマッピングテンプレートを使ってHTML生成までAPI Gateway側で完結さ

Zabbixの3.4.5からZabbixの監視結果の格納先としてダイレクトにElasticsearchを選択できるようになりました。 これまでは、fluentdとか使って、Zabbixでの監視用とログ結果の分析用といった感じで処理を分けて管理しなければならなかったところが、Zabbixの機能だけでElasticsearchとうまく連携できるようになっています。 Zabbixはこれまでログ監視・分析系が少し弱いところがあったので、これでかなり監視結果データの活用がやりやすくなったのではないでしょうか。 詳しくはこちらのZabbix社の公式ドキュメントに記載があります。 では、以下、使う方法について解説します。 ZabbixとElasticsearchのインストール 導入手順は省略しますが、普通にそれぞれインストールします。 ZabbixからElasticsearchのWeb APIを呼び出せ

今年のZabbix Advent Calendarもあと少し。 20日目はZabbixの機能を拡張するためにGolangを使ってみようというお話です。 実は個人的に今年はGo言語を使って何かツールとか作ってみようと目標を立て、1月から少しずつ勉強して触ってました。 一応、簡単ではありますが、こんな感じのものを公開中です。 zaws (ZabbixによるAWS監視ツール) Zabbix Anomaly Detector plugin(Zabbix監視結果を用いた変化点スコア監視ツール) Golang JobScheduler API library(OSSのジョブ管理ツールJobSchedulerのAPIライブラリ) コードは公開していないですが、他にもElasticsearchと連携するGolang製のツール作ったり、GoでLINE Botと連携するツール作ったりちょこちょこ作れた気がしま

インフラ技術週間も最終日となりました。今週の1週間の記事を振り返ると実はすべてがDocker絡み。 何をやるにしてもDockerを中心としたコンテナベースで考えることが当たり前になってきている感じですね。 ということで最終日もDockerを絡めてGitLabを使ったインフラCIについて紹介します。 この記事を読むと何ができるようになる？ 記事全文は長くなるので要点だけ書くと。 この記事ではGitLab(GitHubのようなGitを管理するOSS)を使ってAnsible(構成管理ツール)やserverspec(インフラテストツール)のコードをGit管理。Docker上のコンテナを使って自動構築→自動テストというインフラCI/CDの基礎となるOSSの技術を知ることができます。 CIというとTravisCI、CircleCI、WerckerとかSaaSで便利なものもたくさんありますが、今回はあえ

2016年9月14日にリリースされたZabbix3.2の一つの目玉機能として、 イベントへのタグ付け イベント相関関係 がリリースされました。 これらの機能により、これまでの単純な監視アイテムに対してトリガー条件式を設定して障害検知するだけでなく、Zabbixで発生するイベント情報に対して関連を持たせて検知ができるようになります。 イベントへのタグ付け機能 3.2からはZabbixのトリガーで検知して発生したイベントに対してタグをつけるということができるようになっています。 タグはトリガーの設定にて定義することができます。 トリガーの設定にタグを定義することで、このトリガーを起因として発生したイベント(障害・復旧)に自動的にタグが付与され管理されることになります。 タグはKeyとValueのセットで扱うことができます。 例えば、以下のような感じで設定できます。 このトリガーはどういったサー

オライリーのServerspec本を読んで、こんなこともできるよねということで試してみました。 Serverspecについての紹介は省略します。 Serverspecはデフォルトの場合、テスト対象のサーバ毎にフォルダが作られ、その中にテストコードを書いていきます。 その場合、サーバ間で同様のテストを実施したい時に重複して同じテストコードを書く必要があります。 それでは効率がよくないので、できればサーバ用途毎にテストコードをまとめて管理したいといったケースがあります。 そのような場合には、以下の記事にあるようにRakefileをカスタマイズすることでどのホストに対してどのテストコードを実行するかを柔軟に扱うことができるようになります。 http://mizzy.org/blog/2013/05/12/1/ http://thinkit.co.jp/story/2014/09/04/5212

とうとう最終日まで来ましたTIS Engineer Advent Calendar！ あらためて見てみると、Excelの話から言語系の話、インフラ系の話、とてもバラエティに富んだ内容ではなかったでしょうか？ TISはいわゆるSIerで、様々な業種の顧客向けに多種多様なものを扱っています。 中にはとてもレガシーなシステムもあり、保守的なシーンもありますが、根底としてはやはりよりよいものを提供したいという思いがあるのが事実です。 そのために新しい技術に対しても非常にポジティブにとらえてチャレンジしています。初日のこちらの記事でも紹介されているTech-Circleはまさにその姿を表した形となっています。 ということで、興味をもった方はぜひ私達と一緒に何かやりましょう！！ それでは今日の本題に入ります。 最終日も新しい技術との接触のお話。 ***NodeFabric***ってご存知ですか？ No

HTTPの新しい規格であるHTTP/2。 HTTP/2対応が簡単にできてしかも高速で動くと言われているWebサーバであるH2Oを使ってZabbixのフロントエンドのPHP WebGUIをHTTP/2化してみます。 Zabbixは設定を行ったり、監視結果を見たりする管理画面はPHPのWebアプリケーションとして稼働します。 通常、公開されているrpm等のパッケージからインストールした場合はApache HTTP Serverを使って構成するようになっています。 このApache HTTP ServerをH2Oで置き換えて、Zabbixの管理画面のGUIをHTTP/2化してみます。 前提となる環境は以下の通りです。 OS: CentOS6.7 Zabbix: 2.2.10 PHP: 5.3.3 H2O: 1.6.0 H2Oのインストール まずはH2Oをインストールします。 H2O自体はGith

12月、Advent Calendarの季節になりました。ということで今年はZabbixのAdvent Calendarにチャレンジしてみます！完走できるかな？皆さんよろしくお願いします！！ まず初日はAnsible(構成管理ツール)を使ってZabbixの設定を自動化する方法をご紹介。 Ansible moduleって？ Ansibleは様々な処理をymlの定義ファイルに基づいて自動化できるよう幅広い処理ロジックをモジュールとして管理しています。 モジュールはより優先度の高いモジュール群をcoreとして管理し、その他様々なモジュールはextraという状態で管理されています。Ansibleの仕様に従う形で処理を実施できるようなPythonのコードを書けば非常に簡単にモジュール追加できるような仕組みとなっています。 現状、どのようなモジュールがあるかはこちらを参照してください。 coreモジュ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?