Skip to content

Commit cec7d8d

Browse files
bhillmerbhillmer
authored
Merge pull request splunk#1640 from splunk/repo-sync
Pulling refs/heads/main into main
2 parents e4e2871 + 8ed6a48 commit cec7d8d

File tree

6 files changed

+239
-64
lines changed

6 files changed

+239
-64
lines changed

‎gdi/opentelemetry/otel-other/otel-other-landing.rst‎

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -14,8 +14,10 @@ Other OpenTelemetry ingestion methods
1414

1515
prometheus-generic
1616
telegraf
17+
other-ingestion-collectd
1718

1819
On top of the available native :ref:`OpenTelemetry receivers <otel-components-receivers>`, you can also send data to Splunk Observability Cloud with OpenTelemetry with the following options:
1920

2021
* :ref:`prometheus-generic`
21-
* :ref:`telegraf-generic`
22+
* :ref:`telegraf-generic`
23+
* :ref:`other-ingestion-collectd`

‎gdi/opentelemetry/otel-other/other-ingestion-collectd.rst‎

Lines changed: 171 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,171 @@
1+
.. _other-ingestion-collectd:
2+
3+
Monitor hosts with collectd and OpenTelemetry
4+
=====================================================================
5+
6+
.. meta::
7+
:description: Use collectd and native OpenTelemetry to monitor services in Splunk Observability Cloud. See benefits, install, configuration, and metrics.
8+
9+
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.
10+
11+
Benefits
12+
--------
13+
14+
.. raw:: html
15+
16+
<div class="include-start" id="benefits.rst"></div>
17+
18+
.. include:: /_includes/benefits.rst
19+
20+
.. raw:: html
21+
22+
<div class="include-stop" id="benefits.rst"></div>
23+
24+
25+
Configuration
26+
----------------------------------
27+
28+
Install a collectd daemon in your host and connect it to an OpenTelemetry Collector with the following steps:
29+
30+
1. Install and configure collectd
31+
2. Configure the OpenTelemetry Collector
32+
3. Build and run
33+
34+
1. Install and configure collectd
35+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
36+
37+
Follow these steps to install and configure the collectd daemon:
38+
39+
#. Install collectd as a Debian or Yum package in your host
40+
#. Configure the daemon to ingest free disk related metrics through `collectd/metrics.conf`
41+
#. Configure the daemon to send data over HTTP using `collectd/http.conf`
42+
43+
In this example, the host is represented by an Ubuntu 24.04 docker image.
44+
45+
.. code::
46+
47+
services:
48+
collectd:
49+
build: collectd
50+
container_name: collectd
51+
depends_on:
52+
- otelcollector
53+
volumes:
54+
- ./collectd/http.conf:/etc/collectd/collectd.conf.d/http.conf
55+
- ./collectd/metrics.conf:/etc/collectd/collectd.conf.d/metrics.conf
56+
57+
# OpenTelemetry Collector
58+
otelcollector:
59+
image: quay.io/signalfx/splunk-otel-collector:latest
60+
container_name: otelcollector
61+
command: ["--config=/etc/otel-collector-config.yml", "--set=service.telemetry.logs.level=debug"]
62+
volumes:
63+
- ./otel-collector-config.yml:/etc/otel-collector-config.yml
64+
65+
The http and metrics configuration files look like this:
66+
67+
.. code:: yaml
68+
69+
# http.conf
70+
# The minimal configuration required to have collectd send data to an OpenTelemetry Collector
71+
# with a collectdreceiver deployed on port 8081.
72+
73+
LoadPlugin write_http
74+
<Plugin "write_http">
75+
<Node "collector">
76+
URL "http://otelcollector:8081"
77+
Format JSON
78+
VerifyPeer false
79+
VerifyHost false
80+
</Node>
81+
</Plugin>
82+
83+
.. code:: yaml
84+
85+
# metrics.conf
86+
# An example of collectd plugin configuration reporting free disk space on the host.
87+
88+
<LoadPlugin df>
89+
Interval 3600
90+
</LoadPlugin>
91+
<Plugin df>
92+
ValuesPercentage true
93+
</Plugin>
94+
95+
1. Configure the OpenTelemetry Collector
96+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
97+
98+
Set up your Collector instance to listen for traffic from the collectd daemon over HTTP with the :ref:`collectd-receiver`:
99+
100+
.. code:: yaml
101+
102+
receivers:
103+
collectd:
104+
endpoint: "0.0.0.0:8081"
105+
106+
exporters:
107+
debug:
108+
verbosity: detailed
109+
110+
service:
111+
pipelines:
112+
metrics:
113+
receivers: [collectd]
114+
exporters: [debug]
115+
116+
.. 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.
117+
118+
3. Build and run
119+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
120+
121+
Run the example with the instruction to start the docker-compose setup and build the collectd container:
122+
123+
.. code:: bash
124+
125+
$> docker compose up --build
126+
127+
Check that the Collector is receiving metrics and logging them to ``stdout`` via the debug exporter:
128+
129+
.. code:: bash
130+
131+
$> docker logs otelcollector
132+
133+
A typical output is:
134+
135+
.. code::
136+
137+
StartTimestamp: 1970-01-01 00:00:00 +0000 UTC
138+
Timestamp: 2024-12-20 19:55:44.006000128 +0000 UTC
139+
Value: 38.976566
140+
Metric #17
141+
Descriptor:
142+
-> Name: percent_bytes.reserved
143+
-> Description:
144+
-> Unit:
145+
-> DataType: Gauge
146+
NumberDataPoints #0
147+
Data point attributes:
148+
-> plugin: Str(df)
149+
-> plugin_instance: Str(etc-hosts)
150+
-> host: Str(ea1d62c7a229)
151+
-> dsname: Str(value)
152+
StartTimestamp: 1970-01-01 00:00:00 +0000 UTC
153+
Timestamp: 2024-12-20 19:55:44.006000128 +0000 UTC
154+
Value: 5.102245
155+
{"kind": "exporter", "data_type": "metrics", "name": "debug"}
156+
157+
Troubleshooting
158+
---------------
159+
160+
.. raw:: html
161+
162+
<div class="include-start" id="troubleshooting-components.rst"></div>
163+
164+
.. include:: /_includes/troubleshooting-components.rst
165+
166+
.. raw:: html
167+
168+
<div class="include-stop" id="troubleshooting-components.rst"></div>
169+
170+
171+

‎gdi/opentelemetry/otel-other/telegraf.rst‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,7 @@ Monitor services with Telegraf Input plugins and OpenTelemetry
55
=====================================================================
66

77
.. meta::
8-
:description: Use this Splunk Observability Cloud integration for the Telegraf monitor. See benefits, install, configuration, and metrics.
8+
:description: Use Telegraf and OpenTelemetry to monitor your services in Splunk Observability Cloud. See benefits, install, configuration, and metrics.
99

1010
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.
1111

@@ -39,7 +39,7 @@ Follow these steps to scrape Telegraf metrics with the OTel Collector:
3939
3. Set up the Telegraf OpenTelemetry Output plugin
4040
4. Configure the OpenTelemetry Collector
4141

42-
1. Install Telegraf
42+
5. Install Telegraf
4343
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4444

4545
Run the following commands to install Telegraf from the InfluxData repository:

‎sp-oncall/spoc-integrations/sensu-integration.rst‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -138,5 +138,5 @@ Splunk On-Call Handler
138138
end
139139
end
140140
141-
For more information, see :new-page:`Sensu documentation on Handlers <https://sensuapp.org/docs/0.29/reference/handlers.html#handler-definition-specification>`.
141+
For more information, see search "handlers" on the Sensu documentation website.
142142

‎synthetics/key-concepts.rst‎

Lines changed: 24 additions & 22 deletions
Original file line numberDiff line numberDiff line change
@@ -22,43 +22,45 @@ These key concepts help you get the most out of your experience with Splunk Synt
2222
* - Synthetics
2323
- A common abbreviation for Synthetic Monitoring.
2424

25-
* - Tests
26-
- 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.
25+
* - Test
26+
- 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.
2727

28-
* - Runs
29-
- 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.
28+
* - Run
29+
- An instance of a test invocation from a specific device and location and at a specific time.
3030

31-
* - Metrics
32-
- | 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:
31+
* - Metric
32+
- 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:
3333
|
3434
| - :ref:`browser-metrics`
3535
| - :ref:`uptime-metrics`
3636
| - :ref:`api-test-metrics`
3737
|
3838
39-
* - Browser tests
40-
- Synthetic tests that simulate and analyze the user experience of loading a page or performing a workflow on a site or application.
39+
* - Browser test
40+
- A synthetic test that simulates and analyzes the user experience of loading a page or performing a workflow on a site or application.
4141

42-
* - Uptime tests
43-
- Synthetic tests that monitor the response time and response code of HTTP requests and server ports.
42+
* - Uptime test
43+
- A synthetic test that monitors the response times and response codes of HTTP requests and server ports.
4444

45-
* - API tests
46-
- Synthetic tests that monitor the functionality and performance of API endpoints.
45+
* - API test
46+
- A synthetic test that monitors the functionality and performance of API endpoints.
4747

48-
* - Waterfall charts
49-
- A visualization that represents the performance of resources on a webpage in a Browser test.
48+
* - Waterfall chart
49+
- A visualization that represents the performance of resources on a webpage in a browser test.
5050

51-
* - Devices
52-
- 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.
51+
* - Device
52+
- A predefined combination of a specific viewport size and network connection. For more information about devices, viewports, and network connections, see :ref:`devices`.
5353

54-
* - Viewport
55-
- 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.
54+
* - Public location
55+
- A public IP address from which you can run synthetic tests to simulate performance for users in that location. See :ref:`public-locations`.
56+
57+
* - Private location
58+
- 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 <public-locations>`. See :ref:`private-locations`.
59+
60+
* - Private runner
61+
- 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`.
5662

57-
* - Network connection
58-
- 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.
5963

60-
* - Public Locations
61-
- Global checkpoints from which you can synthetically run tests to simulate performance for users in that location.
6264

6365
Learn more
6466
===========

0 commit comments

Comments
 (0)