diff --git a/_images/apm/spans-traces/service-map-updated-view.png b/_images/apm/spans-traces/service-map-updated-view.png new file mode 100644 index 000000000..74d932615 Binary files /dev/null and b/_images/apm/spans-traces/service-map-updated-view.png differ diff --git a/_images/apm/spans-traces/service-view-errors.png b/_images/apm/spans-traces/service-view-errors.png new file mode 100644 index 000000000..ba3b69365 Binary files /dev/null and b/_images/apm/spans-traces/service-view-errors.png differ diff --git a/_images/logs/indexSelection.png b/_images/logs/indexSelection.png new file mode 100644 index 000000000..998147ed8 Binary files /dev/null and b/_images/logs/indexSelection.png differ diff --git a/_images/synthetics/synthetics-browser-test-excluded-files.png b/_images/synthetics/synthetics-browser-test-excluded-files.png new file mode 100644 index 000000000..8b4d06c0b Binary files /dev/null and b/_images/synthetics/synthetics-browser-test-excluded-files.png differ diff --git a/_includes/logs/query-logs.rst b/_includes/logs/query-logs.rst index 603fb6db3..89365dcab 100644 --- a/_includes/logs/query-logs.rst +++ b/_includes/logs/query-logs.rst @@ -8,7 +8,13 @@ 2. In the content control bar, enter a time range in the time picker if you want to see logs from a specific historical period. To select a time range, you must select :guilabel:`Unlimited` from the :guilabel:`Search Records` field in step 5 below. When you select :guilabel:`150,000`, Log Observer returns only the most recent 150,000 logs regardless of the time range you select. -3. Select :guilabel:`Index` next to :guilabel:`Saved Queries`, then select the indexes you want to query. When you do not select an index, Log Observer runs your query on all indexes to which you have access. If you want to search your Splunk platform (Splunk Cloud Platform or Splunk Enterprise) data, select the integration for the appropriate Splunk platform instance first, then select which index you want to query in Log Observer. You can query indexes from only one Splunk platform instance or Splunk Observability Cloud instance at a time. You can query Splunk platform indexes only if you have the appropriate role and permissions. +3. Select :guilabel:`Index` next to :guilabel:`Saved Queries`. In the pop-up window, first select a Splunk platform (Splunk Cloud Platform or Splunk Enterprise) connection in the :guilabel:`Connection selection` section. Then, in the :guilabel:`Index selection` section, select which index you want to query in Log Observer Connect. + + .. image:: /_images/logs/indexSelection.png + :width: 90% + :alt: The Log Observer index selection pop-up is displayed. + +.. note:: You can query indexes from only one Splunk platform instance at a time. You can query Splunk platform indexes only if you have the appropriate role and permissions in Splunk platform. 4. In the content control bar next to the index picker, select :guilabel:`Add Filter`. Select the :guilabel:`Keyword` tab to search on a keyword or phrase. Select the :guilabel:`Fields` tab to search on a field. Then press Enter. To continue adding keywords or fields to the search, select :guilabel:`Add Filter` again. @@ -18,9 +24,11 @@ 7. Select :guilabel:`Run search`. -8. Review the top values for your query on the the :guilabel:`Fields` panel on right. This list includes the count of each value in the log records. To include log records with a particular value, select the field name, then select ``=``. To exclude log records with a particular value from your results, select the field name, then select ``!=``. To see the full list of values and distribution for this field, select :guilabel:`Explore all values`. +8. [Optional] If you want to stop the current search, select :guilabel:`Cancel search`. Partial results do not display. To continue your search, select :guilabel:`Run search` again. + +9. Review the top values for your query on the the :guilabel:`Fields` panel on right. This list includes the count of each value in the log records. To include log records with a particular value, select the field name, then select ``=``. To exclude log records with a particular value from your results, select the field name, then select ``!=``. To see the full list of values and distribution for this field, select :guilabel:`Explore all values`. -9. Optionally, if you are viewing Splunk platform data, you can open your query results in the Splunk platform and use SPL to further query the resulting logs. You must have an account in Splunk platform. To open the log results in the Splunk platform, select the :guilabel:`Open in Splunk platform` icon at the top of the Logs table. +10. [Optional] If you are viewing Splunk platform data, you can open your query results in the Splunk platform and use SPL to further query the resulting logs. You must have an account in Splunk platform. To open the log results in the Splunk platform, select the :guilabel:`Open in Splunk platform` icon at the top of the Logs table. .. image:: /_images/logs/lo-openinsplunk.png :width: 90% diff --git a/admin/authentication/SSO/sso.rst b/admin/authentication/SSO/sso.rst index 10e02e8f8..1c82f70c9 100644 --- a/admin/authentication/SSO/sso.rst +++ b/admin/authentication/SSO/sso.rst @@ -75,6 +75,24 @@ Give your login service integration a name that your users recognize. On your cu this name appears in the button your users select to sign in. For example, use the name "Log in with Okta" for an Okta login service integration. +.. _default-sso-role: + +.. raw:: html + + +

Set up default SSO role

+ + + +When you set up SSO, the default role for a user signing in to Splunk Observability Cloud through SSO is the :guilabel:`power` role. You can change the default SSO role to any of the available roles in Splunk Observability Cloud. + +To change the default SSO role, do the following: + +1. Go to :guilabel:`Settings` then select :guilabel:`General Settings`. + +2. In the :guilabel:`User Management` section, set a default role for SSO login by selecting a role from the drop-down list. The drop-down list defaults to the :guilabel:`power` role. The role you select becomes the role of any new user logging in through an SSO service. You can return to :guilabel:`General Settings` and update the default role for SSO login at any time. + + .. _multiple-integrations-sso: .. raw:: html diff --git a/apm/apm-spans-traces/service-map.rst b/apm/apm-spans-traces/service-map.rst index c05f6f0d1..3d35139ad 100644 --- a/apm/apm-spans-traces/service-map.rst +++ b/apm/apm-spans-traces/service-map.rst @@ -15,7 +15,7 @@ See :ref:`apm-inferred-services` to learn more about inferred services in APM. The following screenshot shows an example service map: -.. image:: /_images/apm/spans-traces/service-map-global-search-rename.png +.. image:: /_images/apm/spans-traces/service-map-updated-view.png :width: 95% :alt: An example of the service map in Splunk APM Service Map. @@ -28,6 +28,8 @@ Use these steps to access the service map in Splunk APM: #. Log into Splunk Observability Cloud. #. Select :guilabel:`APM` in the navigation bar. #. Select :guilabel:`Service Map` on the APM landing page. The service map view opens, with the service map in the center. +#. (Optional) Select :guilabel:`Switch to Classic Service Map` to switch to the lateral service map layout. The default constellation view displays a larger view of your environment and helps you quickly assess service performance. + Using the service map, you can do the following: @@ -86,15 +88,6 @@ When configured, you can select tiles in the Related Content bar to seamlessly n .. image:: /_images/apm/spans-traces/service-map-related-content-global-search-rename.gif :alt: Using Related Content in Splunk Observability Cloud. -Configure and view global data links for your service map -========================================================== - -You can configure global data links to link Splunk APM properties, such as services, traces, spans, and span tags, to relevant resources. For example, you can link APM properties to Infrastructure Monitoring navigators and dashboards, Splunk instances, Kibana logs, Splunk AppDynamics tiers, or custom URLs. - -For information on how to configure data links to display in your service map, see :ref:`apm-create-data-links`. You can also create a global data link directly from the APM :guilabel:`Service Map` by selecting an inferred service, selecting the :guilabel:`(⋯)` menu next to the inferred service name, and selecting :guilabel:`Configure data links`. - -For information on how to view data links in your service map, see :ref:`apm-use-data-links`. - Share your view of the service map ====================================== To share your view of the service map with a colleague, copy and share the URL. Your current filter selections are preserved in the URL. diff --git a/apm/apm-spans-traces/service-view.rst b/apm/apm-spans-traces/service-view.rst index 2a9ad6a41..7c25d284b 100644 --- a/apm/apm-spans-traces/service-view.rst +++ b/apm/apm-spans-traces/service-view.rst @@ -29,7 +29,7 @@ You can also access the service view for a specific service within the service m Finally, you can also access the service view for a specific service by selecting the service from the APM landing page. -Use the service overview to monitor the health of your service +Use the service view to monitor the health of your service ===================================================================== When you open the service view an environment is selected based on your recently viewed environments. Adjust the environment and time range filters if necessary. Use the following sections to monitor the health of your service. @@ -54,6 +54,18 @@ Use the following metrics in the :guilabel:`Service metrics` section to monitor * Inferred services - un-instrumented third-party services * Pub/sub queues - Publisher/subscriber queues +Error breakdown +----------------- + +Use the following section to troubleshoot service errors and view relevant traces for specific error types. Select a point on the graph to view example traces for a particular data point, or select any value to hide the time series for that value. + +.. image:: /_images/apm/spans-traces/service-view-errors.png + :width: 95% + :alt: Screenshot of charts on the service view page that display service errors. + +* Errors by exception type - Displays errors with the span attribute ``exception.type``. Select a data point on the chart to view related traces and alert details for that time period. +* Errors by status code - Displays errors based on the HTTP or gRPC error status code. Select a data point on the chart to view related traces and alert details for that selected time period and error. For more information about error status codes, see :new-page:`Semantic Conventions for HTTP Spans `. + Runtime metrics ----------------- @@ -82,6 +94,13 @@ View Tag Spotlight view for your service Select :guilabel:`Tag Spotlight` to view Tag Spotlight view filtered for your service. See :ref:`apm-tag-spotlight` to learn more about Tag Spotlight. +View errors for your service +==================================================== + +Select the :guilabel:`Errors` tab to visualize errors for your service. Select a specific error type to view available traces for that error, and troubleshoot by viewing details such as the ``exception.message`` or ``exception.stacktrace``. + +Administrators can pause these metrics by going to the :guilabel:`Sources of Errors MetricSets` section on the :guilabel:`APM MetricSets` page and selecting :guilabel:`Pause Indexing`. These metrics are turned on by default. + View endpoints for your service ================================= diff --git a/apm/profiling/intro-profiling.rst b/apm/profiling/intro-profiling.rst index 87e6745fe..fcbdd7a82 100644 --- a/apm/profiling/intro-profiling.rst +++ b/apm/profiling/intro-profiling.rst @@ -94,10 +94,7 @@ The following programming languages have instrumentation available: * :ref:`profiling-configuration-otel-dotnet` * - .NET (SignalFx) - SignalFx Instrumentation for .NET version 1.0.0 or higher - - .NET versions 6.0 and higher are supported in AlwaysOn Profiling. .NET Framework is not supported. - - * :ref:`instrument-dotnet-applications` - * :ref:`profiling-configuration-dotnet` + - .NET versions 6.0 and higher are supported in AlwaysOn Profiling. .NET Framework is not supported. * - Python (in beta) - Splunk Distribution of OpenTelemetry Python version 1.15 or higher diff --git a/apm/set-up-apm/troubleshoot-apm.rst b/apm/set-up-apm/troubleshoot-apm.rst index bcdcb5573..0aea8786b 100644 --- a/apm/set-up-apm/troubleshoot-apm.rst +++ b/apm/set-up-apm/troubleshoot-apm.rst @@ -14,7 +14,6 @@ If you have instrumented an application but are not seeing the relevant data in - :ref:`common-java-troubleshooting` - :ref:`common-python-troubleshooting` - :ref:`common-nodejs-troubleshooting` -- :ref:`common-dotnet-troubleshooting` - :ref:`common-go-troubleshooting` If the preceding steps don't help you resolve your instrumentation issues, contact :ref:`support`. diff --git a/apm/span-tags/tag-spotlight.rst b/apm/span-tags/tag-spotlight.rst index 34e9caae3..dbbfe8e64 100644 --- a/apm/span-tags/tag-spotlight.rst +++ b/apm/span-tags/tag-spotlight.rst @@ -25,7 +25,7 @@ To view service performance broken down by your indexed span tags, follow these * Select the :guilabel:`Tag Spotlight` panel on the APM landing page or in the service map. * Select the :guilabel:`Tag Spotlight` tab in the service view for your service. * Use the search in the top toolbar to search for Tag Spotlight and select the navigation result to go to Tag Spotlight. -#. Add time range, environment, workflow, service, operation, and tag filters as need to refine the data in your Tag Spotlight view. The default time range is for the last 15 minutes, and the data resolution is 10 seconds. +#. Add time range, environment, workflow, service, endpoint, operation, and tag filters as need to refine the data in your Tag Spotlight view. The default time range is for the last 15 minutes, and the data resolution is 10 seconds. #. Use the request and errors and latency time-series charts at the top to see a distribution of your RED metrics. #. Use the bar charts under the request and errors and latency time-series charts to view RED metrics for each indexed span tag. #. View the distribution of all indexed span tags. The tag bar charts display either request and error distributions or latency distribution. Use the :guilabel:`Cards display` menu to select the data you want to display in the bars. diff --git a/gdi/get-data-in/application/otel-dotnet/get-started.rst b/gdi/get-data-in/application/otel-dotnet/get-started.rst index 48276fe39..e58e6f3b3 100644 --- a/gdi/get-data-in/application/otel-dotnet/get-started.rst +++ b/gdi/get-data-in/application/otel-dotnet/get-started.rst @@ -21,7 +21,6 @@ Instrument .NET applications for Splunk Observability Cloud (OpenTelemetry) Manual instrumentation Performance overhead Troubleshoot the .NET instrumentation - SignalFx Instrumentation for .NET (Deprecated) TOGGLE Migrate from SignalFx Instrumentation for .NET The Splunk Distribution of OpenTelemetry .NET provides zero-code instrumentation for popular .NET libraries and frameworks to collect and send telemetry to Splunk Observability Cloud. diff --git a/gdi/get-data-in/application/otel-dotnet/instrumentation/instrument-dotnet-application.rst b/gdi/get-data-in/application/otel-dotnet/instrumentation/instrument-dotnet-application.rst index c6d78f7f4..dd599c5c1 100644 --- a/gdi/get-data-in/application/otel-dotnet/instrumentation/instrument-dotnet-application.rst +++ b/gdi/get-data-in/application/otel-dotnet/instrumentation/instrument-dotnet-application.rst @@ -180,8 +180,6 @@ Windows #. Check that you meet the requirements. See :ref:`dotnet-otel-requirements`. -#. (Optional) If needed, uninstall the SignalFx Instrumentation for .NET. See :ref:`uninstall-dotnet-sfx`. - #. Download and install the Splunk Distribution of OpenTelemetry .NET from the :new-page:`Releases page on GitHub `. For example: .. code-block:: powershell @@ -305,8 +303,6 @@ Linux #. Check that you meet the requirements. See :ref:`dotnet-otel-requirements`. -#. (Optional) If needed, uninstall the SignalFx Instrumentation for .NET. See :ref:`uninstall-dotnet-sfx`. - #. Download and install the installation script of the Splunk Distribution of OpenTelemetry .NET from the :new-page:`Releases page on GitHub `. For example: .. code-block:: shell diff --git a/gdi/get-data-in/application/otel-dotnet/sfx/configuration/advanced-dotnet-configuration.rst b/gdi/get-data-in/application/otel-dotnet/sfx/configuration/advanced-dotnet-configuration.rst deleted file mode 100644 index 0493a421e..000000000 --- a/gdi/get-data-in/application/otel-dotnet/sfx/configuration/advanced-dotnet-configuration.rst +++ /dev/null @@ -1,323 +0,0 @@ -.. caution:: - - The SignalFx Instrumentation for .NET reached End of Support on February 21, 2025. The library has been archived and is no longer maintained. - - New customers instrumenting the .NET ecosystem should use the :ref:`Splunk Distribution of OpenTelemetry .NET `. Existing customers should consider migrating to Splunk Distribution of OpenTelemetry .NET which offers similar capabilities. To learn how to migrate, see :ref:`migrate-signalfx-dotnet-to-dotnet-otel`. - -.. _advanced-dotnet-configuration: - -******************************************************************** -Configure the SignalFx Instrumentation for .NET -******************************************************************** - -.. meta:: - :description: Configure the SignalFx Instrumentation for .NET to suit your instrumentation needs, such as correlating traces with logs and activating custom sampling. - -You can configure the SignalFx Instrumentation for .NET to suit your instrumentation needs. In most cases, modifying the basic configuration is enough to get started. More advanced settings are also available. - -.. _configuration-methods-dotnet: - -Configuration methods -=========================================================== - -You can change the settings of the SignalFx Instrumentation for .NET in the following ways: - -#. Set environment variables. On Windows, set them in the process scope unless you want to activate autoinstrumentation globally for all .NET applications. - -#. Edit the web.config or app.config file. For example: - - .. code-block:: xml - - - - - - - -#. Generate a JSON configuration file and set the ``SIGNALFX_TRACE_CONFIG_FILE`` environment variable to the path of the file. You can define settings as key-value pairs: - - .. code-block:: json - - { - "SIGNALFX_SERVICE_NAME": "my-service-name" - } - -.. note:: Settings defined using environment variables override settings in XML and JSON configuration files. - -.. _main-dotnet-agent-settings: - -General settings -========================================================================= - -The following settings are common to most instrumentation scenarios: - -.. list-table:: - :header-rows: 1 - :width: 100% - :widths: 40 60 - - * - Setting - - Description - * - ``SIGNALFX_ENV`` - - The value for the ``deployment.environment`` tag added to all spans. - * - ``SIGNALFX_SERVICE_NAME`` - - The name of the application or service. If not set, the instrumentation looks for a suitable default name. See :ref:`dotnet-default-service-name`. - * - ``SIGNALFX_VERSION`` - - The version of the application. When set, it adds the ``version`` tag to all spans. - * - ``SIGNALFX_PROFILER_PROCESSES`` - - Names of the executable files that the profiler can instrument. Supports multiple semicolon-separated values, for example: ``MyApp.exe;dotnet.exe``. - * - ``SIGNALFX_PROFILER_EXCLUDE_PROCESSES`` - - Names of the executable files that the profiler cannot instrument. Supports multiple semicolon-separated values, for example: ``ReservedProcess.exe;powershell.exe``. - * - ``SIGNALFX_TRACE_CONFIG_FILE`` - - Path of the JSON configuration file. Set this environment variable if you're configuring the instrumentation using a JSON file. See :ref:`configuration-methods-dotnet` for more information. - * - ``SIGNALFX_TRACE_ENABLED`` - - Set to ``false`` to deactivate the tracer. The default value is ``true``. - * - ``SIGNALFX_AZURE_APP_SERVICES`` - - Set to ``true`` to indicate that the profiler is running in the context of Azure App Services. The default value is ``false``. - * - ``SIGNALFX_DOTNET_TRACER_HOME`` - - Location of the installed instrumentation. Must be set manually to ``/opt/signalfx`` when instrumenting applications on Linux or background services in Azure App Service. By default, the Windows installer automatically uses the ``C:\Program Files\SignalFx\.NET Tracing`` directory. - -.. _dotnet-exporter-settings: - -Exporter settings -================================================ - -The following settings control trace exporters and their endpoints: - -.. list-table:: - :header-rows: 1 - :width: 100% - :widths: 40 60 - - * - Setting - - Description - * - ``SIGNALFX_ACCESS_TOKEN`` - - Splunk Observability Cloud access token for your organization. The token activates sending traces directly to the Splunk Observability Cloud ingest endpoint. To obtain an access token, see :ref:`admin-api-access-tokens`. - * - ``SIGNALFX_REALM`` - - The name of your organization's realm, for example, ``us0``. When you set the realm, metrics are sent to ``https://ingest..signalfx.com/v2/datapoint`` and traces are sent to ``https://ingest..signalfx.com/v2/trace``. - * - ``SIGNALFX_ENDPOINT_URL`` - - The URL to where the trace exporter sends traces. The default value is ``http://localhost:9411/api/v2/spans``. Setting a value overrides the ``SIGNALFX_REALM`` environment variable. - * - ``SIGNALFX_METRICS_ENDPOINT_URL`` - - The URL to where the metrics exporter sends metrics. The default value is ``http://localhost:9943/v2/datapoint``. Setting a value overrides the ``SIGNALFX_REALM`` environment variable. - * - ``SIGNALFX_TRACE_PARTIAL_FLUSH_ENABLED`` - - Activate to export traces that contain a minimum number of closed spans, as defined by ``SIGNALFX_TRACE_PARTIAL_FLUSH_MIN_SPANS``. The default value is ``false``. - * - ``SIGNALFX_TRACE_PARTIAL_FLUSH_MIN_SPANS`` - - Minimum number of closed spans in a trace before it's exported. The default value is ``500``. Requires the value of the ``SIGNALFX_TRACE_PARTIAL_FLUSH_ENABLED`` environment variable to be ``true``. - -.. _dotnet-trace-propagation-settings: - -Trace propagation settings -================================================ - -The following settings control trace propagation: - -.. list-table:: - :header-rows: 1 - :width: 100% - :widths: 40 60 - - * - Setting - - Description - * - ``SIGNALFX_PROPAGATORS`` - - Comma-separated list of propagators for the tracer. The available propagators are ``B3`` and ``W3C``, which correspond to the ``b3multi`` and ``tracecontext`` propagators in the OpenTelemetry SDK. The default value is ``B3,W3C``. - -.. _profiling-configuration-dotnet: - -.NET settings for AlwaysOn Profiling -=============================================== - -The following settings control the AlwaysOn Profiling feature for the .NET instrumentation: - -.. list-table:: - :header-rows: 1 - :width: 100% - :widths: 40 60 - - * - Environment variable - - Description - * - ``SIGNALFX_PROFILER_ENABLED`` - - Activates AlwaysOn Profiling. The default value is ``false``. - * - ``SIGNALFX_PROFILER_MEMORY_ENABLED`` - - Activates memory profiling. The default value is ``false``. - * - ``SIGNALFX_PROFILER_LOGS_ENDPOINT`` - - The collector endpoint for profiler logs. The default value is ``http://localhost:4318/v1/logs``. - * - ``SIGNALFX_PROFILER_CALL_STACK_INTERVAL`` - - Frequency with which call stacks are sampled, in milliseconds. The default value is ``10000`` milliseconds. - -.. note:: For more information on AlwaysOn Profiling, see :ref:`profiling-intro`. - -.. _dotnet-metric-settings: - -Metrics settings -================================================ - -The following settings control metric collection: - -.. list-table:: - :header-rows: 1 - :width: 100% - :widths: 40 60 - - * - Setting - - Description - * - ``SIGNALFX_METRICS_{0}_ENABLED`` - - Configuration pattern for activating or deactivating a specific metrics group. For example, to activate ``NetRuntime`` metrics, set ``SIGNALFX_METRICS_NetRuntime_ENABLED=true``. Supported metrics are ``NetRuntime``, ``Process``, ``AspNetCore``, and ``Traces``. The default value is ``false``. See :ref:`dotnet-metrics-attributes` for more information. - -.. note:: NetRuntime metrics are always collected if memory profiling is activated. - -.. _dotnet-instrumentation-settings: - -Instrumentation settings -================================================ - -The following settings control instrumentations and tracing behavior: - -.. list-table:: - :header-rows: 1 - :width: 100% - :widths: 40 60 - - * - Setting - - Description - * - ``SIGNALFX_GLOBAL_TAGS`` - - Comma-separated list of key-value pairs that specify global span tags. For example: ``key1:val1,key2:val2``. - * - ``SIGNALFX_RECORDED_VALUE_MAX_LENGTH`` - - Maximum length of the value of an attribute. Values longer than this value are truncated. Values are discarded entirely when set to ``0``, and ignored when set to a negative value. The default value is ``12000``. - * - ``SIGNALFX_DISABLED_INTEGRATIONS`` - - Comma-separated list of library instrumentations you want to deactivate. Each value must match an internal instrumentation ID. See :ref:`supported-dotnet-libraries` for a list of integration identifiers. - * - ``SIGNALFX_TRACE_{0}_ENABLED`` - - Activates or deactivates a specific instrumentation library. For example, to deactivate the Kafka instrumentation, set ``SIGNALFX_TRACE_Kafka_ENABLED`` to ``false``. The value must match an internal instrumentation ID. See :ref:`supported-dotnet-libraries` for a list of integration identifiers. - -.. _dotnet-instrumentation-libraries-settings: - -Library-specific instrumentation settings -================================================ - -The following settings control the behavior of specific instrumentations: - -.. list-table:: - :header-rows: 1 - :width: 100% - :widths: 40 60 - - * - Setting - - Description - * - ``SIGNALFX_HTTP_CLIENT_ERROR_STATUSES`` - - Comma-separated list of HTTP client response statuses or ranges for which the spans are set as errors, for example: ``300, 400-499``. The default value is ``400-599``. - * - ``SIGNALFX_HTTP_SERVER_ERROR_STATUSES`` - - Comma-separated list of HTTP server response statuses or ranges for which the spans are set as errors, for example: ``300, 400-599``. The default value is ``500-599``. - * - ``SIGNALFX_INSTRUMENTATION_ELASTICSEARCH_TAG_QUERIES`` - - Activates the tagging of a ``PostData`` command as ``db.statement``. It might introduce overhead for direct streaming users. The default value is ``true``. - * - ``SIGNALFX_INSTRUMENTATION_MONGODB_TAG_COMMANDS`` - - Activates the tagging of a ``BsonDocument`` command as ``db.statement``. The default value is ``true``. - * - ``SIGNALFX_INSTRUMENTATION_REDIS_TAG_COMMANDS`` - - Activates the tagging of Redis commands as ``db.statement``. The default value is ``true``. - * - ``SIGNALFX_TRACE_DELAY_WCF_INSTRUMENTATION_ENABLED`` - - Activates the updated WCF instrumentation, which delays execution until later in the WCF pipeline when the WCF server exception handling is established. The default value is ``false``. - * - ``SIGNALFX_TRACE_HEADER_TAGS`` - - Comma-separated map of HTTP header keys to tag names, automatically applied as tags on traces. For example: ``x-my-header:my-tag,header2:tag2``. - * - ``SIGNALFX_TRACE_HTTP_CLIENT_EXCLUDED_URL_SUBSTRINGS`` - - Comma-separated list of URL substrings. Matching URLs are ignored by the tracer. For example, ``subdomain,xyz,login,download``. - * - ``SIGNALFX_TRACE_KAFKA_CREATE_CONSUMER_SCOPE_ENABLED`` - - Activate to close consumer scope upon entering a method and starting a new one on method exit. The default value is ``true``. - * - ``SIGNALFX_TRACE_ROUTE_TEMPLATE_RESOURCE_NAMES_ENABLED`` - - Activate to base ASP.NET span and resource names on routing configuration, if applicable. The default value is ``true``. - -.. _server-trace-information-dotnet: - -Server trace information -============================================== - -To connect Real User Monitoring (RUM) requests from mobile and web applications with server trace data, trace response headers are activated by default. The instrumentation adds the following response headers to HTTP responses: - -.. code-block:: - - Access-Control-Expose-Headers: Server-Timing - Server-Timing: traceparent;desc="00---01" - -The ``Server-Timing`` header contains the ``traceId`` and ``spanId`` parameters in ``traceparent`` format. W3C tracecontext and W3C baggage context propagation is activated by default. For more information, see the Server-Timing and traceparent documentation on the W3C website. - -.. note:: If you need to deactivate trace response headers, set ``SIGNALFX_TRACE_RESPONSE_HEADER_ENABLED`` to ``false``. - -.. _dotnet-instrumentation-query-strings: - -Query string settings -================================================ - -.. note:: This feature is only available when instrumenting ASP.NET Core applications. - -The following settings control the inclusion of query strings in the ``http.url`` tag for ASP.NET Core instrumented applications. - -.. list-table:: - :header-rows: 1 - :width: 100% - :widths: 40 60 - - * - Setting - - Description - * - ``SIGNALFX_HTTP_SERVER_TAG_QUERY_STRING`` - - Activates or deactivates query string inclusion in the ``http.url`` tag for ASP.NET Core applications. The default value is ``true``. - * - ``SIGNALFX_TRACE_OBFUSCATION_QUERY_STRING_REGEXP`` - - Custom regular expression to obfuscate query strings. The default value is shown in the example. - * - ``SIGNALFX_TRACE_OBFUSCATION_QUERY_STRING_REGEXP_TIMEOUT`` - - Timeout to the execution of the query string obfuscation pattern defined in ``SIGNALFX_TRACE_OBFUSCATION_QUERY_STRING_REGEXP``, in milliseconds. The default value is ``200``. - -Obfuscating query string prevents your applications from sending sensitive data to Splunk. - -The default regular expression for query obfuscation is the following: - -.. code-block:: - - ((?i)(?:p(?:ass)?w(?:or)?d|pass(?:_?phrase)?|secret|(?:api_?|private_?|public_?|access_?|secret_?)key(?:_?id)?|token|consumer_?(?:id|key|secret)|sign(?:ed|ature)?|auth(?:entication|orization)?)(?:(?:\s|%20)*(?:=|%3D)[^&]+|(?:""|%22)(?:\s|%20)*(?::|%3A)(?:\s|%20)*(?:""|%22)(?:%2[^2]|%[^2]|[^""%])+(?:""|%22))|bearer(?:\s|%20)+[a-z0-9\._\-]|token(?::|%3A)[a-z0-9]{13}|gh[opsu]_[0-9a-zA-Z]{36}|ey[I-L](?:[\w=-]|%3D)+\.ey[I-L](?:[\w=-]|%3D)+(?:\.(?:[\w.+\/=-]|%3D|%2F|%2B)+)?|[\-]{5}BEGIN(?:[a-z\s]|%20)+PRIVATE(?:\s|%20)KEY[\-]{5}[^\-]+[\-]{5}END(?:[a-z\s]|%20)+PRIVATE(?:\s|%20)KEY|ssh-rsa(?:\s|%20)*(?:[a-z0-9\/\.+]|%2F|%5C|%2B){100,})` - -.. _dotnet-debug-logging-settings: - -Diagnostic logging settings -================================================ - -The following settings control the internal logging of the SignalFx Instrumentation for .NET: - -.. list-table:: - :header-rows: 1 - :width: 100% - :widths: 40 60 - - * - Setting - - Description - * - ``SIGNALFX_DIAGNOSTIC_SOURCE_ENABLED`` - - Activate to generate troubleshooting logs using the ``System.Diagnostics.DiagnosticSource`` class. The default value is ``true``. - * - ``SIGNALFX_FILE_LOG_ENABLED`` - - Activates file logging. The default value is ``true``. - * - ``SIGNALFX_MAX_LOGFILE_SIZE`` - - The maximum size for tracer log files, in bytes. The default value is ``245760``, or 10 megabytes. - * - ``SIGNALFX_STDOUT_LOG_ENABLED`` - - Activates ``stdout`` logging. The default value is ``false``. - * - ``SIGNALFX_STDOUT_LOG_TEMPLATE`` - - Configures the ``stdout`` log template using the Serilog formatting conventions. The default value is ``[{Level:u3}] {Message:lj} {NewLine}{Exception}{NewLine}``. - * - ``SIGNALFX_TRACE_DEBUG`` - - Activate to activate debugging mode for the tracer. The default value is ``false``. - * - ``SIGNALFX_TRACE_LOG_DIRECTORY`` - - Directory of the .NET tracer logs. Overrides the value in ``SIGNALFX_TRACE_LOG_PATH`` if present. The default value is ``/var/log/signalfx/dotnet/`` for Linux and ``%ProgramData%\SignalFx .NET Tracing\logs\`` for Windows. - * - ``SIGNALFX_TRACE_LOGGING_RATE`` - - The number of seconds between identical log messages for tracer log files. Setting this environment variable to ``0`` deactivates rate limiting. The default value is ``60``. - * - ``SIGNALFX_TRACE_STARTUP_LOGS`` - - Activate to activate diagnostic logs at startup. The default value is ``true``. - -.. _dotnet-default-service-name: - -Changing the default service name -============================================= - -By default, the SignalFx Instrumentation for .NET retrieves the service name by trying the following steps until it succeeds: - -#. For the SignalFx .NET Tracing Azure Site Extension, the default service name is the site name as defined by the ``WEBSITE_SITE_NAME`` environment variable. - -#. For ASP.NET applications, the default service name is ``SiteName[/VirtualPath]``. - -#. For other applications, the default service name is the name of the entry assembly. For example, the name of your .NET project file. - -#. If the entry assembly is not available, the instrumentation tries to use the current process name. The process name can be ``dotnet`` if launched directly using an assembly. For example, ``dotnet InstrumentedApp.dll``. - -If all the steps fail, the service name defaults to ``UnknownService``. - -To override the default service name, set the ``SIGNALFX_SERVICE_NAME`` environment variable. diff --git a/gdi/get-data-in/application/otel-dotnet/sfx/configuration/dotnet-metrics-attributes.rst b/gdi/get-data-in/application/otel-dotnet/sfx/configuration/dotnet-metrics-attributes.rst deleted file mode 100644 index f32770eb3..000000000 --- a/gdi/get-data-in/application/otel-dotnet/sfx/configuration/dotnet-metrics-attributes.rst +++ /dev/null @@ -1,222 +0,0 @@ -.. caution:: - - The SignalFx Instrumentation for .NET reached End of Support on February 21, 2025. The library has been archived and is no longer maintained. - - New customers instrumenting the .NET ecosystem should use the :ref:`Splunk Distribution of OpenTelemetry .NET `. Existing customers should consider migrating to Splunk Distribution of OpenTelemetry .NET which offers similar capabilities. To learn how to migrate, see :ref:`migrate-signalfx-dotnet-to-dotnet-otel`. - -.. _dotnet-metrics-attributes: - -*************************************************************** -Metrics collected by the SignalFx Instrumentation for .NET -*************************************************************** - -.. meta:: - :description: The SignalFx Instrumentation for .NET collects the following runtime and trace metrics. - -The SignalFx Instrumentation for .NET can collect runtime and trace metrics. To learn about the different metric types, see :ref:`metric-types`. - -.. _enable-dotnet-metrics: - -Activate metrics collection -==================================================== - -To activate the collection of .NET runtime and trace metrics, see :ref:`dotnet-metric-settings`. - -.. note:: NetRuntime metrics are always collected if memory profiling is activated. - -.. _default_app_metrics-dotnet: - -Default metric dimensions -==================================================== - -The following dimensions are automatically added to all metrics exported by the agent: - -.. list-table:: - :header-rows: 1 - :widths: 40 60 - :width: 100% - - * - Dimension - - Description - * - ``deployment.environment`` - - Deployment environment, if present. - * - ``service.name`` - - Name of the service. - * - ``process.pid`` - - The .NET process identifier (PID). - * - ``container.id`` - - Identifier of the container, if applicable. - * - ``host.name`` - - Name of the host. - * - ``telemetry.sdk.name`` - - Name of the SDK, set to ``signalfx-dotnet-tracing``. - * - ``telemetry.sdk.language`` - - Language of the SDK, set to ``dotnet``. - * - ``telemetry.sdk.version`` - - Version of the SDK. - * - ``splunk.distro.version`` - - Version of the Splunk distribution. - -.. _dotnet-runtime-metrics: - -.NET runtime metrics -==================================================== - -The SignalFx Instrumentation for .NET can collect the following runtime metrics: - -.. list-table:: - :header-rows: 1 - :widths: 40 10 50 - :width: 100% - - * - Metric - - Type - - Description - * - ``process.runtime.dotnet.exceptions.count`` - - Gauge - - Count of exceptions since the previous observation. - * - ``process.runtime.dotnet.gc.collections.count`` - - Cumulative counter - - Number of garbage collections since the process started. - * - ``process.runtime.dotnet.gc.heap.size`` - - Gauge - - Heap size, as observed during the last garbage collection. - * - ``process.runtime.dotnet.gc.objects.size`` - - Gauge - - Count of bytes currently in use by live objects in the GC heap. - * - ``process.runtime.dotnet.gc.allocations.size`` - - Cumulative counter - - Count of bytes allocated on the managed GC heap since the process started. Only available for .NET Core. - * - ``process.runtime.dotnet.gc.committed_memory.size`` - - Gauge - - Amount of committed virtual memory for the managed GC heap, as observed during the last garbage collection. Only available for .NET 6 and higher. - * - ``process.runtime.dotnet.gc.pause.time`` - - Counter - - Number of milliseconds spent in GC pause. Only available for .NET Core. - * - ``process.runtime.dotnet.monitor.lock_contention.count`` - - Cumulative counter - - Contentions count when trying to acquire a monitor lock since the process started. - * - ``process.runtime.dotnet.thread_pool.threads.count`` - - Gauge - - Number of thread pool threads, as observed during the last measurement. Only available for .NET Core. - -.. _dotnet-process-metrics: - -Process metrics -==================================================== - -The SignalFx Instrumentation for .NET can collect the following process metrics: - -.. list-table:: - :header-rows: 1 - :widths: 40 10 50 - :width: 100% - - * - Metric - - Type - - Description - * - ``process.memory.usage`` - - Gauge - - The amount of physical memory allocated for this process. - * - ``process.memory.virtual`` - - Gauge - - The amount of committed virtual memory for this process. - * - ``process.cpu.time`` - - CumulativeCounter - - Total CPU seconds broken down by different states, such as user and system. - * - ``process.cpu.utilization`` (deprecated) - - Gauge - - Difference in ``process.cpu.time`` since the last measurement, divided by the elapsed time and number of CPUs available to the process. - * - ``process.threads`` - - Gauge - - Process threads count. - -.. _dotnet-aspnetcore-metrics: - -ASP.NET Core metrics -==================================================== - -The SignalFx Instrumentation for .NET can collect the following ASP.NET Core metrics: - -.. list-table:: - :header-rows: 1 - :widths: 40 10 50 - :width: 100% - - * - Metric - - Type - - Description - * - ``signalfx.dotnet.aspnetcore.connections.current`` - - Gauge - - Number of active HTTP connections to the web server. Only available for .NET Core. - * - ``signalfx.dotnet.aspnetcore.connections.queue_length`` - - Gauge - - Length of the HTTP connection queue. Only available for .NET Core. - * - ``signalfx.dotnet.aspnetcore.connections.total`` - - Gauge - - Number of HTTP connections to the web server. Only available for .NET Core. - * - ``signalfx.dotnet.aspnetcore.requests.current`` - - Gauge - - Number of HTTP requests that have started, but haven't stopped yet. Only available for .NET Core. - * - ``signalfx.dotnet.aspnetcore.requests.failed`` - - Gauge - - Number of failed HTTP requests received by the server. Only available for .NET Core. - * - ``signalfx.dotnet.aspnetcore.requests.queue_length`` - - Gauge - - Length of the HTTP request queue. - * - ``signalfx.dotnet.aspnetcore.requests.total`` - - Gauge - - Number of HTTP requests received by the server. Only available for .NET Core. - - -Additional permissions for IIS -------------------------------------------------------------- - -The .NET Framework collects metrics using performance counters. To let service accounts and IIS application pool accounts access counter data, add them to the ``Performance Monitoring Users`` group. - -IIS application pools use special accounts that don't appear in the list of users. To add IIS application pool accounts to the ``Performance Monitoring Users`` group, search for ``IIS APPPOOL\``. For example, the user for the ``DefaultAppPool`` pool is ``IIS APPPOOL\DefaultAppPool``. - -The following example shows how to add an IIS application pool account to the ``Performance Monitoring Users`` group from a command prompt with Administrator permissions: - -.. code-block:: shell - - net localgroup "Performance Monitor Users" "IIS APPPOOL\DefaultAppPool" /add - -.. _dotnet-trace-metrics: - -Trace metrics -==================================================== - -The SignalFx Instrumentation for .NET can collect the following trace metrics: - -.. list-table:: - :header-rows: 1 - :widths: 40 10 50 - :width: 100% - - * - Metric - - Type - - Description - * - ``signalfx.tracer.queue.enqueued_traces`` - - Counter - - Number of traces pushed into the queue. - * - ``signalfx.tracer.queue.dequeued_traces`` - - Counter - - Number of traces pulled from the queue for flushing. - * - ``signalfx.tracer.queue.enqueued_spans`` - - Counter - - Number of spans pushed into the queue. - * - ``signalfx.tracer.queue.dequeued_spans`` - - Counter - - Number of spans pulled from the queue for flushing. - * - ``signalfx.tracer.queue.dropped_traces`` - - Counter - - Number of traces dropped due to a full queue. - * - ``signalfx.tracer.queue.dropped_spans`` - - Counter - - Number of spans dropped due to a full queue. - * - ``signalfx.tracer.heartbeat`` - - Gauge - - Number of tracers. - - diff --git a/gdi/get-data-in/application/otel-dotnet/sfx/dotnet-requirements.rst b/gdi/get-data-in/application/otel-dotnet/sfx/dotnet-requirements.rst deleted file mode 100644 index 8dffb53ef..000000000 --- a/gdi/get-data-in/application/otel-dotnet/sfx/dotnet-requirements.rst +++ /dev/null @@ -1,157 +0,0 @@ -.. caution:: - - The SignalFx Instrumentation for .NET reached End of Support on February 21, 2025. The library has been archived and is no longer maintained. - - New customers instrumenting the .NET ecosystem should use the :ref:`Splunk Distribution of OpenTelemetry .NET `. Existing customers should consider migrating to Splunk Distribution of OpenTelemetry .NET which offers similar capabilities. To learn how to migrate, see :ref:`migrate-signalfx-dotnet-to-dotnet-otel`. - -.. _dotnet-requirements: - -************************************************************* -.NET instrumentation compatibility and requirements -************************************************************* - -.. meta:: - :description: This is what you need to instrument .NET applications for Splunk Observability Cloud. - :robots: noindex - -Meet the following requirements to instrument .NET applications for Splunk Observability Cloud: - -.. _dotnet-versions: - -Ensure you are using supported .NET versions -============================================================== - -The SignalFx Instrumentation for .NET supports the following .NET versions: - -- Instrumentation for traces and metrics: - - - .NET 6.0 - - .NET Framework 4.6.2 and higher - -- AlwaysOn Profiling: - - - .NET 6.0 - -Support for legacy .NET versions ---------------------------------------------------------------- - -Limited support is available for the following legacy versions of .NET: - -- Instrumentation for traces and metrics: - - - .NET 7.x - - .NET 5.x - - .NET Core 3.1 - - .NET Framework 4.6.1 - -- AlwaysOn Profiling: - - - CPU Profiling: .NET Core 3.1, .NET 5.x, and .NET 7.x - - Memory Profiling: .NET Core 5.x and .NET 7.x - -.. _supported-dotnet-libraries: - -Supported libraries -================================================= - -The SignalFx Instrumentation for .NET instruments the following libraries: - -.. list-table:: - :widths: 60 40 - :width: 100% - :header-rows: 1 - - * - Library - - Instrumentation ID - * - ``Aerospike.Client`` - - ``Aerospike`` - * - ASP.NET 4.x - - ``AspNet`` - * - ASP.NET Core - - ``AspNetCore`` - * - ASP.NET MVC - - ``AspNetMvc`` - * - ASP.NET Web API 2 - - ``AspNetWebApi2v`` - * - ``AWSSDK.Core`` (Experimental) - - ``AwsSdk`` - * - ``AWSSDK.SQS`` (Experimental) - - ``AwsSqs`` - * - ``Confluent.Kafka`` - - ``Kafka`` - * - ``CouchbaseNetClient`` (Experimental) - - ``Couchbase`` - * - ``Elasticsearch.Net`` - - ``ElasticsearchNetv`` - * - GraphQL - - ``GraphQL`` - * - gRPC - - ``Grpc`` - * - ``Microsoft.Data.SqlClient`` and ``System.Data.SqlClient`` - - ``SqlClient`` - * - ``Microsoft.Extensions.Logging.Abstractions`` - - ``ILOgger`` - * - ``Microsoft.Azure.Cosmos`` (Experimental) - - ``CosmosDb`` - * - ``Microsoft.Azure.WebJobs`` (Experimental) - - ``AzureFunctions`` - * - ``Microsoft.ServiceFabric.Services.Remoting`` (Experimental) - - ``ServiceRemoting`` - * - ``Microsoft.VisualStudio.TestPlatform`` (Experimental) - - ``MsTestV2`` - * - ``MongoDB.Driver.Core`` - - ``MongoDb`` - * - ``MySql.Data`` - - ``MySql`` - * - Npgsql - - ``Npgsql`` - * - ``NUnit`` (Experimental) - - ``NUnit`` - * - ``Oracle.ManagedDataAccess`` - - ``Oracle`` - * - ``RabbitMQ.Client`` - - RabbitMQ - * - ``ServiceStack.Redis`` - - ``ServiceStacksRedis`` - * - SQLite - - ``Sqlite`` - * - ``StackExchange.Redis`` - - ``StackExchangeRedis`` - * - ``System.Net.Http.CurlHandler`` - - ``CurlHandler`` - * - ``System.Net.Http.MessageHandler`` - - ``HttpMessageHandler`` - * - ``System.Net.Http.SocketsHandler`` - - ``HttpSocketsHandler`` - * - ``System.Net.Http.WinHttpHandler`` - - ``WinHttpHandler`` - * - ``System.Net.WebRequest`` - - ``WebRequest`` - * - ``System.Messaging`` (Experimental) - - ``Msmq`` - * - Windows Communication Foundation (WCF) - - ``Wcf`` - * - ``xunit`` (Experimental) - - ``XUnit`` - -To instrument the ``System.Net.Http.HttpClient`` library, you must instrument the following group of libraries: - -- ``System.Net.Http.CurlHandler`` -- ``System.Net.Http.MessageHandler`` -- ``System.Net.Http.SocketsHandler`` -- ``System.Net.Http.WinHttpHandler`` - -.. _dotnet-collector-requirement: - -Install and configure the Splunk Distribution of OpenTelemetry Collector -====================================================================================================== - -The SignalFx Instrumentation for .NET exports application traces and spans to the Splunk Distribution of OpenTelemetry Collector, which also collects system metric data and logs, including profiling data. - -To send application traces and spans to Splunk Observability Cloud, install the Splunk Distribution of OpenTelemetry Collector for your platform. The following distributions are available: - -- Splunk OTel Collector for Linux. See :ref:`otel-install-linux`. -- Splunk OTel Collector for Windows. See :ref:`otel-install-windows`. -- Splunk OTel Collector for Kubernetes. See :ref:`otel-install-k8s`. - -.. note:: The OTel Collector is not required when instrumenting Azure App Service applications. See :ref:`instrument-azure-app`. diff --git a/gdi/get-data-in/application/otel-dotnet/sfx/instrumentation/connect-traces-logs.rst b/gdi/get-data-in/application/otel-dotnet/sfx/instrumentation/connect-traces-logs.rst deleted file mode 100644 index 7c25018c1..000000000 --- a/gdi/get-data-in/application/otel-dotnet/sfx/instrumentation/connect-traces-logs.rst +++ /dev/null @@ -1,187 +0,0 @@ -.. caution:: - - The SignalFx Instrumentation for .NET reached End of Support on February 21, 2025. The library has been archived and is no longer maintained. - - New customers instrumenting the .NET ecosystem should use the :ref:`Splunk Distribution of OpenTelemetry .NET `. Existing customers should consider migrating to Splunk Distribution of OpenTelemetry .NET which offers similar capabilities. To learn how to migrate, see :ref:`migrate-signalfx-dotnet-to-dotnet-otel`. - -.. _correlate-traces-with-logs-dotnet: - -**************************************************************** -Connect .NET trace data with logs for Splunk Observability Cloud -**************************************************************** - -.. meta:: - :description: Configure .NET logging libraries to include tracing attributes provided automatically by the SignalFx Instrumentation for .NET. - -You can configure logging libraries to include tracing attributes provided automatically by the SignalFx Instrumentation for .NET. Use the metadata to correlate traces with log events and explore logs in Splunk. - -.. _dotnet-traces-logs-requirements: - -Check compatibility and requirements -==================================================== - -The SignalFx Instrumentation supports the following logging libraries: - -.. list-table:: - :widths: 10 20 70 - :header-rows: 1 - - * - Library - - Versions - - Layouts - * - ILogger - - 2.5.0 to 6.x.x - - * JSON format: ``json`` from the ``NetEscapades.Extensions.Logging`` package - * - Log4Net - - 1.0.0 to 2.x.x - - * JSON format: ``SerializedLayout`` from the ``log4net.Ext.Json`` package - * Raw format: ``PatternLayout`` - * - NLog - - 1.0.0.505 to 4.x.x - - * JSON format: ``JsonLayout`` - * Raw format: Custom layout - * - Serilog - - 1.4.0 to 2.x.x - - * JSON format: ``JsonFormatter`` or ``CompactJsonFormatter`` from the ``Serilog.Formatting.Compact`` package - * Raw format: Output template - -.. _dotnet-enable-log-correlation: - -Activate log correlation -============================ - -To activate log correlation, set the ``SIGNALFX_LOGS_INJECTION`` environment variable to ``true`` before running your instrumented application. - -.. _dotnet-include-trace-data: - -Include trace metadata in log statements -=================================================== - -The SignalFx Instrumentation for .NET provides the following attributes for logging libraries: - -* ``trace_id`` -* ``span_id`` -* ``service.name``, as defined by the ``SIGNALFX_SERVICE_NAME`` environment variable -* ``service.version``, as defined by the ``SIGNALFX_VERSION`` environment variable -* ``deployment.environment``, as defined by the ``SIGNALFX_ENV`` environment variable - -If the logging library uses JSON, the tracing library automatically handles data injection. - -If the logger uses a raw format, you must configure your logger to include the trace metadata. The following sections show how to configure the supported loggers to include trace metadata. - -Log4Net -------------------------- - -When using the ``SerializedLayout`` layout you can add all contextual properties by adding the properties member. For example: - -.. code-block:: xml - - - - - - -You can also add the context fields explicitly. For example: - -.. code-block:: xml - - - - - - - - - - -When using the ``PatternLayout`` layout, add the context fields manually. You must wrap the values in quotation marks. For example: - -.. code-block:: xml - - - - - -NLog -------------------------- - -When using the ``JsonLayout`` layout and NLog version 4.4.10 and higher, you can add all contextual properties by setting the ``includeMdlc`` attribute to ``true``. For example: - -.. code-block:: xml - - - - - -You can also add the context fields explicitly. For example: - -.. code-block:: xml - - - - - - - - - - -When using the custom layout, add the context fields manually. Values must be wrapped in quotation marks. For example: - -.. code-block:: - - - -Serilog -------------------------- - -To extract the trace context that you want to inject, enrich the ``LoggerConfiguration`` instance using the log context: - -.. code-block:: csharp - - var loggerConfiguration = new LoggerConfiguration() - .Enrich.FromLogContext() // addition - -When using the output template, you can either use the ``{Properties}`` placeholder to print all contextual properties or add context fields manually. - -When adding context fields manually, wrap the values in quotation marks. For example: - -.. code-block:: shell - - "{Timestamp:yyyy-MM-dd HH:mm:ss.fff zzz} [{Level:u3}] trace_id=\"{trace_id}\" span_id=\"{span_id}\" service.name=\"{service_name}\" service.version=\"{service_version}\" deployment.environment=\"{deployment_environment}\"{NewLine}{Message:lj}{NewLine}{Exception}" - -The instrumentation uses the underscore character as separator for field names (``_``), as Serilog doesn't support property names that use the dot separator (``.``). To ingest log data, define the following conversion rules: - -- ``service_name`` to ``service.name`` -- ``service_version`` to ``service.version`` -- ``deployment_environment`` to ``deployment.environment`` - - -ILogger -------------------------- - -When using the ``NetEscapades.Extensions.Logging.RollingFile`` package, activate the ``IncludeScopes`` option and use the ``json`` formatter. For example: - -.. code-block:: csharp - - Host.ConfigureLogging(builder => - builder.AddFile(opts => - { - opts.FileName = "logs"; - opts.Extension = "json"; - opts.FormatterName = "json"; // supported formatter - opts.IncludeScopes = true; // addition - }) - ); - -.. note:: SignalFx Instrumentation for .NET only supports ILogger 2.5.0 or higher. - -Log correlation also works when ILogger is wrapping other supported loggers. - -Sample applications -============================================ - -To download several sample applications that show how to configure log correlation, see :new-page:`https://github.com/signalfx/signalfx-dotnet-tracing/tree/main/tracer/samples/AutomaticTraceIdInjection` on GitHub. diff --git a/gdi/get-data-in/application/otel-dotnet/sfx/instrumentation/instrument-dotnet-application.rst b/gdi/get-data-in/application/otel-dotnet/sfx/instrumentation/instrument-dotnet-application.rst deleted file mode 100644 index a90da7a3d..000000000 --- a/gdi/get-data-in/application/otel-dotnet/sfx/instrumentation/instrument-dotnet-application.rst +++ /dev/null @@ -1,404 +0,0 @@ -.. caution:: - - The SignalFx Instrumentation for .NET reached End of Support on February 21, 2025. The library has been archived and is no longer maintained. - - New customers instrumenting the .NET ecosystem should use the :ref:`Splunk Distribution of OpenTelemetry .NET `. Existing customers should consider migrating to Splunk Distribution of OpenTelemetry .NET which offers similar capabilities. To learn how to migrate, see :ref:`migrate-signalfx-dotnet-to-dotnet-otel`. - -.. _instrument-dotnet-applications: - -*************************************************************************** - .NET application for Splunk Observability Cloud -*************************************************************************** - -.. meta:: - :description: The SignalFx Instrumentation for .NET automatically instruments .NET applications, Windows services running .NET applications, ASP.NET applications deployed on IIS, and Azure App Service apps. Follow these steps to get started. - -The SignalFx Instrumentation for .NET automatically instruments .NET applications, Windows services running .NET applications, ASP.NET applications deployed on IIS, and Azure App Service applications. - -To get started, follow the instructions to install the SignalFx Instrumentation for .NET manually. - - -Install the SignalFx Instrumentation for .NET manually -================================================================== - -If you don't use the guided setup, follow these instructions to manually install the SignalFx Instrumentation for .NET: - -- :ref:`install-dotnet-instrumentation` -- :ref:`instrument-windows-service` -- :ref:`instrument-aspnet-iis` -- :ref:`instrument-azure-app` -- :ref:`instrument-azure-webjobs` - -.. _install-dotnet-instrumentation: - -Instrument your .NET application --------------------------------------------------------------------- - -Follow these steps to automatically instrument your application: - -#. Check that you meet the requirements. See :ref:`dotnet-requirements`. - -#. Download the latest release of the SignalFx Instrumentation for .NET for your operating system from the :new-page:`Releases page on GitHub `. - -#. Install the package for your operating system: - - .. tabs:: - - .. group-tab:: Windows (PowerShell) - - .. tabs:: - - .. code-tab:: shell Windows x64 - - msiexec /i signalfx-dotnet-tracing--x64.msi /quiet - - .. code-tab:: shell Windows x86 - - msiexec /i signalfx-dotnet-tracing--x86.msi /quiet - - .. group-tab:: Linux - - .. tabs:: - - .. code-tab:: bash rpm - - rpm -ivh signalfx-dotnet-tracing-.rpm - ./opt/signalfx/createLogPath.sh # Optional - - .. code-tab:: bash deb - - dpkg -i signalfx-dotnet-tracing-.deb - ./opt/signalfx/createLogPath.sh # Optional - - .. code-tab:: bash tar (glibc) - - tar -xf signalfx-dotnet-tracing-.tar.gz -C /opt/signalfx - ./opt/signalfx/createLogPath.sh # Optional - -#. Set the following environment variables: - - .. tabs:: - - .. group-tab:: Windows (PowerShell) - - .. code-block:: shell - - # Set the following variables in the process scope - $Env:COR_ENABLE_PROFILING = "1" - $Env:COR_PROFILER = "{B4C89B0F-9908-4F73-9F59-0D77C5A06874}" - $Env:CORECLR_ENABLE_PROFILING = "1" - $Env:CORECLR_PROFILER = "{B4C89B0F-9908-4F73-9F59-0D77C5A06874}" - $Env:SIGNALFX_SERVICE_NAME = "" - $Env:SIGNALFX_ENV = "" - - - Avoid setting the environment variables in the system or user scopes in Windows unless you require permanent autoinstrumentation. See :ref:`advanced-dotnet-configuration` for more information on how to include or exclude processes for autoinstrumentation. - - .. code-tab:: shell Linux - - export CORECLR_ENABLE_PROFILING="1" - export CORECLR_PROFILER="{B4C89B0F-9908-4F73-9F59-0D77C5A06874}" - export CORECLR_PROFILER_PATH="/opt/signalfx/SignalFx.Tracing.ClrProfiler.Native.so" - export SIGNALFX_DOTNET_TRACER_HOME="/opt/signalfx" - export SIGNALFX_SERVICE_NAME="" - export SIGNALFX_ENV="" - -#. (Optional) To activate automatic metric collection, see :ref:`enable_automatic_metric_collection_dotnet`. - -#. Run your application. - -If no data appears in APM, see :ref:`common-dotnet-troubleshooting`. - -If you need to add custom attributes to spans or want to manually generate spans, instrument your .NET application or service manually. See :ref:`dotnet-manual-instrumentation`. - -.. _enable_profiling_dotnet: - -Activate AlwaysOn Profiling -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -To activate AlwaysOn Profiling, set the ``SIGNALFX_PROFILER_ENABLED`` environment variable to ``true``. - -To activate memory profiling, set the ``SIGNALFX_PROFILER_MEMORY_ENABLED`` environment variable to ``true`` after activating AlwaysOn Profiling. - -See :ref:`get-data-in-profiling` for more information. For more settings, see :ref:`profiling-configuration-dotnet`. - -.. _enable_automatic_metric_collection_dotnet: - -Activate metrics collection -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -To activate automatic metric collection, set the ``SIGNALFX_TRACE_METRICS_ENABLED`` environment variable to ``true``. - -To activate runtime metrics, set the ``SIGNALFX_RUNTIME_METRICS_ENABLED`` environment variable to ``true``. - -See :ref:`dotnet-metrics-attributes` for more information about the metrics collected by the instrumentation. For more metric settings, see :ref:`dotnet-metric-settings`. - -.. note:: Runtime metrics are always collected if AlwaysOn Profiling is activated. - -.. _instrument-windows-service: - -Instrument your Windows service running a .NET application --------------------------------------------------------------------- - -To instrument a Windows service, install the instrumentation and set the following environment variables: - -.. code-block:: shell - - $svcName = "MySrv" # Name of the Windows service you want to instrument - [string[]] $vars = @( - "COR_ENABLE_PROFILING=1", # Activate .NET Framework Profiler - "COR_PROFILER={B4C89B0F-9908-4F73-9F59-0D77C5A06874}", # Select .NET Framework Profiler - "CORECLR_ENABLE_PROFILING=1", # Activate .NET (Core) Profiler - "CORECLR_PROFILER={B4C89B0F-9908-4F73-9F59-0D77C5A06874}", # Select .NET (Core) Profiler - "SIGNALFX_SERVICE_NAME=", # Set service name - "SIGNALFX_ENV=" # Set environment name - ) - Set-ItemProperty HKLM:SYSTEM\CurrentControlSet\Services\$svcName -Name Environment -Value $vars - # Every time you start the service, it will be auto-instrumented. - -For more information on the default service name, see :ref:`dotnet-default-service-name`. - -.. _instrument-aspnet-iis: - -Instrument your ASP.NET application deployed on IIS --------------------------------------------------------------------- - -To instrument an ASP.NET application running on IIS, install the instrumentation and edit the web.config file to add the following settings. See :ref:`configuration-methods-dotnet` for more information. - -.. tabs:: - - .. tab:: ASP.NET 4.x and higher - - Add the following settings inside the ```` block of your web.config file: - - .. code-block:: xml - - - - - After applying the changes to the web.config file, restart IIS by running the following command: - - .. code-block:: powershell - - Start-Process "iisreset.exe" -NoNewWindow -Wait - - In some cases, you might have to restart the machine. - - .. tab:: ASP.NET Core - - Add the following settings inside the ```` block of your web.config file: - - .. code-block:: xml - - - - - - - - - After applying the changes to the web.config file, restart IIS by running the following command: - - .. code-block:: powershell - - Start-Process "iisreset.exe" -NoNewWindow -Wait - - In some cases, you might have to restart the machine. - - .. note:: The ASP.NET Core instrumentation collects and obfuscates query strings by default. See :ref:`dotnet-instrumentation-query-strings` for more information. - -.. note:: By default, the installer activates IIS instrumentation for .NET Framework by setting the ``Environment`` registry key for W3SVC and WAS services located in the ``HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services`` folder. - -.. _instrument-azure-app: - -Instrument your application in Azure App Service --------------------------------------------------------------------- - -To instrument an application or service in Azure App Service, follow these steps: - -#. Find and install the :strong:`SignalFx .NET Tracing` extension in your application. See :new-page:`Adding Extensions to Web Apps in Azure App Service ` in the Azure documentation for more information. - -#. Add the following application settings. See :new-page:`Configure Apps ` in the Azure documentation for more information. - - .. list-table:: - :header-rows: 1 - :width: 100% - :widths: 40 60 - - * - Name - - Value - * - ``SIGNALFX_ACCESS_TOKEN`` - - Your Splunk access token. To obtain an access token, see :ref:`admin-api-access-tokens`. - * - ``SIGNALFX_REALM`` - - ``realm`` is the Splunk Observability Cloud realm, for example, ``us0``. To find your Splunk realm, see :ref:`Note about realms `. - * - ``SIGNALFX_SERVICE_NAME`` - - The name of your service or application. - * - ``SIGNALFX_ENV`` - - The name of your environment where you're instrumenting the application. - -#. Restart the application. - -.. note:: To reduce latency and benefit from OTel Collector features, set the endpoint URL to a Collector instance running in Azure VM over an Azure VNet. - -.. _instrument-azure-webjobs: - -Instrument your background task in Azure App Service -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -When instrumenting an Azure WebJob in App Service, add the following settings. Replace ```` in system paths with the version of the .NET instrumentation, for example, ``v0.2.0``: - - .. list-table:: - :header-rows: 1 - :width: 100% - :widths: 40 60 - - * - Name - - Value - * - ``SIGNALFX_ACCESS_TOKEN`` - - Your Splunk access token. To obtain an access token, see :ref:`admin-api-access-tokens`. - * - ``SIGNALFX_REALM`` - - ``realm`` is the Splunk Observability Cloud realm, for example, ``us0``. To find the realm name of your account, open the navigation menu in Splunk Observability Cloud, select :menuselection:`Settings`, and select your username. The realm name appears in the :guilabel:`Organizations` section. - * - ``SIGNALFX_SERVICE_NAME`` - - The name of your service or application. - * - ``SIGNALFX_ENV`` - - The name of your environment where you're instrumenting the application. - * - ``COR_ENABLE_PROFILING`` - - ``1`` - * - ``COR_PROFILER`` - - ``{B4C89B0F-9908-4F73-9F59-0D77C5A06874}`` - * - ``COR_PROFILER_PATH`` - - ``C:\home\signalfx\tracing\\win-x64\SignalFx.Tracing.ClrProfiler.Native.dll`` - * - ``COR_PROFILER_PATH_32`` - - ``C:\home\signalfx\tracing\\win-x86\SignalFx.Tracing.ClrProfiler.Native.dll`` - * - ``COR_PROFILER_PATH_64`` - - ``C:\home\signalfx\tracing\\win-x64\SignalFx.Tracing.ClrProfiler.Native.dll`` - * - ``CORECLR_ENABLE_PROFILING`` - - ``1`` - * - ``CORECLR_PROFILER`` - - ``{B4C89B0F-9908-4F73-9F59-0D77C5A06874}`` - * - ``CORECLR_PROFILER_PATH_32`` - - ``C:\home\signalfx\tracing\\win-x86\SignalFx.Tracing.ClrProfiler.Native.dll`` - * - ``CORECLR_PROFILER_PATH_64`` - - ``C:\home\signalfx\tracing\\win-x64\SignalFx.Tracing.ClrProfiler.Native.dll`` - * - ``SIGNALFX_DOTNET_TRACER_HOME`` - - ``C:\home\signalfx\tracing\`` - * - ``SIGNALFX_PROFILER_EXCLUDE_PROCESSES`` - - ``SnapshotUploader.exe;workerforwarder.exe`` - * - ``SIGNALFX_TRACE_LOG_PATH`` - - ``C:\home\LogFiles\signalfx\tracing\\dotnet-profiler.log`` - * - ``SIGNALFX_AZURE_APP_SERVICES`` - - ``0`` - -.. caution:: Set ``SIGNALFX_AZURE_APP_SERVICES`` to ``0`` when instrumenting WebJobs. Keep a separate App Service for the WebJob, so that you can use separate settings for your application and for the background service. - -.. _sfx-dotnet-profiling: - -Activate AlwaysOn Profiling -============================================================== - -AlwaysOn Profiling requires .NET 6.0 or higher. - -Limited support is available for the following legacy versions of .NET: - - - CPU profiling: .NET Core 3.1 and .NET 5.x - - Memory profiling: .NET Core 5.x - -To activate AlwaysOn Profiling, do the following: - -- Activate the profiler by setting the ``SIGNALFX_PROFILER_ENABLED`` environment variable to ``true`` for your .NET process. -- Activate memory profiling by setting the ``SIGNALFX_PROFILER_MEMORY_ENABLED`` environment variable to ``true``. - -For more configuration options, including setting a separate endpoint for profiling data, see :ref:`profiling-configuration-dotnet`. - -.. _kubernetes_dotnet: - -Deploy the .NET instrumentation in Kubernetes -================================================================== - -To deploy the .NET instrumentation in Kubernetes, configure the Kubernetes Downward API to expose environment variables to Kubernetes resources. - -The following example shows how to update a deployment to expose environment variables by adding the agent configuration under the ``.spec.template.spec.containers.env`` section: - -.. code-block:: yaml - - apiVersion: apps/v1 - kind: Deployment - spec: - selector: - matchLabels: - app: your-application - template: - spec: - containers: - - name: myapp - env: - - name: SPLUNK_OTEL_AGENT - valueFrom: - fieldRef: - fieldPath: status.hostIP - - name: SIGNALFX_ENDPOINT_URL - value: "http://$(SPLUNK_OTEL_AGENT):9411/api/v2/spans" - - name: SIGNALFX_SERVICE_NAME - value: '' - - name: SIGNALFX_ENV - value: '' - - name: CORECLR_ENABLE_PROFILING - value: "1" - - name: CORECLR_PROFILER - value: '{B4C89B0F-9908-4F73-9F59-0D77C5A06874}' - - name: CORECLR_PROFILER_PATH - value: '/opt/signalfx/SignalFx.Tracing.ClrProfiler.Native.so' - - name: SIGNALFX_DOTNET_TRACER_HOME - value: '/opt/signalfx' - -.. _export-directly-to-olly-cloud-dotnet: - -Send data directly to Splunk Observability Cloud -================================================================== - -By default, the instrumentation sends all telemetry to the local instance of the Splunk Distribution of OpenTelemetry Collector. - -To bypass the OTel Collector and send data directly to Splunk Observability Cloud, set the following environment variables: - -.. tabs:: - - .. code-tab:: shell Windows PowerShell - - $env:SIGNALFX_ACCESS_TOKEN= - $env:SIGNALFX_REALM= - - .. code-tab:: shell Linux - - export SIGNALFX_ACCESS_TOKEN= - export SIGNALFX_REALM= - -To obtain an access token, see :ref:`admin-api-access-tokens`. - -In the ingest endpoint URL, ``realm`` is the Splunk Observability Cloud realm, for example, ``us0``. To find the realm name of your account, follow these steps: - -#. Open the navigation menu in Splunk Observability Cloud. -#. Select :menuselection:`Settings`. -#. Select your username. - -The realm name appears in the :guilabel:`Organizations` section. - -For more information on the ingest API endpoints, see :new-page:`Send APM traces `. - -.. caution:: This procedure applies to spans and traces. To send AlwaysOn Profiling data, you must use the OTel Collector. - -Specify the source host --------------------------------------------------------------------- - - - -.. raw:: html - -
- -.. include:: /_includes/gdi/apm-api-define-host.rst - -.. raw:: html - -
- - - diff --git a/gdi/get-data-in/application/otel-dotnet/sfx/instrumentation/manual-dotnet-instrumentation.rst b/gdi/get-data-in/application/otel-dotnet/sfx/instrumentation/manual-dotnet-instrumentation.rst deleted file mode 100644 index cf0d7a4e6..000000000 --- a/gdi/get-data-in/application/otel-dotnet/sfx/instrumentation/manual-dotnet-instrumentation.rst +++ /dev/null @@ -1,57 +0,0 @@ -.. caution:: - - The SignalFx Instrumentation for .NET reached End of Support on February 21, 2025. The library has been archived and is no longer maintained. - - New customers instrumenting the .NET ecosystem should use the :ref:`Splunk Distribution of OpenTelemetry .NET `. Existing customers should consider migrating to Splunk Distribution of OpenTelemetry .NET which offers similar capabilities. To learn how to migrate, see :ref:`migrate-signalfx-dotnet-to-dotnet-otel`. - -.. _dotnet-manual-instrumentation: - -******************************************************************** -Manually instrument .NET applications for Splunk Observability Cloud -******************************************************************** - -.. meta:: - :description: Manually instrument your .NET application to add custom attributes to spans or manually generate spans. Keep reading to learn how to manually instrument your .NET application for Splunk Observability Cloud. - -The SignalFx Instrumentation for .NET provides and registers an OpenTracing-compatible global tracer that you can use to instrument your applications manually for Splunk Observability Cloud. Custom or manual instrumentation can be helpful when you need to add custom attributes to spans, or need to generate spans manually. - -.. note:: The SignalFx Instrumentation for .NET supports OpenTracing version 0.12.1 and higher. - -To instrument your .NET application manually, follow these steps: - -#. Add the OpenTracing dependency to your project: - - .. code-block:: xml - - - -#. Obtain the ``OpenTracing.Util.GlobalTracer`` instance and create spans: - - .. code-block:: csharp - - using OpenTracing; - using OpenTracing.Util; - - namespace MyProject - { - public class MyClass - { - public static async void MyMethod() - { - // Obtain the automatically registered OpenTracing.Util.GlobalTracer instance - var tracer = GlobalTracer.Instance; - - // Create an active span that automatically becomes a child span of any existing span in this context - using (IScope scope = tracer.BuildSpan("MyTracedFunctionality").StartActive(finishSpanOnDispose: true)) - { - var span = scope.Span; - span.SetTag("MyTag", "MyValue"); - span.Log("My Log Statement"); - - var ret = await MyAppFunctionality(); - - span.SetTag("FunctionalityReturned", ret.ToString()); - } - } - } - } diff --git a/gdi/get-data-in/application/otel-dotnet/sfx/sfx-instrumentation.rst b/gdi/get-data-in/application/otel-dotnet/sfx/sfx-instrumentation.rst deleted file mode 100644 index e48540a3c..000000000 --- a/gdi/get-data-in/application/otel-dotnet/sfx/sfx-instrumentation.rst +++ /dev/null @@ -1,57 +0,0 @@ -.. caution:: - - The SignalFx Instrumentation for .NET reached End of Support on February 21, 2025. The library has been archived and is no longer maintained. - - New customers instrumenting the .NET ecosystem should use the :ref:`Splunk Distribution of OpenTelemetry .NET `. Existing customers should consider migrating to Splunk Distribution of OpenTelemetry .NET which offers similar capabilities. To learn how to migrate, see :ref:`migrate-signalfx-dotnet-to-dotnet-otel`. - -.. _sfx-library-deprecated: - -************************************************************ -SignalFx Instrumentation for .NET (Deprecated) -************************************************************ - -.. meta:: - :description: The SignalFx Instrumentation for .NET is deprecated. Migrate to the Splunk Distribution of OpenTelemetry .NET to use the latest features. - -.. toctree:: - :hidden: - - Requirements - Instrument your .NET application - Connect trace data with logs - Configure the .NET instrumentation - Metrics and attributes - Manual instrumentation - Troubleshoot the .NET instrumentation - -The SignalFx Instrumentation for .NET provides zero-code instrumentation for popular .NET libraries and frameworks to collect and send telemetry data to Splunk Observability Cloud. - -.. raw:: html - - -

Features of the SignalFx Instrumentation for .NET

- - -The SignalFx Instrumentation for .NET provides the following features: - -- Collection and reporting of all spans -- AlwaysOn Profiling for CPU and memory -- Database Query Performance (from version 1.4.0) -- B3 and W3C headers for context propagation -- Zipkin trace exporter to send spans as JSON -- Support for existing custom instrumentation through OpenTracing -- Semantic conventions inspired by the OpenTelemetry standards - -.. raw:: html - - -

Get started

- - -To instrument your .NET application, follow these steps: - -#. Check compatibility and requirements. See :ref:`dotnet-requirements`. -#. Instrument your .NET application. See :ref:`instrument-dotnet-applications`. -#. Configure your instrumentation. See :ref:`advanced-dotnet-configuration`. - -You can also automatically instrument your .NET applications along with the Splunk Distribution of OpenTelemetry Collector installation. Zero-code instrumentation removes the need to install and configure the .NET library separately. See :ref:`windows-backend-auto-discovery` for the installation instructions. diff --git a/gdi/get-data-in/application/otel-dotnet/sfx/troubleshooting/common-dotnet-troubleshooting.rst b/gdi/get-data-in/application/otel-dotnet/sfx/troubleshooting/common-dotnet-troubleshooting.rst deleted file mode 100644 index 7caa2f081..000000000 --- a/gdi/get-data-in/application/otel-dotnet/sfx/troubleshooting/common-dotnet-troubleshooting.rst +++ /dev/null @@ -1,244 +0,0 @@ -.. caution:: - - The SignalFx Instrumentation for .NET reached End of Support on February 21, 2025. The library has been archived and is no longer maintained. - - New customers instrumenting the .NET ecosystem should use the :ref:`Splunk Distribution of OpenTelemetry .NET `. Existing customers should consider migrating to Splunk Distribution of OpenTelemetry .NET which offers similar capabilities. To learn how to migrate, see :ref:`migrate-signalfx-dotnet-to-dotnet-otel`. - -.. _common-dotnet-troubleshooting: - -******************************************************************* -Troubleshoot .NET instrumentation for Splunk Observability Cloud -******************************************************************* - -.. meta:: - :description: If your instrumented .NET application is not sending data to Splunk Observability Cloud, or data is missing, follow these steps to identify and resolve the issue. - :robots: noindex - -When you instrument a .NET application using the SignalFx Instrumentation for .NET and you don't see your data in Splunk Observability Cloud, follow these troubleshooting steps. - -.. _enable-dotnet-debug-logging: - -General troubleshooting -=================================================== - -Follow these steps to troubleshoot general instrumentation issues: - -#. Check that you've configured all settings according to your needs. See :ref:`advanced-dotnet-configuration`. - -#. Check what environment variables apply to your process using tools such as Process Explorer. On Linux, run ``cat /proc//environ`` where ```` is the process ID. - -#. Make sure that all environment variables are configured use the following commands: - - .. tabs:: - - .. code-tab:: shell Windows (PowerShell) - - # Run a tool like Process Explorer or execute the following: - - [System.Diagnostics.Process]::GetProcessById().StartInfo.EnvironmentVariables - - .. code-tab:: shell Linux - - cat /proc//environ # where is the process ID - -Activate debug logging ----------------------------------------------------- - -The SignalFx Instrumentation for .NET logs its configuration using ``INF`` log messages at startup. - -You can activate debug logging to obtain more information about the issue: - -#. Set the ``SIGNALFX_TRACE_DEBUG`` environment variable to ``true`` before starting your instrumented application. - -#. Run your application or service and generate some activity. - -#. Collect the debug logs. By default, log files are in the following locations: - - * Windows: ``%ProgramData%\SignalFx .NET Tracing\logs\`` - * Linux: ``/var/log/signalfx/dotnet/``. If it doesn't exist, run ``/opt/signalfx/createLogPath.sh``. - -You can change the default location by updating the ``SIGNALFX_TRACE_LOG_DIRECTORY`` environment variable. See :ref:`dotnet-debug-logging-settings` for more information and settings. - -.. note:: If you've enabled debug logging and restarted the application, but you don't find any logs in the previous locations, check that other APM agents aren't running or aren't installed on the host. Multiple APM agents might prevent the SignalFx Instrumentation for .NET from instrumenting the application. - -.. caution:: Activate debug logging only when needed. Debug mode requires more resources. - -Traces don't appear in Splunk Observability Cloud -================================================================== - -If traces from your instrumented application or service are not available in Splunk Observability Cloud, verify the OpenTelemetry Collector configuration: - -* Make sure that the Splunk Distribution of OpenTelemetry Collector is running. -* Make sure that a ``zipkin`` receiver and an ``otlp`` exporter are configured. -* Make sure that the ``access_token`` and ``endpoint`` fields are configured. -* Check that the traces pipeline is configured to use the ``zipkin`` receiver and ``otlp`` exporter. - -Metrics don't appear in Splunk Observability Cloud -================================================================== - -If metrics from your instrumented application or service are not available in Splunk Observability Cloud, make sure that the following conditions are true: - -* The Splunk Distribution of OpenTelemetry Collector is running. -* A ``signalfx`` receiver and a ``signalfx`` exporter are configured. -* The ``access_token`` and ``realm`` fields are configured. -* The metrics pipeline is configured to use the ``signalfx`` receiver and ``signalfx`` exporter. - -.. _dotnet-troubleshoot-linux: - -.NET instrumentation not working on Linux -===================================================== - -Installing the instrumentation on Linux might fail if you use an incompatible package. - -Make sure that you're using an installation package that is compatible with your Linux distribution. To find out your distribution or package manager, run the following commands: - -.. code-block:: shell - - lsb_release -a - cat /etc/*release - cat /etc/issue* - cat /proc/version - -.. _dotnet-troubleshoot-cpu: - -High CPU usage -==================================================== - -By default, the SignalFx Instrumentation for .NET instruments all .NET processes running on the host automatically. This might significantly increase CPU usage if you've activated the instrumentation in the system or user scope. Make sure that the instrumentation's environment variables are always set in the process or terminal scope. - -To restrict global instrumentation to a set of processes, use the ``SIGNALFX_PROFILER_PROCESSES`` and ``SIGNALFX_PROFILER_EXCLUDE_PROCESSES`` environment variables, which include and exclude processes for instrumentation. See :ref:`advanced-dotnet-configuration` for more information. - -.. _dotnet-profiler-issues: - -Troubleshoot AlwaysOn Profiling for .NET -=============================================================== - -See the following common issues and fixes for AlwaysOn Profiling: - -Check that AlwaysOn Profiling is activated ----------------------------------------------------------------- - -The .NET instrumentation logs the string ``AlwaysOnProfiler::MemoryProfiling`` started at ``info`` log level. To check whether AlwaysOn Profiling is activated, search your logs for strings similar to the following: - -.. code-block:: bash - - 10/12/22 12:10:31.962 PM [12096|22036] [info] AlwaysOnProfiler::MemoryProfiling started. - -If no string appears, make sure that you've activated the profiler by setting the ``SIGNALFX_PROFILER_ENABLED`` environment variable to ``true``. See :ref:`profiling-configuration-dotnet`. - -If you've activated the CPU profiler or the memory profiler on an unsupported runtime version, entries similar to the following entry appear in the logs: - -.. code-block:: bash - - 2022-10-12 12:37:18.640 +02:00 [WRN] Cpu profiling activated but not supported. - 2022-10-12 12:37:18.640 +02:00 [WRN] Memory profiling activated but not supported. - -Check the AlwaysOn Profiling configuration ----------------------------------------------------------------- - -If AlwaysOn Profiling is :ref:`not working as intended `, check the configuration settings. The .NET instrumentation logs AlwaysOn Profiling settings using INF messages at startup. Search for the string ``TRACER CONFIGURATION``. - -Unsupported .NET version ------------------------------------------------ - -To use AlwaysOn Profiling, upgrade your .NET version to .NET Core 3.1 or .NET 5.0 and higher. Memory profiling requires .NET 5.0 and higher, as ``ICorProfilerInfo10`` must be available in the runtime. - -None of the .NET Framework versions is supported. - -AlwaysOn Profiling data and logs don't appear in Splunk Observability Cloud ------------------------------------------------------------------------------- - -Collector configuration issues might prevent AlwaysOn Profiling data and logs from appearing in Splunk Observability Cloud. - -To solve this issue, do the following: - -#. Check the configuration of the SignalFx Instrumentation for .NET, especially ``SIGNALFX_PROFILER_LOGS_ENDPOINT``. -#. Verify that the Splunk Distribution of OpenTelemetry Collector is running at the expected endpoint and that the application host or container can resolve the host name and connect to the OTLP port. -#. Make sure that you're running the Splunk Distribution of OpenTelemetry Collector and that the version is 0.34 or higher. The required version for memory profiling is 0.44. Other collector distributions might not be able to route the log data that contains profiling data. -#. A custom configuration might override settings that let the collector handle profiling data. Make sure to configure an ``otlp`` receiver and a ``splunk_hec`` exporter with correct token and endpoint fields. The ``profiling`` pipeline must use the OTLP receiver and Splunk HEC exporter you've configured. See :ref:`splunk-hec-exporter` for more information. - -The following snippet contains a sample ``profiling`` pipeline: - -.. code-block:: yaml - - receivers: - otlp: - protocols: - grpc: - - exporters: - # Profiling - splunk_hec/profiling: - token: "${SPLUNK_ACCESS_TOKEN}" - endpoint: "${SPLUNK_INGEST_URL}/v1/log" - log_data_enabled: false - - processors: - batch: - memory_limiter: - check_interval: 2s - limit_mib: ${SPLUNK_MEMORY_LIMIT_MIB} - - service: - pipelines: - logs/profiling: - receivers: [otlp] - processors: [memory_limiter, batch] - exporters: [splunk_hec, splunk_hec/profiling] - -Loss of profiling data or gaps in profiling data -------------------------------------------------------------- - -When the instrumentation can't send data to Splunk OpenTelemetry Collector due to full buffers, AlwaysOn Profiling activates the escape hatch, which drops all logs with profiling data until the buffers are empty. - -If the escape hatch activates, it logs the following message: - -.. code-block:: bash - - Skipping a thread sample period, buffers are full. - -You can also look for the ``** THIS WILL RESULT IN LOSS OF PROFILING DATA **.`` message. - -The thread sampler resumes its activity when any of the buffers is empty. - -To avoid the loss of profiling data due to full buffers, check the configuration and the communication layer between your process and the Splunk Distribution of OpenTelemetry Collector. - -.. _uninstall-dotnet-sfx: - -Uninstall the SignalFx Instrumentation for .NET -===================================================== - -To remove the SignalFx Instrumentation for .NET, follow the instructions for each operating system. - -Windows ----------------------- - -Follow these steps to remove the SignalFx Instrumentation for .NET: - -#. Stop all instrumented services or applications. -#. Remove all environment variables you might have set for the instrumentation. -#. Uninstall :strong:`SignalFx .NET Tracing` from the :guilabel:`Programs and Features` control panel. - -Linux ----------------------- - -Follow these steps to remove the SignalFx Instrumentation for .NET: - -#. Stop all instrumented services or applications. -#. Remove all environment variables you might have set for the instrumentation. -#. Remove ``signalfx-dotnet-tracing`` using your package manager or delete the files from ``/opt/signalfx`` if you installed the instrumentation using the tar file. - - - -.. raw:: html - -
- -.. include:: /_includes/troubleshooting-components.rst - -.. raw:: html - -
- - - diff --git a/gdi/get-data-in/application/otel-dotnet/troubleshooting/common-dotnet-troubleshooting.rst b/gdi/get-data-in/application/otel-dotnet/troubleshooting/common-dotnet-troubleshooting.rst index 0b1c92b67..1a14366dc 100644 --- a/gdi/get-data-in/application/otel-dotnet/troubleshooting/common-dotnet-troubleshooting.rst +++ b/gdi/get-data-in/application/otel-dotnet/troubleshooting/common-dotnet-troubleshooting.rst @@ -84,8 +84,6 @@ If traces from your instrumented application or service are not available in Spl Verify the supported .NET versions ---------------------------------------------------------------- -Make sure that your application targets :ref:`the supported versions of .NET `. - If the .NET version you're using is not supported, your log entries might be similar to the following: .. code-block:: bash diff --git a/gdi/get-data-in/application/otel-dotnet/troubleshooting/migrate-signalfx-dotnet-to-dotnet-otel.rst b/gdi/get-data-in/application/otel-dotnet/troubleshooting/migrate-signalfx-dotnet-to-dotnet-otel.rst index 8e5820f38..3d437d01d 100644 --- a/gdi/get-data-in/application/otel-dotnet/troubleshooting/migrate-signalfx-dotnet-to-dotnet-otel.rst +++ b/gdi/get-data-in/application/otel-dotnet/troubleshooting/migrate-signalfx-dotnet-to-dotnet-otel.rst @@ -1,8 +1,15 @@ .. _migrate-signalfx-dotnet-to-dotnet-otel: -********************************************** -Migrate from the SignalFx .NET Instrumentation -********************************************** +.. caution:: + + The SignalFx Instrumentation for .NET reached End of Support on February 21, 2025. The library has been archived and is no longer maintained. + + If you want to instrument the .NET ecosystem use the :ref:`Splunk Distribution of OpenTelemetry .NET `. + + +***************************************************************** +Migrate to OpenTelemetry from the SignalFx .NET Instrumentation +***************************************************************** .. meta:: :description: The agent of the Splunk Distribution of OpenTelemetry .NET is an alternative to the SignalFx Instrumentation for .NET. To migrate from the SignalFx instrumentation, follow these instructions. @@ -23,7 +30,7 @@ Migrate to the Splunk Distribution of OpenTelemetry .NET To migrate from the SignalFx Instrumentation for .NET to the Splunk Distribution of OpenTelemetry .NET, follow these steps: -#. Uninstall the SignalFx Instrumentation for .NET. See :ref:`uninstall-dotnet-sfx`. +#. Uninstall the SignalFx Instrumentation for .NET. #. Install and activate the Splunk Distribution of OpenTelemetry .NET. See :ref:`install-dotnet-otel-instrumentation`. #. Specify the endpoint of the OpenTelemetry Collector you're exporting traces to. See :ref:`dotnet-otel-exporter-settings`. #. Update your settings. See :ref:`changes-functionality-dotnet-otel`. diff --git a/gdi/get-data-in/application/python/version1x/get-started-1x.rst b/gdi/get-data-in/application/python/version1x/get-started-1x.rst index 35c8d2915..7cb05b5c8 100644 --- a/gdi/get-data-in/application/python/version1x/get-started-1x.rst +++ b/gdi/get-data-in/application/python/version1x/get-started-1x.rst @@ -31,4 +31,3 @@ To instrument your Python application, follow these steps: For more information, see :ref:`splunk-python-otel-dist`. -.. note:: The SignalFx Python Agent is deprecated and will reach End of Support on December 17th, 2022. See :ref:`migrate-signalfx-python-agent-to-otel` to migrate to the Splunk Distribution of OpenTelemetry Python. diff --git a/gdi/opentelemetry/automatic-discovery/k8s/k8s-backend.rst b/gdi/opentelemetry/automatic-discovery/k8s/k8s-backend.rst index 788beb373..95c1db9ef 100644 --- a/gdi/opentelemetry/automatic-discovery/k8s/k8s-backend.rst +++ b/gdi/opentelemetry/automatic-discovery/k8s/k8s-backend.rst @@ -53,7 +53,7 @@ Make sure you've also installed the components specific to your language runtime .. tab:: .NET - * .NET version 6.0 or higher and supported .NET application libraries. For a list of supported libraries, see :ref:`supported-dotnet-libraries`. + * .NET version 6.0 or higher and supported .NET application libraries. * x86 or AMD64 (x86-64) architecture. ARM architectures aren't supported. .. tab:: Node.js @@ -646,7 +646,6 @@ To troubleshoot common errors that occur when instrumenting applications, see th * Java: :ref:`common-java-troubleshooting` * Node.js: :ref:`common-nodejs-troubleshooting` -* .NET: :ref:`common-dotnet-troubleshooting` Learn more =========================================================================== diff --git a/gdi/opentelemetry/automatic-discovery/linux/linux-backend.rst b/gdi/opentelemetry/automatic-discovery/linux/linux-backend.rst index a6192a3e7..c94274ae6 100644 --- a/gdi/opentelemetry/automatic-discovery/linux/linux-backend.rst +++ b/gdi/opentelemetry/automatic-discovery/linux/linux-backend.rst @@ -673,7 +673,6 @@ To troubleshoot common errors that occur when instrumenting applications, see th * Java: :ref:`common-java-troubleshooting` * Node.js: :ref:`common-nodejs-troubleshooting` -* .NET: :ref:`common-dotnet-troubleshooting` .. _auto-discovery-view-results-linux: @@ -681,4 +680,4 @@ View results in Splunk APM ==================================================== After activating zero-code instrumentation, ensure your data is flowing into Splunk Observability Cloud. See :ref:`verify-apm-data`. - \ No newline at end of file + diff --git a/logs/severity-key.rst b/logs/severity-key.rst index 52e82b1a0..1e58a396a 100644 --- a/logs/severity-key.rst +++ b/logs/severity-key.rst @@ -7,15 +7,48 @@ Ensure the correct mapping of your severity key .. meta:: :description: Log Observer Connect relies on the correct mapping of the severity key. Confirm that your severity key is correctly mapped. -The Log Observer Connect timeline displays a histogram of logged events over time, grouped by values of the message field :guilabel:`severity`. The severity key is a field that all logs contain. It has the values :guilabel:`DEBUG`, :guilabel:`ERROR`, :guilabel:`INFO`, :guilabel:`UNKNOWN`, and :guilabel:`WARNING`. Your logs might use a different field name for the severity key. Because the severity key in many logs is called :guilabel:`level`, Log Observer Connect automatically remaps the log field :guilabel:`level` to :guilabel:`severity`. +The Log Observer Connect timeline displays a histogram of logged events over time, grouped by values of the message field :guilabel:`severity`. The severity key is a field that all logs contain. It has the values :guilabel:`debug`, :guilabel:`error`, :guilabel:`info`, :guilabel:`unknown`, and :guilabel:`warning`. Your logs might use a different field name for the severity key. -If your logs call the severity key by a different name, that's okay. To ensure that Log Observer Connect can read your field, transform your field name to :guilabel:`severity` or add a :guilabel:`severity` alias to your field name. To transform your field name, see :new-page:`Extract fields from event data using Ingest Processor `. To add an alias to your field name, see :ref:`logs-alias`. +If your logs call the severity key or its values by different names, that's okay. Ensure that Log Observer Connect can read your field and value names. Log Observer Connect assigns :guilabel:`unknown` to all values that it does not recognize. -The mapping of your severity key and its values is case sensitive. The key and its values must appear exactly as follows: +.. note:: The names of your severity key and its values are not case sensitive. + +Your severity key can have any of the following names: * severity -* DEBUG -* ERROR -* INFO -* UNKNOWN -* WARNING \ No newline at end of file +* level +* otel.log.severity.text + +The following table lists the values that Log Observer Connect recognizes for each severity name: + +.. list-table:: + :header-rows: 1 + :widths: 50, 50 + + * - :guilabel:`Severity field names` + - :guilabel:`Severity value names` + + * - severity + - | info, information + | err, error + | warn, warning + | debug + | critical + + * - level + - | info, information + | err, error + | warn, warning + + * - otel.log.severity.text + - | normal + | warn, warning + + +If your severity key or values do not match any of the names in the previous table, do one of the following to turn them to names that Log Observer Connect recognizes: + +* Use a field extraction to transform your field name. See :new-page:`Extract fields from event data using Ingest Processor ` to learn how. + +* Add a :guilabel:`severity` alias to your field name. See :ref:`logs-alias` to learn how. + +When you create an alias for your severity key name, the original key name and its aliases continue to function for Log Observer queries. On the Log Observer timeline histogram, the severity key name and all its aliases are combined into one and represented as "severity". \ No newline at end of file diff --git a/release-notes/2025-3-rn.rst b/release-notes/2025-3-rn.rst index 247b2cf70..fb4a6e4c6 100644 --- a/release-notes/2025-3-rn.rst +++ b/release-notes/2025-3-rn.rst @@ -6,6 +6,34 @@ March 2025 Splunk Observability Cloud released the following new features and enhancements in March 2025. This is not an exhaustive list of changes in the observability ecosystem. For a detailed breakdown of changes in versioned components, see the :ref:`list of changelogs `. + +.. _2025-3-25-rn: + +March 25, 2025 release +======================= + +.. list-table:: + :header-rows: 1 + :widths: 1 2 + :width: 100% + + * - New feature or enhancement + - Description + * - APM error based troubleshooting + - Quickly understand the root cause of an issue for a specific service without manually setting up index span tags, looking at other traces, or referring back to the service map. For more information, see :ref:`apm-service-view`. + * - APM service centric navigation and filtering + - Improves user navigation in Splunk APM for visualizing, navigating and filtering through services. Service Centric Views in Splunk APM is now more prominently featured on the landing page so users can quickly understand service health without additional click-downs in the product. + * - APM service map redesign + - Service Maps in Splunk APM help engineering teams to quickly identify error sources and latency in complex application environments. We’ve redesigned the service map in this release to make it easier for users to get a holistic view of a service in the context of the larger environment. + * - Synthetics excluded files + - We are excited to introduce the Excluded Files feature for users to have flexibility in configuring what file types their browser tests will exclude from loading on a page. By excluding certain file types, users can prevent skewed analytics due to third-party services and individually test performance of a page with or without certain resources. For more information, see :ref:`browser-adv-setting`. + * - Log Observer Connect search experience enhancements + - * We’re releasing a new “cancel search” functionality to help users gain more control over their log queries by cancelling a log search whenever one is active, allowing them to eliminate workflow inefficiencies and reduce their SVC consumption as well as resource waste. For more information, see :ref:`logs-keyword`. + * We have expanded automatic mapping of the severity key to include more key and value names. This ensures broader compatibility, including OpenTelemetry field names, and reduces the need for custom alias creation. For more information, see :ref:`logs-keyword`. + * We have added guidance in the UI to help you select the appropriate connection and indexes to sharpen the focus of your searches. For more information, see :ref:`severity-key`. + * - SSO default role + - When onboarding new Splunk Observability Cloud users, admins who aren’t able to enable Unified Identity can now select what the default role will be assigned to users in the Organization (Non-Enterprise Customers: Admin & Power; Enterprise Customers: Admin, Power, Read_Only, Usage) for more control on user’s scope and privileges. For more information, see :ref:`sso-label`. + .. _2025-3-4-rn: March 4, 2025 release diff --git a/release-notes/release-notes-overview.rst b/release-notes/release-notes-overview.rst index 99c05dc84..e1a66bd1e 100644 --- a/release-notes/release-notes-overview.rst +++ b/release-notes/release-notes-overview.rst @@ -32,6 +32,7 @@ Each release date includes new features and enhancements for SaaS and versioned - Release date * - :ref:`2025-3-rn` - * :ref:`2025-3-4-rn` + * :ref:`2025-3-25-rn` * - :ref:`2025-2-rn` - * :ref:`2025-2-4-rn` * - :ref:`2024-11-rn` diff --git a/synthetics/browser-test/set-up-browser-test.rst b/synthetics/browser-test/set-up-browser-test.rst index ba42cb8eb..fdb1f624d 100644 --- a/synthetics/browser-test/set-up-browser-test.rst +++ b/synthetics/browser-test/set-up-browser-test.rst @@ -2,17 +2,17 @@ .. _set-up-browser-test: ************************************** -Set up a Browser test +Set up a browser test ************************************** .. meta:: :description: Steps to set up a browser test to track the performance of specific site resources, or a multi-step user flow, in Splunk Synthetic Monitoring. -Use a Browser test to monitor the user experience for a single page or a multi-step user flow by running a synthetic test of the URLs you provide. Use this type of test to monitor conversion paths or any path that requires multiple steps or runs JavaScript. For an example, see :ref:`browser-test-scenario`. +Use a browser test to monitor the user experience for a single page or a multi-step user flow by running a synthetic test of the URLs you provide. Use this type of test to monitor conversion paths or any path that requires multiple steps or runs JavaScript. For an example, see :ref:`browser-test-scenario`. -For each page checked in a Browser test, Splunk Synthetic Monitoring captures an HTTP Archive (HAR) file, represented in a waterfall chart, which illustrates the performance of specific resources within the page. Browser tests also capture a set of 40+ metrics. See :ref:`waterfall-chart` and :ref:`browser-metrics` to learn more. +For each page checked in a browser test, Splunk Synthetic Monitoring captures an HTTP Archive (HAR) file, represented in a waterfall chart, which illustrates the performance of specific resources within the page. Browser tests also capture a set of 40+ metrics. See :ref:`waterfall-chart` and :ref:`browser-metrics` to learn more. .. note:: If the site or application you are monitoring uses allow lists or block lists for visitors or an analytics tool to measure traffic, check that it's configured to accommodate traffic from Splunk Synthetic Monitoring. See :ref:`synth-configure-app` for instructions. @@ -20,13 +20,13 @@ For each page checked in a Browser test, Splunk Synthetic Monitoring captures an -Set up a Browser test +Set up a browser test ========================= -For optimal experience, synthetics browser tests use a stable version of Google Chrome: ``116.0.5845.96-1`` to simulate user activity. +For optimal experience, browser tests use a stable version of Google Chrome: ``116.0.5845.96-1`` to simulate user activity. -Follow these steps to set up a Browser test: +Follow these steps to set up a browser test: #. From the landing page of Splunk Observability Cloud, navigate to Splunk Synthetic Monitoring. @@ -34,12 +34,12 @@ Follow these steps to set up a Browser test: #. In the :guilabel:`Name` field, enter a name for your test. -#. To add steps and synthetic transactions to your Browser test, select :guilabel:`Edit steps or synthetic transactions`. See :ref:`add-transactions` to learn more. +#. To add steps and synthetic transactions to your browser test, select :guilabel:`Edit steps or synthetic transactions`. See :ref:`add-transactions` to learn more. -#. As you build your test, you can use :guilabel:`Try now` to check that the configuration of your test is valid. Try now results are ephemeral and don’t impact persisted run metrics. For more, see :ref:`try-now`. +#. As you build your test, you can use :guilabel:`Try now` to check that the configuration of your test is valid. Try now results are ephemeral and don't impact persisted run metrics. See :ref:`try-now`. -#. (Optional) Add a wait time before a step executes. See, :ref:`browser-wait-times`. -#. (Optional) Turn on automatic test retry in the event a test initially fails. +#. (Optional) Add a wait time before a step executes. See :ref:`browser-wait-times`. +#. (Optional) Enable automatic test retry in the event a test initially fails. #. Save your test. @@ -80,23 +80,23 @@ For steps on how to make a Google Chrome recording, see :new-page:`Record, repla Import a Google Chrome Recorder JSON file -------------------------------------------------------- -.. Note:: Included within recordings from Google Chrome Recorder is the specific viewport size of the browser window used in the recording. When imported, this recorded viewport is not imported into the Synthetics Browser test. Check that the Synthetics Browser test device selection accurately represents the viewport size used by the recorded browser window. +.. Note:: Recordings from Google Chrome Recorder include the specific viewport size of the browser window used in the recording. When you import a recording, Splunk RUM doesn't import the viewport size into the browser test. Therefore, you must check that the test's device setting matches the viewport size used by the recorded browser window. -Follow these steps to import a JSON file from Google Chrome Recorder to a new or existing Browser test. +Follow these steps to import a JSON file from Google Chrome Recorder to a new or existing browser test. #. In Splunk Synthetic Monitoring, select :guilabel:`Edit` on an existing Browser test to open the test configuration page, or create a new test. -#. Select Import. +#. Select :guilabel:`Import`. #. Upload the Google Chrome Recorder JSON file. -#. If a step is not supported, you need to edit or delete the step in the test configuration page. +#. If a step is not supported, edit or delete that step in the test configuration page. #. (Optional) Add a name to each step. #. Save your changes. Troubleshoot unsupported steps ======================================= -If your recording contains unsupported steps, you need to edit the step to reformat it into one of the supported Synthetic Browser step types. The following table shows how Google Chrome Recorder step names and code snippets map to their counterparts in Splunk Synthetic Browser tests. These examples use Buttercup Games, a fictitious game company. +If your recording contains unsupported steps, you need to edit the step to reformat it into one of the supported browser step types. The following table shows how Google Chrome Recorder step names and code snippets map to their counterparts in browser tests. These examples use Buttercup Games, a fictitious gaming company. .. tabs:: @@ -350,7 +350,7 @@ If your recording contains unsupported steps, you need to edit the step to refor -View your Browser test +View your browser test ==================================== Now that you created and saved a test, check whether it's collecting data as expected: @@ -358,13 +358,13 @@ Now that you created and saved a test, check whether it's collecting data as exp #. From the :guilabel:`Tests` list, select the three-dot :guilabel:`Actions` menu and select :guilabel:`Play` arrow icon to manually trigger a live run of the test, or wait for at least one duration of the test frequency you set so that the test has time to run and collect data. #. Select the test you're interested in to open the :guilabel:`Test history` view, where you can view visualizations of recent test results and metrics. -#. See :ref:`browser-test-results` to learn more about Browser test results. +#. See :ref:`browser-test-results` to learn more about browser test results. -Edit your Browser test +Edit your browser test ======================== -To edit your Browser test, do the following: +To edit your browser test, do the following: #. Select the row for the test you want to edit in the :guilabel:`Tests` list to open the :guilabel:`Test history` view. #. Select :guilabel:`Edit test` to edit your test configuration. @@ -373,7 +373,7 @@ If you change the name of your test or the name of a synthetic transaction, it m .. _browser-adv-setting: -Advanced settings for Browser tests +Advanced settings for browser tests ============================================================ There are many reasons why you might want to configure advanced settings for your synthetics tests. Here are a few: @@ -395,7 +395,7 @@ Interactive metrics are collected by default for each page in the test flow, but * First CPU idle: Time until the page is minimally interactive and responds to user input. * Time to interactive: This measures the time until the page responds to user input quickly. It is used to identify when the page is actually usable, not just when the page load looks complete. -* Lighthouse score: A weighted aggregation of several Browser test metric values calculated using v10 of the Lighthouse desktop scoring algorithm. See :new-page:`https://developer.chrome.com/docs/lighthouse/performance/performance-scoring#lighthouse_10` in the Google developer documentation to learn more about Lighthouse scoring. +* Lighthouse score: A weighted aggregation of several browser test metric values calculated using v10 of the Lighthouse desktop scoring algorithm. See :new-page:`https://developer.chrome.com/docs/lighthouse/performance/performance-scoring#lighthouse_10` in the Google developer documentation to learn more about Lighthouse scoring. .. _auto-retry: @@ -473,14 +473,14 @@ You can also indicate whether to retain the original ``HOST`` header by activati Wait times --------------------- -Optimize your test coverage by adding custom wait times to capture longer page loads and improve the accuracy of run results. Applications with long load times can cause a Browser test to fail. If you know that there are certain steps in a workflow that take longer than 10 seconds, add a custom wait time to your Browser test. +Optimize your test coverage by adding custom wait times to capture longer page loads and improve the accuracy of run results. Applications with long load times can cause a browser test to fail. If you know that there are certain steps in a workflow that take longer than 10 seconds, add a custom wait time to your browser test. -* Wait times are available with Browser tests only. +* Wait times are available with browser tests only. * The maximum custom wait time for each test is 200 seconds. -Follow these steps to configure custom wait times for your Browser tests: +Follow these steps to configure custom wait times for your browser tests: -#. In Splunk Synthetic Monitoring, select :guilabel:`Edit` on the Browser test to open the configuration panel. +#. In Splunk Synthetic Monitoring, select :guilabel:`Edit` on the browser test to open the configuration panel. #. Select :guilabel:`New step > Wait`, from the step type drop down. #. Add a name and the wait time in ms. #. When you finish instrumenting your test, save the workflow: :guilabel:`Return to test > Save`. @@ -527,7 +527,6 @@ Here are the limits for each type of wait time. The maximum limit for a run is 3 - Chrome flags ---------------- Google Chrome flags are a helpful tool for troubleshooting. Activate browser features that are not available by default to test custom browser configurations and specialized use cases, like a proxy server. @@ -540,8 +539,6 @@ Note: Global variables are incompatible with Chrome flags. These are the flags available: - - .. raw:: html
@@ -555,6 +552,44 @@ These are the flags available: +Excluded files +------------------------------ + +You can configure your browser test to ignore specific file types or patterns so that it skips all HTTP requests that match those file types or patterns. + +Exclusion rules are useful to: + + +* Prevent false alerts from test analytics. +* Test the performance of a page with or without specific resources loading. +* Prevent specific third-party services from loading, such as random pop-ups from third-party services. +* Ignore files that are known to cause performance problems. + + +To create an exclusion rule: + +#. On the browser test's configuration page, select the :guilabel:`Advanced` toggle. +#. Scroll down to the :guilabel:`Custom content` section. +#. Select :guilabel:`Add excluded file`. +#. Select a value in :guilabel:`File type`: + + .. image:: /_images/synthetics/synthetics-browser-test-excluded-files.png + :width: 60% + :alt: This image shows an exclusion rule for all files of type Crazy Egg. + + * To exclude all files of a common predefined type, select that type. + * To exclude all file types except those that match the value you specify, select :guilabel:`All Except` and specify a value or regular expression. + * To use regular expressions, select :guilabel:`Custom` and specify a value or regular expression. + For example: + + * To exclude a specific domain, including all of its subdomains, enter ``domainname\.com`` + * To exclude only the subdomains of a specific domain, but not the domain itself, enter ``.+\.domainname\.com`` + * To exclude a JavaScript app, enter ``domainname\.com/appname\.js`` + * To exclude entire directories, enter ``domainname\.com/directoryname\/.+`` + +.. note:: + :guilabel:`All Except` inclusions take precedence over other exclusions. The order in which you specify exclusions doesn't matter except when you're using a combination of :guilabel:`All Except` and :guilabel:`Custom`. + .. _browser-custom-props: @@ -568,14 +603,14 @@ Add custom properties in the test creation page in advanced settings. Use key-va :alt: This image shows two custom property key value pairs, env:prod and role:developer. -Custom properties are single-valued and don’t support multiple values, like ``region:eu, us``. For each test, you can only use one and unique key. For example, you can have ``env1:test`` and ``env:test`` in the same test, but you can't have ``env:test``, and ``env:prod``. +Custom properties are single valued and don't support multiple values, like ``region:eu, us``. For each test, you can only use one and unique key. For example, you can have ``env1:test`` and ``env:test`` in the same test, but you can't have ``env:test``, and ``env:prod``. Key requirements: * Keys must start with an uppercase or lowercase letter. Keys can't start with special characters or numbers. * The remainder of the key can contain letters, numbers, underscores and hyphens. - * Keys can’t be named ``test_id`` or ``test``. + * Keys can't be named ``test_id`` or ``test``. * Key size can't exceed 128 characters. See, :ref:`custom-properties`.