cwielenb/CNCF-Dataset huggingface dataset:
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_daemonSet.KubeDaemonSet.md

title: "Interface: KubeDaemonSet" linkTitle: "KubeDaemonSet" slug: "libk8sdaemonSet.KubeDaemonSet" .KubeDaemonSet `KubeDaemonSet` `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 | | : | : | | `selector` | | | `template` | { `metadata`: ; `spec`: } | | `template.metadata` | | | `template.spec` | | | `updateStrategy` | { `rollingUpdate`: { `maxUnavailable`: `number` } ; `type`: `string` } | | `updateStrategy.rollingUpdate` | { `maxUnavailable`: `number` } | | `updateStrategy.rollingUpdate.maxUnavailable` | `number` | | `updateStrategy.type` | `string` | _ status: `Object`
Project: SkyWalking (Observability and Analysis / Observability)
File: kafka-plugin.md

Tracing doesn't work on the Kafka consumer end. The kafka client is responsible for pulling messages from the brokers, after which the data will be processed by user-defined codes. However, only the poll action can be traced by the plug-in and the subsequent data processing work inevitably goes beyond the scope of the trace context. Thus, in order to complete tracing on the client end, manual instrumentation is required, i.e. the poll action and the processing action should be wrapped manually. For a native Kafka client, please use the Application Toolkit libraries to do the manual instrumentation, with the help of the `@KafkaPollAndInvoke` annotation in `apm-toolkit-kafka` or with OpenTracing API. If you're using `spring-kafka` 1.3.x, 2.2.x or above, you can easily trace the consumer end without further configuration.
Project: Grafana Mimir (Observability and Analysis / Observability)
File: LICENSE.md

The MIT License (MIT) Copyright (c) 2014 Mitchell Hashimoto Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Project: Inspektor Gadget (Observability and Analysis / Observability)
File: bindsnoop.md

title: Gadget bindsnoop bindsnoop traces the kernel functions performing socket binding. ```yaml apiVersion: gadget.kinvolk.io/v1alpha1 kind: Trace metadata: name: bindsnoop namespace: gadget spec: node: ubuntu-hirsute gadget: bindsnoop runMode: Manual outputMode: Stream filter: namespace: default ``` Start bindsnoop gadget ```bash $ kubectl annotate -n gadget trace/bindsnoop \ gadget.kinvolk.io/operation=start ``` Stop bindsnoop gadget ```bash $ kubectl annotate -n gadget trace/bindsnoop \ gadget.kinvolk.io/operation=stop ``` Stream
Project: Sentry (Observability and Analysis / Observability)
File: relay.md

Authors: @cmanallen Replay SDK Event | Column | Type | Description | | -- | | -- | | type | string | - | | replay_id | string | - | | replay_type | enum[string] | "error", "session" | | event_id | string | Unique ID specific to the event. | | segment_id | number | - | | timestamp | number | - | | replaystarttimestamp | number | - | | urls | list[string] | A list of URLs in order of visitation. | | error_ids | list[string] | - | | trace_ids | list[string] | - | | contexts.replay.errorsamplerate | float | - | | contexts.replay.sessionsamplerate | float | - | Base SDK Event | Column | Type | Description | | -- | | -- | | dist | string | - | | platform | string | - | | environment | string | - | | release | string | - | | user.id | string | - | | user.username | string | - | | user.email | string | - | | user.ip_address | string | - | | sdk.name | string | - | | sdk.version | string | - | | request.headers.User-Agent | string | - | Request (ContentType: application/json) ```json { "type": "replay_event", "replay_type": "session", "replay_id": "515539018c9b4260a6f999572f1661ee", "event_id": "e4a28052c54743a286be419c9d168ef5", "segment_id": 0, "timestamp": 161657652454, "replaystarttimestamp": 160006562825, "urls": ["https://www.sentry.io", "https://www.sentry.io/login"], "error_ids": [], "trace_ids": [], "dist": "abc123", "platform": "javascript", "environment": "production", "release": "version@1.3", "user": { "id": "123", "username": "username", "email": "username@example.com", "ip_address": "127.0.0.1" }, "sdk": { "name": "sentry.javascript.react", "version": "6.18.1" }, "tags": { "customtag": "is_set", "transaction": "Title" }, "contexts": { "replay": { "errorsamplerate": 0.2, "sessionsamplerate": 0.5 }, "trace": { "op": "pageload", "span_id": "affa5649681a1eeb", "trace_id": "23eda6cd4b174ef8a51f0096df3bfdd1" } }, "request": { "url": "http://localhost:3000/", "headers": { "User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10157) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36" } }, "extra": {} } ``` Request (application/octet-stream) ```bytes {"segment_id": 0} \x00\x00\x00\x14ftypqt \x00\x00\x00\x00qt \x00\x00\x00\x08wide\x03\xbdd\x11mdat ```
Project: Grafana Mimir (Observability and Analysis / Observability)
File: pooling-buffers-for-grpc-messages.md

From time to time we think about how to make gRPC communication more efficient, and idea that comes back over and over is pooling of byte buffers for message marshalling or unmarshalling. In this document we would like to write down notes about doing that. This document may not be fully correct (it's easy to miss something) or up-to-date (code changes and evolves). Updates are appreciated. This originated from discussion in https://github.com/grafana/mimir/pull/5195. In that PR we have introduced pooling of buffers used for marshalling messages sent by Distributor to Ingester. From the discussion: One thing to realize is that we're doing this buffering on the client side. "gRPC" that we talk about here is grpc connection to ingester. Re middlewares... We with following interceptors: , which in turns : `otgrpc.OpenTracingClientInterceptor(opentracing.GlobalTracer())` `middleware.ClientUserHeaderInterceptor` `middleware.UnaryClientInstrumentInterceptor(requestDuration)` Interceptors added by : - Looking at implementation of these interceptors... has ability to 1) pass request to span inclusion function,, 2) log the payload (request) and 3) decorate the span using the request. Note that `OpenTracingClientInterceptor` with any of these options. `middleware.ClientUserHeaderInterceptor`, `middleware.UnaryClientInstrumentInterceptor`, `BackoffRetry` and `RateLimiter` interceptors don't use request in any way (apart from passing it further) More places where our buffer could be passed around: Let's start with binlogs. This is functionality configured by env variable `GRPCBINARYLOG_FILTER`. When configured, gRPC logs each RPC in the format defined by proto GrpcLogEntry. Design for this feature is at https://github.com/grpc/proposal/blob/master/A16-binary-logging.md. When used, request is passed to logging method inside `binarylog.ClientMessage` struct. This struct has which will call another `Marhal` on our message. Once `binary.ClientMessage` is converted to `binlogpb.GrpcLogEntry` (now it contains our buffer from the pool), it's forwarded to the "sink" for writing. There are three `sink` implementations in grpc: , `noopSink` (does nothing) and . `writerSink` marshals `binlogpb.GrpcLogEntry` and writes it to some writer. , and also runs a goroutine to periodically flush the buffer. Important point is that it doesn't keep `binlogpb.GrpcLogEntry` around, but marshals it immediately. My conclusion is: using binary logging feature is safe when using our message buffering. `statsHandlers` for the grpc connection are configured via dial options. We don't use that feature in our code. It's possible that I've missed something, but it seems to me that it's safe to reuse the buffer used to Marshal as soon as `(*grpc.ClientConn).Invoke` returns.
Project: Promscale (Observability and Analysis / Observability)
File: telemetry.md

Promscale collects anonymous usage data to help us better understand how the community uses our products and as a result make our product better for our users. Your privacy is the most important thing to us so we don't collect any personally identifiable information. You can see at all times the data collected by Promscale by running the following query in the database: `SELECT key, value FROM timescaledbcatalog.metadata WHERE key like 'promscale%' order by key;` The query will return something similar to this: | key | value | |-|--| | promscale_arch | amd64 | | promscalebuildplatform | | | promscalecommithash | | | promscaleconnectorinstance_total | 1 | | promscaledbnode_count | 0 | | promscaleingestedsamples_total | 0 | | promscalemetricsbytes_total | 0 | | promscalemetricsdefaultchunkinterval | 08:00:00 | | promscalemetricsdefault_retention | 90 days | | promscalemetricsexemplar_total | 0 | | promscalemetricshaclustercount | 0 | | promscalemetricsmetadata_total | 0 | | promscalemetricsmultitenancytenant_count | 0 | | promscalemetricsqueriessuccesstotal | 0 | | promscalemetricsqueriesfailedtotal | 0 | | promscalemetricsqueriestimedouttotal | 0 | | promscalemetricsregistered_views | 0 | | promscalemetricsseriestotalapprox | 0 | | promscalemetricstotal | 0 | | promscale_os | linux | | promscaleosid | ubuntu | | promscaleosmachine | x86_64 | | promscaleosnode_name | ubuntu-focal | | promscaleossys_name | Linux | | promscaleosversion | 20.04 | | promscale_packager | unknown | | promscalepromqlqueryexecutiontime_p50 | 0.0000 | | promscalepromqlqueryexecutiontime_p90 | 0.0000 | | promscalepromqlqueryexecutiontime_p95 | 0.0000 | | promscalepromqlqueryexecutiontime_p99 | 0.0000 | | promscalepromqlqueryremotereadbatchexecutiontimep50 | 0.0000 | | promscalepromqlqueryremotereadbatchexecutiontimep90 | 0.0000 | | promscalepromqlqueryremotereadbatchexecutiontimep95 | 0.0000 | | promscalepromqlqueryremotereadbatchexecutiontimep99 | 0.0000 | | promscalepromqltelemetryevaluationduration_seconds | 1.027 | | promscaletracedependencyrequestsexecuted_total | 0 | | promscaletracequeryexecutiontime_p50 | 0.0000 | | promscaletracequeryexecutiontime_p90 | 0.0000 | | promscaletracequeryexecutiontime_p95 | 0.0000 | | promscaletracequeryexecutiontime_p99 | 0.0000 | | promscaletracequeryrequestsexecuted_total | 0 | | promscaletracesspansbytestotal | 65536 | | promscaletracesspanstotalapprox | 0 | | promscaletracestotal_approx | 0 | | promscale_version | 0.8.0 | This data together with usage data collected by is sent to our servers every 24 hours. Promscale usage telemetry is collected through TimescaleDB's telemetry feature. You can you are not confortable sharing or .
Project: Checkmk (Observability and Analysis / Observability)
File: 16015.md

key | value | compatible | yes version | 2.4.0b1 date | 2023-07-28T08:14:29+00:00 level | 1 class | fix component | wato edition | cme Prior to this werk, Checkmk raised an error in the following cases: when the user attempted to create a LDAP connection with a config with the customer option set to "Global" when the user attempted to change a LDAP connection config with the customer option set to "Global" when the user attempted to create a SAML connection config when the user attempted to delete an existing SAML connection config This werk resolves these issues and Checkmk will not throw an error anymore.
Project: Checkmk (Observability and Analysis / Observability)
File: 16384.md

key | value | date | 2024-01-17T11:19:06+00:00 version | 2.3.0b1 class | fix edition | cre component | rest-api level | 1 compatible | no When configuring a notification rule via the Rest API, you could not set the value for "matchservicelevels" to anything but the default service levels. This werk addresses this issue by now allowing any of the service levels configured to be used. This change mean that there is a change to the request schema. Previously, we accepeted the service level string value, whereas now we accept the integer value. Previous schema ``` {"matchservicelevels": { "state": "enabled", "value": {"fromlevel": "silver", "tolevel": "gold"} } } ``` New schema ``` {"matchservicelevels: { "state": "enabled", "value": {"fromlevel": 10, "tolevel": 20} } } ```
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: kublr.md

is an Enterprise-ready orchestration platform to centrally deploy, run, and manage Kubernetes clusters across all of your environments with a comprehensive container orchestration platform that finally delivers on the Kubernetes promise. Optimized for large enterprises, Kublr is designed to provide multi-cluster deployments and observability. We made it easy, so your team can focus on what really matters: innovation and value generation. Kublr-provisioned Kubernetes clusters; we apply litmus chaos load to stress-test the clusters and identify the weak spots and components prone to failures under stress when customer applications stress the system Litmus is well-documented, well-supported open source tool with a great community and development team. It is flexible and allows us to adjust the chaos tests any way we need. This is currently used as a part of development testing and adhoc experiments, although we are working on including litmus chaos tests into our standard automated QA process
Project: Graylog (Observability and Analysis / Observability)
File: documentation.md

This guide was created using , so that is a good place to get started if you want to know how to contribute to this document. Here is a summary of what to do if you just want to document a component: Use to write documentation for the component and its props, as those are the main API the component provides to its consumers. The component documentation must be placed just before the component declaration and must contain a brief explanation of what the component intents to do, followed by any warnings, notes, or deprecations if needed. Please do not include code examples in here unless you cannot create an example for some reason. Each `propType` definition must be preceded by its documentation. Pay special attention to: Document data structures the component expect in array and object props Document when a callback function will be called. This is specially helpful if the prop name is not as clear as it should be Document arguments any callback functions will receive In order to write a usage example of the component, you need to create a file in the same directory as the component, with the same name as the component but the `md` extension. E.g. `ReactGridContainer.md` will contain the examples for `ReactGridContainer.jsx`. Only write examples to show important use cases of the component, but you do not need to write an example for each prop and value that the component can accept. You can write React components in examples, and you should do it if you feel that showing how the state flows may help understanding how the component works. Examples do not support `import` statements, but you can `require` any modules you need. Try to not require too many modules, though, as they will make the example more obscure and harder to understand. You can also use object destructuring when requiring more than one thing from the same module. E.g. `const { ButtonToolbar } = require('components/bootstrap');` can save a line of the example without making it harder to read.
Project: Checkmk (Observability and Analysis / Observability)
File: 16237.md

key | value | date | 2024-02-23T11:26:08+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes If you've been using mysql and the corresponding agent plugin mk_sql under Windows, the plugin may have crashed and the agent output would then show the following error: ``` <<<mysql_ping>>> [[MySQL83]] mysqladmin: File '\etc\check_mk\mysql.local.ini' not found (OS errno 2 - No such file or directory) mysqladmin: [ERROR] Stopped processing the 'include' directive in file C:\ProgramData\checkmk\agent\config\mysql.ini at line 8. ``` Under Windows, the plugin config path `C:\ProgramData\checkmk\agent\config` is now used. In contrast to the corresponding Linux plugin `mk_mysql`, the config path under Windows cannot be changed.
Project: Vector (Observability and Analysis / Observability)
File: 2020-02-05-drop-aws-options.md

date: "2020-04-15" title: "AWS specific options have been dropped in the Elasticsearch sink" description: "We've dropped redundant AWS options that may break backward compatibility" authors: ["binarylogic"] pr_numbers: [1703] release: "0.8.0" hideonrelease_notes: true badges: type: "breaking change" providers: ["aws"] domains: ["sinks"] sinks: ["elasticsearch"] The `endpoint` and `region` options have been dropped in the [`elasticsearch` sink][docs.sinks.elasticsearch] in favor of using the `host` option. ```diff title="vector.toml" [sinks.es] type = "elasticsearch" endpoint = "http://my-domain.us-east-1.es.amazonaws.com" region = "us-east-1" host = "http://my-domain.us-east-1.es.amazonaws.com" ``` You can find your AWS ES domain in the AWS console. Simply provide the full domain URL as the `host` value.
Project: VictoriaMetrics (Observability and Analysis / Observability)
File: CODE_OF_CONDUCT.md

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation. Examples of behavior that contributes to creating a positive environment include: Using welcoming and inclusive language Being respectful of differing viewpoints and experiences Gracefully accepting constructive criticism Focusing on what is best for the community Showing empathy towards other community members Examples of unacceptable behavior by participants include: The use of sexualized language or imagery and unwelcome sexual attention or advances Trolling, insulting/derogatory comments, and personal or political attacks Public or private harassment Publishing others' private information, such as a physical or electronic address, without explicit permission Other conduct which could reasonably be considered inappropriate in a professional setting Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting urfave-governance@googlegroups.com, a members-only group that is world-postable. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. This Code of Conduct is adapted from the , version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
Project: Checkmk (Observability and Analysis / Observability)
File: 16377.md

key | value | date | 2024-02-01T08:44:18+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes This affects users monitoring hosts that run one single postfix instance. For new installations, the service "Postfix Queue" will be renamed to "Postfix Queue default". In general, Checkmk is able to monitor multiple postfix instances running on the monitored host. This will change the name in the common case where users are not running multiple postfix instances, but only the "default" one. If you want to switch to the new service description after an upgrade, you can do so using the setting "Use new service descriptions". Be aware that you will lose the historic data in case you do that.
Project: Netdata (Observability and Analysis / Observability)
File: Demo-Sites.md

<!-- title: "Live demos" date: 2020-03-26 customediturl: https://github.com/netdata/netdata/edit/master/docs/Demo-Sites.md sidebar_label: "Live demos" learn_status: "Published" learntopictype: "Getting started" learnrelpath: "Getting started" sidebar_position: "90" --> See the live Netdata Cloud demo with rooms (listed below) for specific use cases at https://app.netdata.cloud/spaces/netdata-demo | Location | Netdata Demo URL | 60 mins reqs | VM donated by | | : | :-- | :| :- | | Netdata Cloud | ||| | Netdata Cloud | ||| | Netdata Cloud | ||| | Netdata Cloud | ||| | Netdata Cloud | ||| | Netdata Cloud | ||| | Netdata Cloud | ||| | Netdata Cloud | ||| | Netdata Cloud | ||| | Netdata Cloud | ||| | Netdata Cloud | ||| | Netdata Cloud | ||| | Netdata Cloud | ||| | Netdata Cloud | ||| | Netdata Cloud | ||| | Netdata Cloud | ||| | Netdata Cloud | ||| | London (UK) | <br/>(this is the global Netdata registry and has named and mysql charts) | ](https://london3.my-netdata.io) | | | Atlanta (USA) | <br/>(with named and mysql charts) | ](https://cdn77.my-netdata.io) | | | Bangalore (India) | | ](https://bangalore.my-netdata.io) | | | Frankfurt (Germany) | | ](https://frankfurt.my-netdata.io) | | | New York (USA) | | ](https://newyork.my-netdata.io) | | | San Francisco (USA) | | ](https://sanfrancisco.my-netdata.io) | | | Singapore | | ](https://singapore.my-netdata.io) | | | Toronto (Canada) | | ](https://toronto.my-netdata.io) | | Netdata dashboards are mobile- and touch-friendly.
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_mutatingWebhookConfiguration.KubeWebhookClientConfig.md

title: "Interface: KubeWebhookClientConfig" linkTitle: "KubeWebhookClientConfig" slug: "libk8smutatingWebhookConfiguration.KubeWebhookClientConfig" .KubeWebhookClientConfig caBundle: `string` _ `Optional` service: `Object` | Name | Type | | : | : | | `name` | `string` | | `namespace` | `string` | | `path?` | `string` | | `port?` | `number` | _ `Optional` url: `string`