インフラエンジニアと謎のサーバ - Qiita
この記事は闇の魔術に対する防衛術 Advent Calendar 2018の6日目の記事です。 あらすじ この世には歴史的経緯により何が動いているか分からない謎のサーバというものが存在する。 謎のサーバには、気の利いたドキュメントだの仕様だのGitHubにコードが上がってるだの、そういう甘っちょろい物は一切ない。謎のサーバは殆ど変更される事なく、あまりトラブルを起こす事なく、しかし何かのサービスによって必要とされてひっそりと動いている。 インフラエンジニアは時にこういった謎のサーバを調査して、ドキュメントに起こすか、コード化するか、ひっそりと退役させるか、はたまたリプレイスするか、といった対応に追われる。 私はこういったタスクの事を”考古学”とか”遺跡発掘”とか呼んだりする。 (考古学の成果の一例) uptime2700日超えのサーバにshutdown -h nowをカマした — かんが
fluentdからkafkaにログ送信する際のパフォーマンスチューニング - Qiita
はじめに fluentdからKafkaにデータ送信する際に、気にしておくべきfluentd側のチューニングポイントのまとめです。 fluent-plugin-kafkaのBufferedOutput前提です。 最初にデータが送信される際の流れを簡単に説明した後、チューニングポイントについて記載します。 使用ソフトウェアとバージョン kafka 0.10 fluentd v0.12 fluent-kafka-plugin(BufferdOutput) v0.57 Kafkaへ送信される流れ BufferedOutputプラグインではレコードはchunkと呼ばれる単位に区切られてバッファリングされます。 以下の記事にBufferedOutputの処理の流れが纏められており、参考になります。 本記事ではchunkがキューに入った後、Kafkaに送信されるにあたりどのような処理が行われるかについて
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
