Datadog Log ManagementでNginxのエラーを監視する - Kaizen Platform 開発者ブログ
SRE Group Managerをしている前田 (@glidenote)です。 弊社では先日監視システムを刷新し、Datadogを全サーバに導入し、今年3月にDatadogから正式リリースされたDatadog Log Managementを利用しNginxのエラー監視をするようにしました。今回はその件について紹介します。 TL;DR Datadog Log Managementを利用して、Nginxのエラーを監視するようにした とりあえずLogを送っておいて、グラフを作ったり、後から必要な形に加工するという運用が簡単に出来るようになった 正式リリース間もないので、まだまだな部分があるが、手軽にログ監視が出来るので今後の機能拡張が楽しみ 前提 以前から弊社では、 Fluentdを利用して計10数億行/dayの各種ログを処理 NginxのログはFluentdを利用して、BigQueryとSe
Fluentdのout_copyのstoreのエラーは他のstoreに影響する - sambaiz-net
Fluentdのout_copyプラグインは 一つのeventを複数のoutputに渡すために使われる。 ただ、複数設定した中のstoreでエラーが起きると他のstoreにも影響してしまう。 例えばこんなの。 <source> @type dummy dummy {"hello":"world"} tag dummy rate 1 </source> <match dummy> @type copy <store> @type stdout </store> <store> @type file path /var/log/td-agent/dummy buffer_queue_limit 0 buffer_chunk_limit 1k </store> </match> <source> @type dummy dummy {"hello":"world"} tag dummy rate
CentOS7.5 の fsnotify がレースコンディションを起こすバグを nginx + td-agent + in_tail プラグインで踏む - hibomaの日記
2018/7/18 追記 3.10.0-862.9.1.el7 で fix されました hiboma.hatenadiary.jp 2018/7/4 追記 最新の情報はこちらにまとめています hiboma.hatenadiary.jp 2018/6/16 追記 CentOS Plus の kernel-plus では修正が入っています. 詳しくはこちらをご覧ください hiboma.hatenadiary.jp エントリの概要 CentOS7.5 の fsnotify() がレースコンディションを起こすバグを、 nginx + td-agent (fluentd) + in_tail プラグインで踏んだ際の調査内容を記していきます. イントロダクション このエントリを書いた時点では、CentOS 7.5.1804 以降でリリースされているカーネルは 3つありますが、カーネルの fsnotif
fluentdからkafkaにログ送信する際のパフォーマンスチューニング - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに fluentdからKafkaにデータ送信する際に、気にしておくべきfluentd側のチューニングポイントのまとめです。 fluent-plugin-kafkaのBufferedOutput前提です。 最初にデータが送信される際の流れを簡単に説明した後、チューニングポイントについて記載します。 使用ソフトウェアとバージョン kafka 0.10 fluentd v0.12 fluent-kafka-plugin(BufferdOutput) v0.57 Kafkaへ送信される流れ BufferedOutputプラグインではレコー
Fluentd 入門 〜運用に必要な基礎知識〜
最近業務で Fluentd を触ることが出てきて入門したんですが、最初のうちはトラブルが起きた時に何が起きているのか、どう対処したら良いのかがさっぱりわからなかったので、「Fluentd ってログの収集とかに使われるやつでしょ？」程度の知識しかなかった過去の自分に向けて「とりあえずこれぐらいは知っておけ！」と言いたい内容をまとめてみました。 トラブルが起きた時にどの処理で問題が起きているのか素早くコードを追うことができて、データの消失を最小限に抑えつつ適切に対処できるようになることを目的としています。 なお、現時点で最新版の Fluentd v0.14.21 を対象にしています。 アジェンダ Getting Started Fluentd のアーキテクチャ Processes Supervisor process Worker process Threads Input thread En
td-agent の in_tail プラグインを使っている際に対象ログがローテーションする瞬間を見たい - ようへいの日々精進XP
きっかけ ということで、td-agent(fluentd) のin_tail プラグインでログのローテーションをどのように捕捉して追従していくかを調べたい やってみた 下記の環境においてクライアントから apache に ab でアクセスさせて確認する。 確認したいこと td-agent を介してログを記録している状況において、ログローテーションが発生した場合に td-agent はログの切り替わりを知って、それに追従するか。 純粋に access.log ファイルに記録される内容（件数）と td-agent を介した記録内容（件数）に際が発生ないか。（ちょっとした負荷テスト的なことも） 環境 サーバー Debian 6.0.7 Apache/2.2.16 (Debian) td-agent 0.10.35 redis 2.6.14 クライアント Ubuntu 13.04 ab 2.3 A
fluentdでnginxのログをElasticsearchとBigQueryに保存するお話 - ハウテレビジョンブログ
こんにちは。夏休みに長野に行って居酒屋で馬刺しをたらふく食べていたら 地元のおっさん人生の大先輩の絡み酒に付き合わされた祖山です。 4月に入社して以降、サーバサイドのWeb開発やスクラムの導入、サイト内検索の改善など様々な業務に 取り組んでいますが、最近の大きな案件としては、アクセスログ解析基盤の整備がありました。 nginxのアクセスログを分析しやすい環境を作るため、ElasticsearchとBigQueryにログを蓄積し始めたのですが、 その際に一番のキモとなるのは、みんな大好きfluentdです。 今回は、我々ハウテレビジョンがどのようにアクセスログを収集、保存しているのかについて、fluentdの設定を中心にご紹介します。 アクセスログ収集の目的 現在の我々のサービス環境を考慮すると、アクセスログの収集には下記2つの目的が存在します。 アクセス情報をもとにユーザーの行動を解析 閲
Collecting Docker Container Data with Fluentd - AppOptics Blog
Note: This article was originally published on Librato, which has since been merged with SolarWinds®AppOptics™. Explore what’s possible with AppOptics Docker performance monitoring. Today, we’re honored to bring you a guest post by Treasure Data’s Kiyoto Tamura. Kiyoto is the developer evangelist at Treasure Data and one of the maintainers of Fluentd, the open-source data collector to simplify a
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
fluentdでログが欠損する可能性を考える : sonots:blog