cwielenb/CNCF-Dataset huggingface dataset:
Project: Graylog (Observability and Analysis / Observability)
File: TimezoneSelect.md

```js import createReactClass from 'create-react-class'; const TimezoneSelectExample = createReactClass({ getInitialState() { return { tz: 'Africa/Timbuktu', }; }, onChange(nextTZ) { this.setState({ tz: nextTZ }); }, render() { const { tz } = this.state; return ( <div> <p>Selected time zone: {tz}</p> <TimezoneSelect value={tz} onChange={this.onChange} /> </div> ); }, }); <TimezoneSelectExample /> ```
Project: gocrane (Observability and Analysis / Continuous Optimization)
File: roadmap-2022.md

title: "Roadmap for 2022" description: "The designed roadmap items for 2022" weight: 11 Please refer the following sections for Crane release plan of H1 2022, new release will be cut on monthly basis. Please let us know if you have urgent needs which are not presented in the plan. Predictor to support Moving Windows and DSP algorithms Resource Request Recommendation and Effective Horizontal Pod Autoscaler Grafana Dashboard to view resource utilization and cost trends fadvisor to support billing Multiple Metric Adaptor support Node QOS Ensurance for CPU Operation Metrics about R3 and EPA applied ratio UI with cost visibility and usage optimizations. Request Recommendation adapts with Virtual Kubelet Multiple Triggers for EPA Node QOS Ensurance for Mem Prediction with CPU, Memory, and Business Metrics Scalability to support 1K TSP and 1K EPA UI to support EPA. Resource and Replicas Recommendation Load-aware Scheduler Scalability to support 3k TSP and 3k EPA Algorithm and QOS Documentation EHPA grafana dashboard DSP Algorithm Optimization Support remote adapter for external metric Prediction with business metrics Recommendation Framework Crane-Descheduler based on CPU/Memory metrics Offline Algorithm Evaluator External recommendation plugins Built-in CICD Pipeline integration CPU topology aware scheduler Enhanced Console with resource optimization Flexible conflict prediction and detection Builtin AI Prediction Wastes discovery and dashboard Enhanced Console with more cost visibility dashboard
Project: OpenObserve (Observability and Analysis / Observability)
File: CHANGELOG.md

Thanks ! - Upgrade all projects to typescript 4.9.5 Updated dependencies , ]: rrweb@2.0.0-alpha.11 Updated dependencies , , , , , ]: rrweb@2.0.0-alpha.10 Thanks ! - Fix `player.getMirror`, `player.playRange`, `player.$set` types in rrwebPlayer Updated dependencies , , , , ]: rrweb@2.0.0-alpha.9 Thanks ! - Reset the finished flag in Controller `goto` instead of `handleProgressClick` so that it is properly handled if `goto` is called directly. Updated dependencies , , , ]: rrweb@2.0.0-alpha.8 Updated dependencies , , , , , , , ]: rrweb@2.0.0-alpha.7 Updated dependencies , , , , , , ]: rrweb@2.0.0-alpha.6 Thanks ! - Refactor all suffix of bundled scripts with commonjs module from 'js' to cjs . Updated dependencies , , , , , ]: rrweb@2.0.0-alpha.5
Project: Flagsmith (Observability and Analysis / Feature Flagging)
File: staged-feature-rollouts.md

title: Staged Feature Rollouts Staged Feature Rollouts allow you to test a new feature with a small subset of your user base. If you are happy with the feature, you can increase the percentage of users that see the feature until it is available to your entire user base. This method can increase your confidence in rolling out a new feature. If there are issues with the rollout, you can disable the Feature Flag, thus hiding the feature within your application. :::important Staged Rollouts _only_ come into effect if you are getting the Flags for a particular Identity. If you are just retrieving the flags for an Environment without passing in an Identity, your user will never be included in the "% Split% Segment. ::: You can achieve staged rollouts by creating a and adding a rule defined with the "% Split" condition. Specifying a "% Split" value between 1 and 100 then defines what percentage of your user base are included within this Segment. Once you have created the Segment, you can then go ahead and connect it up to a Feature Flag as per regular . Note that you can include the "% Split" rule alongside other Segment rules if you wish. Each Identity and Segment has a unique identifier. These two pieces of data are merged then hashed, and a floating point value between 0.0 and 1.0 is generated from this hash. This value is then evaluated against the "% Split" rule. So to take an example. For a single Identity, we perform the following steps: Take the internal Segment ID and their internal Identity ID and combine them into a single string We then hash that string We then generate a float value between 0 and 1 based on that hash So for every Segment/Identity combination, a value of between 0 and 1 is generated. Due to the hashing algorithm used, we ensure a consistent spread of values from 0 to 1. So lets say that number comes out at 0.351 for a particular Identity. If you create a Segment % split to be 30%, that Identity will not be included in that Segment because 0.351 is great than 0.3 (30%). If you then modify the Segment to be a 40% split, the Identity WILL be in that Segment because 0.4 > 0.351. That way you get a consistent experience as an end-user. This works because the ID of a Segment doesn't change after it has been created. A second Identity might have their value hash be equal to 0.94. In that case, they would not be in the Segment with the split at either 30% of 40%.
Project: Vector (Observability and Analysis / Observability)
File: 2021-07-16-remap-multiple.md

date: "2021-07-16" title: "Mapping one log event into multiple" description: "Introducing new methods for converting a single log event into multiple using the `remap` transform" authors: ["jszwedko"] pr_numbers: [] release: "0.15.0" hideonrelease_notes: false badges: type: new feature domains: ["vrl", "remap transform"] This release enables transforming a single log event into multiple log events using the `remap` transform. The groundwork for this was laid in 0.14.0, but we've been waiting to announce it until the addition of the function in this release. The basic premise is that if you assign an array to the root object, `.`, in a VRL program run by `remap`, then `remap` will create one log event for each event in the array. For example: ```toml [transforms.remap] type = "remap" inputs = [] source = """ . = [{"message": "hello"}, {"message": "world"}] """ ``` Would generate two output events: ```json {"message": "hello"} {"message": "world"} ``` Any array elements that are not key/value objects will be converted to an log event by creating a log event with the `message` key set to the array element value. See the docs for more examples. Additionally, to make it easier to convert an incoming log event into an array, we've added an function to VRL that transforms an incoming event where one of the fields is an array into an array of events, each with one of the elements from the array field. This is easiest to see with an example: ```toml [transforms.remap] type = "remap" inputs = [] source = """ . = {"host": "localhost", "events": [{"message": "hello"}, {"message": "world"}]} # to represent the incoming event . = unnest(.events) """ ``` Would output the following log events: ```json { "events": { "message": "hello" }, "host": "localhost" } { "events": { "message": "world" }, "host": "localhost" } ``` In the future, we plan to add functionality to VRL to allow iterating over arrays, but, for now, the simple case of mapping each event in an array separately can be done by having one `remap` transform do the "exploding" of the event, and another `remap` transform to receive each new event. An example of this: ```toml [transforms.explode] type = "remap" inputs = [] source = """ . = {"host": "localhost", "events": [{"message": "hello"}, {"message": "world"}]} # to represent the incoming event . = unnest(.events) """ [transforms.map] type = "remap" inputs = ["explode"] source = """ . |= .events del(.events) """ ``` Would output the following log events: ```json { "message": "hello", "host": "localhost" } { "message": "world", "host": "localhost" } ```
Project: Graylog (Observability and Analysis / Observability)
File: DropdownButton.md

```js import { MenuItem } from 'components/bootstrap'; const styles = ['Primary', 'Danger', 'Warning', 'Success', 'Info', 'Link', 'Default']; styles.map((style) => { const styleName = style.toLowerCase(); return ( <span key={`split-button-${styleName}`}> <DropdownButton title={style} bsStyle={styleName} id={`split-button-${styleName}`}> <MenuItem header>Header</MenuItem> <MenuItem eventKey="1">Default</MenuItem> <MenuItem eventKey="2" active>Active</MenuItem> <MenuItem eventKey="4" disabled>Disabled</MenuItem> <MenuItem divider /> <MenuItem eventKey="5">Separated</MenuItem> </DropdownButton>{' '} </span> ) }) ```
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: schedule-once.md

It schedule the chaos once either on the specified time or immediately after creation of schedule CR. ??? info "View the schedule once schema" <table> <tr> <th>Field</th> <td><code>.spec.schedule.now</code></td> </tr> <tr> <th>Description</th> <td>Flag to control the type of scheduling</td> </tr> <tr> <th>Type</th> <td>Mandatory</td> </tr> <tr> <th>Range</th> <td><code>true</code>, <code>false</code></td> </tr> <tr> <th>Default</th> <td><code>n/a</code></td> </tr> <tr> <th>Notes</th> <td>The <code>now</code> in the <code>spec.schedule</code> ensures immediate creation of chaosengine, i.e., injection of chaos. </tr> </table> <table> <tr> <th>Field</th> <td><code>.spec.schedule.once.executionTime</code></td> </tr> <tr> <th>Description</th> <td>Flag to specify execution timestamp at which chaos is injected, when the policy is <code>once</code>. The chaosengine is created exactly at this timestamp.</td> </tr> <tr> <th>Type</th> <td>Mandatory</td> </tr> <tr> <th>Range</th> <td><i>user-defined</i> (type: UTC Timeformat)</td> </tr> <tr> <th>Default</th> <td><i>n/a</i></td> </tr> <tr> <th>Notes</th> <td><code>.spec.schedule.once</code> refers to a single-instance execution of chaos at a particular timestamp specified by <code>.spec.schedule.once.executionTime</code></td> </tr> </table> It schedule the chaos immediately after creation of the chaos-schedule CR. It can be tuned via setting `spec.schedule.now` to `true`. ```yaml apiVersion: litmuschaos.io/v1alpha1 kind: ChaosSchedule metadata: name: schedule-nginx spec: schedule: now: true engineTemplateSpec: engineState: 'active' appinfo: appns: 'default' applabel: 'app=nginx' appkind: 'deployment' annotationCheck: 'true' chaosServiceAccount: pod-delete-sa jobCleanUpPolicy: 'delete' experiments: name: pod-delete spec: components: env: name: TOTALCHAOSDURATION value: '30' name: CHAOS_INTERVAL value: '10' name: FORCE value: 'false' ``` It schedule the chaos once at the specified time. It can be tuned via setting `spec.schedule.once.executionTime`. The execution time should be in `UTC Timezone`. ```yaml apiVersion: litmuschaos.io/v1alpha1 kind: ChaosSchedule metadata: name: schedule-nginx spec: schedule: once: executionTime: "2020-05-12T05:47:00Z" engineTemplateSpec: engineState: 'active' appinfo: appns: 'default' applabel: 'app=nginx' appkind: 'deployment' annotationCheck: 'true' chaosServiceAccount: pod-delete-sa jobCleanUpPolicy: 'delete' experiments: name: pod-delete spec: components: env: name: TOTALCHAOSDURATION value: '30' name: CHAOS_INTERVAL value: '10' name: FORCE value: 'false' ```
Project: Tracetest (Observability and Analysis / Observability)
File: tracetest_configure.md

Configure your tracetest CLI Configure your tracetest CLI ``` tracetest configure [flags] ``` ``` --ci if cloud is used, don't ask for authentication --environment string set environmentID, so the CLI won't ask you for it -g, --global configuration will be saved in your home dir -h, --help help for configure --organization string set organizationID, so the CLI won't ask you for it -t, --token string set authetication with token, so the CLI won't ask you for authentication ``` ``` -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: Graylog (Observability and Analysis / Observability)
File: ControlledTableList.md

```js import createReactClass from 'create-react-class'; import Immutable from 'immutable'; import { Col, Row } from 'components/bootstrap'; const ControlledTableListExample = createReactClass({ getInitialState() { return { items: Immutable.List([ { id: '1', title: 'One', secret_key: 'uno', description: 'First number' }, { id: '2', title: 'Two', secret_key: 'dos', description: 'Second number' }, { id: '3', title: 'Three', secret_key: 'tres', description: 'Third number' }, { id: '4', title: 'Four', secret_key: 'cuatro', description: 'Fourth number' }, { id: '5', title: 'Five', secret_key: 'cinco', description: 'Fifth number' }, ]), }; }, formatItems(items) { return items.map(item => { return ( <ControlledTableList.Item key={item.id}> <Row className="row-sm"> <Col md={12}> <h5>{item.title} <small>{item.description}</small></h5> </Col> </Row> <Row className="row-sm"> <Col md={12}> </Col> </Row> </ControlledTableList.Item> ) }); }, render() { const { items } = this.state; return ( <ControlledTableList> <ControlledTableList.Header> Numbers </ControlledTableList.Header> {this.formatItems(items)} </ControlledTableList> ); }, }); <ControlledTableListExample /> ```
Project: Checkmk (Observability and Analysis / Observability)
File: 16527.md

key | value | date | 2024-03-07T09:59:38+00:00 version | 2.4.0b1 class | feature edition | cre component | rest-api level | 1 compatible | yes This werk implements endpoints that provide a way to manage LDAP connections via the REST-API in the same way the user interface does. This includes creating, updating, deleting and listing LDAP connections.
Project: PowerfulSeal (Observability and Analysis / Chaos Engineering)
File: 8_contribute.md

layout: default title: Contribute nav_order: 8 description: "" permalink: /contribute {: .no_toc } {: .no_toc .text-delta } TOC {:toc} PowerfulSeal uses to test multiple Python versions in a straightforward manner. In order to use `tox`, `tox` must be installed and Python binaries for the versions listed in must be visible in your PATH. Due to the difficulty in maintaining the required libraries for so many Python versions, it is recommended to use to install and manage multiple versions of Python. The recommended installation steps are: Install pyenv using the method Run `pyenv install --list` For every version specified in `tox.ini`, find the latest patch version corresponding to the version (e.g., `3.7` -> `3.7.5`) and run `pyenv install [version]` In this project's root directory, run `pyenv local [versions]`, where `[versions]` is a space-separated list of every version you just installed (e.g., `pyenv local 3.7.0`) Run `pyenv which 3.7`, etc. and ensure there are no errors and the output path is a `.pyenv` directory With the installation complete, simply run `tox` (or the analagous `make test`). If you are running on a machine with `inotifywait` installed (i.e., a UNIX machine), you can run `make watch` and run tests automatically when you run changes. You can also run tests for specific versions by running `tox -e [version(s)]` (e.g., `tox -e py36`). Additionally, if you need to reinstall dependencies, you can use the `-r` flag. We use Jekyll for the documentation. In order to host/generate the docs locally, you have to follow tutorial.
Project: Netdata (Observability and Analysis / Observability)
File: consul_raft_thread_fsm_saturation.md

This alert monitors the `consulraftthreadfsmsaturation` metric, which represents the saturation of the `FSM Raft` goroutine in Consul, a service mesh. If you receive this alert, it indicates that the Raft goroutine on a specific Consul server is becoming saturated. Consul is a distributed service mesh that provides a full-featured control plane with service discovery, configuration, and segmentation functionalities. It enables organizations to build and operate large-scale, dynamic, and resilient systems. The Raft FSM goroutine is responsible for executing finite state machine (FSM) operations on the Consul servers. Saturation of the FSM Raft goroutine means that it is spending more time executing operations, which may cause delays in Consul's ability to process requests and manage the overall service mesh. High saturation levels can lead to performance issues, increased latency, or even downtime for your Consul deployment. Identify the Consul server and datacenter with the high Raft goroutine saturation: The alert has labels `label:node_name` and `label:datacenter`, indicating the affected Consul server and its respective datacenter. Examine Consul server logs: Check the logs of the affected Consul server for any error messages or indications of high resource usage. This can provide valuable information on the cause of the saturation. Monitor Consul cluster performance: Use Consul's built-in monitoring tools to keep an eye on your Consul cluster's health and performance. For instance, you may monitor Raft metrics via the Consul `/v1/agent/metrics` API endpoint. Scale your Consul infrastructure: If the increased saturation is due to high demand, scaling your Consul infrastructure by adding more servers or increasing the resources available to existing servers can help mitigate the issue. Review and optimize Consul configuration: Review your Consul configuration and make any necessary optimizations to ensure the best performance. For instance, you could adjust the . Investigate and resolve any underlying issues causing the saturation: Look for any factors contributing to the increased load on the FSM Raft goroutine and address those issues. This may involve reviewing application workloads, network latency, or hardware limitations.
Project: GO Feature Flag (Observability and Analysis / Feature Flagging)
File: redis.md

sidebar_position: 7 The `redisRetriever` will use the redis database to get your flags. ```go linenums="1" err := ffclient.Init(ffclient.Config{ PollingInterval: 3 * time.Second, Retriever: &redisRetriver.Retriever{ Prefix: "goff:", Options: &redis.Options{ Addr: "127.0.0.1:6379", }, }, }) defer ffclient.Close() ``` If you use Redis to store your flags, you need a specific format to store your flags. We expect the flag to be stored as a `string:string` format where the key if the flag key (with or without a prefix) and the value is a string representing the flag in JSON. The retriever will `Scan` redis filtering with the `Prefix` and will parse the value as a JSON object. ` To configure your redis retriever: | Field | Description | ||| | `Options` | A `redis.Options` object containing the connection information to the redis instance. | | `Prefix` | (optional) Key prefix to filter on the key names. |
Project: Netdata (Observability and Analysis / Observability)
File: riakkv_vm_high_process_count.md

The `riakkvvmhighprocesscount` alert is related to the Riak KV database. It warns you when the number of processes running in the Erlang VM is high. High process counts can result in performance degradation due to scheduling overhead. This alert is triggered in the warning state when the number of processes is greater than 10,000 and in the critical state when it is greater than 100,000. Check the current number of processes in the Erlang VM. You can use the following command to see the active processes: ``` riak-admin status | grep vnodemanagementprocs ``` Check the Riak KV logs (/var/log/riak) to see if there are any error messages or stack traces. This can help you identify issues and potential bottlenecks in your system. Check the CPU, memory, and disk space usage on the system hosting the Riak KV database. High usage in any of these areas can also contribute to performance issues and the high process count. Use commands like `top`, `free`, and `df` to monitor these resources. Review your Riak KV configuration settings. You may need to adjust the `+P` and `+S` flags, which control the maximum number of processes and scheduler threads (respectively) that the Erlang runtime system can create. These settings can be found in the `vm.args` file. ``` vim /etc/riak/vm.args ``` If needed, optimize the Riak KV database by adjusting the configuration settings or by adding more resources to your system, such as RAM or CPU cores. Ensure that your application is not creating an excessive number of processes. You may need to examine your code and see if there are any ways to reduce the Riak KV process count.
Project: Graylog (Observability and Analysis / Observability)
File: introduction.md

Our UI documentation provides a collection of our UI and UX guidelines. It also provides gallery of shared components that you can use when writing frontend code. You can find an overview of our frontend code conventions in the . Please take your time to read through these documents and make sure you follow our guidelines. This document is not complete, but we will do our best to make it our to-go reference when writing frontend code. If you encounter a shared component or a best practice which has not been documented, please extend the documentation. We all benefit from documenting our processes and components, as it helps us to use them without expending too much time reading at the source code, and also to think twice about how we solved a certain problem.
Project: Netdata (Observability and Analysis / Observability)
File: conntrack.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/proc.plugin/integrations/conntrack.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/proc.plugin/metadata.yaml" sidebar_label: "Conntrack" learn_status: "Published" learnrelpath: "Collecting Metrics/Linux Systems/Firewall" 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/firewall.svg" width="150"/> Plugin: proc.plugin Module: /proc/net/stat/nf_conntrack <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> This integration monitors the connection tracking mechanism of Netfilter in the Linux Kernel. 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. This scope has no labels. Metrics: | Metric | Dimensions | Unit | |:|:-|:-| | netfilter.conntrack_sockets | connections | active connections | | netfilter.conntrack_new | new, ignore, invalid | connections/s | | netfilter.conntrackchanges | inserted, deleted, deletelist | changes/s | | netfilter.conntrack_expect | created, deleted, new | expectations/s | | netfilter.conntrack_search | searched, restarted, found | searches/s | | netfilter.conntrackerrors | icmperror, errorfailed, drop, earlydrop | events/s | The following alerts are available: | Alert name | On metric | Description | |:|:-|:| | | netfilter.conntrack_sockets | netfilter connection tracker table size utilization | No action required. There is no configuration file. There are no configuration options. There are no configuration examples.