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

key | value | date | 2024-01-30T13:09:08+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes BGP Peer States can be in "connect". This state was missing in checkmk and thus the service was in "UNKNOWN" state.
Project: Grafana Loki (Observability and Analysis / Observability)
File: caching.md

title: Caching menuTitle: Caching description: Describes how to enable and configure memcached to speed query performance. weight: keywords: memcached caching Loki supports caching of index writes and lookups, chunks and query results to speed up query performance. This sections describes the recommended Memcached configuration to enable caching for chunks and query results. The index lookup cache is configured to be in-memory by default. It is recommended to deploy three, or in the case of the Helm chart two, dedicated Memcached clusters. As of 2023-02-01, the `memcached:1.6.17-alpine` version of the library is recommended. Consult the Loki ksonnet deployment and the ksonnet . To enable and configure Memcached: Deploy each Memcached service with at least three replicas and configure each as follows: Chunk cache ``` --memory-limit=4096 --max-item-size=2m --conn-limit=1024 ``` Query result and index queries cache ``` --memory-limit=1024 --max-item-size=5m --conn-limit=1024 ``` Configure Loki to use the cache. If the Helm chart is used Set `memcached.chunkcache.host` to the Memcached address for the chunk cache, `memcached.resultscache.host` to the Memcached address for the query result cache, `memcached.chunkcache.enabled=true` and `memcached.resultscache.enabled=true`. Ensure that the connection limit of Memcached is at least `numberofclients * maxidleconns`. The options `host` and `service` depend on the type of installation. For example, using the `bitnami/memcached` Helm Charts with the following commands, the `service` values are always `memcached`. ``` helm upgrade --install chunk-cache -n loki bitnami/memcached -f memcached-overrides-chunk.yaml helm upgrade --install results-cache -n loki bitnami/memcached -f memcached-overrides-results.yaml ``` The current Helm Chart only supports the chunk and results cache. In this case, the Loki configuration would be ```yaml loki: memcached: chunk_cache: enabled: true host: chunk-cache-memcached.loki.svc service: memcached-client batch_size: 256 parallelism: 10 results_cache: enabled: true host: results-cache-memcached.loki.svc service: memcached-client default_validity: 12h ``` If the Loki configuration is used, modify the following three sections in the Loki configuration file. Configure the chunk and index write cache ```yaml chunkstoreconfig: chunkcacheconfig: memcached: batch_size: 256 parallelism: 10 memcached_client: host: <chunk cache memcached host> service: <port name of memcached service> ``` Configure the query result cache ```yaml query_range: cache_results: true results_cache: cache: memcached_client: consistent_hash: true host: <memcached host> service: <port name of memcached service> maxidleconns: 16 timeout: 500ms update_interval: 1m ``` Configure the index queries cache ```yaml storage_config: indexqueriescache_config: memcached: batch_size: 100 parallelism: 100 memcached_client: host: <memcached host> service: <port name of memcached service> consistent_hash: true ```
Project: Checkmk (Observability and Analysis / Observability)
File: 16369.md

key | value | date | 2024-02-20T14:52:12+00:00 version | 2.4.0b1 class | feature edition | cre component | rest-api level | 1 compatible | yes When querying downtimes through the "show all downtimes" endpoint, the service_description field for service downtimes was not included. This werk introduces this field, which is not present in the host downtimes.
Project: Pixie (Observability and Analysis / Observability)
File: live_view_request.md

name: New Pxl Community Script about: Describe the use-case your script addresses. Describe the use-case A concise description of your script's objective Example scenario A brief description of a debugging scenario where such a view would have been helpful. Desired output Output Widgets Widget A '....' Widget B '....' Widget C '....' ..... Additional requirements Add any other context about your needs here. (Optional) Draft scripts If you've attempted to write scripts to generate this view feel free to share them here.
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-dashboard_graph_get_tmpgraph_by_id.md

category: DashboardGraph apiurl: '/api/v1/dashboard/tmpgraph/:id' title: 'Get a tmpgraph by id' type: 'GET' sample_doc: 'dashboard.html' layout: default Required ```Status: 200``` ```{"counters":["agent.alive"],"endpoints":["laiweiofficemac"]}``` For errors responses, see the .
Project: M3 (Observability and Analysis / Observability)
File: namespaces.md

title: "Namespaces" menuTitle: "Namespaces" weight: 12 chapter: true M3DB uses the concept of to determine how metrics are stored and retained. The M3DB operator allows a user to define their own namespaces, or to use a set of presets we consider to be suitable for production use cases. Namespaces are configured as part of an `m3dbcluster` . This preset will store metrics at 10 second resolution for 2 days. For example, in your cluster spec: ```yaml spec: ... namespaces: name: metrics-short-term preset: 10s:2d ``` This preset will store metrics at 1 minute resolution for 40 days. ```yaml spec: ... namespaces: name: metrics-long-term preset: 1m:40d ``` You can also define your own custom namespaces by setting the `NamespaceOptions` within a cluster spec. The lists all available fields. As an example, a namespace to store 7 days of data may look like: ```yaml ... spec: ... namespaces: name: custom-7d options: bootstrapEnabled: true flushEnabled: true writesToCommitLog: true cleanupEnabled: true snapshotEnabled: true repairEnabled: false retentionOptions: retentionPeriod: 168h blockSize: 12h bufferFuture: 20m bufferPast: 20m blockDataExpiry: true blockDataExpiryAfterNotAccessPeriod: 5m indexOptions: enabled: true blockSize: 12h ```
Project: Checkmk (Observability and Analysis / Observability)
File: 16338.md

key | value | date | 2024-02-21T10:40:17+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes With werk #16329 when a password was set, the plugin did not work. This has now been fixed and configuring a password shouldn't cause any issues.
Project: M3 (Observability and Analysis / Observability)
File: roadmap.md

title: "Roadmap" weight: 4 This roadmap is open for contributions and suggestions, it currently only defines near term goals. Near term: Add more diagrams of what M3 deployment architecture by use case Add tutorials for a variety of use cases Improve operational guides for the aggregator Overview of design for M3DB reverse index Overview of design for M3 aggregator
Project: Chaos Mesh (Observability and Analysis / Chaos Engineering)
File: MAINTAINERS.md

Thisfilelists the maintainersand committers oftheChaosMeshproject. In short, maintainers are people who are in charge of the maintenance of the Chaos Mesh project. Committers are active community members who have shown that they are committed to the continuous development of the project through ongoing engagement with the community. For detailed description of the roles, see . TheMaintainersofChaosMesh,alongwiththeiremails,arelistedbelow: | Name | Email | Org | | - | - | | | Cwen Yin () | | | | Keao Yang () | | | | Calvin Weng () | | | | Zhiqiang Zhou () | | Freelancer | | Glen Yang () | | | The Committers of Chaos Mesh, alongwiththeiremails,arelistedbelow: | Name | Email | Org | | - | -- | - | | Shenan Zhang () | | | | Xiang Wang () | | | | Xianglin Gao () | | | The Emeritus Maintainers of Chaos Mesh, along with their emails, are listed below: | Name | Email | Org | | - | - | | | Siddon Tang () | | | | Qiang Zhou () | | | | Song Gao () | | | | Ben Ye () | | | | Hengliang Tan () | | | The Emeritus Committers of Chaos Mesh, along with their emails, are listed below: | Name | Email | Org | | - | -- | - | | Yihao Fu () | | | | Jiaxing Wu () | | | | Shuyang Wu () | | | | Wenbo Zhang () | | | | Shivansh Saini () | | | | Siyu Chen () | | | | Chenxi Li () | | |
Project: Logstash (Observability and Analysis / Observability)
File: STYLE.md

Rather than write a full style guide, please follow by examples you see in the code. If you send me a patch, I will not reject it for style reasons (but I will fix it before it gets committed). We support logging structured data, so please do that. Rather than this: @logger.info("Some error occured in request #{request} on input #{input} from client #{ip}") Do this: @logger.info("Some error occured in this request", :request => request, :input => input, :client => ip) comment everything you can think of. indentation: 2 spaces between methods: 1 line sort your requires long lines should wrap at 80 characters. If you wrap at an operator ('or', '+', etc) start the next line with that operator. parentheses on function definitions/calls explicit is better than implicit implicit returns are forbidden except in the case of a single expression Avoid use of 'and' and 'or' in ruby code The point is consistency and documentation. If you see inconsistencies, let me know, and I'll fix them :) Short example: require "something from a gem" # from gem 'thing' class Foo < Bar def somefunc(arg1, arg2, arg3) puts "Hello" if (somelongcondition \ or someothercondition) puts "World" end # if <very short description> foo = some + long + formula + thing \ stuff + bar; somefunctioncall(arg1, arg2, arg3, somelongthing, alignment_here, arg6) somereallylongfunctioncallblahblah_blah(arg1, arg2, arg3, arg4) case foo when "bar" puts "Hello world" when /testing/ puts "testing else puts "I got nothin'" end # case foo end # def somefunc end # class Foo Use of the "hash colon" syntax (ruby 1.9) is not accepted. { foo: "bar" } { :foo => "bar" } String#[] with one numeric argument must not be used due to bugs and inconsistencies between ruby versions. str = "foo" str[0] str[0, 1]
Project: Hubble (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, 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 oss-conduct@uber.com. The project team will review and investigate all complaints, and will respond in a way that it deems 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 .
Project: GO Feature Flag (Observability and Analysis / Feature Flagging)
File: migrate_v0_v1.md

sidebar_position: 90 description: How to migrate from v0.x.x to v1.x.x :::info Version `v1.0.0` has introduced a new flag format that push the limits of GO Feature Flag even further. BUT the flag format from all the versions `v0.x.x` are still compatible and supported by the `v1.0.0`. ::: A command line is available to help you to convert your actual configuration file to the version `v1.x.x`. ```shell brew tap thomaspoignant/homebrew-tap brew install go-feature-flag-migration-cli ``` ```shell scoop bucket add org https://github.com/thomaspoignant/scoop.git scoop install go-feature-flag-migration-cli ``` ```shell docker pull thomaspoignant/go-feature-flag-migration-cli:latest ``` ```shell ./go-feature-flag-migration-cli \ --input-format=yaml \ --input-file=/config/my-go-feature-flag-config-v0.x.x.yaml \ --output-format=yaml \ --output-file=/config/my-go-feature-flag-config-v1.x.x.yaml ``` The command line has 4 arguments you should specify. `input-format`: Format of your input file (`YAML`, `JSON` or `TOML`). `input-file`: Location of the flag file you want to convert. `output-format`: Format of your output file (`YAML`, `JSON` or `TOML`). `output-file`: Location of the converted flag file. When your file is ready, you just have to replace your file in the location where GO Feature Flag is retrieving it. :::tip If for any reason your file is not readable by GO Feature Flag, it will not break anything, we will keep the latest version we have in memory. :::
Project: Checkmk (Observability and Analysis / Observability)
File: 15316.md

key | value | date | 2023-12-19T13:09:15+00:00 version | 2.3.0b1 class | fix edition | cre component | checks level | 1 compatible | yes Solaris server may keep a bad time when moved to different hardware. This is corrected some minutes after booting via NTP server. If the checkmk client is used before the time has been corrected, it was possible that a negative time span was reported for the time since the last start. This caused a crash in the check. The new behaviour is, that the check will report an UNKNOWN status alongside the message: "Your Solaris system reported to be booted in the future."
Project: SkyWalking (Observability and Analysis / Observability)
File: IT-guide.md

IT(Integration Tests) represents the JUnit driven integration test to verify the features and compatibility between lib and known server with various versions. After setting up the environment and writing your codes, to facilitate integration with the SkyWalking project, you'll need to run tests locally to verify that your codes would not break any existing features, as well as write some unit test (UT) codes to verify that the new codes would work well. This will prevent them from being broken by future contributors. If the new codes involve other components or libraries, you should also write integration tests (IT). SkyWalking leverages the plugin `maven-surefire-plugin` to run the UTs and uses `maven-failsafe-plugin` to run the ITs. `maven-surefire-plugin` excludes ITs (whose class name starts or ends with `IT`, `IT`) and leaves them for `maven-failsafe-plugin` to run, which is bound to the `integration-test` goal. Therefore, to run the UTs, try `./mvnw clean test`, which only runs the UTs but not the ITs. If you would like to run the ITs, please run `./mvnw integration-test` as well as the profiles of the modules whose ITs you want to run. If you don't want to run UTs, please add `-DskipUTs=true`. E.g. if you would like to only run the ITs in `oap-server`, try `./mvnw -Pbackend clean verify -DskipUTs=true`, and if you would like to run all the ITs, simply run `./mvnw clean integration-test -DskipUTs=true`. Please be advised that if you're writing integration tests, name it with the pattern `IT` or `IT` so they would only run in goal `integration-test`.
Project: Chaosblade (Observability and Analysis / Chaos Engineering)
File: PULL_REQUEST_TEMPLATE.md

<!-- Thanks for submitting a pull request! Here are some tips for you: Please make sure you have read and understood the contributing guidelines: https://github.com/chaosblade-io/chaosblade/blob/master/CONTRIBUTING.md Please make sure the PR has a corresponding issue. --> <!--If that, add "Fixes #xxxx" below in the next line. For example, Fixes #15. Otherwise, add "NONE" -->
Project: Netdata (Observability and Analysis / Observability)
File: elasticsearch_node_indices_search_time_fetch.md

This alert is triggered when the Elasticsearch node's average `searchtimefetch` exceeds the warning or critical thresholds over a 10-minute window. The `searchtimefetch` measures the time spent fetching data from shards during search operations. If you receive this alert, it means your Elasticsearch search performance is degraded, and fetches are running slowly. Check the Elasticsearch cluster health Run the following command to check the health of your Elasticsearch cluster: ``` curl -XGET 'http://localhost:9200/_cluster/health?pretty' ``` Look for the `status` field in the output, which indicates the overall health of the cluster: green: All primary and replica shards are active and allocated. yellow: All primary shards are active, but not all replica shards are active. red: Some primary shards are not active. Identify slow search queries Run the following command to gather information on slow search queries: ``` curl -XGET 'http://localhost:9200/_nodes/stats/indices/search?pretty' ``` Look for the `query`, `fetch`, and `take` fields in the output, which indicate the time taken by different parts of the search operation. Check Elasticsearch node resources Ensure the Elasticsearch node has sufficient resources (CPU, memory, disk space, and disk I/O). Use system monitoring tools like `top`, `htop`, `vmstat`, and `iostat` to analyze the resource usage on the Elasticsearch node. Optimize search queries If slow search queries are identified in Step 2, consider optimizing them for better performance. Some techniques for optimizing Elasticsearch search performance include using filters, limiting result set size, and disabling expensive operations like sorting and faceting when not needed. Review Elasticsearch configuration Check your Elasticsearch configuration to ensure it is optimized for search performance. Verify settings such as index refresh intervals, query caches, and field data caches. Consult the Elasticsearch documentation for best practices on configuration settings. Consider horizontal scaling If your Elasticsearch node is experiencing high search loads regularly, consider adding more nodes to distribute the load evenly across the cluster.
Project: gocrane (Observability and Analysis / Continuous Optimization)
File: analytics-and-recommendation.md

Analytics and Recommendation provide capacity that analyzes the workload in k8s cluster and provide recommendations about resource optimize. Two Recommendations are currently supported: : Replicas recommendation analyze the actual application usage and give advice for replicas and HPA configurations. : Resource recommendation allows you to obtain recommended values for resources in a cluster and use them to improve the resource utilization of the cluster. Users create `Analytics` object and config ResourceSelector to select resources to be analyzed. Multiple types of resource selection (based on Group,Kind, and Version) are supported. Analyze each selected resource in parallel and try to execute analysis and give recommendation. Each analysis process is divided into two stages: inspecting and advising: Inspecting: Filter resources that don't match the recommended conditions. For example, for hpa recommendation, the workload that has many not running pod is excluded Advising: Analysis and calculation based on algorithm model then provide the recommendation result. If you paas the above two stages, it will create `Recommendation` object and display the result in `recommendation.Status` You can find the failure reasons from `analytics.status.recommendations` Wait for the next analytics based on the interval Analysis defines a scanning analysis task. Two task types are supported: resource recommendation and hpa recommendation. Crane regularly runs analysis tasks and produces recommended results. The recommendation shows the results of an `Analytics`. The recommended result is a YAML configuration that allows users to take appropriate optimization actions, such as adjusting the resource configuration of the application. Different analytics uses different computing models. Crane provides a default computing model and a corresponding configuration that users can modify to customize the recommended effect. You can modify the default configuration globally or modify the configuration of a single analytics task.
Project: Netdata (Observability and Analysis / Observability)
File: web_log_1m_redirects.md

HTTP response status codes indicate whether a specific HTTP request has been successfully completed or not. The 3XX class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request. The action required may be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. A client SHOULD detect infinite redirection loops, since such loops generate network traffic for each redirection. The Netdata Agent calculates the ratio of redirection HTTP requests over the last minute. This metric does not include the "304 Not modified" message. You can identify exactly what HTTP response code your web server send back to your clients, by opening the Netdata dashboard and inspecting the `detailedresponsecodes` chart for your web server. This chart keeps track of exactly what error codes your web server sends out. You should also check the server error logs. For example, web servers such as Apache or Nginx produce and error logs, by default under `/var/log/{nginx, apache2}/{access.log, error.log}`