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

title: "Namespace: auth" linkTitle: "auth" slug: "lib_util.auth" .auth deleteTokens(): `void` `void` _ getToken(`cluster`): `any` | Name | Type | | : | : | | `cluster` | `string` | `any` _ getUserInfo(`cluster`): `any` | Name | Type | | : | : | | `cluster` | `string` | `any` _ hasToken(`cluster`): `boolean` | Name | Type | | : | : | | `cluster` | `string` | `boolean` _ logout(): `void` `void` _ setToken(`cluster`, `token`): `void` | Name | Type | | : | : | | `cluster` | `string` | | `token` | ``null`` \| `string` | `void`
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-alarm_eventnote_create.md

category: Alarm apiurl: '/api/v1/alarm/event_note' title: 'Create Event Note' type: 'POST' sample_doc: 'alarm.html' layout: default Required ``` { "eventid": "s165_cef145900bf4e2a4a0db8b85762b9cdb", "note": "test note", "status": "comment" } ``` ```Status: 200``` ``` { "id": "s165cef145900bf4e2a4a0db8b85762b9cdb", "message": "add note to s165cef145900bf4e2a4a0db8b85762b9cdb successfuled" } ``` For errors responses, see the .
Project: M3 (Observability and Analysis / Observability)
File: caching.md

title: "Caching" weight: 7 Blocks that are still being actively compressed / M3TSZ encoded must be kept in memory until they are sealed and flushed to disk. Blocks that have already been sealed, however, don't need to remain in-memory. In order to support efficient reads, M3DB implements various caching policies which determine which flushed blocks are kept in memory, and which are not. The "cache" itself is not a separate datastructure in memory, cached blocks are simply stored in their respective with various different mechanisms (depending on the chosen cache policy) determining which series / blocks are evicted and which are retained. For general purpose workloads, the `lru` caching policy is reccommended. The `none` cache policy is the simplest. As soon as a block is sealed, its flushed to disk and never retained in memory again. This cache policy will have the lowest memory consumption, but also the poorest read performance as every read for a block that is already flushed will require a disk read. The `all` cache policy is the opposite of the `none` cache policy. All blocks are kept in memory until their retention period is over. This policy can be useful for read-heavy workloads with small datasets, but is obviously limited by the amount of memory on the host machine. Also keep in mind that this cache policy may have unintended side-effects on write throughput as keeping every block in memory creates a lot of work for the Golang garbage collector. The `recentlyread` cache policy keeps all blocks that are read from disk in memory for a configurable duration of time. For example, if the `recentlyread` cache policy is set with a duration of 10 minutes, then everytime a block is read from disk it will be kept in memory for at least 10 minutes. This policy can be very effective if only a small portion of your overall dataset is ever read, and especially if that subset is read frequently (i.e as is common in the case of database backing an automatic alerting system), but it can cause very high memory usage during workloads that involve sequentially scanning all of the data. Data eviction from memory is triggered by the "ticking" process described in the The `lru` cache policy uses an `lru` list with a configurable max size to keep track of which blocks have been read least recently, and evicts those blocks first when the capacity of the list is full and a new block needs to be read from disk. This cache policy strikes the best overall balance and is the recommended policy for general case workloads. Review the comments in `wired_list.go` for implementation details.
Project: Checkmk (Observability and Analysis / Observability)
File: 16370.md

key | value | date | 2024-02-22T10:48:51+00:00 version | 2.4.0b1 class | fix edition | cre component | rest-api level | 1 compatible | yes Prior to this Werk, when trying to create a time period with a time range shorter than 1 minute, an error code 500 was returned due to a validation error. This Werk solves that problem, and time periods shorter than 1 minute are validated correctly, so the endpoint now accepts them.
Project: Vector (Observability and Analysis / Observability)
File: 2020-01-14-rename-line-field-to-message.md

date: "2020-04-13" title: "Rename `line` field to `message` in `splunk_hec` source" description: "This change ensures the `splunk_hec` source conforms to Vector's schema" authors: ["binarylogic"] pr_numbers: [1457] release: "0.7.0" hideonrelease_notes: false badges: type: "breaking change" domains: ["sources"] sources: ["splunk_hec"] The `splunk_hec` source now emits events with a `message` key instead of a `line` key. This can be renamed via the [global `log_schema` options][docs.reference.configuration.global-options#log_schema]. There are no changes you need to make. Just be aware that your events will no longer have a `line` field.
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: aws_elasticsearch.md

title: Amazon Elasticsearch weight: 200 generated_file: true For details, see https://github.com/atomita/fluent-plugin-aws-elasticsearch-service {{< highlight yaml >}} spec: awsElasticsearch: logstash_format: true includetagkey: true tagkey: "@logname" flush_interval: 1s endpoint: url: https://CLUSTERENDPOINTURL region: eu-west-1 accesskeyid: value: aws-key secretaccesskey: value: aws_secret {{</ highlight >}} Send your logs to a Amazon Elasticsearch Service ElasticSearch AWS Endpoint Credentials flush_interval endpoint AWS access key id. This parameter is required when your agent is not running on EC2 instance with an IAM Role. Typically, you can use AssumeRole for cross-account access or federation. AssumeRoleWithWebIdentity https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html AssumeRoleWithWebIdentity https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html Set with AWSCONTAINERCREDENTIALSRELATIVEURI environment variable value AWS region. It should be in form like us-east-1, us-west-2. Default nil, which means try to find from environment variable AWS_REGION. AWS secret key. This parameter is required when your agent is not running on EC2 instance with an IAM Role. By default, the AWS Security Token Service (AWS STS) is available as a global service, and all AWS STS requests go to a single endpoint at https://sts.amazonaws.com. AWS recommends using Regional AWS STS endpoints instead of the global endpoint to reduce latency, build in redundancy, and increase session token validity. https://docs.aws.amazon.com/IAM/latest/UserGuide/idcredentialstemp_enable-regions.html AWS connection url.
Project: Elastic (Observability and Analysis / Observability)
File: mv_last.md

<!-- This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it. --> Converts a multivalue expression into a single valued column containing the last value. This is most useful when reading from a function that emits multivalued columns in a known order like <<esql-split>>. The order that <<esql-multivalued-fields, multivalued fields>> are read from underlying storage is not guaranteed. It is frequently ascending, but don't rely on that. If you need the maximum value use <<esql-mv_max>> instead of `MVLAST`. `MVMAX` has optimizations for sorted values so there isn't a performance benefit to `MV_LAST`. ``` ROW a="foo;bar;baz" | EVAL lasta = MVLAST(SPLIT(a, ";")) ```
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: CONTRIBUTING.md

Thank you for being interested in contributing to the project, all contributions are welcome! See the file for general contribution guidelines. Please read the ! There are multiple ways you can help with the project. The following channels are available for logging operator related discussions: Please use the appropriate template for your issue type (if applicable): Security related issue (security vulnerability) The Kube Logging team and community take all security issues seriously. Thank you for improving the security of our projects. We appreciate your efforts and responsible disclosure and will make every effort to acknowledge your contributions. Please follow the for the next steps. Steps: Check if there is an that you can reference in your pull request Fork the Create a new branch using `git switch -c <branch-name>` Make your modifications and add unit tests to cover most code branches, input fields, and functionality if possible[^1] Run `make fmt` to run code formatting Run `make generate` to generate code, documentation, manifests, etc. Run `make check` to run license checks, linter, tests (Optional) run `make lint-fix` to fix trivial linting problems Commit your modifications (preferably many smaller commits) using `git commit -s`, because is required Push your commits (`git push <forkorigin> <forkname>`) and open a pull request See the page in the documentation for details (e.g. setting up a development environment, adding documentation). where we can have a discussion about the proposed feature and the suggested test cases. If you use the Logging operator in a production environment, add yourself to the list of production .
Project: Grafana Tempo (Observability and Analysis / Observability)
File: helm-chart.md

title: Deploy Tempo with Helm menuTitle: Deploy with Helm description: Learn how to deploy Tempo with Helm weight: 350 The Helm charts for Grafana Tempo and Grafana Enterprise Traces allows you to configure, install, and upgrade Grafana Tempo or Grafana Enterprise Traces within a Kubernetes cluster. To deploy Tempo using the `tempo-distributed` Helm chart, read the . The Tempo repository has an that shows a complete microservice-based deployment. Tempo has two primary charts used for deployment: deploys Tempo in microservices mode () deploys Tempo in monolithic (single binary) mode
Project: SkyWalking (Observability and Analysis / Observability)
File: backend-token-auth.md

7.0.0+ TLS is about transport security, ensuring a trusted network. On the other hand, token authentication is about monitoring whether application data can be trusted. In the current version, a token is considered a simple string. Set token in `agent.config` file ```properties agent.authentication = ${SWAGENTAUTHENTICATION:xxxx} ``` Set token in `application.yml` file ```yaml receiver-sharing-server: default: authentication: ${SW_AUTHENTICATION:""} ``` The Skywalking OAP verifies every request from the agent and only allows requests whose token matches the one configured in `application.yml` to pass through. If the token does not match, you will see the following log in the agent: ``` org.apache.skywalking.apm.dependencies.io.grpc.StatusRuntimeException: PERMISSION_DENIED ``` No, you shouldn't. Of course, it's technically possible, but token and TLS are used for untrusted network environments. In these circumstances, TLS has a higher priority. Tokens can be trusted only under TLS protection, and they can be easily stolen if sent through a non-TLS network. Not for now. But we welcome contributions to this feature.
Project: Checkmk (Observability and Analysis / Observability)
File: 16261.md

key | value | date | 2023-12-25T17:11:32+00:00 version | 2.3.0b1 class | fix edition | cre component | checks level | 1 compatible | no This affects all users that had rules for "Mails in outgoing mail queue" configured. To clean up inconsistencies that the new APIs no longer tolerate, we had to split the ruleset into two. We renamed "Mails in outgoing mail queue" to "Mails in outgoing mail queue (multiple queues)" and added a new ruleset "Mails in outgoing mail queue (single queue)". The required new rules are created automatically during upgrade, but we advise users to check if they have rules that are not needed anymore. The plugins using the new ruleset are Barracuda SPAM Firewall: Active and Deferred Mail Queue Length (`barracuda_mailqueues`) Nullmailer: Mailqueue Length (`nullmailer_mailq`) qmail: Mailqueue Length (`qmail_stats`)
Project: Checkmk (Observability and Analysis / Observability)
File: 16321.md

key | value | compatible | yes version | 2.4.0b1 date | 2024-03-07T08:35:37+00:00 level | 1 class | fix component | reporting edition | cee If you used the option Inherit from report time range for the painter "Metric history" in report content elements, an error was shown in the report. This affected all previous 2.2 versions.
Project: Netdata (Observability and Analysis / Observability)
File: k6.md

<!-- title: "K6 load test monitoring with Netdata" customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/statsd.plugin/k6.md" sidebar_label: "K6 Load Testing" learn_status: "Published" learnrelpath: "Integrations/Monitor/apps" --> Monitors the impact of load testing experiments performed with . You can read more about the metrics that K6 sends in the . When running the k6 experiment, specify a . Tip: K6 currently supports tags only with , which is in essence StatsD. Netdata can be used with both. Number of HTTP requests that K6 generates, per second. Number of failed HTTP requests that K6 generates, per second. Current number of active virtual users. The time it took K6 to complete one full iteration of the main function. The number of iterations that could not be started either due to lack of Virtual Users or lack of time. The amount of data received and sent. The total duration it took for a round-trip of an HTTP request. It includes: Blocked HTTP requests: time spent blocked before initiating the request Connecting HTTP requests: time spent establishing TCP connection to the remote host Sending HTTP requests: time spent sending data to the remote host Receiving HTTP requests: time spent receiving data from the remote host Waiting HTTP requests: time spent waiting for response from the remote host Different metrics on the HTTP request as defined by K6. The HTTP request duration is defined by K6 as: `HTTP sending request` + `HTTP receiving request` + `HTTP waiting request`. Metrics: Median Average Max Min 95th percentile absolute (the value as it is, without any computation) The collector is preconfigured and defined in `statsd.plugin/k6.conf`. Due to being a StatsD collector, you only need to define the configuration file and then send data to Netdata using the StatsD protocol. If Netdata is running on the same machine as K6, no further configuration is required. Otherwise, you will have to to your node and make sure that the K6 process can reach Netdata. The default namespace that is used in the configuration is `k6`. If you change it in K6, you will have to change it as well in the configuration file `k6.conf`.
Project: OpenCost (Observability and Analysis / Continuous Optimization)
File: opencost-feature-request.md

name: OpenCost Feature request about: Suggest an idea for this project title: '' labels: '' assignees: '' Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] Describe the solution you'd like A clear and concise description of what you want to happen. Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered. Additional context Add any other context, documentation links, or screenshots about the feature request here.
Project: Flagsmith (Observability and Analysis / Feature Flagging)
File: change-requests.md

:::tip Change requests are part of our Scale-Up and Enterprise plans. ::: You can use Change Requests to add workflow control to the changing of Flag values. Change Requests allow a user to propose a change to a flag value, and then require that change is approved by a number of other team members. You can use Change Requests to ensure that, for example, a change to a flag in Production has to be approved by another team member. They work in a similar way to Pull Requests in git. Change Requests are configured at the Environment level. To enable Change Requests, go to the Environment Settings Page, Enable 4 Eyes Change Request Approvals, and select how many approvals you would like for each Change Request to be applied. :::info Any user that has permission to Update a Feature within the Environment can create a Change Request ::: Once an Environment is configured with Change Requests enabled, attempting to change a flag value will prompt you to create a new Change Request. You will need to provide: The title of the Change Request Optionally a description of the reason for the Change Request Any number of assignees. These people will receive an email alerting them of the Change Request :::info Any user that has permission to write to the Environment containing the Change Request can approve it. ::: Change Requests awaiting approval are listed in the Change Request area. Clicking on a Change Request brings up the details of the request, and the current and new Flag values. When the required number of approvals have been made, you will be able to publish the Change Request. The Change Request will immediately come into effect once the Publish Change button is clicked.
Project: DeepFlow (Observability and Analysis / Observability)
File: how-to-profile-server.md

Start the pprof service configuration open: ``` profiler: true ``` if it is not configured, you can also use the command to open `deepflow-ctl -i <server pod IP> ingester profiler on` Get pprof CPU profile(heap/mutex/block/trace profile is also similar) information and generate graphs for analysis you should install `golang 1.18+` and `graphviz` for analyze for example on CentOS, `yum install golang -y; yum install graphviz -y` get the cpu profile and generate graphs to show `go tool pprof http://<server pod IP>:9526/debug/pprof/profile` if not install `golang 1.18+`, you should use `curl` to get profile and name it 'cpu.pprof' `curl http://<server pod IP>:9526/debug/pprof/profile -o cpu.pprof` `go tool pprof cpu.pprof`, do it on another machine which installed `golang 1.18+` suggest execute `pdf` or `svg` to outputs a graph in PDF/SVG format. You should close pprof service, if it is no longer used if you open with the command, close with the command `deepflow-ctl -i <server pod IP> ingester profiler off` if it is configured `profiler: true`, configuration closed, `profiler: false` Install pyroscope in K8S to receive and display continuous profile data ``` helm repo add pyroscope-io https://pyroscope-io.github.io/helm-chart helm install pyroscope pyroscope-io/pyroscope ``` by default installs into the `default` namespace and create service `pyroscope` you should modify the service type of ClusterIP to NodePort for access `kubectl edit svc pyroscope` modify `type: ClusterIP` to `type: NodePort` Start the deepflow-server continuous profiler configuration open: ``` continuous-profiler: enabled: true server-addr: http://pyroscope.default:4040/ ``` Show continuous profiler get service `pyroscope` NodePort `kubectl get svc | grep pyroscope`, get `3xxxx` port web browser access: `http://<pyroscope NodeIP>:<NodePort>/`
Project: Chaos Toolkit (Observability and Analysis / Chaos Engineering)
File: bug_report.md

name: Bug report about: Create a report to help us improve title: '' labels: pending-review assignees: '' Describe the bug A clear and concise description of what the bug is. Runtime versions Please run: ``` $ python --version $ chaos info core $ chaos info extensions ``` To Reproduce Steps to reproduce the behavior. Expected behavior A clear and concise description of what you expected to happen. Additional context Add any other context about the problem here.
Project: Checkmk (Observability and Analysis / Observability)
File: 16292.md

key | value | date | 2024-01-16T14:42:21+00:00 version | 2.3.0b1 class | fix edition | cre component | rest-api level | 1 compatible | yes This werk introduces two changes: it now verifies for create & edit if the provided contact groups actually exist it verifies that for an edit request, locked attributes are not being modified
Project: Vector (Observability and Analysis / Observability)
File: gcp_cloud_storage.md

title: GCP Cloud Storage (GCS) description: Store observability events in GCP short: GCP Cloud Storage component_kind: sink layout: component tags: ["gcp", "gcs", "cloud storage", "component", "sink"] {{/* This doc is generated using: The template in layouts/docs/component.html The relevant CUE data in cue/reference/components/... */}}
Project: Vector (Observability and Analysis / Observability)
File: aws_kinesis_streams.md

title: AWS Kinesis Streams logs description: Publish logs to topics component_kind: sink layout: component tags: ["aws", "kinesis", "streams", "component", "sink", "logs"] {{/* This doc is generated using: The template in layouts/docs/component.html The relevant CUE data in cue/reference/components/... */}}
Project: Grafana (Observability and Analysis / Observability)
File: view-alert-groups.md

aliases: ../../alerting/alert-groups/ # /docs/grafana/<GRAFANA_VERSION>/alerting/alert-groups/ ../../alerting/alert-groups/filter-alerts/ # /docs/grafana/<GRAFANA_VERSION>/alerting/alert-groups/filter-alerts/ ../../alerting/alert-groups/view-alert-grouping/ # /docs/grafana/<GRAFANA_VERSION>/alerting/alert-groups/view-alert-grouping/ ../../alerting/unified-alerting/alert-groups/ # /docs/grafana/<GRAFANA_VERSION>/alerting/unified-alerting/alert-groups/ canonical: https://grafana.com/docs/grafana/latest/alerting/manage-notifications/view-alert-groups/ description: Alert groups keywords: grafana alerting alerts groups labels: products: cloud enterprise oss title: View and filter by alert groups weight: 800 Alert groups show grouped alerts from an Alertmanager instance. By default, alert rules are grouped by the label keys for the default policy in notification policies. Grouping common alert rules into a single alert group prevents duplicate alert rules from being fired. You can view alert groups and also filter for alert rules that match specific criteria. To view alert groups, complete the following steps. In the left-side menu, click Alerts & IRM and then Alerting. Click Groups to view the list of existing groups. From the Alertmanager dropdown, select an external Alertmanager as your data source. By default, the `Grafana` Alertmanager is selected. From Custom group by dropdown, select a combination of labels to view a grouping other than the default. This is useful for debugging and verifying your grouping of notification policies. If an alert does not contain labels specified either in the grouping of the default policy or the custom grouping, then the alert is added to a catch all group with a header of `No grouping`. You can filter by label or state. In Search, enter an existing label to view alerts matching the label. For example, `environment=production,region=~US|EU,severity!=warning`. In States, select from Active, Suppressed, or Unprocessed states to view alerts matching your selected state. All other alerts are hidden.
Project: Weave Scope (Observability and Analysis / Observability)
File: man_docs.md

Generating bash completions from a cobra command is incredibly easy. An example is as follows: ```go package main import ( "github.com/spf13/cobra" ) func main() { cmd := &cobra.Command{ Use: "test", Short: "my test program", } header := &cobra.GenManHeader{ Title: "MINE", Section: "3", } cmd.GenManTree(header, "/tmp") } ``` That will get you a man page `/tmp/test.1`