From ebdc1911c0b18bcdbea875d112f9a6a502b983df Mon Sep 17 00:00:00 2001 From: Anna Urbiztondo Date: Thu, 2 Jan 2025 15:51:59 +0100 Subject: [PATCH 01/19] Draft --- .../otel-other/other-ingestion-collectd.rst | 138 ++++++++++++++++++ 1 file changed, 138 insertions(+) create mode 100644 gdi/opentelemetry/otel-other/other-ingestion-collectd.rst diff --git a/gdi/opentelemetry/otel-other/other-ingestion-collectd.rst b/gdi/opentelemetry/otel-other/other-ingestion-collectd.rst new file mode 100644 index 000000000..9b7a0d83f --- /dev/null +++ b/gdi/opentelemetry/otel-other/other-ingestion-collectd.rst @@ -0,0 +1,138 @@ +.. _other-ingestion-collectd: + +Monitor services with collectd and OpenTelemetry +===================================================================== + +.. meta:: + :description: Use collectd and native OpenTelemetry to monitor services in Splunk Observability Cloud. See benefits, install, configuration, and metrics. + +To monitor your services with collectd using native OpenTelemetry in Splunk Observability Cloud, connect a collectd daemon to your Collector instance as described in this document. + +Benefits +-------- + +.. raw:: html + +
+ +.. include:: /_includes/benefits.rst + +.. raw:: html + +
+ + +Configuration +---------------------------------- + +This example shows how to connect a collectd daemon running on a host to an OpenTelemetry Collector. + +.. note:: In this example, the host is represented by an Ubuntu 24.04 docker image. + +1. Install and configure collectd +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Follow these steps to install and configure the collectd daemon: + +#. Install collectd as a Debian package in your host using stock instructions +#. Configure the daemon to ingest free disk related metrics through `collectd/metrics.conf` +#. Configure the daemon to send data over HTTP using `collectd/http.conf` + +.. code:: + + version: "3" + services: + collectd: + build: collectd + container_name: collectd + depends_on: + - otelcollector + volumes: + - ./collectd/http.conf:/etc/collectd/collectd.conf.d/http.conf + - ./collectd/metrics.conf:/etc/collectd/collectd.conf.d/metrics.conf + + # OpenTelemetry Collector + otelcollector: + image: quay.io/signalfx/splunk-otel-collector:latest + container_name: otelcollector + command: ["--config=/etc/otel-collector-config.yml", "--set=service.telemetry.logs.level=debug"] + volumes: + - ./otel-collector-config.yml:/etc/otel-collector-config.yml + +2. Configure the OpenTelemetry Collector +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Set up your Collector instance to listen for traffic from the collectd daemon over HTTP with the :ref:`collectd-receiver`: + +.. code:: yaml + + receivers: + collectd: + endpoint: "0.0.0.0:8081" + + exporters: + debug: + verbosity: detailed + + service: + pipelines: + metrics: + receivers: [collectd] + exporters: [debug] + +.. caution:: Make sure to use ``0.0.0.0`` to expose port 8081 over the Docker network interface so that both Docker containers can interact. + +3. Run the example +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Run the example with the instruction to start the docker-compose setup and build the collectd container: + +.. code:: bash + + $> docker compose up --build + +Check that the Collector is receiving metrics and logging them to ``stdout`` via the debug exporter: + +.. code:: bash + + $> docker logs otelcollector + +A typical output is: + +.. code:: + + StartTimestamp: 1970-01-01 00:00:00 +0000 UTC + Timestamp: 2024-12-20 19:55:44.006000128 +0000 UTC + Value: 38.976566 + Metric #17 + Descriptor: + -> Name: percent_bytes.reserved + -> Description: + -> Unit: + -> DataType: Gauge + NumberDataPoints #0 + Data point attributes: + -> plugin: Str(df) + -> plugin_instance: Str(etc-hosts) + -> host: Str(ea1d62c7a229) + -> dsname: Str(value) + StartTimestamp: 1970-01-01 00:00:00 +0000 UTC + Timestamp: 2024-12-20 19:55:44.006000128 +0000 UTC + Value: 5.102245 + {"kind": "exporter", "data_type": "metrics", "name": "debug"} + +Troubleshooting +--------------- + +.. raw:: html + +
+ +.. include:: /_includes/troubleshooting-components.rst + +.. raw:: html + +
+ + + From 729ccce72d9279518481cae52326d4957f8e38ab Mon Sep 17 00:00:00 2001 From: Anna Urbiztondo Date: Thu, 2 Jan 2025 16:38:56 +0100 Subject: [PATCH 02/19] Fixes --- gdi/opentelemetry/otel-other/otel-other-landing.rst | 4 +++- gdi/opentelemetry/otel-other/telegraf.rst | 4 ++-- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/gdi/opentelemetry/otel-other/otel-other-landing.rst b/gdi/opentelemetry/otel-other/otel-other-landing.rst index 0137a1661..f6752d0d4 100644 --- a/gdi/opentelemetry/otel-other/otel-other-landing.rst +++ b/gdi/opentelemetry/otel-other/otel-other-landing.rst @@ -14,8 +14,10 @@ Other OpenTelemetry ingestion methods prometheus-generic telegraf + other-ingestion-collectd On top of the available native :ref:`OpenTelemetry receivers `, you can also send data to Splunk Observability Cloud with OpenTelemetry with the following options: * :ref:`prometheus-generic` -* :ref:`telegraf-generic` \ No newline at end of file +* :ref:`telegraf-generic` +* :ref:`other-ingestion-collectd` \ No newline at end of file diff --git a/gdi/opentelemetry/otel-other/telegraf.rst b/gdi/opentelemetry/otel-other/telegraf.rst index 3f466b0a0..c76a523f7 100644 --- a/gdi/opentelemetry/otel-other/telegraf.rst +++ b/gdi/opentelemetry/otel-other/telegraf.rst @@ -5,7 +5,7 @@ Monitor services with Telegraf Input plugins and OpenTelemetry ===================================================================== .. meta:: - :description: Use this Splunk Observability Cloud integration for the Telegraf monitor. See benefits, install, configuration, and metrics. + :description: Use Telegraf and OpenTelemetry to monitor your services in Splunk Observability Cloud. See benefits, install, configuration, and metrics. To monitor your service with Telegraf using native OpenTelemetry in Splunk Observability Cloud, install the service's Telegraf Input plugin then push metrics to the Splunk Opentelemetry Collector via OTLP. @@ -39,7 +39,7 @@ Follow these steps to scrape Telegraf metrics with the OTel Collector: 3. Set up the Telegraf OpenTelemetry Output plugin 4. Configure the OpenTelemetry Collector -1. Install Telegraf +5. Install Telegraf ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Run the following commands to install Telegraf from the InfluxData repository: From 790b2fcfc0976cbe3d2c21ba58fd12cfc5549fba Mon Sep 17 00:00:00 2001 From: Anna Urbiztondo Date: Fri, 3 Jan 2025 07:16:07 +0100 Subject: [PATCH 03/19] Edits --- .../otel-other/other-ingestion-collectd.rst | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/gdi/opentelemetry/otel-other/other-ingestion-collectd.rst b/gdi/opentelemetry/otel-other/other-ingestion-collectd.rst index 9b7a0d83f..f3f70ea40 100644 --- a/gdi/opentelemetry/otel-other/other-ingestion-collectd.rst +++ b/gdi/opentelemetry/otel-other/other-ingestion-collectd.rst @@ -1,12 +1,12 @@ .. _other-ingestion-collectd: -Monitor services with collectd and OpenTelemetry +Monitor hosts with collectd and OpenTelemetry ===================================================================== .. meta:: :description: Use collectd and native OpenTelemetry to monitor services in Splunk Observability Cloud. See benefits, install, configuration, and metrics. -To monitor your services with collectd using native OpenTelemetry in Splunk Observability Cloud, connect a collectd daemon to your Collector instance as described in this document. +To monitor your infrastructure with collectd using native OpenTelemetry in Splunk Observability Cloud, install a collectd daemon in your host and connect it to your Collector instance as described in this document. Benefits -------- @@ -25,19 +25,24 @@ Benefits Configuration ---------------------------------- -This example shows how to connect a collectd daemon running on a host to an OpenTelemetry Collector. +Install a collectd daemon in your a host and connect it to an OpenTelemetry Collector with the following steps: + +1. Install and configure collectd +2. Configure the OpenTelemetry Collector +3. Build and run -.. note:: In this example, the host is represented by an Ubuntu 24.04 docker image. 1. Install and configure collectd ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Follow these steps to install and configure the collectd daemon: -#. Install collectd as a Debian package in your host using stock instructions +#. Install collectd as a Debian package in your host #. Configure the daemon to ingest free disk related metrics through `collectd/metrics.conf` #. Configure the daemon to send data over HTTP using `collectd/http.conf` +In this example, the host is represented by an Ubuntu 24.04 docker image. + .. code:: version: "3" @@ -82,7 +87,7 @@ Set up your Collector instance to listen for traffic from the collectd daemon ov .. caution:: Make sure to use ``0.0.0.0`` to expose port 8081 over the Docker network interface so that both Docker containers can interact. -3. Run the example +3. Build and run ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Run the example with the instruction to start the docker-compose setup and build the collectd container: From f7405de63f5692ab3c83a4286ac6fdb1279d632e Mon Sep 17 00:00:00 2001 From: Bri Hillmer Date: Fri, 3 Jan 2025 10:21:50 -0700 Subject: [PATCH 04/19] remove sensu doc link --- sp-oncall/spoc-integrations/sensu-integration.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sp-oncall/spoc-integrations/sensu-integration.rst b/sp-oncall/spoc-integrations/sensu-integration.rst index c08f0a2c9..576bbe3f2 100644 --- a/sp-oncall/spoc-integrations/sensu-integration.rst +++ b/sp-oncall/spoc-integrations/sensu-integration.rst @@ -138,5 +138,5 @@ Splunk On-Call Handler end end -For more information, see :new-page:`Sensu documentation on Handlers `. +For more information, see search "handlers" on the Sensu documentation website. From 6710402d08a031130cbddf86fbc4a25d696a00c6 Mon Sep 17 00:00:00 2001 From: ada Date: Fri, 3 Jan 2025 19:18:57 -0800 Subject: [PATCH 05/19] Updated and de-duplicated the wording for some key concepts --- synthetics/key-concepts.rst | 46 +++++++++++++++++++------------------ 1 file changed, 24 insertions(+), 22 deletions(-) diff --git a/synthetics/key-concepts.rst b/synthetics/key-concepts.rst index 8f2cbdb96..0c03ca1ed 100644 --- a/synthetics/key-concepts.rst +++ b/synthetics/key-concepts.rst @@ -22,43 +22,45 @@ These key concepts help you get the most out of your experience with Splunk Synt * - Synthetics - A common abbreviation for Synthetic Monitoring. - * - Tests - - Tests are the primary mechanism of application monitoring in Splunk Synthetic Monitoring. You can set up Browser, Uptime, and API tests to run at your preferred frequency from the devices and public locations of your choosing. + * - Test + - An ordered sequence of steps (actions or operations) to perform on a target URL or endpoint, similar to a script. A test is the primary mechanism for monitoring applications in Splunk Synthetic Monitoring. You can set up browser, uptime, and API tests to run at your preferred frequency from the devices and locations of your choosing. - * - Runs - - Each occurrence of a test from a particular device and location at a specific time is called a run. Each run of a test captures a set of metrics and diagnostics that provide insight into your application's performance. + * - Run + - An instance of a test invocation from a specific device and location and at a specific time. - * - Metrics - - | Numeric indicators of site performance that synthetic tests capture in each run of a test. See the following links for the lists of metrics available for each test type: + * - Metric + - A numeric indicator of a performance factor. Each run of a test captures metrics and diagnostics that provide insight into your application's performance. See the following links for details on the metrics available captured by each test type: | | - :ref:`browser-metrics` | - :ref:`uptime-metrics` | - :ref:`api-test-metrics` | - * - Browser tests - - Synthetic tests that simulate and analyze the user experience of loading a page or performing a workflow on a site or application. + * - Browser test + - A synthetic test that simulates and analyzes the user experience of loading a page or performing a workflow on a site or application. - * - Uptime tests - - Synthetic tests that monitor the response time and response code of HTTP requests and server ports. + * - Uptime test + - A synthetic test that monitors the response times and response codes of HTTP requests and server ports. - * - API tests - - Synthetic tests that monitor the functionality and performance of API endpoints. + * - API test + - A synthetic test that monitors the functionality and performance of API endpoints. - * - Waterfall charts - - A visualization that represents the performance of resources on a webpage in a Browser test. + * - Waterfall chart + - A visualization that represents the performance of resources on a webpage in a browser test. - * - Devices - - Options to configure the viewport and network connection type of your tests. For example, you can test a webpage from a laptop screen or a smartphone. + * - Device + - A predefined combination of a specific viewport size and network connection. For more information about devices, viewports, and network connections, see :ref:`devices`. - * - Viewport - - Browser tests in Splunk Synthetic Monitoring capture the visual experience of a user interacting with your application. The viewport is the framed area on a device's screen for viewing information, such as the browser window on a desktop. When you set up a test, you can choose the viewport size from a list of common devices, or set a custom viewport by height and width. + * - Public location + - A public IP address from which you can run synthetic tests to simulate performance for users in that location. See :ref:`public-locations`. + + * - Private location + - A name you create in Splunk Synthetic Monitoring to represent a private, internal location from which you can run synthetic tests on internal applications or private URLs. The name you give to a private location allows you to specify that name in a synthetic test's :guilabel:`Locations` field. You must also set up one or more private runners within every private location to do the actual communication to and from your private target. See :ref:`private-locations`. + + * - Private runner + - A private runner queries Splunk Synthetic Monitoring for each step to perform for the test that it is connected to, performs that step on your private target, and reports the results back to Splunk Synthetic Monitoring. Because a private runner must have access to your private target, it is a Docker image which you deploy on your own infrastructure, within your own internal network. See :ref:`private-locations`. - * - Network connection - - You can run Browser, Uptime or API tests to simulate network connections of various latencies, including Mobile LTE, Mobile 3G, DSL, and cable internet. Testing your site from a variety of connection types lets you monitor the experience of users in a variety of settings. - * - Public Locations - - Global checkpoints from which you can synthetically run tests to simulate performance for users in that location. Learn more =========== From cf9974869d69308908134201aa36fa4602c5a981 Mon Sep 17 00:00:00 2001 From: ada Date: Fri, 3 Jan 2025 20:34:03 -0800 Subject: [PATCH 06/19] Reorder some paragraphs --- synthetics/test-config/private-locations.rst | 33 ++++++++++---------- 1 file changed, 17 insertions(+), 16 deletions(-) diff --git a/synthetics/test-config/private-locations.rst b/synthetics/test-config/private-locations.rst index 60918a1af..31611aaa8 100644 --- a/synthetics/test-config/private-locations.rst +++ b/synthetics/test-config/private-locations.rst @@ -9,16 +9,7 @@ Private locations A private location is a software package that offers a quick and easy deployment of Splunk Synthetic Monitoring solutions beyond the public network so that you can find, fix, and prevent web performance defects on any internal web application, in any environment - whether inside or outside of your firewalls. Private locations allow Splunk Synthetics Monitoring users to test sooner in the development cycle and against internal sites or applications that aren't available to the public. -Customers can, through the Splunk Synthetics Monitoring web interface, create new private locations and open a runner to run any checks assigned to them. - -What is a runner? -=================== - -A runner is a Docker container set up to run tests from a particular private location. A single private location can have one or more runners. - -A location consists of a queue of tests assigned to a particular private location. Runners pick up runs from the queue, so the more active runners you have, the faster the queue of tests is processed. - -Splunk Synthetic Monitoring doesn't track how many runners there are for a given location. It is up to you to manage your own fleet of runners. +Customers can, through the Splunk Synthetics Monitoring web interface, create new private locations connected to private runners that run any tests assigned to them. Use cases for private locations @@ -30,8 +21,18 @@ Use cases for private locations * Test from locations not currently supported by Splunk Synthetic Monitoring's public locations. -Requirements -============= +What is a private runner? +=================== + +A private runner is a Docker container set up to run tests from a particular private location. A single private location can have one or more private runners. + +A private location contains of a queue of tests assigned to that particular private location. Private rrunners pick up runs from the queue, so the more active private runners you have, the faster the queue of tests is processed. + +Splunk Synthetic Monitoring doesn't track how many private runners there are for a given private location. It is up to you to manage your own fleet of private runners. + + +Requirements for private runners +=========================== .. list-table:: @@ -55,7 +56,7 @@ Requirements - Linux, Windows, or macOS -For optimal performance when running Browser tests: +For optimal performance when running browser tests: * Linux * 2.3 GHz Dual-Core Intel Xeon (or equivalent) processor @@ -69,7 +70,7 @@ Follow these steps to set up a new private location: 1. In Splunk Synthetic Monitoring, select the settings gear icon, then :guilabel:`Private locations`. 2. Select :guilabel:`+ Add` and add a name. -3. Follow the steps in the guided setup to set up your runner. +3. Follow the steps in the guided setup to set up one or more private runners for that private location. 4. Save your private location. @@ -139,7 +140,7 @@ For example, here is what a command might look like after you modify it to fit y -Configuring Proxy Settings for Private Locations +Configuring proxy settings for a private location =================================================== In environments where direct internet access is restricted, you can route synthetic test traffic through a proxy server by configuring the following environment variables: @@ -194,7 +195,7 @@ When using runner, it's important to correctly configure the proxy settings to a -Assess the health of your private location +Assess the health of a private location ============================================== A private location's health depends on three factors: From ba906bf052f7e36ef30377e76fdda70a21ce0f1a Mon Sep 17 00:00:00 2001 From: ada Date: Fri, 3 Jan 2025 20:54:31 -0800 Subject: [PATCH 07/19] Fix underline syntax --- synthetics/test-config/private-locations.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/synthetics/test-config/private-locations.rst b/synthetics/test-config/private-locations.rst index 31611aaa8..6cca418da 100644 --- a/synthetics/test-config/private-locations.rst +++ b/synthetics/test-config/private-locations.rst @@ -13,7 +13,7 @@ Customers can, through the Splunk Synthetics Monitoring web interface, create ne Use cases for private locations -================================= +==================================== * Test private applications that aren't exposed to the public. * Test pre-production applications which don't have public staging sites. @@ -22,7 +22,7 @@ Use cases for private locations What is a private runner? -=================== +================================ A private runner is a Docker container set up to run tests from a particular private location. A single private location can have one or more private runners. @@ -32,7 +32,7 @@ Splunk Synthetic Monitoring doesn't track how many private runners there are for Requirements for private runners -=========================== +========================================== .. list-table:: @@ -64,7 +64,7 @@ For optimal performance when running browser tests: Set up a new private location -=============================== +===================================== Follow these steps to set up a new private location: From f6479d591b56a1efd6e6ea2d313982762b10878a Mon Sep 17 00:00:00 2001 From: ada Date: Mon, 6 Jan 2025 08:14:52 -0800 Subject: [PATCH 08/19] Fix typo --- synthetics/test-config/private-locations.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/synthetics/test-config/private-locations.rst b/synthetics/test-config/private-locations.rst index 6cca418da..99b844c96 100644 --- a/synthetics/test-config/private-locations.rst +++ b/synthetics/test-config/private-locations.rst @@ -26,7 +26,7 @@ What is a private runner? A private runner is a Docker container set up to run tests from a particular private location. A single private location can have one or more private runners. -A private location contains of a queue of tests assigned to that particular private location. Private rrunners pick up runs from the queue, so the more active private runners you have, the faster the queue of tests is processed. +A private location contains of a queue of tests assigned to that particular private location. Private runners pick up runs from the queue, so the more active private runners you have, the faster the queue of tests is processed. Splunk Synthetic Monitoring doesn't track how many private runners there are for a given private location. It is up to you to manage your own fleet of private runners. From b357e8ba41a03bbecbd0d54ca3b35e511ae036b8 Mon Sep 17 00:00:00 2001 From: ada Date: Mon, 6 Jan 2025 09:09:31 -0800 Subject: [PATCH 09/19] Updates based on reviewer feedback --- synthetics/key-concepts.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/synthetics/key-concepts.rst b/synthetics/key-concepts.rst index 0c03ca1ed..8b6a0f5fa 100644 --- a/synthetics/key-concepts.rst +++ b/synthetics/key-concepts.rst @@ -23,7 +23,7 @@ These key concepts help you get the most out of your experience with Splunk Synt - A common abbreviation for Synthetic Monitoring. * - Test - - An ordered sequence of steps (actions or operations) to perform on a target URL or endpoint, similar to a script. A test is the primary mechanism for monitoring applications in Splunk Synthetic Monitoring. You can set up browser, uptime, and API tests to run at your preferred frequency from the devices and locations of your choosing. + - An ordered sequence of actions or operations to perform on a target URL or endpoint, similar to a script. A test is the primary mechanism for monitoring applications in Splunk Synthetic Monitoring. You can set up browser, uptime, and API tests to run at your preferred frequency from the devices and locations of your choosing. * - Run - An instance of a test invocation from a specific device and location and at a specific time. @@ -55,10 +55,10 @@ These key concepts help you get the most out of your experience with Splunk Synt - A public IP address from which you can run synthetic tests to simulate performance for users in that location. See :ref:`public-locations`. * - Private location - - A name you create in Splunk Synthetic Monitoring to represent a private, internal location from which you can run synthetic tests on internal applications or private URLs. The name you give to a private location allows you to specify that name in a synthetic test's :guilabel:`Locations` field. You must also set up one or more private runners within every private location to do the actual communication to and from your private target. See :ref:`private-locations`. + - A name you create in Splunk Synthetic Monitoring to represent a custom location from which you can run synthetic tests. The name you give to a private location allows you to specify that name in a synthetic test's :guilabel:`Locations` field. You must also set up one or more private runners within every private location to do the actual communication with your targets and with Splunk Synthetic Monitoring. You can use a private location to test an internal endpoint or to test a public endpoint from a location that isn't included in :ref:`the list of Splunk Synthetic Monitoring public locations `. See :ref:`private-locations`. * - Private runner - - A private runner queries Splunk Synthetic Monitoring for each step to perform for the test that it is connected to, performs that step on your private target, and reports the results back to Splunk Synthetic Monitoring. Because a private runner must have access to your private target, it is a Docker image which you deploy on your own infrastructure, within your own internal network. See :ref:`private-locations`. + - A private runner queries Splunk Synthetic Monitoring for tests configured to run in its inherent private location, performs the test's steps on your private target, and reports the results back to Splunk Synthetic Monitoring. Because a private runner must have access to your private target, it is a Docker image which you deploy on your own infrastructure, within your own internal network. See :ref:`private-locations`. From 13f891f61b8f50448e4a8dd7dc4cf2510667142b Mon Sep 17 00:00:00 2001 From: ada Date: Mon, 6 Jan 2025 13:21:16 -0800 Subject: [PATCH 10/19] Updated wording to match the wording agreed on for PR 2531 --- synthetics/test-config/private-locations.rst | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/synthetics/test-config/private-locations.rst b/synthetics/test-config/private-locations.rst index 99b844c96..f4651a158 100644 --- a/synthetics/test-config/private-locations.rst +++ b/synthetics/test-config/private-locations.rst @@ -7,14 +7,17 @@ Private locations .. meta:: :description: Run synthetic tests from private locations such as internal sites, private web applications, or private networks. -A private location is a software package that offers a quick and easy deployment of Splunk Synthetic Monitoring solutions beyond the public network so that you can find, fix, and prevent web performance defects on any internal web application, in any environment - whether inside or outside of your firewalls. Private locations allow Splunk Synthetics Monitoring users to test sooner in the development cycle and against internal sites or applications that aren't available to the public. - -Customers can, through the Splunk Synthetics Monitoring web interface, create new private locations connected to private runners that run any tests assigned to them. +A private location is a name you create in Splunk Synthetic Monitoring to represent a custom location from which you can run synthetic tests. The name you give to a private location allows you to specify that name in a synthetic test's :guilabel:`Locations` field. You must also set up one or more private runners within every private location to do the actual communication with your targets and with Splunk Synthetic Monitoring. You can use a private location to test an internal endpoint or to test a public endpoint from a location that isn't included in :ref:`the list of Splunk Synthetic Monitoring public locations `. Use cases for private locations ==================================== +A private location offers a quick and easy deployment of Splunk Synthetic Monitoring solutions beyond the public network so that you can find, fix, and prevent web performance defects on any internal web application, in any environment - whether inside or outside of your firewalls. Private locations allow you to test sooner in the development cycle and against internal sites or applications that aren't available to the public. + +Through the Splunk Synthetics Monitoring web interface, you can create new private locations connected to private runners that run any tests assigned to them. + + * Test private applications that aren't exposed to the public. * Test pre-production applications which don't have public staging sites. * Gain a higher level of flexibility in giving Splunk Synthetic Monitoring access to applications. @@ -24,7 +27,8 @@ Use cases for private locations What is a private runner? ================================ -A private runner is a Docker container set up to run tests from a particular private location. A single private location can have one or more private runners. +A private runner queries Splunk Synthetic Monitoring for tests configured to run in its inherent private location, performs the test's steps on your private target, and reports the results back to Splunk Synthetic Monitoring. Because a private runner must have access to your private target, it is a Docker image which you deploy on your own infrastructure, within your own internal network. See :ref:`private-locations`. + A private location contains of a queue of tests assigned to that particular private location. Private runners pick up runs from the queue, so the more active private runners you have, the faster the queue of tests is processed. From ed56aa5f85d28efb89d347e1949ed5288d37042c Mon Sep 17 00:00:00 2001 From: ada Date: Mon, 6 Jan 2025 15:07:24 -0800 Subject: [PATCH 11/19] Additional clarifications --- synthetics/test-config/private-locations.rst | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/synthetics/test-config/private-locations.rst b/synthetics/test-config/private-locations.rst index f4651a158..51384934e 100644 --- a/synthetics/test-config/private-locations.rst +++ b/synthetics/test-config/private-locations.rst @@ -7,32 +7,29 @@ Private locations .. meta:: :description: Run synthetic tests from private locations such as internal sites, private web applications, or private networks. -A private location is a name you create in Splunk Synthetic Monitoring to represent a custom location from which you can run synthetic tests. The name you give to a private location allows you to specify that name in a synthetic test's :guilabel:`Locations` field. You must also set up one or more private runners within every private location to do the actual communication with your targets and with Splunk Synthetic Monitoring. You can use a private location to test an internal endpoint or to test a public endpoint from a location that isn't included in :ref:`the list of Splunk Synthetic Monitoring public locations `. +A private location is a name you create in Splunk Synthetic Monitoring to represent a custom location from which you can run synthetic tests. The name you give to a private location allows you to specify that name in a synthetic test's :guilabel:`Locations` field. In order to run synthetic tests from private locations, you must also set up one or more private runners within the private location to do the actual communication with your test targets and with Splunk Synthetic Monitoring. Use cases for private locations ==================================== -A private location offers a quick and easy deployment of Splunk Synthetic Monitoring solutions beyond the public network so that you can find, fix, and prevent web performance defects on any internal web application, in any environment - whether inside or outside of your firewalls. Private locations allow you to test sooner in the development cycle and against internal sites or applications that aren't available to the public. - -Through the Splunk Synthetics Monitoring web interface, you can create new private locations connected to private runners that run any tests assigned to them. +Private locations provide a way for you to find, fix, and prevent web performance problems in internal web applications in any environment - inside or outside of your firewalls. You can use private locations to run tests earlier in your development cycle - against internal sites or applications that aren't available to the public. You can also use private locations to test public endpoints from locations that aren't included in :ref:`the list of Splunk Synthetic Monitoring public locations `. +To summarize, here are sample use cases for private locations: * Test private applications that aren't exposed to the public. * Test pre-production applications which don't have public staging sites. -* Gain a higher level of flexibility in giving Splunk Synthetic Monitoring access to applications. +* Gain a higher level of flexibility by giving Splunk Synthetic Monitoring access to applications. * Test from locations not currently supported by Splunk Synthetic Monitoring's public locations. What is a private runner? ================================ -A private runner queries Splunk Synthetic Monitoring for tests configured to run in its inherent private location, performs the test's steps on your private target, and reports the results back to Splunk Synthetic Monitoring. Because a private runner must have access to your private target, it is a Docker image which you deploy on your own infrastructure, within your own internal network. See :ref:`private-locations`. - +A private runner is a Docker image which you deploy on your own infrastructure, within your own internal network. It picks up test runs from the queue of tests assigned to its associated private location, performs the actions in the test run on the test target, and reports the results back to Splunk Synthetic Monitoring. -A private location contains of a queue of tests assigned to that particular private location. Private runners pick up runs from the queue, so the more active private runners you have, the faster the queue of tests is processed. -Splunk Synthetic Monitoring doesn't track how many private runners there are for a given private location. It is up to you to manage your own fleet of private runners. +If you create multiple private runners for a private location, they can process that location's test queue faster. Splunk Synthetic Monitoring doesn't track how many private runners there are for a given private location. It's up to you to manage your own fleet of private runners. Requirements for private runners From 5edfe07bf5893cd5abb2417e21b36f4f4860a3b3 Mon Sep 17 00:00:00 2001 From: ada Date: Mon, 6 Jan 2025 16:22:12 -0800 Subject: [PATCH 12/19] Additional clarifications --- synthetics/test-config/private-locations.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/synthetics/test-config/private-locations.rst b/synthetics/test-config/private-locations.rst index 51384934e..9ce00f530 100644 --- a/synthetics/test-config/private-locations.rst +++ b/synthetics/test-config/private-locations.rst @@ -13,7 +13,7 @@ A private location is a name you create in Splunk Synthetic Monitoring to repres Use cases for private locations ==================================== -Private locations provide a way for you to find, fix, and prevent web performance problems in internal web applications in any environment - inside or outside of your firewalls. You can use private locations to run tests earlier in your development cycle - against internal sites or applications that aren't available to the public. You can also use private locations to test public endpoints from locations that aren't included in :ref:`the list of Splunk Synthetic Monitoring public locations `. +Private locations provide a way for you to find, fix, and prevent performance problems in internal applications in any environment, inside or outside of your firewalls. You can use private locations to run tests earlier in your development cycle against internal sites or applications that aren't available to the public. You can also use private locations to test public endpoints from locations that aren't included in the :ref:`list of Splunk Synthetic Monitoring public locations `. To summarize, here are sample use cases for private locations: From 8de3a97a126b529d1aaf78b5cd1490db95a04919 Mon Sep 17 00:00:00 2001 From: adasplunk Date: Mon, 6 Jan 2025 18:46:00 -0800 Subject: [PATCH 13/19] Update synthetics/test-config/private-locations.rst Co-authored-by: jcatera-splunk --- synthetics/test-config/private-locations.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/synthetics/test-config/private-locations.rst b/synthetics/test-config/private-locations.rst index 9ce00f530..82735b0b9 100644 --- a/synthetics/test-config/private-locations.rst +++ b/synthetics/test-config/private-locations.rst @@ -7,7 +7,7 @@ Private locations .. meta:: :description: Run synthetic tests from private locations such as internal sites, private web applications, or private networks. -A private location is a name you create in Splunk Synthetic Monitoring to represent a custom location from which you can run synthetic tests. The name you give to a private location allows you to specify that name in a synthetic test's :guilabel:`Locations` field. In order to run synthetic tests from private locations, you must also set up one or more private runners within the private location to do the actual communication with your test targets and with Splunk Synthetic Monitoring. +A private location is a name you create in Splunk Synthetic Monitoring to represent a custom location from which you can run synthetic tests. The name you give to a private location allows you to specify that name in a synthetic test's :guilabel:`Locations` field. To run synthetic tests from private locations, you must also set up one or more private runners within the private location to do the actual communication with your test targets and with Splunk Synthetic Monitoring. Use cases for private locations From b0390b6f9cd88d4e4855b4467bf7dbfa69522875 Mon Sep 17 00:00:00 2001 From: Anna U <104845867+aurbiztondo-splunk@users.noreply.github.com> Date: Tue, 7 Jan 2025 12:07:29 +0100 Subject: [PATCH 14/19] Update gdi/opentelemetry/otel-other/other-ingestion-collectd.rst Co-authored-by: Antoine Toulme --- gdi/opentelemetry/otel-other/other-ingestion-collectd.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gdi/opentelemetry/otel-other/other-ingestion-collectd.rst b/gdi/opentelemetry/otel-other/other-ingestion-collectd.rst index f3f70ea40..e318bd202 100644 --- a/gdi/opentelemetry/otel-other/other-ingestion-collectd.rst +++ b/gdi/opentelemetry/otel-other/other-ingestion-collectd.rst @@ -25,7 +25,7 @@ Benefits Configuration ---------------------------------- -Install a collectd daemon in your a host and connect it to an OpenTelemetry Collector with the following steps: +Install a collectd daemon in your host and connect it to an OpenTelemetry Collector with the following steps: 1. Install and configure collectd 2. Configure the OpenTelemetry Collector From 2912e4bbe87617d7da18dd7a158a2536937c2cc4 Mon Sep 17 00:00:00 2001 From: Anna U <104845867+aurbiztondo-splunk@users.noreply.github.com> Date: Tue, 7 Jan 2025 12:07:36 +0100 Subject: [PATCH 15/19] Update gdi/opentelemetry/otel-other/other-ingestion-collectd.rst Co-authored-by: Antoine Toulme --- gdi/opentelemetry/otel-other/other-ingestion-collectd.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gdi/opentelemetry/otel-other/other-ingestion-collectd.rst b/gdi/opentelemetry/otel-other/other-ingestion-collectd.rst index e318bd202..c36915d17 100644 --- a/gdi/opentelemetry/otel-other/other-ingestion-collectd.rst +++ b/gdi/opentelemetry/otel-other/other-ingestion-collectd.rst @@ -37,7 +37,7 @@ Install a collectd daemon in your host and connect it to an OpenTelemetry Collec Follow these steps to install and configure the collectd daemon: -#. Install collectd as a Debian package in your host +#. Install collectd as a Debian or Yum package in your host #. Configure the daemon to ingest free disk related metrics through `collectd/metrics.conf` #. Configure the daemon to send data over HTTP using `collectd/http.conf` From a5e5f75e7f0faea723832f2bc1564c12ec71479f Mon Sep 17 00:00:00 2001 From: Anna U <104845867+aurbiztondo-splunk@users.noreply.github.com> Date: Tue, 7 Jan 2025 12:07:48 +0100 Subject: [PATCH 16/19] Update gdi/opentelemetry/otel-other/other-ingestion-collectd.rst Co-authored-by: Antoine Toulme --- gdi/opentelemetry/otel-other/other-ingestion-collectd.rst | 1 - 1 file changed, 1 deletion(-) diff --git a/gdi/opentelemetry/otel-other/other-ingestion-collectd.rst b/gdi/opentelemetry/otel-other/other-ingestion-collectd.rst index c36915d17..5f2d2d677 100644 --- a/gdi/opentelemetry/otel-other/other-ingestion-collectd.rst +++ b/gdi/opentelemetry/otel-other/other-ingestion-collectd.rst @@ -45,7 +45,6 @@ In this example, the host is represented by an Ubuntu 24.04 docker image. .. code:: - version: "3" services: collectd: build: collectd From 184599e8eddbc01bd4404ee9052c590bb971de8c Mon Sep 17 00:00:00 2001 From: Anna Urbiztondo Date: Tue, 7 Jan 2025 12:18:09 +0100 Subject: [PATCH 17/19] Added missing examples --- .../otel-other/other-ingestion-collectd.rst | 33 ++++++++++++++++--- 1 file changed, 29 insertions(+), 4 deletions(-) diff --git a/gdi/opentelemetry/otel-other/other-ingestion-collectd.rst b/gdi/opentelemetry/otel-other/other-ingestion-collectd.rst index 5f2d2d677..ca65bc5c2 100644 --- a/gdi/opentelemetry/otel-other/other-ingestion-collectd.rst +++ b/gdi/opentelemetry/otel-other/other-ingestion-collectd.rst @@ -31,7 +31,6 @@ Install a collectd daemon in your host and connect it to an OpenTelemetry Collec 2. Configure the OpenTelemetry Collector 3. Build and run - 1. Install and configure collectd ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -52,8 +51,8 @@ In this example, the host is represented by an Ubuntu 24.04 docker image. depends_on: - otelcollector volumes: - - ./collectd/http.conf:/etc/collectd/collectd.conf.d/http.conf - - ./collectd/metrics.conf:/etc/collectd/collectd.conf.d/metrics.conf + - ./collectd/http.conf:/etc/collectd/collectd.conf.d/http.conf + - ./collectd/metrics.conf:/etc/collectd/collectd.conf.d/metrics.conf # OpenTelemetry Collector otelcollector: @@ -63,7 +62,33 @@ In this example, the host is represented by an Ubuntu 24.04 docker image. volumes: - ./otel-collector-config.yml:/etc/otel-collector-config.yml -2. Configure the OpenTelemetry Collector +The http and metrics configuration files look like this: + +.. code:: yaml + + # http.conf + # The minimal configuration required to have collectd send data to an OpenTelemetry Collector + # with a collectdreceiver deployed on port 8081. + LoadPlugin write_http + + + URL "http://otelcollector:8081" + Format JSON + VerifyPeer false + VerifyHost false + + + + # metrics.conf + # An example of collectd plugin configuration reporting free disk space on the host. + + Interval 3600 + + + ValuesPercentage true + + +1. Configure the OpenTelemetry Collector ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Set up your Collector instance to listen for traffic from the collectd daemon over HTTP with the :ref:`collectd-receiver`: From 690743f34b42c14f7084a788bbf0f496161b03fd Mon Sep 17 00:00:00 2001 From: Anna Urbiztondo Date: Tue, 7 Jan 2025 12:35:46 +0100 Subject: [PATCH 18/19] Edits --- gdi/opentelemetry/otel-other/other-ingestion-collectd.rst | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/gdi/opentelemetry/otel-other/other-ingestion-collectd.rst b/gdi/opentelemetry/otel-other/other-ingestion-collectd.rst index ca65bc5c2..c71039277 100644 --- a/gdi/opentelemetry/otel-other/other-ingestion-collectd.rst +++ b/gdi/opentelemetry/otel-other/other-ingestion-collectd.rst @@ -69,6 +69,7 @@ The http and metrics configuration files look like this: # http.conf # The minimal configuration required to have collectd send data to an OpenTelemetry Collector # with a collectdreceiver deployed on port 8081. + LoadPlugin write_http @@ -79,8 +80,11 @@ The http and metrics configuration files look like this: +.. code:: yaml + # metrics.conf # An example of collectd plugin configuration reporting free disk space on the host. + Interval 3600 From aeb7b4dfa80d9181035fd5a924563c992605f633 Mon Sep 17 00:00:00 2001 From: ada Date: Tue, 7 Jan 2025 12:03:18 -0800 Subject: [PATCH 19/19] Replace uppercase env variable names with lowercase --- synthetics/test-config/private-locations.rst | 36 +++++++++----------- 1 file changed, 17 insertions(+), 19 deletions(-) diff --git a/synthetics/test-config/private-locations.rst b/synthetics/test-config/private-locations.rst index 82735b0b9..9a8479995 100644 --- a/synthetics/test-config/private-locations.rst +++ b/synthetics/test-config/private-locations.rst @@ -141,59 +141,57 @@ For example, here is what a command might look like after you modify it to fit y -Configuring proxy settings for a private location +Configure proxy settings for a private location =================================================== In environments where direct internet access is restricted, you can route synthetic test traffic through a proxy server by configuring the following environment variables: -* ``HTTP_PROXY``: Specifies the proxy server for HTTP traffic. +* ``http_proxy``: Specifies the proxy server for HTTP traffic. - * Example: ``export HTTP_PROXY="\http://proxy.example.com:8080"`` + * Example: ``export http_proxy="http://proxy.example.com:8443"`` -* ``HTTPS_PROXY``: Specifies the proxy server for HTTPS traffic. +* ``https_proxy``: Specifies the proxy server for HTTPS traffic. - * Example: ``export HTTPS_PROXY="\https://proxy.example.com:8443"`` + * Example: ``export https_proxy="http://proxy.example.com:8443"`` -* ``NO_PROXY``: Specifies a comma-separated list of domains or IP addresses that should bypass the proxy. +* ``no_proxy``: Specifies a comma-separated list of domains or IP addresses that should bypass the proxy. - * Example: ``export NO_PROXY="localhost,127.0.0.1,.internal-domain.com"`` + * Example: ``export no_proxy="localhost,127.0.0.1,.internal-domain.com"`` For example, here is what a command might look like after you modify it to fit your environment: .. code:: yaml - docker run --cap-add NET_ADMIN -e "RUNNER_TOKEN=*****" quay.io/signalfx/splunk-synthetics-runner:latest -e NO_PROXY=".signalfx.com,.amazonaws.com" -e HTTPS_PROXY="https://172.17.0.1:1234" -e HTTP_PROXY="http://172.17.0.1:1234" + docker run --cap-add NET_ADMIN -e "RUNNER_TOKEN=*****" -e "no_proxy=.signalfx.com,.amazonaws.com,127.0.0.1,localhost" -e "https_proxy=http://172.17.0.1:1234" -e "http_proxy=http://172.17.0.1:1234" quay.io/signalfx/splunk-synthetics-runner:latest + In this example: -``HTTP_PROXY`` and ``HTTPS_PROXY`` are set to route traffic through a proxy at ``http://172.17.0.1:1234``. +``http_proxy`` and ``https_proxy`` are set to route traffic through a proxy at ``http://172.17.0.1:1234``. -``NO_PROXY`` is configured to bypass the proxy for local addresses and specific domains like .signalfx.com and .amazonaws.com. +``no_proxy`` is configured to bypass the proxy for local addresses and specific domains like .signalfx.com and .amazonaws.com. Ensure that these variables are correctly configured to comply with your network policies. This setup allows the synthetic tests to communicate securely and efficiently in a controlled network environment. -When using runner, it's important to correctly configure the proxy settings to avoid issues with browser-based tests. The following steps should be followed when setting up their environment: +When using a private runner, it's important to correctly configure the proxy settings to avoid issues with browser-based tests. The following steps should be followed when setting up their environment: -1. :strong:`Ensure proper NO_PROXY setup`: +1. :strong:`Ensure proper no_proxy setup`: - - When configuring ``NO_PROXY`` always include the following addresses: + - When configuring ``no_proxy`` always include the following addresses: - ``127.0.0.1`` (for localhost communication) - ``localhost`` (for resolving local tests) These addresses ensure that internal services and tests run correctly without routing through a proxy, preventing potential failures. -2. :strong:`Merging HTTP_PROXY and http_proxy`: - - - The system automatically handles both ``HTTP_PROXY`` and ``http_proxy`` environment variables. If you define one of these, ensure the other is also set, or they will be automatically merged at start-up. - 3. :strong:`Dockerfile defaults`: - - By default, the runner will set the ``NO_PROXY`` variable in the Dockerfile to include ``127.0.0.1``. If you override ``NO_PROXY``, you must ensure that ``127.0.0.1`` and ``localhost`` are still present, or browser tests may fail. - + - By default, the private runner sets the ``no_proxy`` variable in the Dockerfile to include ``127.0.0.1``. If you override ``no_proxy``, you must ensure that ``127.0.0.1`` and ``localhost`` are still present, or browser tests may fail. +.. note:: + Lower case variable names take precedence and are best practice. Assess the health of a private location