[Workers Logs] Observability docs for Workers Logs (#17028)

* [workers-observability] restructure integrations tab. remove baselime integration from docs

* [workers-observability] first pass on workers logs

* [workers-observability] update real-time logs and reduce redundancy

* [workers-observability] add sidebar ordering. many areas marked todo

* [workers-observability] copy corrections

* [workers-observability] add baselime integration back, mark it as under maintenance

* [workers-observability] add pricing partial, environment copy improvements

* [workers-observability] add execution log message summary, overview page, best practices

* [workers-observability] update cron events documentation

* [workers-observability] hyperlint updates

* [workers-observability] update references to old logging routes, update redirect path for logpush

* Update src/content/docs/workers/observability/logs/workers-logs.mdx

* Update src/content/docs/workers/observability/logs/workers-logs.mdx

* [workers-observability] update references to old logging routes

---------

Co-authored-by: Rohin Lohe <[email protected]>
Co-authored-by: dbenCF <[email protected]>

Author: 2 people

public/_redirects

@@ -1788,6 +1788,8 @@
 # Workers
 /workers/reference/apis/* /workers/runtime-apis/:splat 301
 /workers/templates/pages/* /workers/examples/:splat 301
+/workers/observability/sentry-integration /workers/observability/integrations/sentry 301
+/workers/observability/logging/* /workers/observability/logs/:splat 301
 
 # Others
 /ssl/custom-certificates/* /ssl/edge-certificates/custom-certificates/:splat 301

src/assets/images/workers-observability/preview.png

@@ -27,7 +27,7 @@ entries:
       - Workers with the [mTLS](/workers/runtime-apis/bindings/mtls/) binding now support [Gradual Deployments](/workers/configuration/versions-and-deployments/gradual-deployments/).
   - publish_date: "2024-07-18"
     description: |-
-      - Added a new `truncated` flag to [Tail Worker](/workers/observability/logging/tail-workers/) events to indicate when the event buffer is full and events are being dropped.
+      - Added a new `truncated` flag to [Tail Worker](/workers/observability/logs/tail-workers/) events to indicate when the event buffer is full and events are being dropped.
   - publish_date: "2024-07-17"
     description: |-
       - Updated v8 to version 12.7.
@@ -105,7 +105,7 @@ entries:
       - The new [`unwrap_custom_thenables` compatibility flag](/workers/configuration/compatibility-dates/#handling-custom-thenables) enables workers to accept custom thenables in internal APIs that expect a promise (for instance, the `ctx.waitUntil(...)` method).
       - TransformStreams created with the TransformStream constructor now have a cancel algorithm that is called when the stream is canceled or aborted. This change is part of the implementation of the WHATWG Streams standard.
       - The [`nodejs_compat` compatibility flag](/workers/runtime-apis/nodejs/) now includes an implementation of the [`MockTracker` API from `node:test`](https://nodejs.org/api/test.html#class-mocktracker). This is not an implementation of the full `node:test` module, and mock timers are currently not included.
-      - Exceptions reported to [Tail Workers](/workers/observability/logging/tail-workers/) now include a "stack" property containing the exception's stack trace, if available.
+      - Exceptions reported to [Tail Workers](/workers/observability/logs/tail-workers/) now include a "stack" property containing the exception's stack trace, if available.
   - publish_date: "2024-03-11"
     description: |-
       - Built-in APIs that return Promises will now produce stack traces when the Promise rejects. Previously, the rejection error lacked a stack trace.
@@ -225,7 +225,7 @@ entries:
       - No externally-visible changes.
   - publish_date: "2023-03-06"
     description: |-
-      - [Workers Logpush](/workers/observability/logging/logpush/#limits) now supports
+      - [Workers Logpush](/workers/observability/logs/logpush/#limits) now supports
       300 characters per log line. This is an increase from the previous limit of 150
       characters per line.
   - publish_date: "2023-02-06"

src/content/changelogs/workers.yaml

@@ -12,24 +12,24 @@ Learn how to access logs with Workers for Platforms.
 
 ### Workers Trace Events Logpush
 
-Workers Trace Events logpush is used to get raw Workers execution logs. Refer to [Logpush](/workers/observability/logging/logpush/) for more information.
+Workers Trace Events logpush is used to get raw Workers execution logs. Refer to [Logpush](/workers/observability/logs/logpush/) for more information.
 
 Logpush can be enabled for an entire dispatch namespace or a single user Worker. To capture logs for all of the user Workers in a dispatch namespace:
 
-1. Create a [Logpush job](/workers/observability/logging/logpush/#create-a-logpush-job).
-2. Enable [logging](/workers/observability/logging/logpush/#enable-logging-on-your-worker) on your dispatch Worker.
+1. Create a [Logpush job](/workers/observability/logs/logpush/#create-a-logpush-job).
+2. Enable [logging](/workers/observability/logs/logpush/#enable-logging-on-your-worker) on your dispatch Worker.
 
 Enabling logging on your dispatch Worker collects logs for both the dispatch Worker and for any user Workers in the dispatch namespace. Logs are automatically collected for all new Workers added to a dispatch namespace. To enable logging for an individual user Worker rather than an entire dispatch namespace, skip step 1 and complete step 2 on your user Worker.
 
 All logs are forwarded to the Logpush job that you have setup for your account. Logpush filters can be used on the `Outcome` or `Script Name` field to include or exclude specific values or send logs to different destinations.
 
 ### Tail Workers
 
-A [Tail Worker](/workers/observability/logging/tail-workers/) receives information about the execution of other Workers (known as producer Workers), such as HTTP statuses, data passed to `console.log()` or uncaught exceptions.
+A [Tail Worker](/workers/observability/logs/tail-workers/) receives information about the execution of other Workers (known as producer Workers), such as HTTP statuses, data passed to `console.log()` or uncaught exceptions.
 
-Use [Tail Workers](/workers/observability/logging/tail-workers/) instead of Logpush if you want granular control over formatting before logs are sent to their destination to receive [diagnostics channel events](/workers/runtime-apis/nodejs/diagnostics-channel), or if you want logs delivered in real-time.
+Use [Tail Workers](/workers/observability/logs/tail-workers/) instead of Logpush if you want granular control over formatting before logs are sent to their destination to receive [diagnostics channel events](/workers/runtime-apis/nodejs/diagnostics-channel), or if you want logs delivered in real-time.
 
-Adding a Tail Worker to  your dispatch Worker collects logs for both the dispatch Worker and for any user Workers in the dispatch namespace. Logs are automatically collected for all new Workers added to a dispatch namespace. To enable logging for an individual user Worker rather than an entire dispatch namespace, add the [Tail Worker configuration](/workers/observability/logging/tail-workers/#configure-tail-workers) directly to the user Worker.
+Adding a Tail Worker to  your dispatch Worker collects logs for both the dispatch Worker and for any user Workers in the dispatch namespace. Logs are automatically collected for all new Workers added to a dispatch namespace. To enable logging for an individual user Worker rather than an entire dispatch namespace, add the [Tail Worker configuration](/workers/observability/logs/tail-workers/#configure-tail-workers) directly to the user Worker.
 
 ## Analytics
 

src/content/docs/cloudflare-for-platforms/workers-for-platforms/configuration/observability.mdx

@@ -211,4 +211,4 @@ Review the [`unstable_dev()`](/workers/wrangler/api/#usage) documentation for mo
 
 - Use [`wrangler dev`](/workers/wrangler/commands/#dev) to run your Worker and D1 locally and debug issues before deploying.
 - Learn [how to debug D1](/d1/observability/debug-d1/).
-- Understand how to [access logs](/workers/observability/logging/) generated from your Worker and D1.
+- Understand how to [access logs](/workers/observability/logs/) generated from your Worker and D1.

src/content/docs/d1/build-with-d1/local-development.mdx

@@ -48,4 +48,4 @@ export default {
 ## Related resources
 
 * Learn [how to debug D1](/d1/observability/debug-d1/).
-* Understand how to [access logs](/workers/observability/logging/) generated from your Worker and D1.
+* Understand how to [access logs](/workers/observability/logs/) generated from your Worker and D1.

src/content/docs/d1/build-with-d1/remote-development.mdx

@@ -31,7 +31,7 @@ try {
 
 ## View logs
 
-View a stream of live logs from your Worker by using [`wrangler tail`](/workers/observability/logging/real-time-logs#view-logs-using-wrangler-tail) or via the [Cloudflare dashboard](/workers/observability/logging/real-time-logs#view-logs-from-the-dashboard).
+View a stream of live logs from your Worker by using [`wrangler tail`](/workers/observability/logs/real-time-logs#view-logs-using-wrangler-tail) or via the [Cloudflare dashboard](/workers/observability/logs/real-time-logs#view-logs-from-the-dashboard).
 
 ## Report issues
 
@@ -49,5 +49,5 @@ You should include as much of the following in any bug report:
 ## Related resources
 
 * Learn [how to debug Workers](/workers/observability/).
-* Understand how to [access logs](/workers/observability/logging/) generated from your Worker and D1.
+* Understand how to [access logs](/workers/observability/logs/) generated from your Worker and D1.
 * Use [`wrangler dev`](/workers/wrangler/commands/#dev) to run your Worker and D1 locally and [debug issues before deploying](/workers/testing/local-development/).

src/content/docs/d1/observability/debug-d1.mdx

@@ -12,7 +12,7 @@ import { Render } from "~/components"
 
 When you process emails with Email Workers and you are on [Workers’ free pricing tier](/workers/platform/pricing/) you might encounter an allocation error. This may happen due to the size of the emails you are processing and/or the complexity of your Email Worker. Refer to [Worker limits](/workers/platform/limits/#worker-limits) for more information.
 
-You can use the [log functionality for Workers](/workers/observability/logging/) to look for messages related to CPU limits (such as `EXCEEDED_CPU`) and troubleshoot any issues regarding allocation errors.
+You can use the [log functionality for Workers](/workers/observability/logs/) to look for messages related to CPU limits (such as `EXCEEDED_CPU`) and troubleshoot any issues regarding allocation errors.
 
 If you encounter these error messages frequently, consider upgrading to the [Workers Paid plan](/workers/platform/pricing/) for higher usage limits.
 

src/content/docs/email-routing/limits.mdx

@@ -19,7 +19,7 @@ Logpush does not offer storage or search functionality for logs; its primary aim
 :::note
 
 
-Users without an Enterprise plan can still access [Workers Trace Events Logpush](/workers/observability/logging/logpush/) by subscribing to the [Workers Paid](/workers/platform/pricing/) plan.
+Users without an Enterprise plan can still access [Workers Trace Events Logpush](/workers/observability/logs/logpush/) by subscribing to the [Workers Paid](/workers/platform/pricing/) plan.
 
 
 :::

src/content/docs/logs/about.mdx

@@ -156,4 +156,4 @@ This will issue a HTTP POST request, and if successful, return a HTTP 200 with a
 - If you receive a HTTP 403, this is because the `Authorization` header is invalid, or you did not configure a secret.
 - If you receive a HTTP 500, this is either because you did not correctly create a shared secret to your Worker, or you attempted to send an invalid message to your queue.
 
-You can use [`wrangler tail`](/workers/observability/logging/real-time-logs/) to debug the output of `console.log`.
+You can use [`wrangler tail`](/workers/observability/logs/real-time-logs/) to debug the output of `console.log`.