web-dev-qa-db-ja.com

mongodbは、冗長性が最も低くても、ドキュメント全体をログに記録することがあります

LinuxAMIを使用するAWS環境でmongodbバージョン3を使用しています。

当初、mongoはドキュメント全体をログに記録していました。次に、yamlの冗長性を下げました。これにより、ほとんど（99％）のドキュメントがログに記録されないようになりました。ただし、それでも時々レコードがログに記録されることがあります。 WRITEを実行してからCOMMANDを実行するようで、両方にレコード全体が含まれています。

有用なログを保持しながら、ドキュメントがログに書き込まれないようにする方法はありますか？

ありがとう

systemLog:
  quiet: true
  destination: file
  path: /var/log/mongodb.log
  logAppend: true
  logRotate: rename
  traceAllExceptions: false
  timeStampFormat: iso8601-utc
  verbosity: 1 # This will be inherited by any component with verbosity -1
  component:
    accessControl:
      verbosity: -1 # NOTE: Negative one (-1) means "inherit"
    command:
      verbosity: 0 # MUST BE ZERO!!! Otherwise, inserted/updated records (all the data) will get logged.
    control:
      verbosity: -1
    geo:
      verbosity: 0
    index:
      verbosity: -1
    network:
      verbosity: -1
    query:
      verbosity: -1
    replication:
      verbosity: -1
    sharding:
      verbosity: 0
    storage:
      verbosity: -1
    write:
      verbosity: 0 # MUST BE ZERO!!! Otherwise, inserted/updated records (all the data) will get logged.

バージョンとログは次のようになります。データを入力したので、無効なjsonまたはタイプミスはmongoではなく私が原因であることに注意してください。

バージョン3.0.6

TIMESTAMP I WRITE [conn0001] insert project.collection query {<insert our json document here>}
ninserted:1 
keyUpdates:0
writeConflicts:0
numYields:0
locks:{Global: {acquireCount: {r: 2, w: 2}}, MMAPV1Journal: {acquireCount: {w:2},aquireWaitCount: {w:2}, 
timeAquiringMicros: {w: 119326}}, Database: {acquireCount:w: 2}}, Collection" {acquireCount: {W:1}}, oplog: {acquireCount: {w: 1}}} 119ms



TIMESTAMP I COMMAND [conn0001] insert project.$cmd command:  insert {<insert our json document here>}
ninserted:1 
keyUpdates:0
writeConflicts:0
numYields:0
reslen: 80
locks:{Global: {acquireCount: {r: 2, w: 2}}, MMAPV1Journal: {acquireCount: {w:2},aquireWaitCount: {w:2}, 
timeAquiringMicros: {w: 119326}
timeAquiringMicros: {w: 119326}}, Database: {acquireCount:w: 2}}, Collection" {acquireCount: {W:1}}, oplog: {acquireCount: {w: 1}}} 119ms
loggingmongodbloglevel
1
user5524xx

挿入クエリは遅いクエリと見なされるため、ログに記録されています—デフォルトよりも時間がかかります operationProfiling.slowOpThresholdMs 100msの値。 MongoDB 3.2と同様に、このコンテキストはクエリが遅い理由を理解するのに役立つため、遅いクエリでどの詳細をログに記録するかについての構成はありません。

slowOpThresholdMs構成ファイルのmongodを増やすことで、遅い挿入/コマンドのログを回避できます。たとえば、250ミリ秒の高いslowOpThresholdMsを設定することで、ほとんどの挿入がログに記録されないようにするのに十分な場合があります（ただし、本当に遅い挿入はログに記録される場合があります）。

operationProfiling:
    slowOpThresholdMs: 250

遅い操作がログに記録されないようにしたい場合は、はるかに高い値を設定できますが、これにより、デプロイメントのパフォーマンスに関連する詳細が抑制される可能性があります。

有用なログを保持しながら、ドキュメントがログに書き込まれないようにする方法はありますか？

一般に、トラブルシューティングに役立つログには、低速クエリの詳細と、接続/レプリケーション/認証情報（ quiet:true ）。

これらの詳細をログに記録しないと、実稼働環境の調整とサポートが困難になる可能性があります。

mongodログファイル内の個人情報へのアクセスについて懸念がある場合は、O/Sおよびファイルシステムのアクセス許可を介してログファイルへのアクセスを適切に制限し、バックアップを暗号化するか、機密性の高いログファイルを除外します。 mongodサーバーログを表示するためのアクセスには、mongoシェルを介してログインするだけでなく、より多くのアクセス許可が必要です。サーバーログを表示するアクセス許可を持っている人は、おそらくデータファイルをコピーするためのアクセス権も持っている可能性があります。

デプロイはAWSで行われるため、 Amazon EBS Encryption を検討できます。これにより、ボリューム内で保存されているデータ、ボリュームとインスタンス間を移動するデータ、およびボリュームから作成されたすべてのスナップショットが暗号化されます。

考慮すべきもう1つのオプションは、アプリケーションの機密フィールドを暗号化して、送信、ログ記録、またはクリアテキストで保存されないようにすることです。

デプロイメントのセキュリティ保護の詳細については、 MongoDBセキュリティチェックリスト を参照してください。

0
Stennie