Metrixには...

多くの開発者にとって、製品をリリースするプロセスは、盲犬の子猫を野生の犬の顎に投げ込むことに似ています。 その後、作者の主な仕事は、偶然彼らに飛んでくるバグから反撃することです。 実際、アプリケーションはユーザーの歯の中でそのライフパスを終了するのではなく、開始するだけです。 そして、彼は開発とテストの間に、開発者の助けを必要としています。

この記事では、製品の動作とその戦闘環境を観察する方法を検討し、重要なメトリックを収集し、それらを消化可能な形式で提示する方法を学習します。 時系列とは何か、そしてそれらが診断プロセスにおいて当社およびサードパーティのアプリケーションをどのように支援できるかを学びます。 監視ツール、特殊なInfluxDBストレージ、およびGrafanaデータ視覚化システムのマーケットリーダーと詳細に知り合います。

記事のプロトタイプは、DotNext 2017モスクワのアナトリークラコフによるレポートです。 Anatolyは情報セキュリティの専門家として教育を受け、厳しいC ++ Linux開発者として金を稼いだ。 コーディングにうんざりしていて、作成したいときは、C＃に切り替えました。 彼は.NETで最初のバージョンから書いています。 彼は、ビジネスアプリケーション、分散型およびフォールトトレラントシステムの設計と構築に従事しています。 ES、CQRS、およびDDDで休憩します。

表示する前に、スライドをPDF形式でダウンロードできます。

注意トラフィック！ この投稿には、膨大な数の写真があります。720p形式のビデオのスライドとスクリーンショットです。 スライドには、記事を理解するための重要なコードが含まれています。

メトリックについて話します。 なぜそれらについて正確に？ 実際のところ、私の実践では多くのプロジェクトに出くわし、ほとんどのチームが制作で何が起こっているのかさえ考えていないという状況にいつも怒りました。 彼らは製品をリリースしたばかりで、彼らの意見では、それは飛ぶ。 実際には、これはまったくそうではありません。サーバーはユーザーの流入を抑制でき、ディスクが故障し、何が起こるかわかりません。 そして、ほとんどの場合、誰もこれを疑い、知らない。

残念ながら、これが私たちの開発者の文化が発展した方法です。私たちにとっての主なポイントは、コードを書くプロセスです。 しかし、これは生きた製品のごく一部にすぎないため、時間とともにこの傾向は変化しています。これは非常に喜ばしいことです。 CIやDIなどのひどい虐待的な言葉はすでに知っていますが、ひざに震えることはもうありません。 私たちは、バージョン管理、タスク管理、計画、およびテストシステムが現代のプロジェクトに不可欠な部分であるという事実に慣れています。

この方向の次の大きなステップは、居心地の良いチームの境界を越えて、直接のユーザーの領域で良いことをすることです。 そして、これは非常に興味深いプロセスです。ほとんどの場合、ユーザーは計画どおりにプログラムを使用しないため、通常、これらの天才的な思考が可能な熱狂的なアイデアにプログラムは対応していません。 そのため、製品の実際の使用を観察し始めた後、私たちは常に、狂気と予測不可能性に満ちた、大きくて興味深く魅力的な世界を発見しました。 ランダムな不合理のためにすべての最適化が使用されなかった、主な負担は私たちが頼っていたサービスにかかっている、悪意のある管理者がアプリケーションのリソースを人為的に制限している、ロードバランサーがリクエストを不均等に分散しているなどであることが判明しました 膨大な数の予測不可能な状況が私たちに命を吹き込みます。

それらのほとんどは、疲れたユーザーの猛烈な精神に落ち着きます。 残りは、何が起こったのか理由を理解することは完全に不可能である結果を記述する不明瞭なバグで作られています。 重要なサービスをリアルタイムで常時監視し、現在何をしているのかを理解することは、どちらの側でもはるかに優れています。

監視は、問題と負荷について知らせるだけでなく、分析と予測のための優れたプラットフォームでもあります。 それが私たちのすることです。 私たちは、どのように、そしてどういう意味で、あなたの盗撮的な空想のすべてを絶対に実現できるかを理解します。

問題の本質を説明したとき、多くの人が伐採について考えたと確信しています。 実際、ログをリモートで収集して分析し、結論を導き出すことができます。 そして、これは真実からそう遠くありません。 実際、これらは同様の問題を解決する関連ツールです。 正しい最新のロギングに関する紹介を聞きたい場合は、レポート「 構造化ロギング 」に注意することをお勧めします。

ただし、この記事では特にメトリックに焦点を当てます。 メトリックスとロギングの違いは何ですか？ したがって、ログの主な内容は、世界、ビジネスプロセス、期待、エラーに関する情報です。 それらを正しく調理する方法を知っていれば、その内容を簡単に分析できます。 しかし、ロギングの柔軟性とパワーが冗長で、さらに有害なタスクの巨大な層があります。

たとえば、プロセッサの負荷を常に監視したい場合。 もちろん、この情報を1秒ごとにログに書き込んでから分析できます。 しかし、ここで私たちは多くの問題に直面しています。その主なものはデータ量とその処理速度です。 監視するカウンタの数は、数十（プロセッサ、メモリ、GC、要求、回答）から簡単に始まります。 そして、大規模なプロジェクトでは、何百もの楽に到達します。

200のホストがあり、10秒ごとに100のメトリックを取得するとします。 1日に86,400秒ある場合、ログには毎日1億7280万の値が記録されます。

毎秒数千のメトリックを低レベルの顔のない面白くない情報とマージすると、ログがどうなるかを想像してください。 第一に、ナレーションの人間の可読性とロジックは、インフラストラクチャノイズの山ではなく、ログからまだ期待されています。 しかし、この問題はセマンティックフィルタの助けを借りて簡単に解決できます。 しかし、他の目的のために作成されたツールが処理するために現在必要な情報の量は問題です。 パフォーマンスの問題は、処理、転送、ストレージ、分析のすべてのレベルで発生します。 そして、これは純粋なルーチンです。原子力発電所、工場、または物事のインターネットなど、不釣り合いに大きな欲求を持つ他の多くの領域があります。そこでは、ひげを生やしたアナリストの主張によると、2020年までに各人に6つのデバイスがあります。常に監視する必要があります。

そして、絶対ボリュームについて話している場合、メトリックを操作するために必要なデータのサイズは、通常のログのサイズを大幅に超えています。 これはすべて、ログとメトリックに同じソリューションを使用することは不可能であることを示唆しています。 したがって、人類はメトリックスなどのログから隔離されています。 そして、独自のツール、アルゴリズム、アプローチを使用して、このデータに関する作業を2つの独立した部分に分割しました。 そして、過去2年間の傾向が示すように、決定は完全に正しいものでした。

グラフまたはドキュメント指向のデータベースの人気が高まっていることを聞いたことがあるなら、これはすべて、メトリックデータベースの周りで起こっている誇大広告と比較して、せせらぎです。 メトリックは時系列（時系列）で記述されます。 時系列は、特定の時間間隔で単一のソースから取得されたいくつかの値のシーケンスです。 つまり これらは、時間内に何かを定期的に測定した結果です。 たとえば、このグラフは、ストレージモデルごとにグループ化されたデータベースの人気の定期的な測定結果を表しています。

このグラフが時系列を指す典型的な指標は、時間軸の存在です。 そうである場合、ほとんどの場合、スケジュールはTSです。 確認するために、他の例を見てみましょう。

別の典型的な例は、サイトへのトラフィックを表示するYandex.Metricaです。

例として、ネットワークインターフェイスを使用して構成される時系列を詳しく見てみましょう。

1. まず、これはもちろん、値が読み取られる時間です。
   
2. 意味自体。 いくつかの値が存在する可能性があります。この場合、着信/発信パケットの数です。
   
3. また、アクションが発生したコンテキストを説明するメタ情報を値に追加すると非常に便利です。 これにはタグがあります。 これらには、たとえば、測定を行ったホスト名やネットワークインターフェイスなど、何でも割り当てることができます。
   

リレーショナルデータベースとの類似性を引き出すと、これら3つのパラメーターすべてを「ネットワーク」テーブルの形式で表すことができます。

この場合、時間は常にその主キーであるクラスターインデックスになります。 タグにはインデックスが付けられた列が使用され、その上に集計が非常にうまく構築され、フィルターが作成されます。 値自体は非インデックス列です。

しかし、公開データベースとは異なり、TSDBには固有の情報があります-このデータの性質を知っているため、信じられないほどの最適化が可能です。 そのため、パブリックデータベースは常にはるかに遅れを取り続けます。 たとえば、時系列データベースの作成者の間には興味深い指標があり、その助けを借りて、独自の優位性の観点で一緒に測定されます。1つのレコードを保存するのに必要な平均サイズです。 すぐに見積もりましょう：

日付と時刻は通常ナノ秒単位で保存され、8バイトを占有します。 タグは簡単に20バイトを超えることができ、ダブル（TSDBに格納される値の最も一般的なタイプ）などのデータフィールドは8バイトを使用します。 あまり洗練されていない状態で保存すると、1つのレコードが約40バイトを占有します。 リーダーは何を自慢していると思いますか？ 2バイト。

すべての値を2バイトでパックします。 そして、これは制限ではなく、1バイトの領域で最高の戦いです。 これはどのように可能ですか？ データの発信元の詳細を知って、これをすべて2バイトにする方法はありますか？

最初に頭に浮かぶのは、標準の圧縮アルゴリズムの使用です。 これは通常、悪いアイデアです。なぜなら、それらはまったく異なる量の情報用に作成されたものであり、作業には余裕がないほど多くのコンテキストが必要だからです。 まあ、彼らは30-40倍遅く動作します。

私たちは他の方法で行きます。 タグから始めましょう。 一定のデータストリームでのサイズをゼロに減らすことができます。 これはどのように行われますか？ メトリックの名前にタグのすべてのキーと値を掛けて、いくつかのストレージスロットを取得します（例2）。

したがって、データ領域からスキーマ領域にタグを転送します。 そのため、タグの値を乱数で表すのではなく、最終的な辞書に収める必要があります。 時系列のこの部分は「シリーズ」と呼ばれます。 シリーズ自体はデータを保存せず、時間的に一定であるため、サイズを単純に無視できます。 したがって、タグはゼロに折りたたまれます。

シリーズがスペースを占有しない場合、タイムスタンプと値がそれを占有します。 時間から始めましょう。 時系列で機能するすべての圧縮アルゴリズムは、列データベースと同じ原理に基づいています。 それらは、同じデータの連続ストリームで、単一の列で動作します。 通常、時間はナノ秒単位で正確に保存されます。 8バイト。 時間の経過とともに列を圧縮するには、Delta-of-Delta圧縮を使用できます。 これは、カウンターからのデータが通常定期的に定期的に取得されるという事実に依存するアルゴリズムです。 たとえば、5秒ごと。 これらの時間の間のデルタを計算し、間隔を見つけることができます。 最初の時間と間隔を指定すると、列の次の値を予測できます。

通常、間隔は変更されないため、最初のデルタの値を超えるデルタを再度計算できます。 そして通常はゼロになります。 このような特別な、頻繁に遭遇する値を保存するには、1ビットで十分です（2番目のデルタにゼロがあるか、ゼロではありません）。

これらがあまりにも大きな仮定であるとは考えないでください。現実の世界ではそうではありません。 Facebookによると、彼らはこの1つのゼロビットに時間の96％を詰め込むことができました。 当然、小さなガタガタ音や抜け音などをなくすためのアルゴリズムがあります。

カウンターはどのタイプでもかまいません。 しかし実際には、これらはほとんど常に浮動小数点数です。 メインマジックの目的は、フィールドのサイズを小さくすることです。
値は予期せずに散在する可能性があるため、以前のダブルデルタトリックはここでは機能しません。 別の手法は、すべての値が1つのソースに由来するという知識に基づいています。つまり、それらの値の精度と寸法は同じです。 実際には、これはバイナリ表現が非常に似ていることを意味します。 つまり 近隣の値を使用すると、非常に少数の重要な文字が取得されます。

元の値よりもはるかに少ないビット数で保存できます。 そしてその隣に、最小の側からゼロの数を保持します。 しかし、実際にはもっと楽しいです。 Facebookの統計によると、すべての値の51％が以前の値と一致しています。 xorはゼロになります。

おそらくご想像のとおり、この特殊なケースを保存するには1ビットで十分です。 それだけではありません。この例のXORは、最も平凡な予測子です。 現在のデータに動的に適応し、したがって非常に高い確率で値を予測できる予測子が他にもあります。その結果、非常に重要な変動も1ビットでパッケージ化できます。
したがって、データが同じ間隔で到着し、変更されない場合、これを2ビットにパックできます。 もちろん、これは現実の世界では起こらず、実際にはデータが変更されるため、Facebookは1つの値に1.37バイトを費やします。 そして、これは私たちが今調べたこれらの原始的なアルゴリズムの助けを借りているだけです。

これらは非常に興味深いアルゴリズムです。何時間も話をすることができますが、天から地球に戻って、アプリケーションとその環境を見てみましょう。

• このアプリケーションでは、まず、メトリックが重要であり、そのためにメトリックが機能します。 つまり、ハードウェア、オペレーティングシステムです。 これらのメトリックのソースはパフォーマンスカウンターです。 それらには、CPU、ディスク容量、メモリから、.NET、ガベージコレクター、JIT、IIS、SignalRなどの高レベルプラットフォームで終わる有用な情報がたくさんあります。
  
  
  
  
• それでも通常、私たちがやり取りするサードパーティのコンポーネントがあります。 そして、すべての通常のサードパーティプレーヤーには、常に減算可能な統計APIがあります：Seq、MongoDB、MS SQL-これらすべての製品には、APIが用意されており、これらのAPIを使用して、ステータスを要求し、たとえば、どのように感じているかを確認できます。
  
  
  
  
• また、私たちの愛するETWについても忘れないでください。そこには多くの興味深いものもあります。最初の段落で探しているものが突然見つからなかった場合は、連絡してください。
  
• そして最も重要な、私たちが持っている最高レベルのメトリックは、もちろん、私たち自身のアプリケーション、あなたのビジネスドメインのメトリックです。 ユーザーが開いたドキュメントのサイズ、ログインしているユーザーの数、ビジネストランザクションの平均時間はすべてです。
  

ご覧のとおり、非常に多くの情報源があります。また、この情報を簡単に収集、集計、保存できる特別なソフトウェアツールがあることは驚くことではありません。 そのようなツールの1つがTelegrafエージェントです。 その標準的な配信には、人気のあるさまざまなプログラムを監視するための100以上のプラグインが含まれています。 システムカウンター、一般的なデータベース、Webサーバー、キューなど。

大規模なコミュニティ、柔軟な設定、優れたプラグインシステムにより、このツールは不可欠な監視ツールとなります。 Telegrafは、さまざまなソースや形式から情報を収集できるだけでなく、クライアントで情報を処理および集約できるため、中央サーバーのボリュームと負荷を大幅に削減できます。

実際にTelegrafの仕組みを見てみましょう。 奇妙なことに、Grafanaから始めましょう。

この時点までGrafanaについて特に言及しなかったので、エントリのしきい値がどれだけ低いかを理解できます。 知っておくべきこと：Grafanaは、TSDBから時系列を視覚化できるWebベースのグラフィカルインターフェイスです。 Grafanaには、多くの異なるプラグイン、既存の人気のあるシステム用の既製のダッシュボード、異なるデータソースなどを含むリポジトリがあり、そのうちの1つを使用します。

Influx Windows Host Overviewというダッシュボードがあります。これは、Telegraf for Windowsのダッシュボードを作成するためにのみ必要です。

このダッシュボードは2つの部分で構成されます。1つ目はTelegraf自体の設定で、Grafanaが取得するためにレポートする必要のあるパフォーマンスカウンターとフォーマットを示します。

これらの設定をコピーし、Telegraf自体の設定に貼り付けます。

ご覧のとおり、設定は非常に直感的で理解しやすいものです。パフォーマンスカウンターの名前を設定し、ポーリング期間を構成します。

このTelegrafはすべて収集し、Influxに送信します。

ダッシュボードに戻りましょう。 私が言ったように、それは2つの部分で構成されています。次に、2番目の部分について話しましょう。 2番目の部分は一意のダッシュボード番号で、コピーしてローカルのGrafanaに移動し、この一意の番号で19:04にダッシュボードをインポートします。この時点でGrafanaはインターネットに移動してダッシュボードをダウンロードし、次の2番目にシステムに関する多くの興味深い情報が表示されます。

スレッド、プロセス、CPU使用率、メモリ、ディスク、ネットワークインターフェイス、到着したパケットの数、失われたパケットの数、ハンドルの数などについての完全な情報を以下に示します。 システム内のすべてのプロセスを具体的に誓約しましたが、実稼働コードでは、作業に必要なプロセスのみに制限する必要があります。
先ほど言ったように、TelegrafはGrafanaと直接対話せず、それらの間にInfluxがあります。 InfluxDBは、現時点で最も人気のある時系列データベースです。

彼女は非常に迅速にすべての競合他社を追い越しましたが、今は遅くなりません。 そして、私たちのテストは、これが当然のことだと示しました。
Influxの例を、TSDBが通常使用するデータの詳細と、リレーショナルデータベースとの違いを見てみましょう。

• まず、これらは数百万のデータポイントと数百万のシリーズです。 リレーショナルデータベースに数百万のテーブルを作成し、それらに数百万の値を入力し始めたかのようです;これは実際にはめったに見られません。 Influxの場合、これは標準的な状況です。
  
• 頻繁な録音。 実際、ユーザーが何もしなくても、データは常にメトリックに書き込まれます。 メトリックは、彼が何もしない、まだ何もしないなどの事実について書かれています。
  
• 状況は読書でも同じです。 分析、ダッシュボード、アラートなどはすべて一定の読み取り値を必要とするため、非常に大きな負荷もかかります。
  
• 取り外し。 削除の主な理由は単にデータの「減衰」であるため、大きなバンドルで発生します。
  
• 更新はほとんどなく、無視できます。
  

CRUDに関しては、InfluxはCRシステムであり、データをすばやく作成して読み取ることが非常に重要です。 更新と削除は非常にまれにしか行われず、特定の最適化された状況で発生します。
「内部」では、データを独自の時間構造化されたマージツリー形式で保存します。

これは、時系列に関連した既知のログ構造化マージツリー（LSMツリー）の最適化であり、実際に実証されています。 これは、頻繁に挿入される状況でインデックスによる迅速なアクセスのために最適化されたデータ構造です。 たとえば、ほとんどすべての最新のデータベースのトランザクションログで使用されます。
Influxのもう1つの大きな利点は、SQLに似たクエリ構文です。

なぜこれが重要なのですか？ 彼の以前の反対者は、この側面の不十分な研究で非常にひどく罪を犯しました、彼らは私たちに、このような厄介な正規表現、JSON、および著者の病的な精神のクエリから構成するように頼みました。 一般的に、1週間のうちにどこかに来て、問い合わせを見て、目が尽きることを維持することは不可能でした。 そして、Influxが一般の人々を襲ったのは通常のクエリ構文でした。

私たちが絶えずデータを蓄積しているという事実について話すならば、あなたは私たちがそれらで何をするかを理解する必要があります。 これには保持ポリシーがあります（必要ない場合、一定期間後にデータを削除する特別なメカニズム）。 しかし、これはあまりにもありふれたものです。 連続クエリ（マテリアライズドビュー、サーバー上の複雑な集計の事前計算など）などの機能を使用すると、ダウンサンプリングなどの興味深いメカニズムが得られます。 例を挙げます。

あなたのサイトに来るリクエストの数を測定したいとしましょう。 グラフでリアルタイムでそれを実行し、すべての負荷を監視し、何らかの形でそれに反応することができます。 1日後、リアルタイムの値は冗長になり、10秒間隔に集約し、集約（最小、最大、カウント、目的の値）を計算し、同じデータセットを非常に小さいサイズでのみ保存できます。したがって、はるかに少ないスペースを使用します。 1週間で、期間を1分間、1か月-1時間に増やし、このデータをアーカイブに残して、たとえば、1年間のアプリケーションのパフォーマンスを比較できます。

パフォーマンスについては、数値について説明する前に、このような高度に専門化された分野では、すべてがパフォーマンスに絶対に影響することを予約する必要があります：メトリックの数、タグの飽和、クエリの頻度、Influxを絶えず動かし、このデータを読み取る分析アルゴリズムの複雑さ。 最もありふれたアドバイス-常にデータと環境を試してみて、あなたに何が起こるかを見てください。 それでも、私がこれについて話している理由を理解できるように、いくつかの数字を示したいと思います。

1秒あたり25万件のレコードに満足し、十分な数のエピソードがある場合、6コアと32 GBのRAMを搭載したマシンで十分です。 . , . Influx- , , .

time series ? , :

TSDB — InfluxDB OpenTSDB. OpenTSDB — TSDB, .

— .

, , , , , . , , . , , .

elastic (, ), .

, . Influx 5 27 :

9 84 , :

MongoDB, 168 Cassandra.

.

, Influx . , . , App Metrics, , WebAPI-, Grafana. , :

, Owin-, , , , , App Metrics:

, , InfluxDB :

, HealthChecks:

HealthChecks — «» , . , .
, , , - :

AppMetrics , , , , .

.

, , , , API-:

, , , , , , . , , — . , , HealthCheckers:

, , — .

, , , , . , ? :

• -, Telegraf , . .
  
• App Metrics , . Web API, .
  
• . . , , , body. , , .
  
• , .
  
• , , -.
  

, , -, , . , . , Influx Grafana.

, BenchmarkDotNet. , -: . , , . , , , -, Influx. , , Grafana , , , , .

? , . , influx.exe:

Influx . , benchmarks, .

: , , .

:

:

BenchmarkDotNet, . , — InfluxExporter, :

. :

IExporter, BenchmarkDotNet, , .

MetricsCollector:

, InfluxDBCollector. , .

. , , real time.
, , :

.

InfluxDB LineProtocol, :

, .
Grafana. , Data Source.

, InfluxDB, Influx ( ). Data Source , .
Influx , .

Data Source , Influx . , , :

, . . : , , Grafana .

, , .

, Grafana Telegram. , .

, , Telegram. , . .

.

, .

. , , , . . . , , . , , . .

, , . , , , . .

Dynamic Time Warping. . , «» . , , , , .. : , , , API gateway. API gateway DDoS-. , , . 100% CPU, — - , — - . , , , . . DTW .

, , , . , , , , . , , , , — .

— . .
.

, . , . , .

現実に目を向けて、ツールを見てみましょう。 InfluxDataは、アプリケーションで役立ついくつかのツールのセットを提供します。 それらはすべてTICKという一般名で統一されており、互いに完全に統合されています。

私たちはすでにTelegrafに精通しています。 これは、データを集約してサーバーに送信できるメトリックコレクターです。

InfluxDB。 原則として、InfluxDBは優れています。1秒間に100万件未満のレコードを作成する場合、無料版で十分です。 無料版の唯一の重要な制限は、クラスタリングの欠如です。 したがって、メトリックシステムのフォールトトレランスと信頼性が必要な場合は、これがすべて揃った有料版が必要です。 Influxは、クラウドソリューションとセルフホストソリューションの両方で販売されています。

クロノグラフは、この家族全員を結び付けるWeb UIです。 彼はひどいので、私は彼について話しませんでした。 しかし、残念ながら、他のツールはありません。 Influxにアクセスして、存在するデータ、作成されるメトリック、保持ポリシーを確認する必要がある場合は、この不名誉が役立ちます。 原則として、それは順調に発展しており、近い将来、それを使用することさえ可能になるという希望があります。

Kapacitorは、機械学習を使用して異常を検出するツールとして位置付けられています。 しかし、それは多くのバグと頭脳に耐えるクエリ構文を持っています;したがって、実際にそれを使用することは今後数年で完全に非現実的です、試みさえしないでください。 機械学習を使用して異常を実際に検出する必要がある場合、次のリンクが機能します：データを同じ方法でInfluxに保存しますが、独自のアプリケーションを使用して読み取り、ドメインに基づいて作成し、アナライザーとして工作機械用の標準ライブラリを使用します学習。 それはうまくいきます。 必要に応じて、このように見てください。

それでも何らかの形でInfluxのライバルを見つけることができれば、Grafanaは競争を超えています。 優れた視覚化、最小限のバグ。 エントリのしきい値をフラットにする視覚的なクエリエディターの存在。 存在を保証する柔軟なプラグインシステム：データソースのヒープ、カスタムパネル、すべての一般的なニーズに対応する既製のダッシュボード。 これは、椅子でモニターを壊したくない、唯一のレスポンシブWebアプリケーションです。 一般的に、ここでは今後数年間で代替手段を探すことさえしません。

興味深い点は、GrafanaとInfluxの組み合わせです。このスキームは非常に自律的です。 これはどういう意味ですか？ これらのツールをインストールしたら、開発者に2つのURLのみを提供します。 1つ目はInfluxからのもので、開発者は別の機能を実装して、このURLに独自のメトリックを書き始めます。 Influxについて何も知る必要はありません。動的回路があるため、Influx自体がそれに適応します。 2番目のURLはGrafanaからです。 開発者はデータをInfluxに記録し、Grafanaにログインし、ビジュアルエディターの助けを借りて簡単かつ迅速に自分用の素敵なグラフを表示し、すぐに作業の結果を確認します。これは開発の実践において非常に重要です。 したがって、アプリケーションの非常に大きなメトリックカバレッジがあり、将来的には非常にうまく利用できます。

残念ながら、現代世界の多くのツールにはLinuxファーストのアプローチが採用されています。 これは、まず、プログラムがLinuxで開発され、その後、残差の原則によってWindowsに移植されることを意味します。 同じ運命が私たちのヒーローに降りかかった。 Grafanaは簡単で、ウェブインターフェースを備えており、どこから始めても構いませんが、Influxは5年以上開発されているという事実にもかかわらず、わずか6か月前にWindows用の配布キットを受け取りました。 ） 現時点では、このような遺伝の唯一残っていることは、これらのツールがコンソールアプリケーションであり、Windowsシステムとしての標準的な展開単位であるWindowsサービスとして実行できないことです。 NS Service Managerなどのツールは、この問題の解決に役立ち、コンソールアプリケーションを使用して、本格的なWindowsサービスを作成します。 小さくて良いユーティリティ、中断や苦情なしで動作します。

別のアプローチを見てみましょう。 だから：

• 即時挿入と高速読み取りが重要でない場合;
  
• 帯域幅に達していない場合;
  
• 透明なダウンサンプリングを夢見ていない場合;
  
• 連続クエリがどのように役立つかわからない場合
  
• 組み込みの統計と高度な集計機能が必要ない場合;
  
• 廃止された各エントリを個人的に削除する場合。
  
• あなたがベースのサイズを恐れていない場合;
  
• システムに高負荷がないことが確実な場合;
  
• リアルタイム分析を失う準備ができている場合。
  

その後、原則として、標準データベースを使用して、それらにメトリックを保存できます。 そして、これは一見したほど馬鹿げているわけではありません。これらの昔から働いていたチームの既製の専門知識は、プロジェクトに新しいツールを導入するために必要なリスクしきい値を超えることがあるからです。

私はこの方法が最も実行可能であることが判明した多くのプロジェクトに出会ったので、恥ずかしがらずに、これは普通のことです。

今日お見せしたその束（Telegraf、Influx、Grafana）は、パフォーマンスと柔軟性の点で最も低レベルで最適なシステムです。 当然、誰もがそのような低レベルを必要とするわけではありません。 多くの人はこれに煩わされたくないし、より高いレベルのソリューションを選択したいと考えています。彼らはまた、市場で満員であり、機能します。

また、クラウドについて恥ずかしがり屋でない場合は、有料ソリューションがたくさんありますが、かなり良いものです。

通常、これらの高レベルのソリューションはすべて、メトリックとログを一緒に使用して、同じダッシュボードという1つのスキームにそれらを関連付けようとします。
残念ながら、1つはお勧めできません。 高レベルのソリューションについて話すときは、プロジェクト、ワークロード、開発へのアプローチを具体的に検討する必要があります。 InfluxDBとGrafanaは、基本的なレベルの一種であり、突然代替手段を探すことにした場合にガイドする必要があります。

お気づきかもしれませんが、TSDBを使用する際の大きな機会の1つは、アルゴリズムに慣れることです。 アルゴリズムは非常に興味深いものです。

• ゴリラ紙
• アクムリ
• ランレングスエンコーディング
• ヴァリンツ
• ジグザグ
• 動的なタイムワーピング
• スケッチベースの変更検出
• 携帯電話ベースの飲酒運転検出

このトピックをもう少し詳しく知るためのリンクを次に示します。 突然、ちょっとした魔法、エレガントなソリューション、またはクールで優れた圧縮のファンなら、寝る前に夜にこの最小限を読んで、よく眠れると思います。

ヒーローに関する詳細情報を知りたい場合は、公式ウェブサイトの標準情報で十分です。

• Influxdataサイト
• Grafanaサイト
• アプリ指標サイト
• 非吸盤サービスマネージャー

もちろん、非常によく書かれており、常に関連しています。

記事を読んだ後に質問がある場合は、メトリックの使用方法、おもしろいグラフィックについてお気軽にご連絡ください。

• Anatoly.Kulakov@outlook.com
• twitter.com/KulakovT
• github.com/AnatolyKulakov
• SpbDotNet.org

古典が言ったように、「楽観主義は情報の欠如である」という理由で、私はこのトピックに長い間多くのことを対処します。 したがって、友人は現実的になり、アプリケーションが何をするかを知ってください。 ご清聴ありがとうございました。

広告の分。 おそらくご存知のように、会議を行っています。 今後の .NET会議はDotNext 2018 Piterです。 2018年4月22〜23日、サンクトペテルブルクで開催されます。 どんなレポートがありますか-YouTubeのアーカイブで見ることができます。 会議では、各レポートの後、特別なディスカッションゾーンで講演者や最高の.NETエキスパートとライブチャットを行うことができます。 要するに、私たちはあなたを待っています。