Skip to content
This repository was archived by the owner on Sep 2, 2025. It is now read-only.

Commit 733e7b0

Browse files
Merge pull request #1720 from splunk/repo-sync
Pulling refs/heads/main into main
2 parents 97acccd + 000e735 commit 733e7b0

File tree

7 files changed

+56
-28
lines changed

7 files changed

+56
-28
lines changed

apm/db-query-perf/turn-on-db-perf.rst

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -32,6 +32,12 @@ Follow these steps to turn on Database Query Performance and begin indexing data
3232
:width: 25%
3333
:alt: Screenshot of the APM Configuration menu on the APM landing page.
3434

35+
.. note:: Before proceeding, ensure that you have configured the instrumentation for your specific programming language:
36+
* Java, see :ref:`instrument-java-applications`.
37+
* .NET, see :ref:`configure-otel-dotnet`.
38+
* Python, see :ref:`instrument-python-applications`.
39+
* Node.js, see :ref:`instrument-nodejs-applications-3x`.
40+
3541
2. In the Database Query Performance section, check that the :guilabel:`Status` is Active. If it is, skip to the next step. If it's not, select :guilabel:`Resume Indexing` to initiate cardinality analysis, and then wait for the cardinality analysis to run in the Pending MetricSet section at the top of the table.
3642

3743
.. image:: /_images/apm/db-query-perf/db-cardinality-success.png

gdi/get-data-in/application/otel-dotnet/instrumentation/instrument-dotnet-application.rst

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -359,6 +359,8 @@ SQL statements might contain sensitive information. To configure this behavior,
359359
* ``OTEL_DOTNET_AUTO_ENTITYFRAMEWORKCORE_SET_DBSTATEMENT_FOR_TEXT``
360360
* ``OTEL_DOTNET_AUTO_ORACLEMDA_SET_DBSTATEMENT_FOR_TEXT``
361361

362+
For more details on enabling Database Query Performance, visit :ref:`turn-on-db-perf`.
363+
362364
.. _docker-install-otel-dotnet:
363365

364366
Instrument an application running within a Docker container

gdi/get-data-in/connect/aws/get-awstoc.rst

Lines changed: 2 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -111,8 +111,7 @@ You can deactivate this check by setting the ``enableCheckLargeVolume`` field in
111111
<h4>Tag filtering<a name="tag-filtering-aws" class="headerlink" href="#tag-filtering-aws" title="Permalink to this headline">¶</a></h4>
112112
</embed>
113113

114-
If you filter data based on tags, your costs for Amazon CloudWatch and Splunk Infrastructure Monitoring might decrease. Read more at :ref:`specify-data-metadata`.
115-
114+
If you filter data based on tags, your costs for Amazon CloudWatch and Splunk Observability Cloud might decrease. Read more at :ref:`specify-data-metadata`.
116115

117116

118117
.. raw:: html
@@ -126,7 +125,7 @@ If you filter data based on tags, your costs for Amazon CloudWatch and Splunk In
126125
<div class="include-stop" id="gdi/aws-unsupported-chars.rst"></div>
127126

128127

129-
128+
For more information on tagging see :ref:`aws-data-in-splunk`.
130129

131130
.. raw:: html
132131

infrastructure/monitor/aws-infra-import.rst

Lines changed: 8 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -28,14 +28,20 @@ AWS provides a CloudWatch agent that lets you import metrics, logs, and metadata
2828

2929
By default, Splunk Observability Cloud brings in data from all :ref:`supported AWS services <aws-integrations>` associated with your account, with :ref:`certain limitations <aws-data-limits>`.
3030

31+
.. _aws-data-in-splunk:
32+
3133
AWS data in Splunk Observability Cloud
3234
--------------------------------------------------------------------------------
3335

34-
During import, Splunk Observability Cloud gives the metrics special names so you can identify them as coming from AWS:
36+
During import, Splunk Observability Cloud gives metrics special names so you can identify them as coming from AWS:
3537

3638
- AWS metadata becomes dimensions and custom properties.
3739
- AWS tags are key-value pairs, so Infrastructure Monitoring converts them into custom properties.
3840

41+
Splunk Observability Cloud adds the prefix ``aws_tag_`` to the names of tags imported from AWS, which indicates their origin. For example, the AWS tag ``version:canary`` is converted to ``aws_tag_version:canary``.
42+
43+
.. caution:: For target groups Splunk Observability Cloud adds the prefix ``aws_tag_tg_`` to avoid conflicts with load balancer tags.
44+
3945
To learn more, see :ref:`aws-oc-metrics`, or refer to the AWS documentation site.
4046

4147
.. _aws-namespaces:
@@ -235,9 +241,7 @@ To create these specifications, follow these steps:
235241
* Use :guilabel:`Import some` if you want a filter that only imports data.
236242
* Use :guilabel:`Exclude some` if you want a filter that only excludes data.
237243

238-
#. To use AWS tags to limit the data Infrastructure Monitoring imports, filter by tag. For this example, specify a filter that excludes data from resources that have the AWS tag ``version:canary``.
239-
240-
Infrastructure Monitoring adds the prefix ``aws_tag_`` to the names of tags imported from AWS, which indicates their origin. For example, the AWS tag ``version:canary`` appears in Infrastructure Monitoring as ``aws_tag_version:canary``. When you filter an AWS integration by tag, enter the name of the tag as it appears in AWS.
244+
#. To use AWS tags to limit the data Infrastructure Monitoring imports, filter by tag. For this example, specify a filter that excludes data from resources that have the AWS tag ``version:canary``. Infrastructure Monitoring adds the prefix ``aws_tag_`` to the names of tags imported from AWS, which indicates their origin. For example, the AWS tag ``version:canary`` appears in Infrastructure Monitoring as ``aws_tag_version:canary``. When you filter an AWS integration by tag, enter the name of the tag as it appears in AWS.
241245

242246
You can also choose specific metrics to include or exclude. For example, consider the following conditions.
243247

infrastructure/monitor/aws-infra-metadata.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -25,7 +25,7 @@ For example, `DBClusterIdentifier` becomes `aws_db_cluster_identifier`.
2525
Common properties
2626
=============================================================================
2727

28-
For all services, the system imports the following common properties:
28+
For all services, Splunk Observability Cloud imports the following common properties:
2929

3030
.. list-table::
3131
:header-rows: 1

rum/rum-session-replay.rst

Lines changed: 35 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -12,7 +12,8 @@ Replay a session to take a look at exactly what a user experienced and make info
1212

1313

1414
Use cases
15-
===================
15+
======================================================================
16+
1617
There are many reasons why you might want to replay sessions. Here are a few:
1718

1819
* Reduce the amount of time support teams take to troubleshoot a problem. By seeing errors from the perspective of an actual user, support teams can quickly identify what happened, and take action. Without session replay, support teams could spend a long time investigating a variety of possible causes based on an incomplete description of the problem.
@@ -21,19 +22,20 @@ There are many reasons why you might want to replay sessions. Here are a few:
2122

2223

2324
Prerequisite
24-
=================
25+
======================================================================
2526

2627
Session replay is available for enterprise customers only. For more information on each type of subscription, see :new-page:`Splunk RUM Pricing <https://www.splunk.com/en_us/products/pricing/faqs/observability.html#splunk-rum>`.
2728

2829

2930
Set up session replay
30-
=====================
31-
There are two ways to set up session replay: CDN or NPM.
31+
======================================================================
3232

33-
.. admonition:: Note
34-
33+
There are three ways to set up session replay: CDN, self-hosted, or NPM.
34+
35+
.. note::
3536
Initialize Splunk Browser RUM before you initialize the session recorder package.
3637

38+
3739
This example shows the order in which to initialize the scripts:
3840

3941
.. code-block:: html
@@ -71,38 +73,53 @@ Initialize this code snippet to set up session replay through Splunk CDN.
7173

7274

7375

74-
NPM
76+
Self-hosted
7577
--------------------------------------------
7678

77-
Use the following command to set up session replay with NPM through a package named ``@splunk/otel-web-session-recorder``.
79+
#. Download the desired version of :new-page:`splunk-otel-web-session-recorder.js <https://github.com/signalfx/splunk-otel-js-web/releases/latest/download/splunk-otel-web-session-recorder.js>`.
80+
#. Deploy the file in a location accessible by the users of your application.
81+
#. Add the following session replay snippet after the ``SplunkRum.init`` snippet:
7882

83+
.. code-block:: javascript
7984
80-
.. code-block:: html
85+
<script src="<your-self-hosted-path>/splunk-otel-web-session-recorder.js" crossorigin="anonymous"></script>
8186
82-
npm install @splunk/otel-web-session-recorder
8387
84-
Next, initialize this code snippet:
88+
To avoid gaps in your data, load and initialize the Splunk JavaScript Agent asynchronously and as early as possible.
8589

86-
.. code-block:: html
8790

88-
import SplunkSessionRecorder from '@splunk/otel-web-session-recorder'
91+
NPM
92+
--------------------------------------------
8993

90-
SplunkSessionRecorder.init({
91-
realm: '<realm>',
92-
rumAccessToken: '<your_rum_token>'
93-
});
94+
#. Use the following command to set up session replay with NPM through a package named ``@splunk/otel-web-session-recorder``.
95+
96+
.. code-block:: html
97+
98+
npm install @splunk/otel-web-session-recorder
99+
100+
#. Next, initialize this code snippet:
101+
102+
.. code-block:: html
103+
104+
import SplunkSessionRecorder from '@splunk/otel-web-session-recorder'
105+
106+
SplunkSessionRecorder.init({
107+
realm: '<realm>',
108+
rumAccessToken: '<your_rum_token>'
109+
});
94110

95111

96112
Deactivate session replay
97113
--------------------------------------------
114+
98115
To deactivate session replay you can either:
99116

100117
* Turn it off for the particular session replay.
101118
* Remove the instrumentation if you want to deactivate it completely.
102119

103120

104121
Additional instrumentation settings
105-
------------------------------------
122+
--------------------------------------------
106123

107124
For more information on configuration options, see :new-page:`rrweb guide <https://github.com/rrweb-io/rrweb/blob/rrweb%401.1.3/guide.md#guide>` on GitHub.
108125

synthetics/test-config/private-locations.rst

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -502,7 +502,7 @@ Automatic upgrades
502502
###################################
503503

504504
You can automate the upgrade of the private location Docker images by using an automated upgrade solution such as
505-
`Watchtower <https://github.com/v2tec/watchtower>`, a third party open source Docker container that connects to remote Docker repositories on a schedule and checks for updates. This section explains how to use Watchtower, but if your operations team already has a mechanism established for deploying updates to Docker images you can use your existing mechanism without making any configuration changes to the private runner. The best practice is to run your upgrade automation at least once every 24 hours. Failing to update the private runner to the latest available image may result in inconsistent data and loss of functionality.
505+
:new-page:`Watchtower <https://github.com/v2tec/watchtower>`, a third-party open source Docker container that connects to remote Docker repositories on a schedule and checks for updates. This section explains how to use Watchtower, but if your operations team already has a mechanism established for deploying updates to Docker images, you can use your existing mechanism without making any configuration changes to the private runner. The best practice is to run your upgrade automation at least once every 24 hours. Failing to update the private runner to the latest available image may result in inconsistent data and loss of functionality.
506506

507507
When Watchtower finds an updated image, it instructs your Docker host to pull the newest image from the repository, stop the container, and start it again. It also ensures that environment variables, network settings, and links between containers are intact.
508508

@@ -517,7 +517,7 @@ On your Docker host, launch the Watchtower container from the command line:
517517
518518
Using the ``label-enable`` flag ensures that only containers with the correct label, like the Splunk private runner, are be auto-updated.
519519

520-
There are additional options available in the `Watchtower documentation <https://github.com/v2tec/watchtower#options>` that you can explore, including auto-cleanup of old images to ensure that your Docker host does not hold onto outdated images.
520+
There are additional options available in the :new-page:`Watchtower documentation <https://github.com/v2tec/watchtower#options>` that you can explore, including auto-cleanup of old images to ensure that your Docker host does not hold onto outdated images.
521521

522522
.. note::
523523
In order for Watchtower to issue commands to the Docker host, it requires the ``docker.sock`` volume or TCP connection, which provides Watchtower with full administrative access to your Docker host. If you are unable to provide Watchtower with this level of access you can explore other options for automating updates.

0 commit comments

Comments
 (0)