[SERVER-39851] Create traffic capture output in subdirectory of dbpath Created: 26/Feb/19  Updated: 06/Dec/22

Status: Open
Project: Core Server
Component/s: Networking, Shell
Affects Version/s: None
Fix Version/s: features we're not sure of

Type: Improvement Priority: Major - P3
Reporter: Benjamin Caimano (Inactive) Assignee: Backlog - Server Tooling and Methods (STM) (Inactive)
Resolution: Unresolved Votes: 0
Labels: move-stm
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-39854 Expand executor.archive granularity f... Backlog
Assigned Teams:
Server Tooling & Methods
Sprint: Service Arch 2019-03-11, Service Arch 2019-03-25
Participants:

 Description   

The TrafficRecorder attempts to use logpath by default. There are two unfortunate side effects of this:

  • The logpath must be set even for trivial experiments with traffic capture
  • Files are named by the startTrafficCapture command. It can be difficult to collect the set of files in certain situations.

I would like us to follow the ftdc pardigm wherein by default we make a subfolder in dbpath and put files there. This has the added advantage of automatically capturing traffic recordings via resmoke rules where applicable.



 Comments   
Comment by Mira Carey [ 01/Apr/19 ]
  • I'd believe then that if relative paths are given via startTrafficCapture, they're done relative to the run directory. Does it make sense to provide a trafficCaptureOutputPath startup parameter so that we could normalize that? It might make it easier to defend against weird situations with mixed mounts.

That's trafficRecordingDirectory. It's a mandatory startup param if you don't have always record traffic on

  • I don't think ShouldAlwaysRecordTraffic would be used by our devs in CI. So it would probably be good to provide some by default configured way to place files relative to a known archive location.

I'm pretty sure the sane thing to do here is to set trafficRecordingDirectory if we actually want to always record traffic. No need to have it piggy back on other file types.


I'm going to leave this as wont fix for now, until we hook this up with a wider use of the feature

Comment by Benjamin Caimano (Inactive) [ 04/Mar/19 ]

Ahhh, I hadn't internalized that we didn't have a true dbpath for mongos. (I walked over to Drew for more context. I miiiiiight file a ticket about formalizing server proc working directories.)

So two things that occur to me here:

  • I'd believe then that if relative paths are given via startTrafficCapture, they're done relative to the run directory. Does it make sense to provide a trafficCaptureOutputPath startup parameter so that we could normalize that? It might make it easier to defend against weird situations with mixed mounts.
  • I don't think ShouldAlwaysRecordTraffic would be used by our devs in CI. So it would probably be good to provide some by default configured way to place files relative to a known archive location.
Comment by Mira Carey [ 26/Feb/19 ]

That writing to logpath is only true if ShouldAlwaysRecordTraffic is on, which is a test only thing. I buy that we could do something smarter for that, but note that traffic recording also works in mongos, that doesn't have a dbpath.

I think it's also a little less risky to slam some random, start up param named file, in logpath than under dbpath (if we have to pick a directory based on existing args).

Generated at Thu Feb 08 04:53:18 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.