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

```js import { NavItem } from 'components/bootstrap'; <Nav bsStyle="pills" activeKey={1}> <NavItem eventKey={1} href="#"> NavItem 1 content </NavItem> <NavItem eventKey={2} title="Item"> NavItem 2 content </NavItem> <NavItem eventKey={3} disabled> NavItem 3 content </NavItem> </Nav> ``` ```js import { NavItem, NavDropdown, MenuItem } from 'components/bootstrap'; <Nav bsStyle="tabs" activeKey="1" onSelect={k => this.handleSelect(k)}> <NavItem eventKey="1" href="/home"> NavItem 1 content </NavItem> <NavItem eventKey="2" title="Item"> NavItem 2 content </NavItem> <NavItem eventKey="3" disabled> NavItem 3 content </NavItem> <NavDropdown eventKey="4" title="Dropdown" id="nav-dropdown"> <MenuItem eventKey="4.1">Action</MenuItem> <MenuItem eventKey="4.2">Another action</MenuItem> <MenuItem eventKey="4.3">Something else here</MenuItem> <MenuItem divider /> <MenuItem eventKey="4.4">Separated link</MenuItem> </NavDropdown> </Nav> ``` ```js import { NavItem, NavDropdown, MenuItem } from 'components/bootstrap'; <Nav bsStyle="pills" stacked activeKey={1}> <NavItem eventKey={1} href="/home"> NavItem 1 content </NavItem> <NavItem eventKey={2} title="Item"> NavItem 2 content </NavItem> <NavItem eventKey={3} disabled> NavItem 3 content </NavItem> </Nav> ``` ```js import { NavItem } from 'components/bootstrap'; <Nav bsStyle="tabs" justified activeKey={1} <NavItem eventKey={1} href="/home"> NavItem 1 content </NavItem> <NavItem eventKey={2} title="Item"> NavItem 2 content </NavItem> <NavItem eventKey={3} disabled> NavItem 3 content </NavItem> </Nav> ```
Project: PowerfulSeal (Observability and Analysis / Chaos Engineering)
File: master-node.md

layout: default title: Taking VMs down description: "" permalink: /master-node parent: Writing policies nav_order: 3 {: .no_toc } {: .no_toc .text-delta } TOC {:toc} Let's say that you'd like to make sure that if one of the VMs in your cluster goes down (let's say one that's running master nodes), some service running on them still works well. Well, PowerfulSeal can do that for you. If you'd like to modify the state of VMs, you're going to need to configure a cloud driver. You can learn how to do that . ```yaml name: Test load-balancing on master nodes steps: nodeAction: matches: property: name: "name" value: ".master." filters: property: name: "state" value: "UP" randomSample: size: 1 actions: stop: force: false probeHTTP: target: url: "http://load-balancer.example.com" retries: 3 count: 100 nodeAction: matches: property: name: "name" value: ".master." filters: property: name: "state" value: "DOWN" actions: start ``` By default, VMs stopped by the Seal will be auto-restarted at the end of scenario (or if there is a failure, in the cleanup). You can disable that by setting `autoRestart` to false. ```yaml name: Take machines down, and don't bring them back up steps: nodeAction: matches: property: name: "name" value: ".master." filters: randomSample: size: 1 actions: stop: autoRestart: false ```
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_priorityClass.KubePriorityClass.md

title: "Interface: KubePriorityClass" linkTitle: "KubePriorityClass" slug: "libk8spriorityClass.KubePriorityClass" .KubePriorityClass `KubePriorityClass` `Optional` apiVersion: `string` . _ description: `string` _ `Optional` globalDefault: `boolean` _ 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: . _ preemptionPolicy: `string` _ value: `number`
Project: VictoriaMetrics (Observability and Analysis / Observability)
File: enterprise.md

sort: 13 weight: 13 title: Enterprise features menu: docs: parent: "operator" weight: 13 aliases: /operator/enterprise.html Operator doesn't have enterprise version for itself, but it supports : : - : - - - - - - - - - More information about enterprise features you can read on . In order to find examples of deploying enterprise components with operator, please, check documentation.
Project: Graylog (Observability and Analysis / Observability)
File: TimeUnitInput.md

```js import createReactClass from 'create-react-class'; const TimeUnitInputExample = createReactClass({ getInitialState() { return { value: undefined, unit: 'MINUTES', enabled: false, }; }, onChange(value, unit, checked) { this.setState({ value: value, unit: unit, enabled: checked }); }, render() { const { value, unit, enabled } = this.state; return ( <div> <p>{enabled ? `${value} ${unit}` : 'Disabled'}</p> <TimeUnitInput value={value} unit={unit} units={['SECONDS', 'MINUTES', 'DAYS']} enabled={enabled} update={this.onChange} defaultValue={7} /> </div> ); }, }); <TimeUnitInputExample /> ```
Project: Netdata (Observability and Analysis / Observability)
File: bandwidth-requirements.md

Standalone Netdata may use network bandwidth under the following conditions: You configured data collection jobs that are fetching data from remote systems. There is no such jobs enabled by default. You use the dashboard of the Netdata. (see below). Netdata supports multiple compression algorithms for streaming communication. Netdata Children offer all their compression algorithms when connecting to a Netdata Parent, and the Netdata Parent decides which one to use based on algorithms availability and user configuration. | Algorithm | Best for | |::|:--:| | `zstd` | The best balance between CPU utilization and compression efficiency. This is the default. | | `lz4` | The fastest of the algorithms. Use this when CPU utilization is more important than bandwidth. | | `gzip` | The best compression efficiency, at the expense of CPU utilization. Use this when bandwidth is more important than CPU utilization. | | `brotli` | The most CPU intensive algorithm, providing the best compression. | The expected bandwidth consumption using `zstd` for 1 million samples per second is 84 Mbps, or 10.5 MiB/s. The order compression algorithms is selected is configured in `stream.conf`, per `[API KEY]`, like this: ``` compression algorithms order = zstd lz4 brotli gzip ``` The first available algorithm on both the Netdata Child and the Netdata Parent, from left to right, is chosen. Compression can also be disabled in `stream.conf` at either Netdata Children or Netdata Parents. When Netdata Agents connect to Netdata Cloud, they communicate metadata of the metrics being collected, but they do not stream the samples collected for each metric. The information transferred to Netdata Cloud is: Information and metadata about the system itself, like its hostname, architecture, virtualization technologies used and generally labels associated with the system. Information about the running data collection plugins, modules and jobs. Information about the metrics available and their retention. Information about the configured alerts and their transitions. This is not a constant stream of information. Netdata Agents update Netdata Cloud only about status changes on all the above (e.g. an alert being triggered, or a metric stopped being collected). So, there is an initial handshake and exchange of information when Netdata starts, and then there only updates when required. Of course, when you view Netdata Cloud dashboards that need to query the database a Netdata agent maintains, this query is forwarded to an agent that can satisfy it. This means that Netdata Cloud receives metric samples only when a user is accessing a dashboard and the samples transferred are usually aggregations to allow rendering the dashboards.
Project: Grafana (Observability and Analysis / Observability)
File: link-trace-id.md

description: Link to trace IDs from logs and metrics keywords: grafana tempo guide tracing labels: products: cloud enterprise oss menuTitle: Link to a trace ID title: Link to a trace ID weight: 700 You can link to Tempo traces from logs or metrics. You can link to Tempo traces from logs in Loki, Elasticsearch, Splunk, and other logs data sources by configuring an internal link. To configure this feature, see the section of the Loki data source docs or the section of the Elasticsearch or Splunk data source docs. You can link to Tempo traces from metrics in Prometheus data sources by configuring an exemplar. To configure this feature, see the documentation. {{% docs/reference %}} {{% /docs/reference %}}
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-8-2-1.md

_build: list: false labels: products: cloud enterprise oss title: Release notes for Grafana 8.2.1 <!-- Auto generated by update changelog github action --> Dashboard: Fix rendering of repeating panels. , Datasources: Fix deletion of data source if plugin is not found. , Packaging: Remove systemcallfilters sections from systemd unit files. , Prometheus: Add Headers to HTTP client options. ,
Project: PowerfulSeal (Observability and Analysis / Chaos Engineering)
File: 7_faq.md

layout: default title: FAQ nav_order: 7 description: "" permalink: /faq {: .no_toc } {: .no_toc .text-delta } TOC {:toc} We found these two links to be a good start: PowerfulSeal was inspired by Chaos Monkey, but it differs in a couple of important ways. The Seal does: speak Kubernetes offer flexible, easy to write YAML scenarios provide interactive mode with awesome tab-completion The Seal doesn't: need external dependencies (db, Spinnaker), apart from SSH, cloud and Kubernetes API access need you to setup ```cron``` rely on randomness for all of your experiments We would love you to. In particular, it would be great to get help with: get more get more <del>get an amazing logo</del> make the PowerfulSeal more powerful Check out our page for more information about how to contribute. It might have been inspired by .
Project: M3 (Observability and Analysis / Observability)
File: grafana.md

title: "Grafana" weight: 4 M3 supports a variety of Grafana integrations. M3Coordinator can function as a datasource for Prometheus as well as Graphite. See the and documents respectively for more information. All M3 applications expose Prometheus metrics on port `7203` by default as described in the , so if you're already monitoring your M3 stack with Prometheus and Grafana you can use our pre-configured dashboards. M3Coordinator Prometheus / Grafana dashboard: TODO Alternatively, you can obtain the JSON for our most up-to-date dashboards from our directly.
Project: Netdata (Observability and Analysis / Observability)
File: tcp_connections.md

This alert is related to the percentage of used IPv4 TCP connections. If you receive this alert, it means that your system has high TCP connections utilization, and you might be approaching the limit of maximum connections. When the number of IPv4 TCP connections gets too high, the system's ability to establish new connections decreases. This is because there are limitations due to resources such as memory or system settings. High utilization could lead to connection-related issues or service interruptions. Check current TCP connections: To see the current number of TCP connections, you can use the `ss` or `netstat` command: ``` ss -t | grep ESTAB | wc -l ``` or ``` netstat -ant | grep ESTABLISHED | wc -l ``` Identify connections with high usage: To list the connections with their state (e.g., ESTABLISHED, LISTEN), use the following command: ``` ss -tan ``` Look for connections with a high number of ESTABLISHED connections, as these may be contributing to the high utilization. Inspect running processes to identify potential culprits: You can use the `lsof` command to list all open files and the processes that are using them: ``` sudo lsof -iTCP ``` Look for processes with a high number of open files, as these are likely responsible for the increased TCP connections utilization. Take action: Once you have identified the processes contributing to high TCP connections utilization, you can take appropriate action. This may involve optimizing the application, adjusting system settings, or optimizing hardware resources.
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-alarm_eventnote_get.md

category: Alarm apiurl: '/api/v1/alarm/event_note' title: 'Get Event Note by id or time range' type: 'GET' sample_doc: 'alarm.html' layout: default Required Content-type: application/x-www-form-urlencoded ```endTime=1466697600&startTime=1466611200``` or ```eventid=s165_cef145900bf4e2a4a0db8b85762b9cdb``` ```Status: 200``` ``` [ { "case_id": "", "eventcaseId": "s165_cef145900bf4e2a4a0db8b85762b9cdb", "note": "test", "status": "ignored", "timestamp": "2016-06-23T05:39:09+08:00", "user": "root" }, { "case_id": "", "eventcaseId": "s165_9d223f126e7ecb3477cd6806f1ee9656", "note": "Ignored by user", "status": "ignored", "timestamp": "2016-06-23T05:38:56+08:00", "user": "root" } ] ``` For errors responses, see the .
Project: Checkmk (Observability and Analysis / Observability)
File: 16165.md

key | value | compatible | yes version | 2.3.0b1 date | 2024-01-02T10:09:48+00:00 level | 1 class | fix component | checks edition | cre Previously, Checkmk agents would be run with a preset LC_ALL environment variable if neither C.UTF-8 or C.utf-8 locales were installed. That led to invalid agent output and crashes in section parsing in multiple checks for some of the locales. Linux, AIX, Solaris, FreeBSD and OpenWrt agents were affected. Now, LC_ALL variable is set to C for the described case.
Project: Inspektor Gadget (Observability and Analysis / Observability)
File: snisnoop.md

title: Gadget snisnoop The snisnoop gadget retrieves Server Name Indication (SNI) from TLS requests. ```yaml apiVersion: gadget.kinvolk.io/v1alpha1 kind: Trace metadata: name: snisnoop namespace: gadget spec: node: minikube gadget: snisnoop filter: namespace: default runMode: Manual outputMode: Stream ``` Start snisnoop ```bash $ kubectl annotate -n gadget trace/snisnoop \ gadget.kinvolk.io/operation=start ``` Stop snisnoop ```bash $ kubectl annotate -n gadget trace/snisnoop \ gadget.kinvolk.io/operation=stop ``` Stream
Project: Grafana Loki (Observability and Analysis / Observability)
File: local.md

title: Local menuTitle: Install locally description: Describes how to install and run Grafana Loki locally. aliases: ../../installation/local/ weight: 500 In order to log events with Grafana Loki, download and install both Promtail and Loki. Loki is the logging engine. Promtail sends logs to Loki. The configuration specifies running Loki as a single binary. Add Granafa's Advanced Package Tool or RPM Package Manager package repository following the linked instructions. Install Loki and Promtail Using `dnf` ``` dnf update dnf install loki promtail ``` Using `apt-get` ``` apt-get update apt-get install loki promtail ``` Navigate to the . Scroll down to the Assets section under the version that you want to install. Download the Loki and Promtail .zip files that correspond to your system. Do not download LogCLI or Loki Canary at this time. `LogCLI` allows you to run Loki queries in a command line interface. is a tool to audit Loki performance. Unzip the package contents into the same directory. This is where the two programs will run. In the command line, change directory (`cd` on most systems) to the directory with Loki and Promtail. Copy and paste the commands below into your command line to download generic configuration files. Use the corresponding Git refs that match your downloaded Loki version to get the correct configuration file. For example, if you are using Loki version 2.9.2, you need to use the `https://raw.githubusercontent.com/grafana/loki/v2.9.2/cmd/loki/loki-local-config.yaml` URL to download the configuration file that corresponds to the Loki version you aim to run. ``` wget https://raw.githubusercontent.com/grafana/loki/main/cmd/loki/loki-local-config.yaml wget https://raw.githubusercontent.com/grafana/loki/main/clients/cmd/promtail/promtail-local-config.yaml ``` Enter the following command to start Loki: Windows ``` .\loki-windows-amd64.exe --config.file=loki-local-config.yaml ``` Linux ``` ./loki-linux-amd64 -config.file=loki-local-config.yaml ``` Loki runs and displays Loki logs in your command line and on http://localhost:3100/metrics. The next step will be running an agent to send logs to Loki. To do so with Promtail, refer to the . Every release includes binaries for Loki which can be found on the . The community provides packages of Loki for openSUSE Linux. To install: Add the repository `https://download.opensuse.org/repositories/security:/logging/` to your system. For example, if you are using Leap 15.1, run `sudo zypper ar https://download.opensuse.org/repositories/security:/logging/openSUSELeap15.1/security:logging.repo ; sudo zypper ref` Install the Loki package with `zypper in loki` Enable the Loki and Promtail services: `systemd start loki && systemd enable loki` `systemd start promtail && systemd enable promtail` Modify the configuration files as needed: `/etc/loki/promtail.yaml` and `/etc/loki/loki.yaml`.
Project: Vector (Observability and Analysis / Observability)
File: 2020-10-27-metrics-integrations.md

date: "2020-10-27" title: "New metrics integrations" description: "Collect metrics from your host, Apache, Nginx, and Mongodb." authors: ["jamtur01"] pr_numbers: [3704, 4157, 4500, 4698, 5209] release: "0.11.0" hideonrelease_notes: false badges: type: "new feature" domains: ["metrics", "sources"] Vector 0.11 includes new metrics sources: A new A new A new A new A new A new And while these are only six sources, they represent a broader initiative to replace metrics agents entirely. A lot of groundwork was laid to expedite these types of integrations, so you can expect many more of them in subsequent Vector releases. For anyone that manages observability pipelines, it's not uncommon to deploy multiple agents on a single host (an understatement). We've seen setups that deploy five or more agents on a single host -- using more than _30% of the CPU resources for that host_! We cover this in detail in our . It's a genuine and costly problem. Vector has its sights set on solving this. We want Vector to be the single agent for all of your logs, metrics, and traces. To get started with these sources, define them and go: ```toml [sources.host_metrics] type = "hostmetrics" # or apachemetrics, mongodbmetrics, or internalmetrics [sinks.prometheus] type = "prometheus" inputs = ["host_metrics"] ``` Tada! One agent for all of your data. Check out the for more details. We'd love to chat! We're eager to unblock the transition. If Vector is missing a metrics integration or feature, . We are working closely with a number of organizations to assist with this transition.
Project: PowerfulSeal (Observability and Analysis / Chaos Engineering)
File: README.md

Powerfulseal can be deployed on your Kubernetes cluster to perform random chaos the application services. Apply the rbac.yml (choose the appropriate namespace) to setup a service account with sufficient privileges `kubectl apply -f rbac.yml` Precondition the powerfulseal.yml to reflect the desired chaos policy & application service (namespace, labels) in the configmap data `kubectl apply -f powerfulseal.yml`
Project: Graylog (Observability and Analysis / Observability)
File: ClipboardButton.md

```js <ClipboardButton title="Copy me!" text="Copy me!" /> ``` `ClipboardButton` with `onSuccess` callback: ```js <div> <p id="clipboard-button-2">This text will be copied to your clipboard.</p> <ClipboardButton title="Copy me too!" target="#clipboard-button-2" onSuccess={() => alert('Copied to clipboard!')} bsStyle="info" bsSize="small" /> </div> ```
Project: Vector (Observability and Analysis / Observability)
File: 2021-10-06-arc-default.md

date: "2021-10-06" title: "HTTP-based sinks now use adaptive concurrency by default" description: "" authors: ["jszwedko"] pr_numbers: [] release: "0.17.0" hideonrelease_notes: false badges: type: "announcement" Originally released as an opt-in feature in , Vector's adaptive concurrency has been promoted to the default behavior for all HTTP-based sinks. This was following months of testing and feedback from users that had opted into adaptive concurrency. We expect users to see an overall improvement in the throughput of Vector along with Vector automatically backing off in the face of increased pressure downstream, to avoid overwhelming the sink destination. This feature was previously able to be opted into with the following configuration: ```toml request.concurrency = "adaptive" ``` This is the new default for HTTP-based sinks. As mentioned in the [announcement blog post][0.11.0] the adaptive concurrency controller will automatically respond to back-pressure from the destination of the sink (in the form of increased response times or explicit HTTP 429 response codes, among others). We welcome any feedback from users in our ! If you would like to instead use a fixed concurrency as was previously the default, you can set a static value like: ```toml request.concurrency = 5 ``` This will tell Vector to limit to 5 concurrent requests.
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_namespace.Namespace.md

title: "Class: Namespace" linkTitle: "Namespace" slug: "libk8snamespace.Namespace" .Namespace `any` `Namespace` new Namespace(`json`) | Name | Type | | : | : | | `json` | | makeKubeObject<KubeNamespace\>('namespace').constructor `Static` apiEndpoint: `Object` | Name | Type | | : | : | | `apiInfo` | { `group`: `string` ; `resource`: `string` ; `version`: `string` }[] | | `delete` | (`name`: `string`, `queryParams?`: , `cluster?`: `string`) => `Promise`<`any`\> | | `get` | (`name`: `string`, `cb`: , `errCb`: , `queryParams?`: , `cluster?`: `string`) => `Promise`<() => `void`\> | | `isNamespaced` | `boolean` | | `list` | (`cb`: , `errCb`: , `queryParams?`: , `cluster?`: `string`) => `Promise`<() => `void`\> | | `patch` | (`body`: `OpPatch`, `cluster?`: `string`) => `Promise`<`any`\> | | `post` | (`body`: , `queryParams?`: , `cluster?`: `string`) => `Promise`<`any`\> | | `put` | (`body`: , `queryParams?`: , `cluster?`: `string`) => `Promise`<`any`\> | _ `Static` className: `string` makeKubeObject<KubeNamespace\>('namespace').className `get` status(): `any` `any` `Static` apiList(`onList`, `onError?`, `opts?`): `any` | Name | Type | | : | : | | `onList` | (`arg`: `any`[]) => `void` | | `onError?` | (`err`: ) => `void` | | `opts?` | | `any` makeKubeObject<KubeNamespace\>('namespace').apiList _ `Static` `Optional` getAuthorization(`arg`, `resourceAttrs?`): `any` | Name | Type | | : | : | | `arg` | `string` | | `resourceAttrs?` | | `any` makeKubeObject<KubeNamespace\>('namespace').getAuthorization _ `Static` getErrorMessage(`err?`): ``null`` \| `string` | Name | Type | | : | : | | `err?` | ``null`` \| | ``null`` \| `string` makeKubeObject<KubeNamespace\>('namespace').getErrorMessage _ `Static` useApiGet(`onGet`, `name`, `namespace?`, `onError?`): `void` | Name | Type | | : | : | | `onGet` | (...`args`: `any`) => `void` | | `name` | `string` | | `namespace?` | `string` | | `onError?` | (`err`: ) => `void` | `void` makeKubeObject<KubeNamespace\>('namespace').useApiGet _ `Static` useApiList(`onList`, `onError?`, `opts?`): `any` | Name | Type | | : | : | | `onList` | (`arg`: `any`[]) => `void` | | `onError?` | (`err`: ) => `void` | | `opts?` | | `any` makeKubeObject<KubeNamespace\>('namespace').useApiList _ `Static` useGet(`name`, `namespace?`): , (`item`: `any`) => `void`, (`err`: ``null`` \| ) => `void`] | Name | Type | | : | : | | `name` | `string` | | `namespace?` | `string` | , (`item`: `any`) => `void`, (`err`: ``null`` \| ) => `void`] makeKubeObject<KubeNamespace\>('namespace').useGet _ `Static` useList(`opts?`): , (`items`: `any`) => `void`] | Name | Type | | : | : | | `opts?` | | , (`items`: `any`) => `void`] makeKubeObject<KubeNamespace\>('namespace').useList
Project: Checkmk (Observability and Analysis / Observability)
File: 16316.md

key | value | compatible | yes version | 2.4.0b1 date | 2024-02-09T10:20:05+00:00 level | 1 class | fix component | reporting edition | cee If a report with more than one view element was created e.g. via the report snapin, the defined timerange was only set from the second view element on.