今日のセッションはフレントリーとディステビットログを紹介します私の名前はマサヒロンナカガワーですこのセッションはフレントリーとディステビットログを紹介しますログとコンテナーを紹介しますこのテーマはコンテナーのログを紹介しますありがとうございます今、プロダクションのログを採用する必要がありますログのタイプが多いので、サービスログを採用する必要がありますこのログはビジネスの影響により、ウェブアクセスログを採用する必要がありますこのログはエコマシスのゲームやトランザーチャルログを採用する必要がありますこのログはKPIモニタリングやマシンライニングを採用する必要がありますこのログはシステムログを採用する必要がありますこのログはシステムジーログやセッションログを採用する必要がありますこれがプロダクションのエンジンガーやGPUモニタリングのメトリングやシステムログを採用する必要がありますこのデータyピヨーゼルトなどが息を出したデータはパフォルマスなどはちょっと向かう math struggleプロダクションを作っていますでも今、コンテナエラのためにローギングに変わっているとシステムアクテクチャーはモノスティックの大きなアプリケーションでマイクロサービスを使ってコンテナを使ってコンテナのシステムはミュータブルでイメージをアップロードする必要がありますシステムをアップロードする必要があります一つの重要な点はデータはFMLでコンテナを使ってデータはデストロインでコンテナデータを使ってコンテナを使ってデータを使ってコンテナの動きを使ってコンテナのアプリケーションでシステムを使ってコンテナのアプリケーションでサーバーエラを使ってサーバーアドレスにグルーピングしグルーピングや厚いタスクが hashingそのため、ローギングに関しては非常に難しい問題があります。FMLRのコンテナーはFMLRストレーションです。そのため、ローギングに関する必要があります。このように、ローギングに関する必要があります。このように、アドレスを使う必要があります。そのため、コンテナーを取り出す必要があります。この意味は、コンテナーは外側に関してのローギングに関してのローギングを取り出す必要があります。そして、マイクロサービスを使う必要があります。この意味は、アプリケーションのタイプがあります。この意味は、ローギングのタイプとローギングを取り出す必要があります。一部はファイル、一部はネットワークス、一部はシスローグリオ、システムディを取り出す必要があります。このようなローギングのタイプに関する必要があります。ローギングデーモンを取り出す必要があります。この問題をみるいに説明します。フレントリーを使う必要があります。この問題をあなたのお話しをしてもらえます。この問題は、私はこの問題についても言う必要があります。この問題がこのシンプルでスクリプションの必要があります。この問題は、フレントリーの状態が即序と同じ可能性であるのです。フレントリーは、現実的なデータコレクションの咒嚐を使っている。シンプルなバランスが即序と同じ可能性であるのです。ドメインスペシックの問題は、プラグインを作ることができます。フレントリーQ2コアは簡単です。プラグインの問題は、スペシックの問題を解決しています。フレントリーはリライアブルです。リライアブルは、フレントリーコアがログトランスフォルスとログコレクティングを作ることができます。フレントリーは、フレントリーコアを作り、ステーブルログトランスフォルスフォルスなどのプラグを受け、ステーブルログロスフォルスなどのプラグを受け、データクラスの作業は、簡単です。リライアブルは、フレントリーコアを作ることができます。フレントDのログコレクションのメカニーズは非常に素晴らしいですフレントDはインタイルプラグインを見ることができますアプリケーションでフレントDのログコンテンツを見ることができますこのイメージでフレントDのログサーバーを見ることができますこのトレーショナルアプローチの上、ログロータションについて、非常に高い高さを持っているので、1時間か1日か、トレーションの通り、RSCINCOが、ログフォーマットのデータについて、ログサーバーのデータの上にアプリケーションを調整することができますでもフレントリーは、ストラクチャードログの方法を使います。フレントリーは、データをストラクチャードフォームアップに入れ、エジ2を使って、ログサーバーのサイドに入れることができることができます。フレントリーは、データのインティグレーションについての差し込みを解決します。フレントリーは、セブナルスクリプトを使って、データのデータソーシーを取り出すことができます。データソーシーは、ハードウェープやデータソーシーを取り出すことができます。 sometimes the implemented language is different.one is a shell, one is a Python or one is a Goran.This is a very messy and complicated problem for the data integration.フレントリーは、データパイプラインを使って、フレントリーを使って、セブナルデータソーシーやデータネタソーシーを取り出すことができます。これは、プラグインでエクステントさせることができることができます。このメカニズムは、ユニファイドロイングレーションです。フレントリーのオーバーベースです。次に、フレントリーアーキャクチャーを紹介します。データストリームのフレントリーを紹介します。これは、シンプレファイドアーキャクチャーのフレントリーインターナーです。フレントリーは、データをプロセスして、この4個は、データパイプラインで重要です。この4個を紹介します。データを通過すると、左から右から左から、プラグインでデータソーシーを取り出すことができます。プラグインでデータを取り出すことができます。重要なポイントは、ログフォーマンスです。下に、タイムとタグランドのレコードを使っています。フレントリーは、ログを取り出すことができます。プラグスを変更すれば、チェックでこういうフォーマンスを取り出せます。タイム、タグランドを取り出すことはできます。タイムがでもっとが 상 Lionとインプと合わせるので With this structure group format。タグランド、フォーマンスト、ルーブ、拉すりばことができます。このタイムでログを取り出すことはできます。このウ email これくからそしてこのエプリコード点ができます。このメトリックスローグやアプリケーションローグなどレコードはテキソラインではありませんJSONはキーバリュウペアーです新たなシステムでJSONフォーマットを受けたエラシックスターチやモンゴディービューなどJSONを使ってテキソラインを使ってテキソラインはデータインティグレーションを使ってモデリファイズのデータはパイプラインでメタデータやジオロケーションからのIPアドレスを使ってハードトゥンブリファイズのデータはフェン・レコードフォーマットでテキストを使ってJSONフォーマットを使ってJSONフォーマットを使ってフェントリーはバッファーを使ってアウトプットを使ってパフォーマンスとリライアブリティを使ってバッファーを使ってチャンクを使ってアウトフラッシュコストを使って大きなチャンクを使ってスループットを使ってバッファーファイズを使ってローカルディスクを使ってサーバーやフレッドディクラッシュを使ってバッファーのイベントがローカルディスクを使ってデータパイプラインを使ってスループットを使ってスループットを使ってほっと、フレッドディスクを使ってフレッドディスクを使ってサーバーのアイスセットはスライミングマンスでリローupでデータローコラクションでデータローコレクションを使ってスループットでアイスセットはこのモデルはEG2リトライを使ってチャンクが小さくなっているのでこのフェルトを使ってEG2リトライを使ってサイズが小さくなっているバッチモデルを使ってリカバリモデルを使ってもちろんディスネーションサーバーはネットワークエラーやオーバーローディットを使ってこの場合はフレントリーをリトライを使ってフレントリーはアルゴリズムを使ってバッコフを使ってリトライをオーバーロードしてフレントリーはペロディックのターバルを使ってこのディスネーションサーバーは良いですフレントリーはパラメーターを使ってリカバリモデルを使ってたくさんバッコスを使ってリトライデータは常に行われているこの場合リトライリクエストはリカバリモデルの数が増えているシステムシャットダウンを使ってこの問題を見つけたフレントリーはパラメーターを使ってリトライを使ってフレントリーを使ってフラッシュインターバルをバッコスの中にチェンジすることができますディスネーションは低い能力でフレントリーはスローリーでこのディスネーションを使ってフレントリーはフローコントロールを使ってフラッシュインターバルをバッコスの中にリカバリを使ってフレントリーはプラグインを使ってインプットとアウトプットを使ってインプットを使ってフレントリーはカフカやシステムメトリーを使ってDFやツイッターやSQLを使ってRDBMSを使ってフレントリーを使ってアウトプットはプラグインを使ってログスを使ってネーションを使ってAWSGCPやマイクロソードを使ってアジュールやエラスティクサーやチカフカを使ってディスネーションを使ってフレントリーを使ってコンフュレーションを使ってディスネーションを使ってフレントリーを使ってキャンボリーにコードをデータをパイプラインにログスを使ってコンテナを使ってコンテナを使ってアプリケーションを使ってコンフュレーションでアプリケーションを使ってその分解してこれらの新物のコンテナを使ってコントナーを使ってローグs are distributed, so we need to collect the logs from lots of containers for the data analytics or data stores.So, I talked about how to use the friendly for the distributed logging cases.Okay, distributed logging, there are three roles.One is a source.A source is a consist of two components.One is the application container, and one is the agent.Tipically, it's a fluently or other several monitoring agents, like a data log or something.Next is aggregation layer.This is mainly for scalability and stability.So, I will talk about this point later.Destination.Destination is very simple.So, you are destination storage.So, you have to put a search or cloud services.And each roles has each tasks.So, a source is need to get the little logs from the file or network or API.So, mainly container and data logs to the standard output or something.So, we need to collect these logs.Of course, if you are using the friendly,so, need to pass the payload for the structured logging for the further next layer computation.Aggregator is simple.Aggregator is get logs from the multiple sources to collecting the source layers.And the important point is aggregator should the task is splitting or merging the logs into the streams.This is mainly for the network efficiency,or this is mainly for the splitting of the traffic into the small traffic.This is for the scalable logging.Destination is received logs from aggregator.So, stores data into the local fileor SC or something.So, the important point.So, I said that you need to collect logs from the containers.So, how to collect logs?So, friendly has several ways to get the logs from containers.In this talk, I assumed the container is running on the docker.But maybe similar approach is as other containers can support the similar approach.One is the logging driver.Logging driver is a docker feature.So, this is very useful for the collecting applications output to the other destinations.Docker drawing driver supports the front-end in the core.So, you can use this drawing driver to collect logs from the container to send to the front-endwithout no additional dependency.So, in this model, docker collects the output logs natively.So, your container or your application don't need to write any code.We just write the logs to the output.Docker collects the logs and sends it to the front-end.So, this is very easy.Next way is using the front-end logger.The front-end logger is a library for sending logs to the front-end via the forward protocol.The benefit is that you need to write the code in your application.But you can export any metrics into the front-end directory.So, you can do the distributed tracing-like mechanism by this approach.Of course, front-logger is supported by the many languages, so PHP or Ruby or Python or Rust or Goran or something.So, maybe your application can use this approach for sending the metrics.Next is, this is mainly for the middleware containers.So, using the shared volume.I see that the front-end has an Intel mechanism towatching the file to get the logs immediately.So, we use the front-end Intel fortaking the container's shared volume tocollecting the data without modification.This approach is using Kubernetes.Using the front-end and the shared data volume approach tocollecting the Apache or nginx logs to send to theElastic Sector to Kibana to visualize the data traffic.So, this is popular in Kubernetes.Kuban is like orchestration tools.So, we have several...I showed the three approaches for thecollecting the logs from the container.So, you can select the logging method for eachpurpose.So, easy two ways are usinglogging driver to collect the logs from theapplications output.And if you want to send any specific metrics from the application,you can use the front-end logout.And if you can't modify the middlewaresettings,you can use the shared data volumesto use the front-end Intel mechanism.So, this is also good for thecollecting the middleware logs.Of course, you can also put thefront-end in the container and thecollecting using the front-end plugins tocollecting the system metrics or something.We can collect the container's logs.So, the next problem is how todeliver these container logs to thedesignation.We have several deployment patterns on the production.We show the actual example withFluent-D.So, this is a very old and primitivedeployment.So, this model is sendingthe data application, sending data tothe destination directly.So, thisis very primitive, so noFluent-D cases.So, this isseveral problems.So, one isapplication should know the destinationside settings in the containersand the image.So, it meansif you change something in thedestination side.So, IP addressor cluster settings or changingthe destination middleware, you needto restart the old application.So, this is verymanaged to...this is hard tomanage the containers.Andanother problem is this isneed to the container...thenumber of containers to send tothe lots of connections intothe destination.So, thisit means the small requestmiddleware receives lots ofsmall requests in thedestination side.This isokay for the cloud lifeservices, but some middlewareis not good for thesmall request.Forexample, elastic search ormongodb.This middlewareimportal request is thehigh cost.So, if youlots of small request, smallimportal request, sometimeselastic search like themiddleware is overloaded andit causes a system trouble.So, we should avoid thesmall request for themiddleware.Avoidthese problems.We canuse the fluently put inthe source site.So, wecall the source siteapplication.So, these arethe several methods.So, onemedit is the configuration isdecoupled from the application.So,if you care the destination settings and the fluently free thelogging pain from theapplication.So, Iseed the fluently has a goodfeatures for the buffering orHA or retry mechanism.So,just container applicationjust sends logs to theflently efficiently.So, ifthe destination site isshut the troubles,flentlybuffering and retry smoothly.So, this isvery good for theapplication.And,flently buffering mechanismmerges the small requestinto the chunks.So, itis also good for thedestination.So,flently don't send thesmall request frequently in thedestination.So, this isgood performance for the elasticstature of MongoDB like middlewares.And, next modeldestination site aggregation.Thisis mainly for the high trafficenvironment.So, ifthe traffic is high andthere are lots of containers orservers.So, sourceside aggregation is not enough forthe destination site.So,in this case, weput the fluently on thedestination site and built themulti-tier aggregation toreduce the number of requests or themulti-tier aggregation.So,flently protocol has a good load balancing oractive standby or activeactive model.So, ifyour traffic is high,flently can handle thesetraffics in the veryefficient ways.So, this isgood for the high trafficenvironment.So, this isthe summary of why we usethe aggregation servers.So, iflogging directory from the containers,it has some type ofproblem with too many connectionsand the frequent API calls.So,put aggregationbefore the destination site.So, it resolvesthe problems.So,flently merge the connectioninto the small chunks,the buffer for thethroughput.And, ofcourse,flently has agood little mechanism.So,prevent the log lossduring the destination timedowntime.So,aggregation server isgood for the scalablelogging.This image issummary of the simplified image.So, you can selectyour bestapproach deployment patternfrom this images.So, if yourtraffics is lower,so, maybeonly source-side aggregationis better.This islower small containersand the flintly can handlecontainer logingsefficiently.And, ifyour environment hashigh traffics, so, pleaseput the destination-sideaggregation.So, yeah,yes.So, if youuse the distributed logings,so, source-side aggregationis a good start pointfor the collecting logsfrom the containers.So, this sideit depends on theyour environment.So, good forthe high traffics or if yourdestination has adon't have a goodstrong point for the frequentrequest,maybe please usethe destination-sidedestination-side aggregation.Itreserves the several problemshigh workload orseveral problems.So, this is thekeypoint of the scalabledistribute logging.So, this issimilar to the distributed processing.So, if you have heavytraffics, so, it shouldspread into thesmall traffics tothe several nodes.So, itis easy to recoverfrom the heavy traffics.And, if you have lotsof connections, pleaselet's merge the connections intothe small collection, numberof small connections.So, itreuses the problem with lotsof requests.and the CPU memory.So,of course, heavyprocessing should be done inthe data analytics layer.So, forHadoop ordata warehouse or something.But sometimes we can, wewant to use theseveralnotes to be distributed tothe several nodes.For example, the machinelearning or something.Itshould not bein the one nodesshould be distributed.And,of course, toforce scalability, we needto use the HA feature.So,if we have lotsof containers or lotsof servers, sometimes tocontainize the server iscrushed.So, we shouldrecover from the failure cases.So,for this cases,frontly has a built-in HA cases.So, if destination iscrushed,frontly switches fromto another node.And, of course, load balancingis also a good feature for thebalances, the traffics into themost small nodes.Actually,we shouldreconfigure foursystems.Iffen modifies the destination.So, please decouple theconfiguration of theseveral settingshould be separated to eachcomponent.Not depend on theother components.So, this isside conclusion.So,frontly,I talk abouthowfrontly is thecontainer-logging mechanism.So,frontly's protocol model isa bit for the lots ofapplication types.So,frontlyprovides lots of plugins.So,you cancollect the logs from the lotsof applications by changingthe configuration.And,frontly is robust throughbuffering on the littoralmechanines.EG2 sendsthe data to the destinationswith the robust way.Of course,frontly hassupported the typicalcommodation.We can usethe source side aggregationand the distance side aggregationand both aggregation.So,you can selectthe good deployment patternfor the requirements.Of course,we nowhave a very good productunder the CNCF for thescaled system.So,case relation for the Kubernetesand monitoring for theprometheus.Of course,logging is very important.So,we can noweasy to make the scalableand stable systems foryour business orservices.Enjoy learning.Thank you.