cwielenb/CNCF-Dataset huggingface dataset:
Project: Flagsmith (Observability and Analysis / Feature Flagging)
File: dynatrace.md

title: Dynatrace Integration sidebar_label: Dynatrace hide_title: true You can integrate Flagsmith with Dynatrace. Send flag change events from Flagsmith into your Dynatrace event stream. :::tip The Flagsmith Javascript SDK can also talk to the Dynatrace Javascript SDK. . ::: Log into Dynatrace create a new Access Token with the following permissions: `API v2 scopes` : `Ingest events` Go to Flagsmith > Integrations > Dynatrace > Add Integration Select the `Flagsmith Environment` you want to track. The `Base URL` depends on your Dynatrace installation: Managed: `https://{your-domain}/e/{your-environment-id}/` SaaS: `https://{your-environment-id}.live.dynatrace.com/` Environment ActiveGate: `https://{your-activegate-domain}/e/{your-environment-id}/` The `API Key` is the Access Token you created in step 1. The `Entity Selector` defines which Dynatrace entities you want to associate Flag Change events with. for more information on those. Once the setup is complete, try changing a Flag value in the Environment you configured during setup. Then look at one of the Dynatrace Entities defined in the `Entity Selector`. You will see Deployment Events show up in the Events panel. You can also send Identity flag values from Flagsmith to Dynatrace using our .
Project: Grafana Pyroscope (Observability and Analysis / Observability)
File: pyroscope-in-grafana.md

title: Pyroscope and profiling in Grafana menuTitle: Pyroscope in Grafana description: Learn about how you can use profile data in Grafana. weight: 200 keywords: Pyroscope Profiling Grafana <!-- This is placeholder page while we get the content written. --> Pyroscope can be used alongside the other Grafana tools such as Loki, Tempo, Mimir, and k6. You can use Pyroscope to get the most granular insight into your application and how you can use it to fix issues that you may have identified via metrics, logs, traces, or anything else. You can use Pyroscope within Grafana by using the . This plugin lets you query Pyroscope data from within Grafana and visualize it alongside your other Grafana data. Here is a screenshot of the Explore page where combined traces and profiles to be able to see granular line-level detail when available for a trace span. This allows you to see the exact function that's causing a bottleneck in your application as well as a specific request. Here is an example of how you can integrate profiles into your dashboards. In this case, the screenshot shows memory profiles alongside panels for logs and metrics to be able to debug OOM errors alongside the associated logs and metrics.
Project: Grafana (Observability and Analysis / Observability)
File: redux.md

Grafana uses to handle Redux boilerplate code. Some of our Reducers are used by Angular and therefore state is to be considered as mutable for those reducers. Fluent API that simplifies the testing of reducers ```typescript reducerTester() .givenReducer(someReducer, initialState) .whenActionIsDispatched(someAction('reducer tests')) .thenStateShouldEqual({ ...initialState, data: 'reducer tests' }); ``` Sometimes you encounter a `resulting state` that contains properties that are hard to compare, such as `Dates`, but you still want to compare that other props in state are correct. Then you can use `thenStatePredicateShouldEqual` function on `reducerTester` that will return the `resulting state` so that you can expect upon individual properties.. ```typescript reducerTester() .givenReducer(someReducer, initialState) .whenActionIsDispatched(someAction('reducer tests')) .thenStatePredicateShouldEqual((resultingState) => { expect(resultingState.data).toEqual('reducer tests'); return true; }); ``` Fluent API that simplifies the testing of thunks. ```typescript const dispatchedActions = await thunkTester(initialState).givenThunk(someThunk).whenThunkIsDispatched(arg1, arg2, arg3); expect(dispatchedActions).toEqual([someAction('reducer tests')]); ``` It is possible to infer connected props automatically from `mapStateToProps` and `mapDispatchToProps` using a helper type `ConnectedProps` from Redux. For this to work the `connect` call has to be split into two parts. ```typescript import { connect, ConnectedProps } from 'react-redux'; const mapStateToProps = (state: StoreState) => { return { location: state.location, initDone: state.panelEditor.initDone, uiState: state.panelEditor.ui, }; }; const mapDispatchToProps = { updateLocation, initPanelEditor, panelEditorCleanUp, setDiscardChanges, updatePanelEditorUIState, updateTimeZoneForSession, }; const connector = connect(mapStateToProps, mapDispatchToProps); type Props = OwnProps & ConnectedProps<typeof connector>; class PanelEditorUnconnected extends PureComponent<Props> {} export const PanelEditor = connector(PanelEditorUnconnected); ``` For more examples, refer to the .
Project: Netdata (Observability and Analysis / Observability)
File: user_groups.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/apps.plugin/integrations/user_groups.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/apps.plugin/metadata.yaml" sidebar_label: "User Groups" learn_status: "Published" learnrelpath: "Collecting Metrics/Processes and System Services" most_popular: False message: "DO NOT EDIT THIS FILE DIRECTLY, IT IS GENERATED BY THE COLLECTOR'S metadata.yaml FILE" endmeta--> <img src="https://netdata.cloud/img/user.svg" width="150"/> Plugin: apps.plugin Module: groups <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> This integration monitors resource utilization on a user groups context. This collector is supported on all platforms. This collector supports collecting metrics from multiple instances of this integration, including remote instances. This integration doesn't support auto-detection. The default configuration for this integration does not impose any limits on data collection. The default configuration for this integration is not expected to impose a significant performance impact on the system. Metrics grouped by scope. The scope defines the instance that the metric belongs to. An instance is uniquely identified by a set of labels. These metrics refer to the user group. Labels: | Label | Description | |:--|:-| | user_group | The name of the user group. | Metrics: | Metric | Dimensions | Unit | |:|:-|:-| | usergroup.cpu_utilization | user, system | percentage | | usergroup.cpuguestutilization | guest | percentage | | usergroup.cpucontextswitches | voluntary, involuntary | switches/s | | usergroup.mem_usage | rss | MiB | | usergroup.memprivateusage | mem | MiB | | usergroup.vmem_usage | vmem | MiB | | usergroup.mempagefaults | minor, major | pgfaults/s | | usergroup.swap_usage | swap | MiB | | usergroup.diskphysicalio | reads, writes | KiB/s | | usergroup.disklogicalio | reads, writes | KiB/s | | usergroup.processes | processes | processes | | usergroup.threads | threads | threads | | usergroup.fdsopenlimit | limit | percentage | | usergroup.fds_open | files, sockets, pipes, inotifies, event, timer, signal, eventpolls, other | fds | | usergroup.uptime | uptime | seconds | | usergroup.uptime_summary | min, avg, max | seconds | There are no alerts configured by default for this integration. No action required. There is no configuration file. There are no configuration options. There are no configuration examples.
Project: Netdata (Observability and Analysis / Observability)
File: 1m_ipv4_tcp_resets_received.md

This alert, `1mipv4tcpresetsreceived`, calculates the average number of TCP RESETS received (`AttemptFails`) over the last minute on your system. If you receive this alert, it means that there is an increase in the number of TCP RESETS, which might indicate a problem with your networked applications or servers. `TCP RESET` is a signal that is sent from one connection end to the other when an ongoing connection is immediately terminated without an orderly close. This usually happens when a networked application encounters an issue, such as an incorrect connection request, invalid data packet, or a closed port. Identify the top consumers of TCP RESETS: You can use the `ss` utility to list the TCP sockets and their states: ``` sudo ss -tan ``` Look for the `State` column to see which sockets have a `CLOSE-WAIT`, `FIN-WAIT`, `TIME-WAIT`, or `LAST-ACK` status. These states usually have a high number of TCP RESETS. Check the logs of the concerned applications: If you have identified the problematic applications or servers, inspect their logs for any error messages, warnings, or unusual activity related to network connection issues. Inspect the system logs: Check the system logs, such as `/var/log/syslog` on Linux or `/var/log/system.log` on FreeBSD, for any network-related issues. This could help you find possible reasons for the increased number of TCP RESETS. Monitor and diagnose network issues: Use tools like `tcpdump`, `wireshark`, or `iftop` to capture packets and observe network traffic. This can help you identify patterns that may be causing the increased number of TCP RESETS. Check for resource constraints: Ensure that your system's resources, such as CPU, memory, and disk space, are not under heavy load or reaching their limits. High resource usage could cause networked applications to behave unexpectedly, resulting in an increased number of TCP RESETS.
Project: Checkmk (Observability and Analysis / Observability)
File: 16398.md

key | value | date | 2024-01-23T09:28:00+00:00 version | 2.3.0b1 class | fix edition | cre component | checks level | 1 compatible | yes Previously, passing a timeout parameter the agent plugin `mk_jolokia` had no effect. This has been fixed.
Project: Netdata (Observability and Analysis / Observability)
File: elasticsearch_node_index_health_red.md

This alert is triggered when the health status of an Elasticsearch node index turns `red`. If you receive this alert, it means that at least one primary shard and its replicas are not allocated to any node, and the data in the index is potentially at risk. In Elasticsearch, the index health status can be green, yellow, or red: Green: All primary and replica shards are allocated and active. Yellow: All primary shards are active, but not all replicas are allocated due to the lack of available nodes. Red: At least one primary shard and its replicas are not allocated, which means the cluster can't serve all the incoming data, and data loss is possible. Check the cluster health Use the Elasticsearch `_cluster/health` endpoint to check the health status of your cluster: ``` curl -X GET "localhost:9200/_cluster/health?pretty" ``` Identify the unassigned shards Use the Elasticsearch `_cat/shards` endpoint to view the status of all shards in your cluster: ``` curl -X GET "localhost:9200/_cat/shards?h=index,shard,prirep,state,unassigned.reason&pretty" ``` Check Elasticsearch logs Examine the Elasticsearch logs for any error messages or alerts related to shard allocation. The log file is usually located at `/var/log/elasticsearch/`. Resolve shard allocation issues Depending on the cause of the unassigned shards, you may need to perform actions such as: Add more nodes to the cluster to distribute the load evenly. Reallocate shards manually using the Elasticsearch `_cluster/reroute` API. Adjust shard allocation settings in the Elasticsearch `elasticsearch.yml` configuration file. Recheck the cluster health After addressing the issues found in the previous steps, use the `_cluster/health` endpoint again to check if the health status of the affected index has improved.
Project: Tracetest (Observability and Analysis / Observability)
File: feature_request.md

name: Feature request about: Suggest an idea for this project title: '' labels: 'feature request, triage' assignees: '' Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] Describe the solution you'd like A clear and concise description of what you want to happen. Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered. Additional context Add any other context or screenshots about the feature request here.
Project: Grafana (Observability and Analysis / Observability)
File: traceql-editor.md

description: Learn how to create TraceQL queries in Grafana using the query editor. keywords: grafana tempo traces queries labels: products: cloud enterprise oss menuTitle: Write TraceQL queries title: Write TraceQL queries with the editor weight: 300 {{< docs/shared source="grafana" lookup="datasources/tempo-editor-traceql.md" version="<GRAFANA VERSION>" >}}
Project: OpenTelemetry (Observability and Analysis / Observability)
File: repo-permissions.md

name: Repository Maintenance Request about: Request changes on an existing OpenTelemetry repository title: 'REQUEST: Repository maintenance on <REPOSITORY-NAME>' labels: area/repo-maintenance assignees: '' <!-- Please remember to change the title of this issue by replacing <REPOSITORY-NAME> with the actual respository name --> e.g. https://github.com/open-telemetry/community e.g. "Give 'Admin' permissions to `@username`" or "Enable branch protection rules for `release-*`" <!-- Please review the repository configuration guidelines at https://github.com/open-telemetry/community/blob/main/docs/how-to-configure-new-repository.md --> e.g. "We are setting up a new release management tool (link) and need to adapt our required merge checks for this." e.g. "1-2 weeks. We'll comment again on this issue once we are done so the permissions can be reverted." or "permanently" <!-- Tag the current maintainers team here to make them aware of the request. --> @open-telemetry/xxx-maintainers
Project: Elastic (Observability and Analysis / Observability)
File: to_integer.md

<!-- This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it. --> Converts an input value to an integer value. If the input parameter is of a date type, its value will be interpreted as milliseconds since the Unix epoch, converted to integer. Boolean true will be converted to integer 1, false to 0. ``` ROW long = [5013792, 2147483647, 501379200000] | EVAL int = TO_INTEGER(long) ```
Project: Netdata (Observability and Analysis / Observability)
File: machine-learning-and-assisted-troubleshooting.md

Netdata provides a variety of Machine Learning features to help you troubleshoot certain scenarios that might come up. K-means clustering are trained to power the on the dashboard, which allows you to identify anomalies in your infrastructure are possible through the dashboard using the statistical test and Volume heuristic measures The is able to answer your prompts when it comes to troubleshooting alerts and anomalies.
Project: Checkmk (Observability and Analysis / Observability)
File: 15320.md

key | value | date | 2024-01-25T13:39:59+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes Stopped resources are marked `CRIT`. If a resources was stopped and unmanaged, it was not marked as `CRIT`.
Project: Headlamp (Observability and Analysis / Observability)
File: plugin_registry.ResourceListViewLoadedEvent.md

title: "Interface: ResourceListViewLoadedEvent" linkTitle: "ResourceListViewLoadedEvent" slug: "plugin_registry.ResourceListViewLoadedEvent" .ResourceListViewLoadedEvent Event fired when a list view is loaded for a resource. data: `Object` | Name | Type | Description | | : | : | : | | `error?` | `Error` | The error, if an error has occurred | | `resourceKind` | `string` | The kind of resource that was loaded. | | `resources` | `any`[] | The list of resources that were loaded. | _ type: `LIST_VIEW`
Project: GO Feature Flag (Observability and Analysis / Feature Flagging)
File: mongodb.md

sidebar_position: 7 The `mongodbRetriever` will use the mongoDB database to get your flags. ```go linenums="1" err := ffclient.Init(ffclient.Config{ PollingInterval: 3 * time.Second, Retriever: &mongodbretriever.Retriever{ Collection: "featureFlags", Database: "appConfig", URI: "mongodb://root:example@127.0.0.1:27017/", }, }) defer ffclient.Close() ``` If you use MongoDB to store your flags, you need a specific format to store your flags. We expect the flag to be stored in JSON format as defined in the , but you should also add a new field called `flag` containing the name of the flag. The retriever will read all the flags from the collection. ```json { "flag": "new-admin-access", "variations": { "default_var": false, "false_var": false, "true_var": true }, "defaultRule": { "percentage": { "false_var": 70, "true_var": 30 } } } ``` To configure your mongodb retriever: | Field | Description | ||-| | `Collection` | Name of the collection where your flags are stored | | `Database` | Name of the mongo database where the collection is located. | | `URI` | Connection URI of your mongoDB instance. |
Project: Checkmk (Observability and Analysis / Observability)
File: 16149.md

key | value | date | 2024-01-29T10:12:24+00:00 version | 2.4.0b1 class | feature edition | cre component | livestatus level | 1 compatible | yes We provide a new header for livestatus that returns the rows in sorted order. For example, to sort host names in descending order ``` $ lq 'GET hosts\nColumns: name\nOrderBy: name desc' zhost yhost xhost ... ``` in ascending order ``` $ lq 'GET hosts\nColumns: name\nOrderBy: name asc' ahost bhost ... ``` or, alternatively without `asc`, ``` $ lq 'GET hosts\nColumns: name\nOrderBy: name' ahost bhost ... ``` The `OrderBy` header can be combined with the `Limit` header to limit the number of results as expected. ``` $ lq 'GET hosts\nColumns: name\nOrderBy: name\nLimit: 1' ahost ``` Furthermore, it is possible to sort on dictionary keys with the following syntax ``` $ lq << EOF GET services Columns: hostname description performancedata OrderBy: performancedata.usertime EOF ... ```
Project: Grafana Pyroscope (Observability and Analysis / Observability)
File: dotnet-span-profiles.md

title: Span profiles with Traces to profiles for .NET menuTitle: Span profiles with Traces to profiles (.NET) description: Learn about and configure Span profiles with Traces to profiles in Grafana for .NET applications. weight: 103 Span Profiles represents a major shift in profiling methodology, enabling deeper analysis of both tracing and profiling data. Traditional continuous profiling provides an application-wide view over fixed intervals. In contrast, Span Profiles delivers focused, dynamic analysis on specific execution scopes within applications, such as individual requests or specific trace spans. This shift enables a more granular view of performance, enhancing the utility of profiles by linking them directly with traces for a comprehensive understanding of application behavior. As a result, engineering teams can more efficiently identify and address performance bottlenecks. To learn more about Span Profiles, refer to . Pyroscope integrates with distributed tracing systems supporting the standard. This integration lets you link traces with the profiling data and find resource usage for specific lines of code for your trace spans. {{< admonition type="note" >}} Only CPU profiling is supported at the moment. Because of how sampling profilers work, spans shorter than the sample interval may not be captured. {{< /admonition >}} To use Span Profiles, you need to: Configure a client-side package to link traces and profiles: Your applications must be instrumented for profiling and tracing before you can use span profiles. Profiling: Your application must be instrumented with Pyroscope's .NET instrumentation library. Refer to the guide for instructions. Tracing: Your application must be instrumented with OpenTelemetry traces. Refer to the guide for isntructions. {{< admonition type="note" >}} Span profiles in .NET are only supported using because Pyroscope's .NET profiler and OpenTelemetry's auto instrumentation are based on separate .NET CLR profilers. {{< /admonition >}} To start collecting Span Profiles for your .NET application, you need to include in your code. This package provides a implementation, which connects the two telemetry signals (traces and profiles) together. ```shell dotnet add package Pyroscope.OpenTelemetry ``` Next, create and register the `PyroscopeSpanProcessor`: ```csharp builder.Services.AddOpenTelemetry() .WithTracing(b => { b .AddAspNetCoreInstrumentation() .AddConsoleExporter() .AddOtlpExporter() .AddProcessor(new Pyroscope.OpenTelemetry.PyroscopeSpanProcessor()); }); ``` With the span processor registered, spans created automatically (for example, HTTP handlers) and manually (`ActivitySource.StartActivity()`) have profiling data associated with them. To view the span profiles in Grafana Tempo, you need to have a Grafana instance running and a data source configured to link traces and profiles. Refer to the to see how to configure the visualization to link traces with profiles. Check out the directory for a complete demo application of span profiles in multiple languages.
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_storageClass.KubeStorageClass.md

title: "Interface: KubeStorageClass" linkTitle: "KubeStorageClass" slug: "libk8sstorageClass.KubeStorageClass" .KubeStorageClass `KubeStorageClass` `Optional` apiVersion: `string` . _ kind: `string` Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. In CamelCase. Cannot be updated. `see` . _ metadata: . _ provisioner: `string` _ reclaimPolicy: `string` _ volumeBindingMode: `string`
Project: Headlamp (Observability and Analysis / Observability)
File: plugin_lib.Headlamp.md

title: "Class: Headlamp" linkTitle: "Headlamp" slug: "plugin_lib.Headlamp" .Headlamp This class is a more convenient way for plugins to call registerPlugin in order to register themselves. new Headlamp() getProductName(): `string` Returns the name of the product. `string` the name of the product. _ getVersion(): `Object` Returns the version of Headlamp as an object with a VERSION (application version) and GIT_VERSION (commit) fields. Like: { VERSION: 'v0.0.0', GIT_VERSION: '0000000000000} `Object` the version of Headlamp. | Name | Type | | : | : | | `GIT_VERSION` | `string` | | `VERSION` | `string` | _ `Static` isRunningAsApp(): `boolean` Returns whether Headlamp is running as a desktop app. `boolean` true if Headlamp is running as a desktop app. _ `Static` registerPlugin(`pluginId`, `pluginObj`): `void` Got a new plugin to add? Well, registerPlugin is your friend. `example` ```javascript const myPlugin = { initialize: (register) => { // do some stuff with register // use some libraries in window.pluginLib return true; } } Headlamp.registerPlugin("aPluginIdString", myPlugin) ``` | Name | Type | Description | | : | : | : | | `pluginId` | `string` | a unique id string for your plugin. | | `pluginObj` | | the plugin being added. | `void` _ `Static` setAppMenu(`appMenuFunc`): `void` Changes the app menu. If Headlamp is not running as a desktop app, then this method prints an error and doesn't do anything. | Name | Type | Description | | : | : | : | | `appMenuFunc` | (`currentAppMenuSpec`: ``null`` \| [] | A function that receives the current app menu configuration and a new one. If the function returns null, the menu is not changed. | `void` _ `Static` setCluster(`clusterReq`): `Promise`<`any`\> Configure (or update) a cluster that can then be used throughout Headlamp. If the request is successful, further calls to `K8s.useClustersConf()` will show the newly configured cluster. Important: This is only available in the desktop version and will result in a bad request when running in-cluster. | Name | Type | Description | | : | : | : | | `clusterReq` | | the cluster to be added or updated. | `Promise`<`any`\> a promise which completes to Headlamp's configuration (showing the list of configured clusters).