cwielenb/CNCF-Dataset huggingface dataset:
Project: Netdata (Observability and Analysis / Observability)
File: 1m_sent_traffic_overflow.md

Network interfaces are categorized primarily on the bandwidth rate at which they can operate (1 Gbps, 10 Gbps, etc). High network utilization occurs when the volume of data on a network link approaches the capacity of the link. Netdata agent calculates the average outbound utilization for a specific network interface over the last minute. High outbound utilization increases latency and packet loss because packet bursts are buffered. This alarm may indicate either a network congestion or malicious activity. Prioritize important traffic Quality of service (QoS) is the use of mechanisms or technologies to control traffic and ensure the performance of critical applications. QoS works best when low-priority traffic exists that can be dropped when congestion occurs. The higher-priority traffic must fit within the bandwidth limitations of the link or path. Add more bandwidth For Cloud infrastructures, adding bandwidth might be easy. It depends on your cloud infrastracture and your cloud provider. Some of them either offer you the service to upgrade machines to a higher bandwidth rate or upgrade you machine to a more powerful one with higher bandwidth rate. For Bare-metal machines, you will need either a hardware upgrade or the addition of a network card using link aggregation to combine multiple network connections in parallel (e.g LACP). is a traffic shaping helper. It has a very simple shell scripting language to express traffic shaping. is a command wrapper that makes it easy to set up traffic control of network bandwidth/latency/packet-loss/packet-corruption/etc.
Project: OpenLLMetry (Observability and Analysis / Observability)
File: GOVERNANCE.md

This document defines the governance policies of OpenLLMetry. Anyone can contribute to OpenLLMetry, whether through code, design discussions, documentation, blog posts, talks, or other means. All contributors are expected to follow the OpenLLMetry . Contributions to the code base, documentation, or other components in the OpenLLMetry GitHub repositories must follow the guidelines described in the document. Whether these contributions get merged into the project is the prerogative of the maintainers. Maintainers are responsible for the overall security, quality and integrity of the project. They propose, manage, review, approve/reject major change and enhancement requests. They also have the ability to merge code into the project. See the document for the full list of maintainer responsibilities. Ideally, all project decisions are resolved by maintainer consensus. If this is not possible, maintainers may call for a vote. The voting process is a simple majority in which each maintainer receives one vote. If a maintainer is no longer interested in or cannot perform the duties listed above, they should move themselves to emeritus status. This can also occur by a vote of the maintainers. Anyone can become an OpenLLMetry maintainer. Maintainers should be extremely proficient in Python; have relevant domain expertise; have the time and ability to meet the maintainer expectations outlined above, and demonstrate the ability to work with the existing maintainers and project process. To become a maintainer, start by expressing interest to existing maintainers. Existing maintainers will then ask you to demonstrate the qualifications above by contributing PRs, doing code reviews, and other such tasks under their guidance. After several months of working together, maintainers will decide whether to grant maintainer status. This governance is a living document and its policies will need to be updated over time to meet the community's needs. Until the steering committee is set up, the maintainers will have full ownership of this governance. Changes can be proposed at any time, but a super majority is required to approve any updates.
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_cronJob.CronJob.md

title: "Class: CronJob" linkTitle: "CronJob" slug: "libk8scronJob.CronJob" .CronJob `any` `CronJob` new CronJob(`json`) | Name | Type | | : | : | | `json` | | makeKubeObject<KubeCronJob\>('CronJob').constructor `Static` apiEndpoint: `Object` | Name | Type | | : | : | | `scale?` | { `get`: (`namespace`: `string`, `name`: `string`, `clusterName?`: `string`) => `Promise`<`any`\> ; `put`: (`body`: { `metadata`: ; `spec`: { `replicas`: `number` } }, `clusterName?`: `string`) => `Promise`<`any`\> } | | `scale.get` | (`namespace`: `string`, `name`: `string`, `clusterName?`: `string`) => `Promise`<`any`\> | | `scale.put` | (`body`: { `metadata`: ; `spec`: { `replicas`: `number` } }, `clusterName?`: `string`) => `Promise`<`any`\> | _ `Static` className: `string` makeKubeObject<KubeCronJob\>('CronJob').className `get` spec(): `any` `any` _ `get` status(): `any` `any` getContainers(): [] [] _ `Static` apiList(`onList`, `onError?`, `opts?`): `any` | Name | Type | | : | : | | `onList` | (`arg`: `any`[]) => `void` | | `onError?` | (`err`: ) => `void` | | `opts?` | | `any` makeKubeObject<KubeCronJob\>('CronJob').apiList _ `Static` `Optional` getAuthorization(`arg`, `resourceAttrs?`): `any` | Name | Type | | : | : | | `arg` | `string` | | `resourceAttrs?` | | `any` makeKubeObject<KubeCronJob\>('CronJob').getAuthorization _ `Static` getErrorMessage(`err?`): ``null`` \| `string` | Name | Type | | : | : | | `err?` | ``null`` \| | ``null`` \| `string` makeKubeObject<KubeCronJob\>('CronJob').getErrorMessage _ `Static` useApiGet(`onGet`, `name`, `namespace?`, `onError?`): `void` | Name | Type | | : | : | | `onGet` | (...`args`: `any`) => `void` | | `name` | `string` | | `namespace?` | `string` | | `onError?` | (`err`: ) => `void` | `void` makeKubeObject<KubeCronJob\>('CronJob').useApiGet _ `Static` useApiList(`onList`, `onError?`, `opts?`): `any` | Name | Type | | : | : | | `onList` | (`arg`: `any`[]) => `void` | | `onError?` | (`err`: ) => `void` | | `opts?` | | `any` makeKubeObject<KubeCronJob\>('CronJob').useApiList _ `Static` useGet(`name`, `namespace?`): , (`item`: `any`) => `void`, (`err`: ``null`` \| ) => `void`] | Name | Type | | : | : | | `name` | `string` | | `namespace?` | `string` | , (`item`: `any`) => `void`, (`err`: ``null`` \| ) => `void`] makeKubeObject<KubeCronJob\>('CronJob').useGet _ `Static` useList(`opts?`): , (`items`: `any`) => `void`] | Name | Type | | : | : | | `opts?` | | , (`items`: `any`) => `void`] makeKubeObject<KubeCronJob\>('CronJob').useList
Project: Grafana Loki (Observability and Analysis / Observability)
File: output.md

title: output menuTitle: description: The 'output' Promtail pipeline stage. aliases: ../../../clients/promtail/stages/output/ weight: The `output` stage is an action stage that takes data from the extracted map and changes the log line that will be sent to Loki. ```yaml output: source: <string> ``` For the given pipeline: ```yaml json: expressions: user: user message: message labels: user: output: source: message ``` And the given log line: ``` {"user": "alexis", "message": "hello, world!"} ``` Then the first stage will extract the following key-value pairs into the extracted map: `user`: `alexis` `message`: `hello, world!` The second stage will then add `user=alexis` to the label set for the outgoing log line, and the final `output` stage will change the log line from the original JSON to `hello, world!`
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-7-4-1.md

_build: list: false labels: products: cloud enterprise oss title: Release notes for Grafana 7.4.1 <!-- Auto generated by update changelog github action --> Influx: Make max series limit configurable and show the limiting message if applied. , Make value mappings correctly interpret numeric-like strings. , Variables: Adds queryparam formatting option. , Alerting: Fixes so notification channels are properly deleted. , BarGauge: Improvements to value sizing and table inner width calculations. , DashboardLinks: Fixes crash when link has no title. , Elasticsearch: Fix alias field value not being shown in query editor. , Elasticsearch: Fix log row context errors. , Elasticsearch: Show Size setting for raw_data metric. , Graph: Fixes so graph is shown for non numeric time values. , Logging: Ignore 'file already closed' error when closing file. , Plugins: Fix plugin signature validation for manifest v2 on Windows. , TextPanel: Fixes so panel title is updated when variables change. , Transforms: Fixes Outer join issue with duplicate field names not getting the same unique field names as before. ,
Project: Checkmk (Observability and Analysis / Observability)
File: 15515.md

key | value | date | 2024-04-03T13:15:48+00:00 version | 2.4.0b1 class | feature edition | cre component | checks level | 2 compatible | no The old plug-in is being deprecated in a soft way with this werk. Unlike hard deprecation, the deprecated rule set "Check HTTP service" will remain fully functional. However, new rules should only be created if absolutely necessary, such as when experiencing issues with the new "Check HTTP web service" implementation and needing to roll back to the old one. Please note that the rule set will be hard deprecated in version 2.4.0, meaning that you will no longer be able to create new rules. However, the plug-in itself will remain available as this is a component of the monitoring-plugins collection that comes with Checkmk. Please let us know if you find any features that were present in the old plug-in but are missing in the new one.
Project: Checkmk (Observability and Analysis / Observability)
File: 16172.md

key | value | date | 2024-02-27T09:14:50+00:00 version | 2.4.0b1 class | security edition | cre component | checks level | 1 compatible | yes Kaspersky Anti-Virus plugin uses /opt/kaspersky/kav4fs/bin/kav4fs-control and /opt/kaspersky/kesl/bin/kesl-control commands to monitor a Kaspersky Anti-Virus installation. To prevent privilege escalation, the plugin (which is run by root user) must not run executables which can be changed by less privileged users. In the default installation, kav4fs-control and kesl-control commands are owned by root and root is the only user with write permissions, which prevents privilege escalation attacks. With this Werk, the plugin checks if control commands are owned by root and root is the only user with write permissions before running the command. If that's not the case the commands won't be run. This prevents privilege escalation attacks if the permissions of the control commands have been changed. We rate this with a CVSS of 0 (None) (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N). This CVSS is primarily meant to please automatic scanners.
Project: Graphite (Observability and Analysis / Observability)
File: CONTRIBUTING_FOR_COMMITTERS.md

First of all, Welcome, and Thank You! I don't know about you, but I'm in it for all of the glory that @obfuscurity promised... The team has grown some in the last year or so, so let's get some ground rules: Be polite to the community. We are part of the community. Don't commit directly to the public repo. Please Fork and PR. Unless things are publicly broken and nobody else is around to validate, don't merge your own PR. If you're going to do something directly on the main repo, or something Meta (tags, releases, etc), other people should probably know about it. When in doubt, check with @deniszh, @DanCech or @piotr1212. Please update global CHANGELOG.md with your changes Be polite to the community.
Project: M3 (Observability and Analysis / Observability)
File: commitlogs.md

title: "Commit Logs And Snapshot Files" menuTitle: "Commit Logs" weight: 5 M3DB has a commit log that is equivalent to the commit log or write-ahead-log in other databases. The commit logs are completely uncompressed (no M3TSZ encoding), and there is one per database (multiple namespaces in a single process will share a commit log.) There are two integrity levels available for commit logs: Synchronous: write operations must wait until it has finished writing an entry in the commit log to complete. Behind: write operations must finish enqueueing an entry to the commit log write queue to complete. Depending on the data loss requirements users can choose either integrity level. Commit logs will be stamped by the start time, aligned and rotated by a configured time window size. To restore data for an entire block you will require the commit logs from all time commit logs that overlap the block size with buffer past subtracted from the bootstrap start range and buffer future extended onto the bootstrap end range. Commit logs for a given time window are kept in a single file. An info structure keeping metadata is written to the header of the file and all consequent entries are a repeated log structure, optionally containing metadata describing the series if it's the first time a log entry for a given series appears. The structures can be conceptually described as: ```golang CommitLogInfo { start int64 duration int64 index int64 } CommitLog { created int64 index uint64 metadata bytes timestamp int64 value float64 unit uint32 annotation bytes } CommitLogMetadata { id bytes namespace bytes shard uint32 } ``` Commit log files are compacted via the snapshotting proccess which (if enabled at the namespace level) will snapshot all data in memory into compressed files which have the same structure as the but are stored in a different location. Once these snapshot files are created, then all the commit log files whose data are captured by the snapshot files can be deleted. This can result in significant disk savings for M3DB nodes running with large block sizes and high write volume where the size of the (uncompressed) commit logs can quickly get out of hand. In addition, since the snapshot files are already compressed, bootstrapping from them is much faster than bootstrapping from raw commit log files because the individual datapoints don't need to be decoded and then M3TSZ encoded. The M3DB node just needs to read the raw bytes off disk and load them into memory. Commit log files are automatically deleted once all the data they contain has been flushed to disk as immutable compressed filesets or all the data they contain has been captured by a compressed snapshot file. Similarly, snapshot files are deleted once all the data they contain has been flushed to disk as filesets.
Project: Kubecost (Observability and Analysis / Continuous Optimization)
File: SECURITY.md

The OpenCost project greatly appreciates the need for security and timely updates, given our proximity to cloud billing. We are very grateful to the users, security researchers, and developers for reporting security vulnerabilities to us. All reported security vulnerabilities will be carefully assessed, addressed, and responded to. Application code is version controlled using GitHub. All code changes are tracked with full revision history and are attributable to a specific individual. Code must be reviewed and accepted by a different engineer than the author of the change. OpenCost has enabled for assessing dependencies in the project. OpenCost provides security updates for the two most recent minor versions released on GitHub. For example, if `v1.102.0` is the most recent stable version, we will address security updates for `v1.101.0` and later. Once `v1.103.0` is released, we will no longer provide updates for `v1.101.x` releases. The OpenCost project has enabled for our repositories which allows for direct reporting of issues to administrators and maintainers in a secure fashion. Please include a thorough description of the issue, the steps you took to create the issue, affected versions, and, if known, mitigations for the issue. The team will help diagnose the severity of the issue and determine how to address the issue. Issues deemed to be non-critical will be filed as GitHub issues. Critical issues will receive immediate attention and be fixed as quickly as possible. Kubecost offers a Bug Bounty program that pays $250 USD for unique, not previously disclosed publicly available CVEs, and accepted security bug reports submitted to vulnerability-report@kubecost.com. For known public security vulnerabilities, we will disclose the disclosure as soon as possible after receiving the report. Vulnerabilities discovered for the first time will be disclosed in accordance with the following process: The received security vulnerability report shall be handed over to the security team for follow-up coordination and repair work. After the vulnerability is confirmed, we will create a draft Security Advisory on GitHub that lists the details of the vulnerability. Invite related personnel to discuss the fix. Fork the temporary private repository on GitHub, and collaborate to fix the vulnerability. After the fixed code is merged into all supported versions, the vulnerability will be publicly posted in the GitHub Advisory Database.
Project: Grafana Loki (Observability and Analysis / Observability)
File: feature_request.md

name: Feature request about: Suggest an idea for this project title: '' labels: '' assignees: '' <!-- Please keep the structure below, or your issue may be closed. --> 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: Graylog (Observability and Analysis / Observability)
File: PaginatedList.md

```js import createReactClass from 'create-react-class'; const PaginatedListExample = createReactClass({ getInitialState() { const items = []; for(let i = 1; i <= 12; i++) items.push(i); return { currentPage: 0, items: items, pageSize: 5, }; }, onPageChange(currentPage, pageSize) { this.setState({ currentPage: currentPage - 1, pageSize: pageSize, }); }, render() { const { currentPage, items, pageSize } = this.state; const paginatedItems = items.slice(currentPage pageSize, (currentPage + 1) pageSize); return ( <PaginatedList totalItems={items.length} pageSize={pageSize} onChange={this.onPageChange} pageSizes={[5, 10, 20]}> <table className="table"> <thead> <tr> <th>Item</th> </tr> </thead> <tbody> {paginatedItems.map((item) => <tr key={item}><td>{item}</td></tr>)} </tbody> </table> </PaginatedList> ); }, }); <PaginatedListExample /> ```
Project: Netis (Observability and Analysis / Observability)
File: LICENSE.md

BSD 3-Clause License Copyright (c) 2018, Netis Technologies Co., Ltd. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. Neither the name of Netis nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Project: Kepler (Observability and Analysis / Observability)
File: fuzzy_mode_convert_table.md

| json type \ dest type | bool | int | uint | float |string| | | | | |--|--| | number | positive => true <br/> negative => true <br/> zero => false| 23.2 => 23 <br/> -32.1 => -32| 12.1 => 12 <br/> -12.1 => 0|as normal|same as origin| | string | empty string => false <br/> string "0" => false <br/> other strings => true | "123.32" => 123 <br/> "-123.4" => -123 <br/> "123.23xxxw" => 123 <br/> "abcde12" => 0 <br/> "-32.1" => -32| 13.2 => 13 <br/> -1.1 => 0 |12.1 => 12.1 <br/> -12.3 => -12.3<br/> 12.4xxa => 12.4 <br/> +1.1e2 =>110 |same as origin| | bool | true => true <br/> false => false| true => 1 <br/> false => 0 | true => 1 <br/> false => 0 |true => 1 <br/>false => 0|true => "true" <br/> false => "false"| | object | true | 0 | 0 |0|originnal json| | array | empty array => false <br/> nonempty array => true| [] => 0 <br/> [1,2] => 1 | [] => 0 <br/> [1,2] => 1 |[] => 0<br/>[1,2] => 1|original json|
Project: Vector (Observability and Analysis / Observability)
File: 2019-10-21-require-encoding-option-for-console-and-file-sinks.md

date: "2020-07-13" title: "Require `encoding` option for console and file sinks" description: "The `encoding` option is now required for these sinks" authors: ["binarylogic"] pr_numbers: [1033] release: "0.6.0" hideonrelease_notes: false badges: type: "breaking change" domains: ["sinks"] sinks: ["console", "file"] The dynamic `encoding` concept in Vector was confusing users, so we've made it required and explicit. Simply add `encoding.codec = "json"` to your `console` and `file` sinks. Make the following changes in your `vector.toml` file: ```diff title="vector.toml" [sinks.console] type = "console" encoding.codec = "json" [sinks.file] type = "file" encoding.codec = "json" ``` That's it!
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: fossa.md

|Litmus Component | Fossa Report | |--|--| | | No issues reported | | | https://app.fossa.com/attribution/163990cf-620c-4d6b-8fa9-f0b67deebe52 | | | https://app.fossa.com/attribution/2bbe14e1-8d7f-4c00-8bd9-3a70fd67539e | | | https://app.fossa.com/attribution/2bbe14e1-8d7f-4c00-8bd9-3a70fd67539e | | | https://app.fossa.com/attribution/220e18ad-2e3b-4671-90f6-2b6cc8f8601e | | | https://app.fossa.com/attribution/5f70aa0e-1379-404e-b069-0e50636f1cd6 | | | No issues reported | | | https://app.fossa.com/attribution/271d72f9-18b2-4c65-b32e-e6c7f9969d8e | | | No issues reported | | | No issues reported | | | https://app.fossa.com/attribution/5b329bbb-831d-48ec-9ff3-b6f75dab1d4e | | | No issues reported |