C++ 文字列を途中経過を確認しながら辞書順にする
next_permutation
[始め,終わり]の範囲を起点として順当に辞書順にしていく。
使い方
string s = "cab";
sort(s.begin(), s.end());
do{
cout << s <<endl;
}while(next_permutation(s.begin(),s.end()));出力例
abc acb bac bca cab cba
このようにnext_permutationを使うことにより簡単に並び替えの途中経過を知ることができます。
C++ bitsetのお話
bitsetについて調べたことをまとめておきます。
bitsetとは
配列である。
配列のすべての要素は0か1である。集合などに使うと便利だったりする。
サンプルコード
#include <bitset> //宣言方法 bitset<8> a(a1); //10進数にする cout << a.to_ullong() << endl;
bitset<ビット数> a(bitsetにする変数)
()に入る変数はstringやint型でも可
Monitoring Distributed Real-Time Systems:A Survey and Future Directions論文メモ(1)
1章
元米国大統領ロナルド・レーガンの署名フレーズは、ロシアのことわざ「信頼するが、検証する」だった。予期しない環境条件や論理的な設計エラーにより、システムの想定される信頼性が大幅に低下する可能性がある。システムが「10億分の1」の信頼性を実証するためのテストは実行不可能である。テストもフォーマル検証(設計の仕様と、設計結果の回路をそれぞれ数学的に解析することで、回路の正しさを検証する手法)であるが、超信頼システムの信頼性を実証するためには、不十分であるため実行時にシステムを監視するというアイデアが提案されている。モニターシステムの動作を観察し、それが仕様と一致しているかどうかを検出する。モニターはシステムが仕様を満たしているか追加の信頼性を実行時に提供できる。
2章
スペースシャトルのデータ処理システムは、冗長セットで動作する4台の汎用コンピュータがある。オービター(スペースシャトル本体)は23個のマルチプレクサー(複数の信号を入力として受け取り、それをあれこれすることで1つの信号にして出力する)デマルチプレクサ(1つの信号を入力として受け取り、それをあれこれすることで複数の信号にばらして出力する)ユニットも搭載されており、そのうち16個は共有バス(複数のデバイスが1本のバスを共有する形)を介して直接GPCに接続されている。GPCは、障害検出、分離、および回復機能を含む冗長性管理アルゴリズムを実行する。
Tools and Benchmarks for Automated Log Parsingの論文メモ
概要
最新のソフトウェアの規模と複雑さが増えると、ログの量が莫大に増える。それに伴って手動でログの検査をするのは困難になる。ログは構造化されていない。初めの重要な段階は、ログメッセージを解析して、構造化データにして分析を行うこと。自動ログ解析に関する包括的な評価研究提示して、簡単に再利用ができるようにツールとベンチマーク(基準点)をリリースする。
1章
ログは、ソフトウェアの開発・保守において重要な役割。豊富な情報とログが普及すると使用統計(開発の際にどのような新機能や機能の向上を優先させるかを決定するのに役に立つもの)などのさまざまなシステム管理や診断タスクに役立つ。
ログを効果的に分析することは課題である。その課題を下記に上げる。
- ログメッセージにおいて診断情報を手動ですることは現実的でない。
- 開発者はフリーテキストを使用して記録するため、ログメッセージは構造化されていない。
ログメッセージはロギングステートメントで出力されて、メッセージヘッダとメッセージコンテンツとともに特定のシステムイベントを記録する。だが、開発者のフリーテキストメッセージを構造化するのは困難。
ログ解析の目的は、各ログメッセージを特定のイベントテンプレートに変換すること。大量のログを解析するためにアドホック(その場限りの)ルールを手動で作成することは時間がかかる。
2章
既存のログ解析の特性と手法を確認し、ツールの実装を行う。
テキストログメッセージを構造化された形に解析をするとログの効率的な検索、フィルタリング、グループ化、カウントや高度なマイニングが可能となる。
- 使用状況分析・・・ソフトウェアの開発及び保守中の一般的なタスクである。例として、ユーザーの行動分析が含まれる(例：Twitter)。
- 異常検出・・・システムを監視するのに大きな役割を果たす。ログは詳細な実行情報を記録するため、システムの異常な動作を検出するための貴重なデータソースとして機能する。最近の研究で、機械学習技術の使用が調査されている。(例:PCA,不変マイニング,ディープラーニング)このような場合ログ解析は機械学習モデルをトレーニングするために必要なデータ前処理ステップである。
- 問題の識別が重複している。システムの問題において例えばディスクエラー、ネットワークの切断などが頻繁に再発するか、様々なユーザーから繰り返し報告される可能性がある。多くの重複する問題に開発者やサポートエンジニアの労力を減らすため、重複する問題を自動的に特定することが重要。
- Facebookは昨今ユースケースを報告した。ログを貴重なデータソースとしてパフォーマンスモデリングに適用し、潜在的なパフォーマンスの向上を迅速に検証できる。
- 故障診断・・・ログは膨大な量だけじゃなく、乱雑であるため手動の障害診断は困難な作業。機械学習技術に基づいて根本原因分析を自動化するために作成された。
ログ解析の特性
オフラインのログ解析は、バッチ処理(データをかなりためてから行う処理)の一種。
大量のログを考慮すると実際のログ解析では効率が常に主要な懸念事項である。効率の悪いログ解析は、リアルタイムの異常検出やパフォーマンスモニタリング等の場合にレイテンシ(データ転送要求してからデータが送られるまでに生じる遅延時間)要件が低い後続のログ分析タスクを大幅に妨げる可能性がある。
ツールが受け入れられていない理由
自動ログ解析は数年前から研究されているが、それでも業界で広く受け入れられている手法はない。この要因は、主に産業用にすぐに使用できる公開されているツールが不足しているためである。
3章
ツールの評価
16あるデータセットで13のログ解析を精度、堅牢性、効率の観点から評価を行う。
現在実際のログデータは公開されていないため、分散システム、スーパーコンピュータ、オペレーティングシステムなどから作成した。可能な限り、ログはいかなる方法でも、サニタイズ(危険なデータやコードを変換または削除をして無力化すること)、匿名化、変更はされない。
図２は、最高のところが*最高の数値を示している。13のうち8個が少なくとも2つのログデータセットで最高の精度を出した。いくつかのログツールは複雑な構造と豊富なイベントテンプレートが原因で正確に解析ができなかった。平均において最も正確だったのがdrainであった。
堅牢性
堅牢性は、実稼働環境でログ解析を実際に使用するために重要である。様々なタイプのログに渡る堅牢性と様々なボリュームのログの2つの観点から堅牢性を測る。
精度の良かった13のツールから８個抽出して比較してわかったことは、Drainが最も高い精度を誇っていたが、8個に差が見られない。そのため、すべてのログデータで適切に機能するログ解析はない。最初に、自分のログで様々なログ解析を試す必要がある。
データ量を増やすとどうなるか？
6つのログ解析はデータが増えるにつれて精度が低下しているのがわかった。特に、Androidのデータセットは解析がより複雑であるため、全てのログ解析の精度が落ちたことが観測された。
ログ解析の効率
効率を知るために、実行時間を計測する。
多数のイベントを含むデータセットは解析プロセスが遅くなる傾向がある。(Androidなど)
解析ルールは管理できなくなる。既存の解析ルールは解析ルールを一つずつ作成するのに時間がかかる。そのため、すべてのログのタイプをカバーできるわけではない。
結論として、平均的にうまくいくログ解析はDrainであるということが判明した。この研究では精度、堅牢性、実行速度総体的にみて良い結果であった。
最近の研究で開発中にロギングガイダンスまたは効果的なロギングメカニズムを提供することに焦点が当てられている。
現在の殆どのログ管理ツールは、ルールベースの解析をサポートしている。
