cwielenb/CNCF-Dataset huggingface dataset:
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-8-1-3.md

_build: list: false labels: products: cloud enterprise oss title: Release notes for Grafana 8.1.3 <!-- Auto generated by update changelog github action --> Alerting: Fix alert flapping in the internal alertmanager. , Alerting: Fix request handler failed to convert dataframe "results" to plugins.DataTimeSeriesSlice: input frame is not recognized as a time series. , Dashboard: Fix UIDs are not preserved when importing/creating dashboards thru importing .json file. , Dashboard: Forces panel re-render when exiting panel edit. , Dashboard: Prevent folder from changing when navigating to general settings. , Docker: Force use of libcrypto1.1 and libssl1.1 versions to fix CVE-2021-3711. , Elasticsearch: Fix metric names for alert queries. , Elasticsearch: Limit Histogram field parameter to numeric values. , Elasticsearch: Prevent pipeline aggregations to show up in terms order by options. , LibraryPanels: Prevent duplicate repeated panels from being created. , Loki: Fix ad-hoc filter in dashboard when used with parser. , Plugins: Track signed files + add warn log for plugin assets which are not signed. , Postgres/MySQL/MSSQL: Fix region annotations not displayed correctly. , Prometheus: Fix validate selector in metrics browser. , Security: Fix stylesheet injection vulnerability , . Big thanks to Tobias Hamann and Lauritz Holtmann of usd AG for reporting this issue. Security: Fix short URL vulnerability , . Big thanks to Tobias Hamann and Lauritz Holtmann of usd AG for reporting this issue.
Project: Vector (Observability and Analysis / Observability)
File: aws_kinesis_firehose.md

title: AWS Kinesis Firehose description: Collect logs from component_kind: source layout: component tags: ["aws", "kinesis", "firehose", "component", "source", "logs"] {{/* This doc is generated using: The template in layouts/docs/component.html The relevant CUE data in cue/reference/components/... */}}
Project: Cortex (Observability and Analysis / Observability)
File: prettier_rules.md

This files contains rules for prettifying PromQL expressions. Note: The current version of prettier does not preserve comments. `maxcharactersper_line`: Maximum number of characters that will be allowed on a single line in a prettified PromQL expression. A node exceeding the `maxcharactersper_line` will qualify for split unless It is a `MatrixSelector` It is a `VectorSelector`. Label sets in a `VectorSelector` will be in the same line as metric_name, separated by commas and a space Note: Label groupings like `by`, `without`, `on`, `ignoring` will remain on the same line as their parent node Nodes that are nested within another node will be prettified only if they exceed the `maxcharactersper_line` Expressions like `sum(expression) without (labelmatchers)` will be modified to `sum without(labelmatchers) (expression)` Functional call args will be split to different lines if they exceed the `maxcharactersper_line`
Project: Kepler (Observability and Analysis / Observability)
File: CICDv1.md

title: Kepler CI/CD pipeline maintenance authors: Sam Yuan reviewers: n/A, though github approvers: n/A, though github creation-date: 2023-05 last-updated: 2023-05 tracking-links: # link to related GitHub issues https://github.com/orgs/sustainable-computing-io/projects/2/views/1?pane=issue&itemId=28750581 As we onboarded with CNCF sandbox, now it's time to review and open our mind on CI/CD pipeline. For example, Open to cloud service provider's contribute with k8s environment and we run our CI/CD pipeline on it. Open to hardware provider integrate kepler to verify kepler running on specific hardware well or not. Further see discussion at . To quick response to CI/CD breaks due to github action agent upgrade as cases happens in the past below: github action agent upgrade, some network tips updated for container runtime. we updated kind version to fix it. github action agent upgrade with their own kernel, conflicts with our hard code. we fixed up in code. Hence, as infrastructure as code, we have motivations to make our CI/CD pipeline more flexible to face those challenges. Support development branch and stable branch for pipeline. For either development kepler or hardware provide verification usage. Quick response for github agent update.(or quick response for CI/CD breaking related with github agent) Quick update version of tools we used, for example kind/kubectl. We should keep update our tooling version to avoid using any duplicated version. Flexible the k8s cluster adoption for micro shift/minikube or others. For could provider usage. Keep today's feature as Start up a k8s cluster with local development usage. Start up a k8s cluster during pipeline as github action usage on github agent. Support version update for tooling as KIND. Support direct deploy on an existing k8s cluster. Support clean up local cluster. Support working branch and stable branch by Tag. Build up a mechanism to update version of CI/CD pipeline, with release cycle. Switch to other CI/CD tool. Note: no matter which CI/CD tool we are using, the infrastructure as code keep the same. Hence integration with specific CI/CD tool is no goal by treated as just invoke our infrastructure as code. In short term, we update current pipeline with Tag v0.0.0 base on today's version. For new features as Add versioning tool support. Add decouple k8s deployment. Support clean up local cluster. ... Once 0.6 release or in a specific lifecycle, create a new tag, for pipeline. Update pipeline with new tag. n/A, keep open at implementation details n/A n/A n/A, keep open at implementation details The frequence of version bump up for our tooling. Covered in and for example checking cluster running. And as infrastructure as code, integration test should be covered. n/A n/A
Project: Prometheus (Observability and Analysis / Observability)
File: management_api.md

title: Management API sort_rank: 8 Prometheus provides a set of management APIs to facilitate automation and integration. ``` GET /-/healthy HEAD /-/healthy ``` This endpoint always returns 200 and should be used to check Prometheus health. ``` GET /-/ready HEAD /-/ready ``` This endpoint returns 200 when Prometheus is ready to serve traffic (i.e. respond to queries). ``` PUT /-/reload POST /-/reload ``` This endpoint triggers a reload of the Prometheus configuration and rule files. It's disabled by default and can be enabled via the `--web.enable-lifecycle` flag. Alternatively, a configuration reload can be triggered by sending a `SIGHUP` to the Prometheus process. ``` PUT /-/quit POST /-/quit ``` This endpoint triggers a graceful shutdown of Prometheus. It's disabled by default and can be enabled via the `--web.enable-lifecycle` flag. Alternatively, a graceful shutdown can be triggered by sending a `SIGTERM` to the Prometheus process.
Project: Elastic (Observability and Analysis / Observability)
File: to_geoshape.md

<!-- This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it. --> Converts an input value to a `geo_shape` value. A string will only be successfully converted if it respects WKT format. ``` ROW wkt = "POLYGON ((30 10, 40 40, 20 40, 10 20, 30 10))" | EVAL geom = TO_GEOSHAPE(wkt) ```
Project: Grafana Loki (Observability and Analysis / Observability)
File: bug_report.md

name: Bug report about: Create a report to help us improve title: '' labels: '' assignees: '' <!-- Please keep the structure below, or your issue may be closed. --> Describe the bug A clear and concise description of what the bug is. To Reproduce Steps to reproduce the behavior: Started Loki (SHA or version) Started Promtail (SHA or version) to tail '...' Query: `{} term` Expected behavior A clear and concise description of what you expected to happen. Environment: Infrastructure: [e.g., Kubernetes, bare-metal, laptop] Deployment tool: [e.g., helm, jsonnet] Screenshots, Promtail config, or terminal output If applicable, add any output to help explain your problem.
Project: SkyWalking (Observability and Analysis / Observability)
File: dependencies.md

This section is only applicable to dependencies of the OAP server and UI. As one of the Top Level Projects of The Apache Software Foundation (ASF), SkyWalking must follow the . So if you're adding new dependencies to the project, you should make sure that the new dependencies would not break the policy, and add their LICENSE and NOTICE to the project. We use to help you make sure that you haven't missed out any new dependencies: Install `license-eye` according to . Run `license-eye dependency resolve --summary ./dist-material/release-docs/LICENSE.tpl` in the root directory of this project. Check the modified lines in `./dist-material/release-docs/LICENSE` (via command `git diff -U0 ./dist-material/release-docs/LICENSE`) and check whether the new dependencies' licenses are compatible with Apache 2.0. Add the new dependencies' notice files (if any) to `./dist-material/release-docs/NOTICE` if they are Apache 2.0 license. Copy their license files to `./dist-material/release-docs/licenses` if they are not standard Apache 2.0 license. Copy the new dependencies' license file to `./dist-material/release-docs/licenses` if they are not standard Apache 2.0 license.
Project: Checkmk (Observability and Analysis / Observability)
File: 16313.md

key | value | date | 2024-01-24T09:17:40+00:00 version | 2.3.0b1 class | fix edition | cre component | multisite level | 1 compatible | no If you used the "Tree of folders" snapin and the shown dashboard contained a dashlet "Host statistics" or "Service statistics" the wato folder was not filtered for that dashlet.
Project: Skooner (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, sex characteristics, 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 the project team at . 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 For answers to common questions about this code of conduct, see https://www.contributor-covenant.org/faq
Project: GO Feature Flag (Observability and Analysis / Feature Flagging)
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, sex characteristics, 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 the project team at contact@gofeatureflag.org. 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 For answers to common questions about this code of conduct, see https://www.contributor-covenant.org/faq
Project: GO Feature Flag (Observability and Analysis / Feature Flagging)
File: github.md

sidebar_position: 6 The will perform an HTTP Request with your GitHub configuration to get your flags. !!! Tip GitHub has rate limits, be sure to correctly set your `PollingInterval` to avoid reaching the limit. ```go linenums="1" err := ffclient.Init(ffclient.Config{ PollingInterval: 3 * time.Second, Retriever: &githubretriever.Retriever{ RepositorySlug: "thomaspoignant/go-feature-flag", Branch: "main", FilePath: "testdata/flag-config.yaml", GithubToken: "XXXX", Timeout: 2 * time.Second, }, }) defer ffclient.Close() ``` To configure the access to your GitHub file: | Field | Description | |-|--| | `RepositorySlug` | Your GitHub slug `org/repo-name`. | | `FilePath` | The path of your file. | | `Branch` | (optional)<br/>The branch where your file is.<br/>Default: `main` | | `GithubToken` | (optional)<br/>Github token is used to access a private repository, you need the `repo` permission (). | | `Timeout` | (optional)<br/>Timeout for the HTTP call <br/>Default: 10 seconds |
Project: Vector (Observability and Analysis / Observability)
File: splunk_hec.md

title: Splunk HTTP Event Collector (HEC) description: Receive logs from short: Splunk HEC component_kind: source layout: component tags: ["splunk", "hec", "http event collector", "component", "source", "logs"] {{/* This doc is generated using: The template in layouts/docs/component.html The relevant CUE data in cue/reference/components/... */}}
Project: Checkmk (Observability and Analysis / Observability)
File: 16342.md

key | value | date | 2024-03-25T12:28:56+00:00 version | 2.3.0b4 class | feature edition | cee component | multisite level | 2 compatible | yes This is a follow-up for werk #13872. The service labels have been renamed to 'cmk/rmk/htmllastlog:yes' and 'cmk/rmk/htmllasterror_log:yes'. The icons for the last log file and last error log file will have an icon based on the new labels as well as the old ones from werk #13872.
Project: gocrane (Observability and Analysis / Continuous Optimization)
File: 20220228-advanced-cpuset-manger.md

title: "Advanced CPUSet Manager" weight: 10 Static CPU manager is supported by kubelet, when a guaranteed Pod is running on a node, kubelet allocate specific cpu cores to the processes exclusively, which generally keeps the cpu utilization of the node low. This proposal provides a new mechanism to manage cpusets, which allows sharing cpu cores with other processes while binds cpuset.It also allows to revise cpuset when pod is running and relaxes restrictions of binding cpus in kubelet. <!-- TOC --> - - - - - - <!-- /TOC --> Some latency-sensitive applications have lower lantency and cpu usage when running with specific cores, which results in fewer context switches and higer cache affinity. But kubelet will always exclude assigned cores in shared cores, which may waste resources.Offline and other online pods can running on the cores actually. In our experiment, for the most part, it is barely noticeable for performance of service. Provide a new mechanism to manage cpuset bypass Provide a new cpuset manager method "shared" Allow revise cpuset when pod running Relax restrictions of binding cpus Solve the conflicts with kubelet static cpuset manager, you need to set kubelet cpuset manager to "none" Numa manager will support in future, CCX/CCD manager also be considered Kubelet allocate cpus for containers should meet the conditions: requests and limits are specified for all the containers and they are equal the container's resource limit for the limit of CPU is an integer greater than or equal to one and equal to request request of CPU. In Crane, only need to meet condition No.2 ```yaml apiVersion: v1 kind: Pod metadata: annotations: qos.gocrane.io/cpu-manager: none/exclusive/share ``` Provide three polices for cpuset manager: none: containers of this pod shares a set of cpus which not allocated to exclusive containers exclusive: containers of this pod monopolize the allocated CPUs , other containers not allowed to use. share: containers of this pod runs in theallocated CPUs , but other containers can also use. Crane-agent use podLister informs to sense the creation of pod. Crane-agent allocate cpus when pod is binded, and loop in cycle to addContainer(change cpuset) until the containers are created Update/Delete pod will handle in reconcile state. state.State referenced from kubelet and topologycpuassignment copied from kubelet Users can update pod annotaion to control cpuset policy flexibly make pod from none to share without recreating pod make pod from exclusive to share, so offline process can use these CPUs kubelet cpu manger policy need to be set to none, otherwise will be conflicted with crane-agent if crane-agent can not allocate CPUs for pods, it will not refuse to start pod as kubelet
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: anutanetworks.md

is a leading provider of Web-Scale On-prem and Cloud Network Orchestration and Assurance software for the branch, campus, data center and service provider-managed multi-vendor enterprise networks. We wanted to test the resiliency of our platform and also verify observability of stack. Below are the primary reasons to go with Litmus Resiliency of k8s Infrastructure - OnPrem and Cloud Observability Validations It's an Open Source project It has a wide selection of experiments available K8s Native Implementation It's a CNCF sandbox project It has a vibrant community There are frequent releases and it is well maintained
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: apisix.md

Developed and donated by API7.ai, Apache APISIX is an open source, dynamic, scalable, and high-performance cloud native API gateway for all your APIs and microservices. It is a top-level project of the Apache Software Foundation. You can use APISIX API Gateway as a traffic entrance to process all business data. It offers features including dynamic routing, dynamic upstream, dynamic certificates, A/B testing, canary release, blue-green deployment, limit rate, defense against malicious attacks, metrics, monitoring alarms, service observability, service governance, and more. We practice chaos engineering using Litmus in the Apache APISIX Ingress. Litmus also helped us find hidden bugs. Project website: https://apisix.apache.org/ This is the text version of my online sharing content. https://dev.to/apisix/building-a-more-robust-apache-apisix-ingress-controller-with-litmus-chaos-3ldn
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: throttle.md

title: Throttle weight: 200 generated_file: true A sentry plugin to throttle logs. Logs are grouped by a configurable key. When a group exceeds a configuration rate, logs are dropped for this group. Maximum number logs allowed per groups over the period of groupbucketperiod_s Default: 6000 This is the period of of time over which groupbucketlimit applies Default: 60 When a group reaches its limit, logs will be dropped from further processing if this value is true Default: true Used to group logs. Groups are rate limited independently Default: kubernetes.container_name After a group has exceeded its bucket limit, logs are dropped until the rate per second falls below or equal to groupresetrate_s. Default: groupbucketlimit/groupbucketperiod_s When a group reaches its limit and as long as it is not reset, a warning message with the current log rate of the group is emitted repeatedly. This is the delay between every repetition. Default: 10 seconds {{< highlight yaml >}} apiVersion: logging.banzaicloud.io/v1beta1 kind: Flow metadata: name: demo-flow spec: filters: throttle: groupkey: "$.kubernetes.containername" selectors: {} localOutputRefs: demo-output {{</ highlight >}} Fluentd config result: {{< highlight xml >}} <filter > @type throttle @id test_throttle groupkey $.kubernetes.containername </filter> {{</ highlight >}}