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

title: Heap Analytics Integration sidebar_label: Heap Analytics hide_title: true You can integrate Flagsmith with Heap Analytics. The integration automatically sends the flag states for identified users into Heap for cohort analysis, A/B testing and more. The process is as follows: Get the Heap Project Environment ID for your Heap project from the Heap Manage Project page (Account > Manage > Projects > Environment > Get ID) Add the ID key into Flagsmith (Integrations > Add Heap Integration) All API calls generated by the Flagsmith SDK to the `Get Identity Flags` endpoint will send the a full set of flag evaluations for that particular user to Heap as an :::tip For flags that contain remote config values, Flagsmith will pass the value of the flag to Heap if the flag is `enabled`. If the flag has no remote config value, Flagsmith will just pass the boolean state for the flag. ::: Identity flag values are passed into Heap. If we make the call to the Flagsmith API to get the flags for an Identity. ```bash curl 'https://edge.api.flagsmith.com/api/v1/identities/?identifier=developmentuser123456' \ -H 'x-environment-key: 8KzETdDeMY7xkqkSkY3Gsg' ``` And then take a look in our Heap dashboard, you can see the user and the flag data that has been sent to the Heap platform. Once the integration has been set up, you can start segmenting your Heap identities based on the flags that they saw. This means you can run AB tests driven by Flagsmith segments, and have the data show up automatically in Heap. Once your integration has been set up and has been running for a few days, you will see flag values appear in Heap as "Custom Event Properties" as child properties of the "Flagsmith Feature Flags" event. Here's how you can see the effectiveness of a flag being enabled. We're going to use an example of our own platform, where people can toggle the "Dark Mode" flag within our application on and off. In Heap, go to Definitions > New Definition > New Event. Set up your event similar to the below: In Heap, go to Definitions > New Definition > New Segment. Set up your Segment similar to the below: Once you have your Segment created, based on a Flagsmith flag value, you can use that Segment in reports within Heap. Here's an example of us seeing what the conversion rate of a dark mode vs non-dark mode user looks like. Notice the "Group Analysis - Conversion Rate" at the bottom of the page. You have to identify users on both platforms in the same way. The Flagsmith `Identity ID` must be the same as the Heap `identity`.
Project: Graylog (Observability and Analysis / Observability)
File: SelectPopover.md

```js import createReactClass from 'create-react-class'; import { Button } from 'components/bootstrap'; const items = [ 'Black', 'Blue', 'Green', 'Red', 'White', 'Yellow', ]; const SelectPopoverExample = createReactClass({ getInitialState() { return { selectedColor: undefined, }; }, handleItemSelect(item) { this.setState({ selectedColor: item[0] }); }, render() { const selectedColor = this.state.selectedColor; return ( <div> <div style={{ display: 'inline-block', marginRight: 20 }}> <SelectPopover id="example-popover" title="Filter by color" triggerNode={<Button bsStyle="info" bsSize="small">Select color</Button>} items={items} selectedItems={selectedColor ? [selectedColor] : []} onItemSelect={this.handleItemSelect} displayDataFilter={false} clearSelectionText="Clear color selection"/> </div> {selectedColor ? `You have selected ${selectedColor}` : 'Please select a color!'} </div> ); } }); <SelectPopoverExample /> ``` ```js import createReactClass from 'create-react-class'; import { Button, Badge } from 'components/bootstrap'; import { Icon } from 'components/common'; const items = [ 'AliceBlue', 'Aqua', 'Black', 'Blue', 'Brown', 'Cyan', 'DarkMagenta', 'Gold', 'Green', 'Magenta', 'Navy', 'Red', 'SeaGreen', 'Turquoise', 'White', 'Yellow', ]; const SelectPopoverFormattedExample = createReactClass({ getInitialState() { return { selectedColors: [], }; }, handleItemSelect(item) { this.setState({ selectedColors: item }); }, formatItem(item) { return ( <span> <Icon name="square" style={{ color: item }} /> {item} </span> ) }, render() { const selectedColors = this.state.selectedColors; return ( <div> <div style={{ display: 'inline-block', marginRight: 20 }}> <SelectPopover id="example-popover-formatted" title="Filter by color" triggerNode={<Button bsStyle="info" bsSize="small">Select color</Button>} items={items} itemFormatter={this.formatItem} onItemSelect={this.handleItemSelect} filterPlaceholder="Filter by color" multiple={true} selectedItems={selectedColors} /> </div> {selectedColors.length > 0 ? `You have selected ${selectedColors.join(', ')}` : 'Please select some colors!'} </div> ); } }); <SelectPopoverFormattedExample /> ```
Project: Grafana (Observability and Analysis / Observability)
File: upgrading-dependencies.md

Notes on upgrading various backend dependencies. When upgrading the library in Grafana and the plugin SDK, you typically also want to upgrade your protobuf compiler toolchain and re-compile protobuf files. Note: You need Buf CLI installed and availabile in your path, see https://buf.build/docs/installation for instructions. Re-compile protobuf files in grafana and the plugin SDK: ```shell cd $GRAFANA make protobuf cd $GRAFANAPLUGINSDK_GO mage protobuf ``` After upgrading the protobuf dependency in Grafana and the plugin SDK, it might be wise to test that things still work, before making corresponding PRs: Test a plugin built with upgraded SDK on upgraded Grafana Test a plugin built with non-upgraded SDK on upgraded Grafana Test a plugin built with upgraded SDK on non-upgraded Grafana
Project: Tracetest (Observability and Analysis / Observability)
File: tracetest_export.md

Export resource Export a resource from your Tracetest server ``` tracetest export analyzer|config|datastore|demo|env|organization|pollingprofile|test|testrunner|testsuite|variableset [flags] ``` ``` -f, --file string file path with name where to export the resource (default "resource.yaml") -h, --help help for export --id string id of the resource to export ``` ``` -c, --config string config file will be used by the CLI (default "config.yml") -o, --output string output format [pretty|json|yaml] -s, --server-url string server url -v, --verbose display debug information ``` - CLI to configure, install and execute tests on a Tracetest server
Project: Vector (Observability and Analysis / Observability)
File: prometheus_pushgateway.md

title: Prometheus Pushgateway description: Collect metrics from component_kind: source layout: component tags: ["prometheus", "pushgateway", "component", "source", "metrics"] {{/* This doc is generated using: The template in layouts/docs/component.html The relevant CUE data in cue/reference/components/... */}}
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-tpl_list.md

category: Template apiurl: '/api/v1/template' title: "Template List" type: 'GET' sample_doc: 'template.html' layout: default Template List Required ```Status: 200``` ```[ { "id": 1, "tpl_name": "cpu.board", "parent_id": 0, "action_id": 5, "create_user": "usera" }, { "id": 2, "tpl_name": "traffic checking", "parent_id": 0, "action_id": 6, "create_user": "userb" }, { "id": 3, "tpl_name": "cputest", "parent_id": 0, "action_id": 7, "create_user": "userc" }, { "id": 5, "tpl_name": "all metrics base", "parent_id": 0, "action_id": 12, "create_user": "root" } ]```
Project: Tracetest (Observability and Analysis / Observability)
File: websocket.md

Tracetest allow you to subscribe to updates of resources using websockets. There are two endpoints that you can use to manage subscriptions: You can open a websocket connection by sending a request the path `/ws`. Example: `ws://localhost:11633/ws`. Once the connection is open, you can send a message with the format: ```json { "type": "subscribe", "resource": "test/{testID}/run/{runID}" } ``` If a problem happens, you will see an error like: ```json { "type": "error", "message": "details of the error" } ``` If the operation executes successfully, you will see a response like: ```json { "type": "success", "resource": "test/{testID}/run/{runID}", "message": { "subscriptionId": "bdbc6cc8-bba6-4208-a8d3-d3c2c5b3e38b" } } ``` The `subscriptionId` is an important field because it is required to cancel the subscription. You should store it, otherwise you will keep receiving updates of a resource that you might not want. Once you have a subscription to a resource, you might want to stop receiving events from that resource. So, there is a `unsubscribe` message that you can send to achieve that. But send this message to the websocket connection: ```json { "type": "unsubscribe", "resource": "test/{testID}/run/{runID}", "subscriptionId": "id returned in the subscription command" } ``` You will receive an error message if any required field is not field. But in case of a successful operation, you will receive a message like: ```json { "type":"success", "message":"ok" } ``` This message will be sent regardless if the subscription exists or not.
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_ingress.IngressBackend.md

title: "Interface: IngressBackend" linkTitle: "IngressBackend" slug: "libk8singress.IngressBackend" .IngressBackend `Optional` resource: `Object` | Name | Type | | : | : | | `apiVersion` | `string` | | `kind` | `string` | | `name` | `string` | _ `Optional` service: `Object` | Name | Type | | : | : | | `name` | `string` | | `port` | { `name?`: `string` ; `number?`: `number` } | | `port.name?` | `string` | | `port.number?` | `number` |
Project: Netdata (Observability and Analysis / Observability)
File: systemd_slice_unit_failed_state.md

This alert is triggered when a `systemd slice unit` enters a `failed state`. Systemd slice units are a way to organize and manage system processes in a hierarchical manner. If you receive this alert, it means that there is an issue with a specific slice unit, which can be crucial for system stability and performance. A `failed state` in the context of systemd units means that the unit has encountered a problem and is not functioning properly. This could be caused by a variety of reasons, such as misconfiguration, dependency issues, or unhandled errors in the underlying service. Identify the problematic systemd slice unit. Run the following command to list all systemd units and their states: ```bash systemctl --all ``` Look for the units with the `failed` state in the output, and take note of the affected unit(s). Investigate the specific issue with the failed unit. Use the `systemctl status` command followed by the unit name to get more information about the problem: ```bash systemctl status <unit-name> ``` The output will provide more details on the issue and may include error messages or log entries that can help identify the root cause. Check the unit logs for additional clues. The `journalctl` command can be used to view the logs related to a specific unit by specifying the `-u` flag followed by the unit name: ```bash journalctl -u <unit-name> ``` Analyze the log entries for any reported errors or warnings that could be related to the failure. Address the root cause of the issue. Based on the information gathered, take the necessary steps to resolve the issue with the failed unit. This may involve reconfiguring the unit, adjusting dependencies, or fixing the underlying service. Restart the unit and verify its status. Once the issue has been resolved, restart the systemd unit using the `systemctl restart` command: ```bash systemctl restart <unit-name> ``` Afterwards, check the unit's status to confirm that it is no longer in a failed state and is functioning properly: ```bash systemctl status <unit-name> ```
Project: Grafana Mimir (Observability and Analysis / Observability)
File: CONTRIBUTING.md

Welcome to Kubernetes. We are excited about the prospect of you joining our ! The Kubernetes community abides by the CNCF . Here is an excerpt: As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities. We have full documentation on how to get started contributing here: <! If your repo has certain guidelines for contribution, put them here ahead of the general k8s resources --> Kubernetes projects require that you sign a Contributor License Agreement (CLA) before we can accept your pull requests - Main contributor documentation, or you can just jump directly to the - Common resources for existing developers - We have a diverse set of mentorship programs available that are always looking for volunteers! <! Custom Information - if you're copying this template for the first time you can add custom content here, for example: - Replace `kubernetes-users` with your slack channel string, this will send users directly to your channel. -->
Project: Checkmk (Observability and Analysis / Observability)
File: 16642.md

key | value | date | 2024-03-21T12:35:39+00:00 version | 2.4.0b1 class | feature edition | cre component | checks level | 1 compatible | no This only affects plugin developers. The datamodel for the `Password` Formspec is changed. Use the `migratetopassword` migration function to update your stored configurations to the newer datamodel.
Project: Centreon (Observability and Analysis / Observability)
File: nodes.md

This module aims to automatically register Poller servers as Gorgone nodes, in opposition to the module. For now, nodes can be registered as SSH nodes or ZMQ nodes. No specific configuration. ```yaml name: nodes package: "gorgone::modules::centreon::nodes::hooks" enable: true ``` | Event | Description | | :-- | :-- | | CENTREONNODESREADY | Internal event to notify the core | | Endpoint | Method | | :- | :-- | | /centreon/nodes/sync | `POST` | | Header | Value | | :-- | : | | Accept | application/json | | Content-Type | application/json | No parameters. ```bash curl --request POST "https://hostname:8443/api/centreon/nodes/sync" \ --header "Accept: application/json" \ --header "Content-Type: application/json" \ --data "{}" ```
Project: Netdata (Observability and Analysis / Observability)
File: hdfs_dead_nodes.md

The Netdata Agent monitors the number of DataNodes that are currently dead. Receiving this alert indicates that there are dead DataNodes in your HDFS cluster. The NameNode characterizes a DataNode as dead if no heartbeat message is exchanged for approximately 10 minutes. Any data that was registered to a dead DataNode is not available to HDFS anymore. This alert is triggered into critical when the number of dead DataNodes is 1 or more. Fix corrupted or missing blocks. ``` root@netdata # hadoop dfsadmin -report ``` Inspect the output and check which DataNode is dead. Connect to the DataNode and check the log of the DataNode. You can also check for errors in the system services. ``` root@netdata # systemctl status hadoop ``` Restart the service if needed. Verify that the network connectivity between NameNode and DataNodes is functional. You can use tools like `ping` and `traceroute` to confirm the connectivity. Check the logs of the dead DataNode(s) for any issues. Log location may vary depending on your installation, but you can typically find them in the `/var/log/hadoop-hdfs/` directory. Analyze the logs to identify any errors or issues that may have caused the DataNode to become dead. ``` root@netdata # tail -f /var/log/hadoop-hdfs/hadoop-hdfs-datanode-*.log ``` If the DataNode service is not running or has crashed, attempt to restart it. ``` root@netdata # systemctl restart hadoop ``` Remember that troubleshooting and resolving issues, especially on a production environment, requires a good understanding of the system and its architecture. Proceed with caution and always ensure data backup and environmental safety before performing any action.
Project: Checkmk (Observability and Analysis / Observability)
File: 16801.md

key | value | date | 2024-04-23T10:22:44+00:00 version | 2.4.0b1 class | fix edition | cee component | metrics level | 1 compatible | yes When adding a scalar to a custom graph, it is possible that no value is available for this scalar. For example, this is the case when adding the CRIT threshold of a metric for which no thresholds are configured. In such cases, no graph was rendered. Instead, the Checkmk UI displayed the message "Cannot calculate graph recipes" and showed a traceback. This werk restores the correct behavior: No lines are rendered for unavailable scalars and they are denoted with "n/a" in the graph legend.
Project: OpenSearch (Observability and Analysis / Observability)
File: opensearch.release-notes-2.3.0.md

) ) ) () ) () Segment Replication - Fix NoSuchFileException errors caused when computing metadata snapshot on primary shards. () () ) () ) () ) () Segment Replication - Implement segment replication event cancellation. () () ) ) ) () ) () ) ) ) ) () ) Bug fixes for dependabot changelog verifier () () ) () ) () ) ) () OpenSearch crashes on closed client connection before search reply when total ops higher compared to expected () () Add workflow for changelog verification () () Add 2.x version to CHANGELOG () () Update the head ref to changelog verifier () () Publish transport-netty4 module to central repository () () Add bwcVersion 1.3.6 to 2.x () ) Update to Netty 4.1.80.Final () () Adding @dreamer-89 to Opensearch maintainers. () () ) () Some dependency updates () () Added bwc version 2.2.1 () Update Gradle to 7.5.1 () () ) Bumping 2.x to 2.3.0 () Refactored the src and test of GeoHashGrid and GeoTileGrid Aggregations on GeoPoint from server folder to geo module.() () () () Update the head ref to changelog verifier () () ) () Refactored the src and test of GeoHashGrid and GeoTileGrid Aggregations on GeoPoint from server folder to geo module.() () () () Refactors the GeoBoundsAggregation for geo_point types from the core server to the geo module. () Backporting multiple 2. release notes from main to the 2.x branch ()
Project: Vector (Observability and Analysis / Observability)
File: pipeline-model.md

title: Pipeline model weight: 1 tags: ["pipeline", "dag", "graph", "configuration"] {{< svg "img/pipeline-model.svg" >}} Vector's pipeline model is based on a of [components] that contains independent subgraphs. [Events] must flow in a single direction from sources to sinks and can't create cycles. Each component in the graph can produce zero or more events. A Vector pipeline is defined through a YAML, TOML, or JSON [configuration] file. For maintainability, many Vector users use configuration and data templating languages like [Jsonnet] or [CUE]. Configuration is checked at pipeline compile time (when Vector boots). This prevents simple mistakes and enforces DAG properties. Vector's configured pipeline can be adjusted in real time without restarting Vector. Vector supports to apply any configuration changes. This is achieved by sending a `SIGHUP` process signal to Vector's process. Vector also includes an [API] that allows for real-time observation and manipulation of a running Vector instance.
Project: Checkmk (Observability and Analysis / Observability)
File: pull_request_template.md

Thank you for your interest in contributing to Checkmk! Consider looking into regarding process details. Please give a brief summary of the affected device, software or appliance. Keep in mind that we are experts in monitoring, but we cannot be experts on all supported devices. A little context will help us assess your proposed change. Please include: Your operating system name and version Any details about your local setup that might be helpful in troubleshooting Detailed steps to reproduce the bug An agent output or SNMP walk The ID of a submitted crash report for reference (if applicable) Sometimes it is hard for us to assess the quality of a fix. While it may work for you, it is our job to ensure that it works for everybody. These are some ways to help us: What is the expected behavior? What is the observed behavior? If it's not obvious from the above: In what way does your patch change the current behavior? Consider writing a unit test that would have failed without your fix. Is this a new problem? What made you submit this PR (new firmware, new device, changed device behavior)?
Project: Elastic (Observability and Analysis / Observability)
File: mv_avg.md

<!-- This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it. --> Converts a multivalued field into a single valued field containing the average of all of the values. ``` ROW a=[3, 5, 1, 6] | EVAL avga = MVAVG(a) ```
Project: OpenLLMetry (Observability and Analysis / Observability)
File: PULL_REQUEST_TEMPLATE.md

<!-- Thanks for submitting a PR! To make sure this gets merged quickly, make sure to check the following checkboxes. --> [ ] I have added tests that cover my changes. [ ] If adding a new instrumentation or changing an existing one, I've added screenshots from some observability platform showing the change. [ ] PR name follows conventional commits format: `feat(instrumentation): ...` or `fix(instrumentation): ...`. [ ] (If applicable) I have updated the documentation accordingly.
Project: Cortex (Observability and Analysis / Observability)
File: overrides-exporter.md

title: "Overrides Exporter" linkTitle: "Overrides Exporter" weight: 10 slug: overrides-exporter Since Cortex is a multi-tenant system, it supports applying limits to each tenant to prevent any single one from using too many resources. In order to help operators understand how close to their limits tenants are, the `overrides-exporter` module can expose limits as Prometheus metrics. To update configuration without restarting, Cortex allows operators to supply a `runtime_config` file that will be periodically reloaded. This file can be specified under the `runtime_config` section of the main or using the `-runtime-config.file` command line flag. This file is used to apply tenant-specific limits. The `overrides-exporter` is not enabled by default, it must be explicitly enabled. We recommend only running a single instance of it in your cluster due to the cardinality of the metrics emitted. With a `runtime.yaml` file given below ```yaml overrides: "user1": ingestionburstsize: 350000 ingestion_rate: 350000 maxglobalseriespermetric: 300000 maxglobalseriesperuser: 300000 maxseriesper_metric: 0 maxseriesper_user: 0 maxsamplesper_query: 100000 maxseriesper_query: 100000 ``` The `overrides-exporter` is configured to run as follows ``` cortex -target overrides-exporter -runtime-config.file runtime.yaml -server.http-listen-port=8080 ``` After the `overrides-exporter` starts, you can to use `curl` to inspect the tenant overrides. ```text curl -s http://localhost:8080/metrics | grep cortex_overrides cortexoverrides{limitname="ingestionburstsize",user="user1"} 350000 cortexoverrides{limitname="ingestion_rate",user="user1"} 350000 cortexoverrides{limitname="maxglobalseriespermetric",user="user1"} 300000 cortexoverrides{limitname="maxglobalseriesperuser",user="user1"} 300000 cortexoverrides{limitname="maxlocalseriespermetric",user="user1"} 0 cortexoverrides{limitname="maxlocalseriesperuser",user="user1"} 0 cortexoverrides{limitname="maxsamplesper_query",user="user1"} 100000 cortexoverrides{limitname="maxseriesper_query",user="user1"} 100000 ``` With these metrics, you can set up alerts to know when tenants are close to hitting their limits before they exceed them.