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

key | value | date | 2024-01-08T12:25:13+00:00 version | 2.3.0b1 class | fix edition | cce component | wato level | 1 compatible | yes When using a CCE in the trial phase or in the free license state, the UI was mostly unusable when the CMC was not running (with the pages showing the error "Cannot connect to 'unix:/omd/sites/monitoring_eval/tmp/run/live'....") Since the CMC is prohibited from starting if too many services are being monitored in the free license state, this meant that in order to get out of the free state, the license could only be applied via REST-API. This has now been fixed.
Project: Jaeger (Observability and Analysis / Observability)
File: ADOPTERS.md

* Case study: * Case study: PalFish Official site: , * https://github.com/jaegertracing/jaeger-openshift https://www.hawkular.org/blog/2017/04/19/hawkular-apm-jaeger.html * Case study: Talk: * Blog post: * Blog post: * Case study: Talk:
Project: Krkn (Observability and Analysis / Chaos Engineering)
File: pvc_scenario.md

Scenario to fill up a given PersistenVolumeClaim by creating a temp file on the PVC from a pod associated with it. The purpose of this scenario is to fill up a volume to understand faults caused by the application using this volume. ``` pvc_scenario: pvcname: <pvcname> # Name of the target PVC. podname: <podname> # Name of the pod where the PVC is mounted. It will be ignored if the pvc_name is defined. namespace: <namespace_name> # Namespace where the PVC is. fill_percentage: 50 # Target percentage to fill up the cluster. Value must be higher than current percentage. Valid values are between 0 and 99. duration: 60 # Duration in seconds for the fault. ``` Get the pod name where the PVC is mounted. Get the volume name mounted in the container pod. Get the container name where the PVC is mounted. Get the mount path where the PVC is mounted in the pod. Get the PVC capacity and current used capacity. Calculate file size to fill the PVC to the target fill_percentage. Connect to the pod. Create a temp file `kraken.tmp` with random data on the mount path: `dd bs=1024 count=$filesize </dev/urandom > /mountpath/kraken.tmp` Wait for the duration time. Remove the temp file created: `rm kraken.tmp`
Project: Grafana (Observability and Analysis / Observability)
File: testing.md

We should strive to use MSW for mocking API as often as possible. It gives us the closest behaviour to the real server. `public/app/features/alerting/unified/mockApi.ts` contains helper functions that speed up mocking API configuration with MSW. If you don't find a helper for an endpoint you're looking for, please add it. Mocking using MSW forces developers to handle loading states in tests which gives us a chance to discover UI inconsistencies at very early stages `/buildinfo` Use `mockFeatureDiscoveryApi` and `buildInfoResponse` object to mock the endpoint response according to your needs `api/v1/eval` used by AlertingQueryRunner Use `mockApi.eval` Usually an empty response should do the trick `public/app/features/alerting/unified/testSetup/datasources.ts` file contains functions facilitating setting up mock data sources. By default tests should be written with RBAC enabled. This is the most common scenario for our users. Testing with RBAC disabled should be considered as an additional option when we already have tests for enabled RBAC. To enable or disable Role Based Access Control in tests use `enableRBAC` or `disableRBAC` from `public/app/features/alerting/unified/mocks.ts` To grant a permission to a user use `grantUserPermission` from the same file. TODO
Project: OpenTelemetry (Observability and Analysis / Observability)
File: client-instrumentation.md

We believe that in order for OpenTelemetry to be adopted across the board, it needs to have a good support for client applications. Client instrumentation has some unique challenges that are currently not well supported. Our initial goals include define which signal(s) are used for different types of client telemetry define semantic conventions for different types of client events define semantic conventions for client-specific resources define how sessions are handled in SDKs and represented across the wire Beyond these, we expect that this will be a long-term ongoing project, which might include development of client-optimized SDKs. Also, given that there are many types of client applications/environments, this group may branch into multiple groups over time. https://github.com/orgs/open-telemetry/projects/19/views/1 Semantic conventions for (most common) client events Semantic conventions for (most common) client resources Logs/Events API + SDK in the Javascript SDK * Logs/Events API + SDK for Android Logs/Events API + SDK for Swift Implementation of sessions in the Javascript SDK Research + proposal for how browser SDK should be optimized Expertise required: browser instrumentation, mobile instrumentation The group currently has several regular contributors who have expertise in browser instrumentation. Most of the focus so far has been on browser and shared concerns across all types of client applications. We need more participation from mobile in order to move mobile instrumentation forward. Project lead(s): @martinkuba, @scheler, @MSNev TC sponsoring members: Josh Suereth, Jack Berg SIG meeting times: Mondays 12:30am PT Secondary meeting times: Tuesdays 9am PT Timeline 6 - 12 months
Project: Flagsmith (Observability and Analysis / Feature Flagging)
File: flag-analytics.md

title: Flag Analytics Flag Analytics allow you to track how often individual Flags are evaluated within the Flagsmith SDK. To view Analytics for a particular flag, browse to the relevant environment and click on a single flag to edit that flag. Flag Analytics can be really useful when removing flags from Flagsmith. More often than not, flags can be removed from your codebase and platform once they have been rolled out and everyone is comfortable with them running in production. Once you have removed the evaluation code from your code base, its nice to be sure that all references to that flag have been removed, and that removing the flag itself from Flagsmith will not cause any unforeseen issues. Flag Analytics help with this. Flag Analytics can also be helpful when identifying integration issues. Occasionally errors can creep into your code that cause multiple needless evaluations of a flag. Again, these analytics can help isolate these situations. :::info The Flag Analytics data will be visible in the Dashboard between 30 minutes and 1 hour after it has been collected. ::: Flag analytics are disabled by default in our SDKs. You need to explicitly enable it when you initialize the Flagsmith client. Please refer to the corresponding SDK documentation for more details. For the Javascript family SDKs please refer to . Every time a flag is evaluated within the SDK (generally a call to a method like `flagsmith.hasFeature("myCoolFeature")`), the SDK keeps a track of the flag name along with an evaluation count. Every `n` seconds (currently set to 10 seconds in the JS SDK) the SDK sends a message to the Flagsmith API with the list of flags that have been evaluated and their count. If no flags have been evaluated in that time window, no message is sent.
Project: Checkmk (Observability and Analysis / Observability)
File: 16167.md

key | value | compatible | yes version | 2.3.0b1 date | 2024-01-04T13:07:52+00:00 level | 1 class | fix component | checks edition | cre Pandacom devices with PSU types 65025-65033 caused a crash during section parsing. Now, Checkmk recognizes the new type codes and reports the correct PSU type.
Project: Grafana Mimir (Observability and Analysis / Observability)
File: about-ip-address-logging.md

aliases: ../configuring/about-ip-address-logging/ description: Troubleshoot errors by logging IP addresses of reverse proxies. menuTitle: IP address logging of a reverse proxy title: About Grafana Mimir IP address logging of a reverse proxy weight: 30 If a reverse proxy is used in front of Mimir, it might be difficult to troubleshoot errors. You can use the following settings to log the IP address passed along by the reverse proxy in headers such as `X-Forwarded-For`. `-server.log-source-ips-enabled` Set this to `true` to add IP address logging when a `Forwarded`, `X-Real-IP`, or `X-Forwarded-For` header is used. A field called `sourceIPs` is added to error logs when data is pushed into Grafana Mimir. `-server.log-source-ips-header` The header field stores the source IP addresses and is used only if `-server.log-source-ips-enabled` is `true`, and if `-server.log-source-ips-regex` is set. If you do not set these flags, the default `Forwarded`, `X-Real-IP`, or `X-Forwarded-For` headers are searched. `-server.log-source-ips-regex` A regular expression that is used to match the source IPs. The regular expression must contain at least one capturing group, the first of which is returned. This flag is used only if `-server.log-source-ips-enabled` is `true` and if `-server.log-source-ips-header` is set.
Project: Netdata (Observability and Analysis / Observability)
File: load_cpu_number.md

This alert, `loadcpunumber`, calculates the base trigger point for load average alarms, which helps identify when the system is overloaded. The alert checks the maximum number of CPUs in the system over the past 1 minute. If there is only one CPU, the trigger is set at 2. The term `system load average` on a Linux machine measures the number of threads that are currently working and those waiting to work (CPU, disk, uninterruptible locks). In simpler terms, the load average measures the number of threads that aren't idle. An overloaded system is when the demand on the system's resources (CPUs, disks, etc.) is higher than its capacity to handle tasks. This can lead to increased wait times, slower processing, and in worst cases, system crashes. Determine the current load average on the system: Use the `uptime` command in the terminal to see the current load average: ``` uptime ``` Identify if the problem is CPU load or I/O load: Use `vmstat` (or `vmstat 1`, to set a delay between updates in seconds) to get a report on system statistics: The `procs` column shows: r: The number of runnable processes (running or waiting for run time). b: The number of processes blocked waiting for I/O to complete. Check per-process CPU/disk usage to find the top consumers: a. Use `top` to see the processes that are the main CPU consumers: ``` top -o +%CPU -i ``` b. Use `iotop` to monitor Disk I/O usage (install it if not available): ``` sudo iotop ``` Minimize the load by closing any unnecessary main consumer processes. Double-check if the process you want to close is necessary.
Project: HertzBeat (Observability and Analysis / Observability)
File: alert_enterprise_wechat_app.md

id: alertenterprisewechat_app title: Alert Enterprise Wechat App notification sidebar_label: Alert Enterprise Wechat App notification keywords: [open source monitoring tool, open source alerter, open source Enterprise Wechat App notification] After the threshold is triggered send alarm information and notify the recipient by enterprise WeChat App. Enterprise Wechat backstage-> App Management-> Create an app-> Set App message->Copy AgentId and Secret adding successfully Alarm notification->Add new recipient ->Select Enterprise WeChat App notification method->Set Enterprise WeChat ID,Enterprise App ID and Enterprise App Secret -> Confirm Configure the associated alarm notification strategy Add new notification strategy-> Associate the recipient just set-> Confirm Note Adding a new recipient does not mean that it is effective to receive alarm information. It is also necessary to configure the associated alarm notification strategy, that is, to specify which messages are sent to which recipients. Enterprise WeChat App did not receive the alarm notification. Please check if the user has application permissions. Please check if the enterprise application callback address settings are normal. Please check if the server IP is on the enterprise application whitelist. Other issues can be fed back through the communication group ISSUE!
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-metric_tmplist.md

category: Metric apiurl: '/api/v1/metric/default_list' title: "Get Default Builtin Metric List" type: 'GET' sample_doc: 'template.html' layout: default Required Metric Suggestion for create strategy base on `./data/metric` file ```Status: 200``` ```[ "cpu.busy", "cpu.cnt", "cpu.guest", "cpu.idle", "cpu.iowait", "cpu.irq", "cpu.nice", "cpu.softirq", "cpu.steal", "cpu.system", "cpu.user", "df.bytes.free", "df.bytes.free.percent" .... ]```
Project: M3 (Observability and Analysis / Observability)
File: multiple_m3db_clusters.md

title: "Write to multiple M3DB clusters via m3coordinator" weight: 2 draft: true Default M3 architecture has the m3coordinator writing to and aggregating metrics from a single M3DB cluster. To map a single coordinator to more than one M3DB cluster, follow the below instructions. Use case(s): Sending metrics to different namespaces for different retention periods, etc. Add `clusterManagement` to config file to add multiple M3BD clusters to m3coordinator: Example config file with `clusterManagement` (see end of the config): ```bash clusters: client: config: service: env: default_env zone: embedded service: m3db cacheDir: /data/m3kv_default etcdClusters: zone: embedded endpoints: <ETCDIP1> <ETCDIP2> <ETCDIP3> writeRetry: initialBackoff: 500ms backoffFactor: 3 maxRetries: 2 jitter: true fetchRetry: initialBackoff: 500ms backoffFactor: 2 maxRetries: 3 jitter: true client: config: service: env: lts_env zone: embedded service: m3db cacheDir: /data/m3kv_lts etcdClusters: zone: embedded endpoints: <ETCDIP1> <ETCDIP2> <ETCDIP3> writeRetry: initialBackoff: 500ms backoffFactor: 3 maxRetries: 2 jitter: true fetchRetry: initialBackoff: 500ms backoffFactor: 2 maxRetries: 3 jitter: true tagOptions: idScheme: quoted clusterManagement: etcd: env: default_env zone: embedded service: m3db cacheDir: /data/m3kv_default etcdClusters: zone: embedded endpoints: <ETCDIP1> <ETCDIP2> <ETCDIP3> ``` Use the `Cluster-Environment-Name` header for any API requests to the m3coordinator.
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-user_get_info_by_id.md

category: User apiurl: '/api/v1/user/u/#{user_id}' title: 'Get User info by id' type: 'GET' sample_doc: 'user.html' layout: default Required `Admin` usage ex. /api/v1/user/u/4 ```Status: 200``` ```{ "id": 4, "name": "userA", "cnname": "tear", "email": "", "phone": "", "im": "", "qq": "", "role": 0 }``` For more example, see the . For errors responses, see the .
Project: Vector (Observability and Analysis / Observability)
File: 2023-05-22-0-30-0-upgrade-guide.md

date: "2023-05-22" title: "0.30 Upgrade Guide" description: "An upgrade guide that addresses breaking changes in 0.30.0" authors: ["neuronull"] release: "0.30.0" hideonrelease_notes: false badges: type: breaking change Vector's 0.30.0 release includes breaking changes: We cover them below to help you upgrade quickly: In v0.29.0 the `max_length` setting, used by the `tcp` and `unix` modes of the `socket` source, was marked as deprecated. That setting was replaced by the `max_length` setting within the `framing` setting. Any explicit usages of `max_length` for those modes of the `socket` source will no longer work and configurations will need to instead use a `framing` setting in order to set a maximum length.
Project: Graylog (Observability and Analysis / Observability)
File: InputGroup.md

```js import { FormControl, FormGroup, InputGroup, Button, DropdownButton, MenuItem } from 'components/bootstrap'; import Icon from 'components/common/Icon'; class FormExample extends React.Component { constructor(props, context) { super(props, context); this.handleChange = this.handleChange.bind(this); this.state = { value: '' }; } getValidationState() { const length = this.state.value.length; if (length > 10) return 'success'; if (length > 5) return 'warning'; if (length > 0) return 'error'; return null; } handleChange(e) { this.setState({ value: e.target.value }); } render() { return ( <form> <FormGroup validationState={this.getValidationState()}> <InputGroup> <InputGroup.Addon>@</InputGroup.Addon> <FormControl type="text" value={this.state.value} placeholder="Example w/ Validation" onChange={this.handleChange} /> </InputGroup> </FormGroup> <FormGroup> <InputGroup> <FormControl type="text" /> <InputGroup.Addon>.00</InputGroup.Addon> </InputGroup> </FormGroup> <FormGroup> <InputGroup> <InputGroup.Addon>$</InputGroup.Addon> <FormControl type="text" /> <InputGroup.Addon>.00</InputGroup.Addon> </InputGroup> </FormGroup> <FormGroup> <InputGroup> <FormControl type="text" /> <InputGroup.Addon> <Icon name="music" /> </InputGroup.Addon> </InputGroup> </FormGroup> <FormGroup> <InputGroup> <InputGroup.Button> <Button>Before</Button> </InputGroup.Button> <FormControl type="text" /> </InputGroup> </FormGroup> <FormGroup> <InputGroup> <FormControl type="text" /> <DropdownButton componentClass={InputGroup.Button} id="input-dropdown-addon" title="Action" > <MenuItem key="1">Item</MenuItem> </DropdownButton> </InputGroup> </FormGroup> <FormGroup> <InputGroup> <InputGroup.Addon> <input type="radio" aria-label="..." /> </InputGroup.Addon> <FormControl type="text" /> </InputGroup> </FormGroup> <FormGroup> <InputGroup> <InputGroup.Addon> <input type="checkbox" aria-label="..." /> </InputGroup.Addon> <FormControl type="text" /> </InputGroup> </FormGroup> </form> ); }; }; <FormExample /> ```
Project: Grafana Loki (Observability and Analysis / Observability)
File: logs-deletion.md

title: Log entry deletion menuTitle: Log entry deletion description: Describes how Loki implements log deletion and deletion configuration options. weight: 700 Grafana Loki supports the deletion of log entries from a specified stream. Log entries that fall within a specified time window and match an optional line filter are those that will be deleted. Log entry deletion is supported only when TSDB or BoltDB shipper is configured as the index store. The compactor component exposes REST that process delete requests. Hitting the endpoint specifies the streams and the time window. The deletion of the log entries takes place after a configurable cancellation time period expires. Log entry deletion relies on configuration of the custom logs retention workflow as defined for the . The compactor looks at unprocessed requests which are past their cancellation period to decide whether a chunk is to be deleted or not. Enable log entry deletion by setting `retentionenabled` to true in the compactor's configuration and setting and `deletionmode` to `filter-only` or `filter-and-delete` in the runtime config. `deleterequeststore` also needs to be configured when retention is enabled to process delete requests, this determines the storage bucket that stores the delete requests. {{% admonition type="warning" %}} Be very careful when enabling retention. It is strongly recommended that you also enable versioning on your objects in object storage to allow you to recover from accidental misconfiguration of a retention setting. If you want to enable deletion but not not want to enforce retention, configure the `retention_period` setting with a value of `0s`. {{% /admonition %}} Because it is a runtime configuration, `deletion_mode` can be set per-tenant, if desired. With `filter-only`, log lines matching the query in the delete request are filtered out when querying Loki. They are not removed from storage. With `filter-and-delete`, log lines matching the query in the delete request are filtered out when querying Loki, and they are also removed from storage. A delete request may be canceled within a configurable cancellation period. Set the `deleterequestcancel_period` in the compactor's YAML configuration or on the command line when invoking Loki. Its default value is 24h. As long as the `compactor.retentionenabled` setting is `true`, the API endpoints will be available. Afterwards, access to the deletion API can be enabled per tenant via the `deletionmode` tenant override.
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_role.Role.md

title: "Class: Role" linkTitle: "Role" slug: "libk8srole.Role" .Role `any` `Role` new Role(`json`) | Name | Type | | : | : | | `json` | | makeKubeObject<KubeRole\>('role').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<KubeRole\>('role').className `get` rules(): `any` `any` `Static` apiList(`onList`, `onError?`, `opts?`): `any` | Name | Type | | : | : | | `onList` | (`arg`: `any`[]) => `void` | | `onError?` | (`err`: ) => `void` | | `opts?` | | `any` makeKubeObject<KubeRole\>('role').apiList _ `Static` `Optional` getAuthorization(`arg`, `resourceAttrs?`): `any` | Name | Type | | : | : | | `arg` | `string` | | `resourceAttrs?` | | `any` makeKubeObject<KubeRole\>('role').getAuthorization _ `Static` getErrorMessage(`err?`): ``null`` \| `string` | Name | Type | | : | : | | `err?` | ``null`` \| | ``null`` \| `string` makeKubeObject<KubeRole\>('role').getErrorMessage _ `Static` useApiGet(`onGet`, `name`, `namespace?`, `onError?`): `void` | Name | Type | | : | : | | `onGet` | (...`args`: `any`) => `void` | | `name` | `string` | | `namespace?` | `string` | | `onError?` | (`err`: ) => `void` | `void` makeKubeObject<KubeRole\>('role').useApiGet _ `Static` useApiList(`onList`, `onError?`, `opts?`): `any` | Name | Type | | : | : | | `onList` | (`arg`: `any`[]) => `void` | | `onError?` | (`err`: ) => `void` | | `opts?` | | `any` makeKubeObject<KubeRole\>('role').useApiList _ `Static` useGet(`name`, `namespace?`): , (`item`: `any`) => `void`, (`err`: ``null`` \| ) => `void`] | Name | Type | | : | : | | `name` | `string` | | `namespace?` | `string` | , (`item`: `any`) => `void`, (`err`: ``null`` \| ) => `void`] makeKubeObject<KubeRole\>('role').useGet _ `Static` useList(`opts?`): , (`items`: `any`) => `void`] | Name | Type | | : | : | | `opts?` | | , (`items`: `any`) => `void`] makeKubeObject<KubeRole\>('role').useList
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_cronJob.KubeCronJob.md

title: "Interface: KubeCronJob" linkTitle: "KubeCronJob" slug: "libk8scronJob.KubeCronJob" .KubeCronJob CronJob structure returned by the k8s API. `see` Kubernetes API reference for CronJob `see` Kubernetes definition for CronJob `KubeCronJob` `Optional` apiVersion: `string` . _ kind: `string` Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. In CamelCase. Cannot be updated. `see` . _ metadata: . _ spec: `Object` | Name | Type | | : | : | | `concurrencyPolicy` | `string` | | `failedJobsHistoryLimit` | `number` | | `jobTemplate` | { `spec`: { `metadata?`: `Partial`<\> ; `template`: { `spec`: { `containers`: \> } } } } | | `jobTemplate.spec` | { `metadata?`: `Partial`<\> ; `template`: { `spec`: { `containers`: \> } } } | | `jobTemplate.spec.metadata?` | `Partial`<\> | | `jobTemplate.spec.template` | { `spec`: { `containers`: \> } } | | `jobTemplate.spec.template.spec` | { `containers`: \> } | | `jobTemplate.spec.template.spec.containers` | [] | | `jobTemplate.spec.template.spec.metadata?` | `Partial`<\> | | `schedule` | `string` | | `startingDeadlineSeconds?` | `number` | | `successfulJobsHistoryLimit` | `number` | | `suspend` | `boolean` | _ status: `Object`