ref(profiling) fix method name (#12078)

Author: JonasBa

docs/product/explore/profiling/transaction-vs-continuous-profiling.mdx

@@ -28,9 +28,9 @@ Continuous profiling mode is capable of profiling long-running workflows or proc
 
 ## SDK Differences
 
-Transaction-based profiling was opaque from the SDK side, with the SDK being in full control of when the profiler would start and stop based on the transactions it generated. In continuous profiling mode, this is no longer true. Developers can now control when the profiler is started or stopped via new top-level SDK methods. The exact method-naming varies, but most SDKs that support continuous profiling now expose a top level `Sentry.profiler` that exposes a `startProfiling` and `stopProfiling` method. (Please see the SDK docs for exact definitions.)
+Transaction-based profiling was opaque from the SDK side, with the SDK being in full control of when the profiler would start and stop based on the transactions it generated. In continuous profiling mode, this is no longer true. Developers can now control when the profiler is started or stopped via new top-level SDK methods. The exact method-naming varies, but most SDKs that support continuous profiling now expose a top level `Sentry.profiler` that exposes a `startProfiler` and `stopProfiler` method. (Please see the SDK docs for exact definitions.)
 
-We recommend that you call the `startProfiling` method right after the Sentry SDK is initialized so that you gain visibility at the earliest point in your application lifecycle. From then on, the profiler will keep collecting profiles and sending chunks to Sentry until `stopProfiling` is called.
+We recommend that you call the `startProfiler` method right after the Sentry SDK is initialized so that you gain visibility at the earliest point in your application lifecycle. From then on, the profiler will keep collecting profiles and sending chunks to Sentry until `stopProfiler` is called.
 
 ## Choosing Between Transaction and Continuous Profiling Mode
 
@@ -46,12 +46,12 @@ Sentry.Init({
   integrations: [nodeProfilingIntegration()],
 });
 
-Sentry.profiler.startProfiling();
-// Code executed after the first call to startProfiling will now be profiled
+Sentry.profiler.startProfiler();
+// Code executed after the first call to startProfiler will now be profiled
 
 // You can stop profiling at any time by calling stopProfiling.
 // This can help you isolate the code you wish to profile.
-Sentry.profiler.stopProfiling();
+Sentry.profiler.stopProfiler();
 ```
 
 If you want to keep using transaction-based profiling, then the options are the same. You can set either the `profilesSampleRate` or the `profilesSampler` option on the SDK.

includes/profiling-node-runtime-flags.mdx

@@ -1,5 +1,5 @@
-
 ## Runtime Flags
+
 There are three runtime flags you can set that control the behavior of the profiler. Two of the flags relate to how the SDK resolves the profiler binaries. The third alters how the underlying profiler is initialized by [v8](https://v8docs.nodesource.com/).
 
 <Note>
@@ -16,10 +16,11 @@ Acts similarly to the flag above, however, this flag only specifies the director
 
 - SENTRY_PROFILER_LOGGING_MODE
 
-The default mode of the v8 CpuProfiler is [kEagerLogging](https://v8docs.nodesource.com/node-18.2/d2/dc3/namespacev8.html#a874b4921ddee43bef58d8538e3149374), which enables the profiler even when no profiles are active—this is good because it makes calls to `startProfiling` fast with the tradeoff of constant CPU overhead. This behavior can be controlled via the `SENTRY_PROFILER_LOGGING_MODE` environment variable with values of `eager|lazy`. If you opt to use the lazy-logging mode, calls to `startProfiling` may be slow. (Depending on environment and node version, it can be in the order of a few hundred ms.)
+The default mode of the v8 CpuProfiler is [kEagerLogging](https://v8docs.nodesource.com/node-18.2/d2/dc3/namespacev8.html#a874b4921ddee43bef58d8538e3149374), which enables the profiler even when no profiles are active—this is good because it makes calls to startProfgiler faster with the tradeoff of constant CPU overhead. This behavior can be controlled via the `SENTRY_PROFILER_LOGGING_MODE` environment variable with values of `eager|lazy`. If you opt to use the lazy-logging mode, calls to `startProfiler` may be slow. (Depending on environment and node version, it can be in the order of a few hundred ms.)
 
 Here's an example of starting a server with lazy-logging mode:
 
-  ```bash
-  # Run profiler in lazy mode
-  SENTRY_PROFILER_LOGGING_MODE=lazy node server.js
+```bash
+# Run profiler in lazy mode
+SENTRY_PROFILER_LOGGING_MODE=lazy node server.js
+```