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

description: Upgrade Opstrace to latest available release. This guide will show you how to upgrade Opstrace to the latest available version on AWS. The upgrade command updates the cloud resources and deploys an updated version of the Opstrace operator, which in turn updates the components of the system: NOTES: There are many issues associated with doing upgrades well. There are a few scenarios that are not yet fully supported, but we plan to continue working on them into the future. If you'd like to contribute we'd love to have your help. In the directory you originally installed Opstrace from, make note of the original Opstrace CLI version you have: ```bash ./opstrace --version ``` Make sure you have the config file you origally used for installation: ```bash cat opstrace-config.yaml ``` Download the latest Opstrace CLI binary from S3, which you will use to upgrade Opstrace (~50M compressed): <!--tabs--> ```bash curl -L https://go.opstrace.com/cli-latest-release-macos | tar xjf - ``` ```bash curl -L https://go.opstrace.com/cli-latest-release-linux | tar xjf - ``` <!-- /tabs --> Make note of this new version: ```bash ./opstrace --version ``` Define `OPSTRACE_NAME` with your Opstrace installation name: <!--export-to-input--> ```bash export OPSTRACENAME=<namechoosenatinstall_time> ``` <!--/export-to-input--> Your input needed: After you initiate the command below, a browser page may pop up asking you to sign in with your Google account. (The URL will also be printed in the CLI output.) Let's get things going: ```bash ./opstrace upgrade aws $OPSTRACE_NAME -c opstrace-config.yaml ``` Be patient: Upgrade takes on average 10 minutes on AWS (but it can go as long as 30 minutes if upgrading Cortex and Loki). So you know: The CLI is largely re-entrant for both `create` and `upgrade`. If it is interrupted for some reason, you can re-invoke the same command and it will continue where it left off. For additional information understanding and troubleshooting the `upgrade` command, see our . When everything is done, you'll see the following log line: ```text info: Opstrace cluster upgrade done for $OPSTRACE_NAME (aws) ``` In case of any upgrade errors check our .
Project: M3 (Observability and Analysis / Observability)
File: TESTING.md

M3DB Testing Patterns ===================== `m3db` uses a combination of testing strategies, they're listed below for completeness. (1) Unit tests These are package local tests where we use mocks/stubs to ensure components interact with each other as we expect. These come in two flavours: white-box: i.e. the tests know about the internals of the components they are testing, and may modify them (by injecting functions, changing consts) for testing. black-box: i.e. when the tests do not know about the internals of the components they are testing, and rely on only the exported methods for testing. These are all run by the CI for every push, with race detection enabled, and code coverage within the package being tested. (2) Property tests We use a property testing library, [gopter] for generative tests. These allow us to specify input generators, and ensure the invariants expected on the system hold. These come in two flavours: Vanilla property tests: used when we're testing `pure` functions (i.e. side-effect free). System under test: used when we're testing stateful systems. The allow generation of input state, and the methods use to transition the state of the system. These are all run by the CI for every push, with race detection enabled, and code coverage within the package being tested. (3) Big Unit Tests These are a specialized version of the unit tests that are marked with the build tag `big`. They are heavier weight unit tests for which we disable race detection. These are all run by the CI for every push, with race detection disabled, and code coverage measured across all m3db packages. (4) Integration tests These tests are heavier weight tests that spin up one or more m3db DB's within a single process and test interactions with each other, and other components (e.g. etcd, read/write quorum). These are all run by the CI for every push, with race detection disabled, and code coverage measured across all m3db packages. (5) DTests TODO
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_cluster.KubeCondition.md

title: "Interface: KubeCondition" linkTitle: "KubeCondition" slug: "libk8scluster.KubeCondition" .KubeCondition lastProbeTime: Last time we probed the condition. _ `Optional` lastTransitionTime: _ `Optional` lastUpdateTime: _ `Optional` message: `string` _ `Optional` reason: `string` Unique, one-word, CamelCase reason for the condition's last transition. _ status: `string` Status of the condition, one of True, False, Unknown. _ type: `string`
Project: Netdata (Observability and Analysis / Observability)
File: ebpf_process.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/ebpf.plugin/integrations/ebpf_process.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/ebpf.plugin/metadata.yaml" sidebar_label: "eBPF Process" learn_status: "Published" learnrelpath: "Collecting Metrics/eBPF" 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/ebpf.jpg" width="150"/> Plugin: ebpf.plugin Module: process <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> Monitor internal memory usage. Uses netdata internal statistic to monitor memory management by plugin. This collector is only supported on the following platforms: Linux 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. How plugin is allocating memory. This scope has no labels. Metrics: | Metric | Dimensions | Unit | |:|:-|:-| | netdata.ebpfaralstat_size | memory | bytes | | netdata.ebpfaralstat_alloc | aral | calls | | netdata.ebpf_threads | total, running | threads | | netdata.ebpfloadmethods | legacy, co-re | methods | | netdata.ebpfkernelmemory | memory_locked | bytes | | netdata.ebpfhashtablescount | hashtable | hash tables | | netdata.ebpfhashtablesinsertpid_elements | thread | rows | | netdata.ebpfhashtablesremovepid_elements | thread | rows | There are no alerts configured by default for this integration. To have these charts you need to compile netdata with flag `NETDATADEVMODE`. There is no configuration file. There are no configuration options. There are no configuration examples.
Project: M3 (Observability and Analysis / Observability)
File: consistencylevels.md

title: "Consistency Levels" weight: 3 M3DB provides variable consistency levels for read and write operations, as well as cluster connection operations. These consistency levels are handled at the client level. One: Corresponds to a single node succeeding for an operation to succeed. Majority: Corresponds to the majority of nodes succeeding for an operation to succeed. All: Corresponds to all nodes succeeding for an operation to succeed. One: Corresponds to reading from a single node to designate success. UnstrictMajority: Corresponds to reading from the majority of nodes but relaxing the constraint when it cannot be met, falling back to returning success when reading from at least a single node after attempting reading from the majority of nodes. Majority: Corresponds to reading from the majority of nodes to designate success. All: Corresponds to reading from all of the nodes to designate success. Connect consistency levels are used to determine when a client session is deemed as connected before operations can be attempted. Any: Corresponds to connecting to any number of nodes for all shards, this strategy will attempt to connect to all, then the majority, then one and then fallback to none and as such will always succeed. None: Corresponds to connecting to no nodes for all shards and as such will always succeed. One: Corresponds to connecting to a single node for all shards. Majority: Corresponds to connecting to the majority of nodes for all shards. All: Corresponds to connecting to all of the nodes for all shards.
Project: Checkmk (Observability and Analysis / Observability)
File: 16622.md

key | value | date | 2024-03-11T14:01:12+00:00 version | 2.4.0b1 class | fix edition | cre component | inv level | 1 compatible | no Previously a regex was applied for the Checkmk versions -> #Sites inventory column to filter on the number of sites. This has been changed to instead filter a range of numbers to better match the column type. For example a previous filter of `[0-9]|10` now translates to an explicit range from `0` to `10`. If you currently have any filters for the number of sites configured, you need to reconfigure them.
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: match.md

title: Syslog-NG match weight: 200 generated_file: true The match filter can be used to selectively keep records Default: - Default: - Default: - Default: - Specify filtering rule. Pattern expression to evaluate Default: - Specify a template of the record fields to match against. Default: - Specify a field name of the record to match against the value of. Default: - Pattern flags Default: - Pattern type Default: - ```yaml apiVersion: logging.banzaicloud.io/v1beta1 kind: Flow metadata: name: demo-flow spec: filters: match: regexp: value: first pattern: ^5\d\d$ match: {} localOutputRefs: demo-output ``` ``` log { source(main_input); filter { match("^5\d\d$" value("first")); }; destination(outputdefaultdemo-output); }; ```
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_runtime.RuntimeClass.md

title: "Class: RuntimeClass" linkTitle: "RuntimeClass" slug: "libk8sruntime.RuntimeClass" .RuntimeClass `any` `RuntimeClass` new RuntimeClass(`json`) | Name | Type | | : | : | | `json` | | makeKubeObject<KubeRuntimeClass\>('RuntimeClass').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<KubeRuntimeClass\>('RuntimeClass').className `get` spec(): `any` `any` _ `Static` `get` listRoute(): `string` `string` _ `Static` `get` pluralName(): `string` `string` `Static` apiList(`onList`, `onError?`, `opts?`): `any` | Name | Type | | : | : | | `onList` | (`arg`: `any`[]) => `void` | | `onError?` | (`err`: ) => `void` | | `opts?` | | `any` makeKubeObject<KubeRuntimeClass\>('RuntimeClass').apiList _ `Static` `Optional` getAuthorization(`arg`, `resourceAttrs?`): `any` | Name | Type | | : | : | | `arg` | `string` | | `resourceAttrs?` | | `any` makeKubeObject<KubeRuntimeClass\>('RuntimeClass').getAuthorization _ `Static` getErrorMessage(`err?`): ``null`` \| `string` | Name | Type | | : | : | | `err?` | ``null`` \| | ``null`` \| `string` makeKubeObject<KubeRuntimeClass\>('RuntimeClass').getErrorMessage _ `Static` useApiGet(`onGet`, `name`, `namespace?`, `onError?`): `void` | Name | Type | | : | : | | `onGet` | (...`args`: `any`) => `void` | | `name` | `string` | | `namespace?` | `string` | | `onError?` | (`err`: ) => `void` | `void` makeKubeObject<KubeRuntimeClass\>('RuntimeClass').useApiGet _ `Static` useApiList(`onList`, `onError?`, `opts?`): `any` | Name | Type | | : | : | | `onList` | (`arg`: `any`[]) => `void` | | `onError?` | (`err`: ) => `void` | | `opts?` | | `any` makeKubeObject<KubeRuntimeClass\>('RuntimeClass').useApiList _ `Static` useGet(`name`, `namespace?`): , (`item`: `any`) => `void`, (`err`: ``null`` \| ) => `void`] | Name | Type | | : | : | | `name` | `string` | | `namespace?` | `string` | , (`item`: `any`) => `void`, (`err`: ``null`` \| ) => `void`] makeKubeObject<KubeRuntimeClass\>('RuntimeClass').useGet _ `Static` useList(`opts?`): , (`items`: `any`) => `void`] | Name | Type | | : | : | | `opts?` | | , (`items`: `any`) => `void`] makeKubeObject<KubeRuntimeClass\>('RuntimeClass').useList
Project: Vector (Observability and Analysis / Observability)
File: 2020-03-12-rename-host_field-to-host_key.md

date: "2020-07-13" title: "The `splunkhec` source's `hostfield` option has been renamed to `host_key`" description: "This change ensures that the `host_key` option is consistent across all sources" authors: ["binarylogic"] pr_numbers: [2037] release: "0.9.0" hideonrelease_notes: true badges: type: "breaking change" domains: ["sinks"] sinks: ["splunk_hec"] We've renamed the [`splunkhec` source's] `hostfield` option to `host_key`. This ensures that the `host_key` option is consistent across all sources. ```diff title="vector.toml" [sources.splunk] type = "splunk_hec" host_field = "host" host_key = "host" ```
Project: Cortex (Observability and Analysis / Observability)
File: tenant_retention.md

title: "Retention of Tenant Data from Blocks Storage" linkTitle: "Retention of Tenant Data from Blocks Storage" weight: 1 slug: tenant-retention Author: Date: January 2021 Status: Accepted, Implemented in . Metric data is growing over time per-tenant, at the same time, the value of data decreases. We want to have a retention policy like prometheus does. In Cortex, data retention is typically achieved via a bucket policy. However, this has two main issues: Not every backend storage support bucket policies Bucket policies don't easily allow a per-tenant custom retention When using blocks storage, Cortex stores tenants data in object store for long-term storage of blocks, tenant id as part of the object store path. We discover all tenants via scan the root dir of bucket. Using the "overrides" mechanism (part of runtime config) already allows for per-tenant settings. See for more details. Using it for tenant retention would fit nicely. Admin could set per-tenant retention here, and also have a single global value for tenants that don't have custom value set. We propose to introduce just one new field `RetentionPeriod` in the Limits struct(defined at pkg/util/validation/limits.go). `RetentionPeriod` setting how long historical metric data retention period per-tenant. `0` is disable. Runtime config is reloaded periodically (defaults to 10 seconds), so we can update the retention settings on-the-fly. For each tenant, if a tenant-specific runtime_config value exists, it will be used directly, otherwise, if a default limits_config value exists, then the default value will be used; If neither exists, do nothing. A BlocksCleaner within the Compactor run periodically (which defaults to 15 minutes) and the retention logic will insert into it. The logic should compare retention value to block `maxTime` and blocks that match `maxTime < now - retention` will be marked for delete. Blocks deletion is not immediate, but follows a two steps process. See
Project: Chaos Mesh (Observability and Analysis / Chaos Engineering)
File: SECURITY.md

Chaos Mesh is a growing community devoted to building a chaos engineering ecology under the cloud-native realm. As maintainers of Chaos Mesh, we attach great importance to code security. We are very grateful to the users, security vulnerability researchers, etc. for reporting security vulnerabilities to us. All reported security vulnerabilities will be carefully assessed, addressed, and answered by us. We provide security updates for the two most recent minor versions released on GitHub. For example, if `v1.2.2` is the most recent stable version, we will address security updates for `v1.1.0` and later, Once `v1.3.0` is released, we will no longer provide updates for `v1.1.x` releases. To report a security problem in Chaos Mesh, please contact the Chaos Mesh Security Team: chaos-mesh-security@lists.cncf.io. 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. 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: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: grep.md

title: Grep weight: 200 generated_file: true The grep filter plugin "greps" events by the values of specified fields. Specify filtering rule (as described in the ). This directive contains two parameters. Specify field name in the record to parse. Pattern expression to evaluate {{< highlight yaml >}} apiVersion: logging.banzaicloud.io/v1beta1 kind: Flow metadata: name: demo-flow spec: filters: grep: regexp: key: first pattern: /^5\d\d$/ selectors: {} localOutputRefs: demo-output {{</ highlight >}} Fluentd config result: {{< highlight xml >}} <filter > @type grep @id demo-flow1grep <regexp> key first pattern /^5\d\d$/ </regexp> </filter> {{</ highlight >}} Specify filtering rule to reject events (as described in the ). This directive contains two parameters. Specify field name in the record to parse. Pattern expression to evaluate {{< highlight yaml >}} apiVersion: logging.banzaicloud.io/v1beta1 kind: Flow metadata: name: demo-flow spec: filters: grep: exclude: key: first pattern: /^5\d\d$/ selectors: {} localOutputRefs: demo-output {{</ highlight >}} Fluentd config result: {{< highlight xml >}} <filter > @type grep @id demo-flow0grep <exclude> key first pattern /^5\d\d$/ </exclude> </filter> {{</ highlight >}} Specify filtering rule (as described in the . This directive contains either `regexp` or `exclude` directive. {{< highlight yaml >}} apiVersion: logging.banzaicloud.io/v1beta1 kind: Flow metadata: name: demo-flow spec: filters: grep: or: exclude: key: first pattern: /^5\d\d$/ key: second pattern: /\.css$/ selectors: {} localOutputRefs: demo-output {{</ highlight >}} Fluentd config result: {{< highlight xml >}} <or> <exclude> key first pattern /^5\d\d$/ </exclude> <exclude> key second pattern /\.css$/ </exclude> </or> {{</ highlight >}} Specify filtering rule (as described in the . This directive contains either `regexp` or `exclude` directive. {{< highlight yaml >}} apiVersion: logging.banzaicloud.io/v1beta1 kind: Flow metadata: name: demo-flow spec: filters: grep: and: regexp: key: first pattern: /^5\d\d$/ key: second pattern: /\.css$/ selectors: {} localOutputRefs: demo-output {{</ highlight >}} Fluentd config result: {{< highlight xml >}} <and> <regexp> key first pattern /^5\d\d$/ </regexp> <regexp> key second pattern /\.css$/ </regexp> </and> {{</ highlight >}}
Project: Botkube (Observability and Analysis / Observability)
File: botkube_uninstall.md

title: botkube uninstall uninstall Botkube from cluster Use this command to uninstall the Botkube agent. ``` botkube uninstall [OPTIONS] [flags] ``` ``` botkube uninstall botkube uninstall --release-name botkube-dev ``` ``` -y, --auto-approve Skips interactive approval for deletion. --cascade string Must be "background", "orphan", or "foreground". Selects the deletion cascading strategy for the dependents. Defaults to background. (default "background") --description string add a custom description --dry-run Simulate an uninstallation -h, --help help for uninstall --keep-history remove all associated resources and mark the release as deleted, but retain the release history --kubeconfig string Paths to a kubeconfig. Only required if out-of-cluster. --namespace string Botkube namespace. (default "botkube") --no-hooks prevent hooks from running during uninstallation --release-name string Botkube Helm release name. (default "botkube") --timeout duration time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s) --wait if set, will wait until all the resources are deleted before returning. It will wait for as long as --timeout (default true) ``` ``` -v, --verbose int/string[=simple] Prints more verbose output. Allowed values: 0 - disable, 1 - simple, 2 - trace (default 0 - disable) ``` - Botkube CLI
Project: HertzBeat (Observability and Analysis / Observability)
File: oracle.md

id: oracle title: MonitoringORACLE database monitoring sidebar_label: ORACLE database keywords: [open source monitoring tool, open source database monitoring tool, monitoring oracle database metrics] Collect and monitor the general performance Metrics of ORACLE database. | Parameter name | Parameter help description | ||| | Monitoring Host | Monitored IPV4, IPV6 or domain name. NoteWithout protocol header (eg: https://, http://) | | Monitoring name | Identify the name of this monitoring. The name needs to be unique | | Port | Port provided by the database. The default is 1521 | | Query timeout | Set the timeout time when SQL query does not respond to data, unit: ms, default: 3000ms | | Database name | Database instance name, optional | | Username | Database connection user name, optional | | Password | Database connection password, optional | | URL | Database connection URLoptionalIf configured, the database name, user name, password and other parameters in the URL will overwrite the above configured parameters | | Collection interval | Interval time of monitor periodic data collection, unit: second, and the minimum interval that can be set is 30 seconds | | Whether to detect | Whether to detect and check the availability of monitoring before adding monitoring. Adding and modifying operations will continue only after the detection is successful | | Description remarks | For more information about identifying and describing this monitoring, users can note information here | | Metric name | Metric unit | Metric help description | | -- | -- | -- | | database_version | none | Database version | | database_type | none | Database type | | hostname | none | Host name | | instance_name | none | Database instance name | | startup_time | none | Database start time | | status | none | Database status | | Metric name | Metric unit | Metric help description | | -- | -- | -- | | file_id | none | File ID | | file_name | none | File name | | tablespace_name | none | Table space name | | status | none | Status | | bytes | MB | Size | | blocks | none | Number of blocks | | Metric name | Metric unit | Metric help description | | -- | -- | -- | | username | none | Username | | counts | number | Current connection counts | | Metric name | Metric unit | Metric help description | | -- | -- | -- | | qps | QPS | I/O Requests per second | | tps | TPS | User transaction per second | | mbps | MBPS | I/O Megabytes per second |