docs(sdks): Group develop docs about collecting telemetry data with o…

…ur SDKs

develop-docs/sdk/signal-handlers.mdx

@@ -9,7 +9,7 @@ This applies to mobile SDKs as well as the native SDK.  As signal handlers
 are notoriously difficult to work with and the restrictions placed on us are
 quite limiting we have to partially bend the rules of what is acceptable.
 
-# General Risks
+## General Risks
 
 The general risks with signal handlers stem from the interruptive nature:
 
@@ -25,7 +25,7 @@ theory you can only call [async safe functions](https://man7.org/linux/man-pages
 which unfortunately put a lot of limitations in place.  In particular not even
 allocations are possible, let alone most threading functions.
 
-# Basic Recommendations
+## Basic Recommendations
 
 We want to optimize our outcomes for getting good crash reports and getting
 crash reports altogether.  We do not necessarily optimize for not crashing if
@@ -49,15 +49,15 @@ disk in reducing priority.  If for instance we can only collect auxiliary
 information with the risk of crashing in the crash handler, that one should be
 extracted and dumped after the stack trace has been created.
 
-# Memory Allocation
+## Memory Allocation
 
 The recommendation is for libraries to use custom allocation functions which
 under normal circumstances use `malloc` but after once have entered a crashing
 situation in the signal handler switch over to a bump allocator.  This is
 necessary as malloc can (and will!) hold a lock when entering into a signal
 handler which can cause us to either dead lock or crash.
 
-# Locks and Signal Handler Marking
+## Locks and Signal Handler Marking
 
 Another issues is that we cannot generally use locks properly once in signal
 handlers.  The way the native SDK is dealing with this situation is to
@@ -66,7 +66,7 @@ generic code that might be wanting to wait for a real lock can either
 additionally block on the spinlock or silently pass if it's in the same
 thread as the signal handler.
 
-# Writing Files
+## Writing Files
 
 For writing files the `fwrite` family of functions must not be used as they
 are not async safe.  Instead, the underlying `write` and `open` functions

develop-docs/sdk/check-ins.mdx → develop-docs/sdk/telemetry/check-ins/index.mdx

@@ -1,6 +1,6 @@
 ---
 title: Check-Ins
-sidebar_order: 20
+sidebar_order: 50
 ---
 
 ## Cron Monitor Check-In Payload

develop-docs/sdk/telemetry/index.mdx

@@ -0,0 +1,6 @@
+---
+title: Telemetry
+description: Learn about the different telemetry data, that our SDKs can collect.
+---
+
+<PageGrid />

develop-docs/sdk/metrics.mdx → develop-docs/sdk/telemetry/metrics/index.mdx

@@ -1,6 +1,6 @@
 ---
 title: Metrics
-sidebar_order: 13
+sidebar_order: 90
 ---
 
 Sentry supports the emission of pre-aggregated metrics information via the `statsd`

develop-docs/sdk/profiles.mdx → develop-docs/sdk/telemetry/profiles/index.mdx

@@ -1,6 +1,6 @@
 ---
 title: Profiles
-sidebar_order: 20
+sidebar_order: 40
 ---
 
 This document defines the Sample format used by Sentry to ingest profiles. This
@@ -353,7 +353,7 @@ required in order to be able to symbolicate and get more info about the frame.
 For the rest of the platforms, whatever is passed here will travel to the
 frontend and whatever is available can be used to show more or less information.
 
-We will use `module` or `package` (in that order) to group frames when needed. 
+We will use `module` or `package` (in that order) to group frames when needed.
 
 Some attributes are not used at the moment:
 - `raw_function`

develop-docs/sdk/performance/index.mdx → develop-docs/sdk/telemetry/traces/index.mdx

@@ -1,5 +1,6 @@
 ---
-title: Performance Monitoring
+title: Traces
+sidebar_order: 20
 ---
 
 This document covers how SDKs should add support for Performance Monitoring with [Distributed

redirects.js

@@ -22,6 +22,10 @@ const developerDocsRedirects = [
     source: '/api/:path*',
     destination: '/application/api/:path*',
   },
+  {
+    source: '/sdk/performance/:path*',
+    destination: '/sdk/telemetry/traces/:path*',
+  },
 ];
 
 /** @type {import('next/dist/lib/load-custom-routes').Redirect[]} */
@@ -592,6 +596,7 @@ const userDocsRedirects = [
  *
  * loads the redirects based on the environment variable `NEXT_PUBLIC_DEVELOPER_DOCS`
  */
+// eslint-disable-next-line require-await
 const redirects = async () => {
   console.log(
     '🔄 using',

src/middleware.ts

@@ -3436,6 +3436,22 @@ const DEVELOPER_DOCS_REDIRECTS: Redirect[] = [
     from: '/sdk/craft-quick-start/',
     to: '/sdk/processes/releases/',
   },
+  {
+    from: '/sdk/metrics/',
+    to: '/sdk/telemetry/metrics/',
+  },
+  {
+    from: '/sdk/check-ins/',
+    to: '/sdk/telemetry/check-ins/',
+  },
+  {
+    from: '/sdk/profiles/',
+    to: '/sdk/telemetry/profiles/',
+  },
+  {
+    from: '/sdk/distributed-tracing/',
+    to: '/sdk/telemetry/traces/distributed-tracing/',
+  },
 ];
 
 const redirectMap = new Map(