Merge branch 'develop' into NR-488604-Data-Ingest-Budgets

Author: adutta-newrelic

scripts/listMdxFreshness.mjs

@@ -62,63 +62,48 @@ function main() {
   rows.sort((a,b) => b.ageDays - a.ageDays);
   console.log('Sorted files by age (descending)');
 
-  // Grouping buckets
-  const buckets = [
-    { label: '24+ months', filter: r => r.ageMonths >= 24 },
-    { label: '18-24 months', filter: r => r.ageMonths >= 18 && r.ageMonths < 24 },
-    { label: '12-18 months', filter: r => r.ageMonths >= 12 && r.ageMonths < 18 },
-    { label: '6-12 months', filter: r => r.ageMonths >= 6 && r.ageMonths < 12 },
-    { label: '0-6 months', filter: r => r.ageMonths < 6 },
-  ];
-
-  function renderTable(sectionRows) {
-    if (sectionRows.length === 0) return '_No files_';
-    const header = ['Path','Last Commit','Age (months)','Age (days)'];
-    const lines = [
-      `| ${header.join(' | ')} |`,
-      `| ${header.map(()=> '---').join(' | ')} |`
-    ];
-    for (const r of sectionRows) {
-      lines.push(`| ${r.path} | ${r.lastCommit} | ${r.ageMonths.toFixed(1)} | ${r.ageDays.toFixed(0)} |`);
-    }
-    return lines.join('\n');
+  // Determine age bucket for each row
+  function getAgeBucket(ageMonths) {
+    if (ageMonths >= 24) return '24+ months';
+    if (ageMonths >= 18) return '18-24 months';
+    if (ageMonths >= 12) return '12-18 months';
+    if (ageMonths >= 6) return '6-12 months';
+    return '0-6 months';
   }
 
-  const summaryCounts = buckets.map(b => ({ label: b.label, count: rows.filter(b.filter).length }));
-
-  const out = [];
-  out.push('# MDX Report');
-  out.push('');
-
-  out.push(`Generated: ${new Date().toISOString()}`);
-  out.push('');
-
-  out.push('## Summary by Age Bucket');
-  out.push('');
-
-  out.push('| Age Bucket | File Count |');
-  out.push('| --- | ---: |');
-  for (const sc of summaryCounts) {
-    out.push(`| ${sc.label} | ${sc.count} |`);
+  // Escape CSV field if needed (contains comma, quote, or newline)
+  function escapeCSV(field) {
+    if (field.includes(',') || field.includes('"') || field.includes('\n')) {
+      return `"${field.replace(/"/g, '""')}"`;
+    }
+    return field;
   }
-  out.push('');
-
-  for (const b of buckets) {
-    const sectionRows = rows.filter(b.filter);
-    out.push(`## ${b.label}`);
-    out.push('');
-    out.push(renderTable(sectionRows));
-    out.push('');
+
+  // Generate CSV output
+  const csvLines = [];
+  csvLines.push('Path,Last Commit,Age (months),Age (days),Age Bucket');
+
+  for (const r of rows) {
+    const bucket = getAgeBucket(r.ageMonths);
+    const line = [
+      escapeCSV(r.path),
+      r.lastCommit,
+      r.ageMonths.toFixed(1),
+      r.ageDays.toFixed(0),
+      bucket
+    ].join(',');
+    csvLines.push(line);
   }
-  const outputTxt = out.join('\n');
+
+  const outputCSV = csvLines.join('\n');
   const outArg = process.argv.find(a => a.startsWith('--out='));
-  const outPath = outArg ? outArg.split('=')[1] : 'mdx-freshness.txt';
+  const outPath = outArg ? outArg.split('=')[1] : 'mdx-freshness.csv';
   try {
-    writeFileSync(outPath, outputTxt, 'utf8');
+    writeFileSync(outPath, outputCSV, 'utf8');
     console.log(`Wrote report to ${outPath}`);
   } catch (e) {
     console.log('Failed writing file, falling back to stdout');
-    console.log(outputTxt);
+    console.log(outputCSV);
   }
   console.log('Done');
 }

src/content/docs/accounts/accounts-billing/new-relic-one-user-management/user-management-concepts.mdx

@@ -131,18 +131,15 @@ You can create roles at three different scopes, each serving different purposes:
 
 * **Organization-scoped roles**: You apply these roles for organization-wide functions like managing authentication domains, creating accounts, configuring organization settings, or managing scorecards and teams. Standard roles include:
   * <DNT>**Organization manager**</DNT>: Permissions related to organization settings, including adding accounts, and changing the name of the organization and accounts. This also includes sensitive observability tasks, such as deleting certain entities.
-  * <DNT>**Authentication domain manager**</DNT>: Permissions related to adding and managing users, including configuring authentication domains and customizing groups and roles. Options within this include:
-    * <DNT>**Manage**</DNT>: Can manage all aspects of authentication domains, including configuring domains and adding users.
-    * <DNT>**Read only**</DNT>: Can view authentication domain and user information.
-    * <DNT>**Add users**</DNT>: Can view user information, and add users to the organization, but lacks other auth domain configuration and management abilities.
-    * <DNT>**Read users**</DNT>: Can only view user information.
+  * <DNT>**Authentication domain manager**</DNT>: Permissions related to adding and managing users, including configuring authentication domains and customizing groups and roles.
   * <DNT>**Billing**</DNT>: Lets a user view and manage billing and usage, and data retention. For organizations with multiple accounts, billing is aggregated in the <DNT>**reporting account**</DNT> (usually the first account created in an organization).
-  * <DNT>**Organization product admin**</DNT>: Permissions related to organization-scoped observability features like scorecard and team management. This is the organization-scoped equivalent to <strong>All product admin</strong>.
+  * <DNT>**Organization product admin**</DNT>: Permissions related to organization-scoped observability features like scorecard and team management. This is the organization-scoped equivalent to <strong>All product admin</strong>
+* <DNT>**Organization read only**</DNT>: Provides read-only access to the New Relic platform organization-scoped features.
 
 * **Account-scoped roles**: You apply these roles for access to platform features within specific accounts, such as configuring APM settings, managing alerts, or running queries. These are the traditional roles most users work with. Standard roles include:
   * <DNT>**All product admin**</DNT>: Includes all New Relic platform permissions except the ability to manage organization-level settings, users, and billing.
   * <DNT>**Standard user**</DNT>: Provides access to our platform features but lacks permissions to configure those features and lacks organization-level and user management permissions.
-  * <DNT>**Read only**</DNT>: Provides read-only access to the New Relic platform.
+  * <DNT>**Read only**</DNT>: Provides read-only access to the New Relic platform account-scoped features.
 
 * **Entity-scoped roles**: You apply these roles for fine-grained access to specific resources like individual dashboards, fleets, or alert policies. This enables precise permission control at the individual resource level. You can create custom entity-scoped roles based on your needs.
 

src/content/docs/alerts/organize-alerts/change-applied-intelligence-correlation-logic-decisions.mdx

@@ -412,7 +412,7 @@ The time range is set to 20 minutes by default. You can adjust it between 1-120
 
 #### Step 5: Testing your decision using a simulation [#basic-test-with-simulation]
 
-After adding a filter logic, the system automatically runs a [simulation](#simulations) using the past 7 days of incident data.
+After adding filter logic, the system automatically runs a [simulation](#simulations) using the past 7 days of incident data to help you validate the decision before applying it.
 
 You can also manually trigger the simulation by clicking <DNT>**Simulate**</DNT>, which you may want to do if something is changed in the decision.
 
@@ -1295,9 +1295,17 @@ You can use the correlation assistant to more quickly analyze [incidents](/docs/
   </Collapser>
 </CollapserGroup>
 
+### Simulation vs real-time correlation [#simulation-vs-decisions]
+
+It's important to understand the difference between simulation and real-time correlation in decisions:
+
+* <DNT>**Simulation**</DNT>: Simulation correlation involves analyzing two separate incidents to understand their relationship under simulated conditions. These incidents can originate from either the same underlying issue or from different issues. The focus is on determining potential causative factors or shared characteristics between individual incidents. Simulation helps you test and validate your correlation logic against historical data before applying it in real-time.
+
+* <DNT>**Real-time correlation (decisions)**</DNT>: In contrast, real-time correlation targets distinct issues, with each issue potentially encompassing multiple incidents. The aim is to detect and connect patterns across these multiple incidents to identify underlying issues for more efficient correlation. Real-time correlation leverages live data streams, allowing for prompt identification and response to emerging problems.
+
 ### Using simulation [#simulations]
 
-Simulation will test the logic against the last week of your data and show you how many correlations would have happened. Here's a breakdown of the decision preview information displayed when you simulate:
+Simulation tests your correlation logic by analyzing two separate incidents from the last week of your data, showing you how many correlations would have happened. This allows you to validate your decision logic before it's applied to real-time correlation of issues. Here's a breakdown of the decision preview information displayed when you simulate:
 
 * <DNT>**Potential correlation rate:**</DNT> The percentage of tested incidents this decision would have affected.
 * <DNT>**Total created incidents:**</DNT> The number of incidents tested by this decision.

src/content/docs/apm/agents/nodejs-agent/getting-started/compatibility-requirements-nodejs-agent.mdx

@@ -302,10 +302,10 @@ supported by the agent.
 | `@hapi/hapi` | 20.1.2 | 21.4.4 | 9.0.0 |
 | `@koa/router` | 12.0.1 | 15.0.0 | 3.2.0 |
 | `@langchain/core` | 0.1.17 | 1.1.1 | 11.13.0 |
-| `@modelcontextprotocol/sdk` | 1.13.0 | 1.24.1 | 13.2.0 |
+| `@modelcontextprotocol/sdk` | 1.13.0 | 1.24.2 | 13.2.0 |
 | `@nestjs/cli` | 9.0.0 | 11.0.14 | 10.1.0 |
 | `@opensearch-project/opensearch` | 2.1.0 | 3.5.1 | 12.10.0 |
-| `@prisma/client` | 5.0.0 | 7.0.1 | 11.0.0 |
+| `@prisma/client` | 5.0.0 | 7.1.0 | 11.0.0 |
 | `@smithy/smithy-client` | 2.0.0 | 4.9.9 | 11.0.0 |
 | `amqplib` | 0.5.0 | 0.10.9 | 2.0.0 |
 | `aws-sdk` | 2.2.48 | 2.1692.0 | 6.2.0 |

src/content/docs/data-apis/manage-data/manage-data-retention.mdx

@@ -145,6 +145,23 @@ This table shows the default [namespace](/docs/glossary/glossary) retention sett
         8
       </td>
     </tr>
+    <tr>
+      <td>
+        APM
+      </td>
+
+      <td>
+        AI Monitoring
+      </td>
+
+      <td>
+        30
+      </td>
+
+      <td>
+        120
+      </td>
+    </tr>
 
     <tr>
       <td>

src/content/docs/data-apis/understand-data/event-data/events-reported-browser-monitoring.mdx

@@ -114,6 +114,15 @@ Select an event name in the following table to see its attributes.
         `Span` data is reported for [distributed tracing](/docs/browser/new-relic-browser/browser-pro-features/browser-data-distributed-tracing).
       </td>
     </tr>
+    <tr>
+      <td>
+        [`UserAction`](/attribute-dictionary/?event=UserAction)
+      </td>
+
+      <td>
+        `UserAction` event is captured as the result of a user interaction with the web application. This event includes action information and DOM target identifiers along with several default attributes, such as application and geographic data.
+      </td>
+    </tr>
   </tbody>
 </table>
 

src/content/docs/distributed-tracing/infinite-tracing-on-premise/bring-your-own-cache.mdx

@@ -19,21 +19,21 @@ The processor supports any Redis-compatible cache implementation. It has been te
 For production deployments, we recommend using cluster mode (sharded) to ensure high availability and scalability. To enable distributed caching, add the `distributed_cache` configuration to your `tail_sampling` processor section:
 
   ```yaml
-    tail_sampling:
-      distributed_cache:
-        connection:
-          address: redis://localhost:6379/0
-          password: 'local'
-        trace_window_expiration: 30s      # Default: how long to wait after last span before evaluating
-        in_flight_timeout: 120s           # Optional: defaults to trace_window_expiration if not set
-        traces_ttl: 3600s                 # Optional: default 1 hour
-        cache_ttl: 7200s                  # Optional: default 2 hours
-        suffix: "itc"                     # Redis key prefix
-        max_traces_per_batch: 500         # Default: traces processed per evaluation cycle
-        evaluation_interval: 1s           # Default: evaluation frequency
-        evaluation_workers: 4             # Default: number of parallel workers (defaults to CPU count)
-        data_compression:
-          format: lz4                     # Optional: compression format (none, snappy, zstd, lz4); lz4 recommended
+  tail_sampling:
+    distributed_cache:
+      connection:
+        address: redis://localhost:6379/0
+        password: 'local'
+      trace_window_expiration: 30s      # Default: how long to wait after last span before evaluating
+      in_flight_timeout: 120s           # Optional: defaults to trace_window_expiration if not set
+      traces_ttl: 3600s                 # Optional: default 1 hour
+      cache_ttl: 7200s                  # Optional: default 2 hours
+      suffix: "itc"                     # Redis key prefix
+      max_traces_per_batch: 500         # Default: traces processed per evaluation cycle
+      evaluation_interval: 1s           # Default: evaluation frequency
+      evaluation_workers: 4             # Default: number of parallel workers (defaults to CPU count)
+      data_compression:
+        format: lz4                     # Optional: compression format (none, snappy, zstd, lz4); lz4 recommended
   ```
 
   <Callout variant="important">
@@ -43,16 +43,16 @@ For production deployments, we recommend using cluster mode (sharded) to ensure
 The `address` parameter must specify a valid Redis-compatible server address using the standard format:
 
   ```shell
-  redis[s]://[[username][:password]@][host][:port][/db-number]
+  [output] redis[s]://[[username][:password]@][host][:port][/db-number]
   ```
 
 Alternatively, you can embed credentials directly in the `address` parameter:
 
   ```yaml
-    tail_sampling:
-      distributed_cache:
-        connection:
-          address: redis://:yourpassword@localhost:6379/0
+  tail_sampling:
+    distributed_cache:
+      connection:
+        address: redis://:yourpassword@localhost:6379/0
   ```
 
 The processor is implemented in Go and uses the [go-redis](https://github.com/redis/go-redis/tree/v9) client library.
@@ -114,8 +114,8 @@ Proper Redis instance sizing is critical for optimal performance. Use the config
 
 ### Memory estimation formula
 
-  ```shell
-    Total Memory = (Trace Data) + (Decision Caches) + (Overhead)
+  ```
+  Total Memory = (Trace Data) + (Decision Caches) + (Overhead)
   ```
 
 #### 1. Trace data storage
@@ -133,13 +133,13 @@ Trace data is stored in Redis for the full `traces_ttl` period to support late-a
 
 **Example calculation**: At 10,000 spans/second with 1-hour `traces_ttl`:
 
-  ```shell
+  ```
   10,000 spans/sec × 3600 sec × 900 bytes = 32.4 GB
   ```
 
 **With lz4 compression** (we have observed 25% reduction):
 
-  ```shell
+  ```
   32.4 GB × 0.75 = 24.3 GB
   ```
 
@@ -164,7 +164,7 @@ When using `distributed_cache`, the decision caches are stored in Redis without
 
 **Example calculation**: 500 traces per batch (default) with 20 spans per trace on average:
 
-  ```shell
+  ```
   500 × 20 × 900 bytes = 9 MB per batch
   ```
 
@@ -247,4 +247,4 @@ The processor uses a cascading TTL structure, with each level providing protecti
 4. **`cache_ttl`** (default: 2 hours)
    - Redis key expiration for decision cache entries (sampled/non-sampled)
    - Prevents duplicate evaluation for late-arriving spans
-   - Defined via `distributed_cache.cache_ttl`
+   - Defined via `distributed_cache.cache_ttl`