はてなブックマーク

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

############################################# #POST method ############################################# resource "aws_api_gateway_model" "post-sample" { rest_api_id = "${aws_api_gateway_rest_api.sample.id}" name = "PostSample" description = "post-sample" content_type = "application/json" schema = <<EOF { "type" : "object", "properties" : { "key": { "type": "string" } } } EOF } resource "aws_api_g

fluentdのrequire_ack_response設定は、やっぱり必須設定だと再認識したときの検証メモAWSFluentd 1.検証背景 参考記事 Fluentd v0.12のAt-least-once Semanticsを試す fluentdでログが欠損する可能性を考える などで、fluentd v0.12を使ったときに、「require_ack_responseを必ず設定しておくように」というノウハウは、大分浸透するようになったと思われる。 ただ、fluentdを運用する中で、require_ack_responseの設定漏れに気付かず、受信側のfluentdをreloadしてしまうケースも考えられる。 ということで、実際の運用下でこの設定がどれぐらいの効果を発揮するのかを検証してみた。 2.検証環境 2-1.構成図 図にするほどでもないが、fluentdの送信側と受信側のEC2

#1.Git LFSとは Git LFSは、昨年10月1にGitHubからGit LFSの正式版がリリースされた、gitの拡張機能です。 具体的な利用用途としては、大きなバイナリファイルのバージョン管理を想定した機能です。 gitでプロジェクトを運用する際、大きなバイナリファイルの管理は、 一番頭を悩ませる部分だっただけに、多くのgit管理者および利用者に嬉しい機能追加でした。 なお、現在では、SourceTreeといったgitのクライアントツールでもgit lfsが利用可能です。 【公式】 Git LFS公式サイト 【参考】 サイズの大きいバイナリファイルを扱うための Git LFS 導入 “Git LFS”をサポート。UIデザインを一新した「SourceTree」v1.8が公開 #2.Bitbucket Serverでgit lfsを設定する Bitbucket Serverは、バージ

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

1.記事の背景 NewRelicのREST APIを使うと、NewRelic APM(Application Performance Monitoring)の画面で見れる内容がJSONで取得できます。 公式ドキュメント Summary data examples (v2) 今回の参考記事 NewRelic Rest API と Sensu との連携 詳解 NewRelic で性能改善〜その３ このAPIを使えば、参考記事のように色々なことができますが、今回はKey Transaction機能を使って、特定URLのパフォーマンスデータを取得する方法を記載します。 2.NewRelic APIを叩くまでの下準備 2-1.API Keyの取得 REST API Keyは、NewRelic画面上の以下の場所にある。 REST API Keyをそのまま使うか、Adminユーザごとに作成できるAPI

gumiアドベントカレンダー9日目です。 今回はちょっと技術的なことを離れて、チームマネジメントまわりのことを書いてみようと思います。 1.チーム背景 私の所属しているチームは、主にAWS環境の運用を行っています。 チームメンバーは、ほぼ私が1人で対応していた時期から、数人規模のチームを推移してきました。 「愚者は経験に学び、賢者は歴史に学ぶ」とはよく言ったもので、残念ながら私は完全に前者になってしまいました。 改めて自分の失敗を振り返ると、良書と呼ばれる本には、失敗内容に関連した内容が記載されています。 特に、【Team Geek】の内容は、以前読んだ筈なのに全く実践できていなかったなあと。。。 【参考】『Team Geek』を読んだメモ 今回は、私のチームマネジメント失敗事例やそこから学んだことを徒然なるままに書いてみようと思います。 2.失敗したこと 2-1.メンバーの増加タイミング

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

##検証を思いついた経緯 appサーバ側のforward設定で複数の<server>タグを管理したくない td-agentのconfigに影響されず、AWSメンテナンスやインスタンス障害の対応を行いたい アプリケーションが乗るappサーバと違い、td-agentクラスタは純粋に負荷を見極めやすいため、AutoScalingに適している fluentdのコミュニティで「TCPロードバランシングはユーザ側で試して欲しい」という状況で更新が止まっていた https://groups.google.com/forum/#!topic/fluentd/3ZuG_1dPovE ##td-agentクラスタ環境準備 ###1.環境構成 今回、VPC,SecutityGroup,AMIの作成方法は割愛。 以下の環境を準備する。 ###2.appインスタンスのtd-agent設定 <source> type

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

Help us understand the problem. What is going on with this article?