cwielenb/CNCF-Dataset huggingface dataset:
Project: Netdata (Observability and Analysis / Observability)
File: 10min_qos_packet_drops.md

This alert is triggered when there are `packet drops` within the last 10 minutes in your system's `Quality of Service` (`QoS`). If you receive this alert, it means your system's `network performance` may be suffering due to dropped packets. Packet drops refer to situations where one or more packets of data traveling across a computer network fail to reach their destination, often caused by network congestion or faulty hardware. Dropped packets can result in poor QoS, including degraded voice and video quality, or even data loss in severe cases. Check the network utilization, packet loss, and latency You can use the `netdata` dashboard to check the network utilization, packet loss, and latency. This will help you identify if there is any congestion or excessive usage in your network that could be causing the packet drops. Examine the system logs Inspect your system logs to identify any potential hardware issues or network-related errors that could be causing the packet drops. You can use tools like `dmesg`, `journalctl`, or check the `/var/log` directory for log files. Check for faulty hardware or misconfigurations Inspect your network devices, such as routers, switches, and network interfaces, for any signs of faulty hardware or misconfigurations that could be causing dropped packets. Optimize your network configuration Review your network configuration for any settings that could be causing dropped packets, such as improper buffer sizes, incorrect QoS settings, or misconfigured packet handling mechanisms. Update network device drivers or firmware Ensure that you are using the latest drivers and firmware for your network devices. Outdated or buggy drivers can sometimes cause packet drops. Monitor the network continuously Regularly monitor the performance of your network to identify and address any issues that may be causing packet drops. You can use tools like `tc`, `ip`, `ifconfig`, and others for this purpose.
Project: gocrane (Observability and Analysis / Continuous Optimization)
File: pv-recommendation.md

title: "PV Recommendation" description: "Introduce for PV Recommendation" weight: 17 PV recommendation scans the running status of PVs in the cluster to help users find idle Kubernetes PVs. In Kubernetes, we usually use PV + Workload to automatically create and manage storage volumes and attach them to applications. However, in daily operations, idle or unused storage volumes may inevitably occur, wasting a lot of costs. PV recommendation tries to help users find these PVs to achieve cost optimization. ```yaml apiVersion: analysis.crane.io/v1alpha1 kind: Recommendation metadata: annotations: analysis.crane.io/last-start-time: "2023-06-14 08:55:25" analysis.crane.io/message: Success analysis.crane.io/run-number: "653" labels: analysis.crane.io/recommendation-rule-name: persistentvolumes-rule analysis.crane.io/recommendation-rule-recommender: Volume analysis.crane.io/recommendation-rule-uid: 39d30abe-4c7f-4e65-b961-b00ec7776b45 analysis.crane.io/recommendation-target-kind: PersistentVolume analysis.crane.io/recommendation-target-name: pvc-6ce24277-24e9-4fcf-8e8a-f9bdb5694134 analysis.crane.io/recommendation-target-namespace: "" analysis.crane.io/recommendation-target-version: v1 name: persistentvolumes-rule-volume-5r9zn namespace: crane-system ownerReferences: apiVersion: analysis.crane.io/v1alpha1 blockOwnerDeletion: false controller: false kind: RecommendationRule name: persistentvolumes-rule uid: 39d30abe-4c7f-4e65-b961-b00ec7776b45 spec: adoptionType: StatusAndAnnotation completionStrategy: completionStrategyType: Once targetRef: apiVersion: v1 kind: PersistentVolume name: pvc-6ce24277-24e9-4fcf-8e8a-f9bdb5694134 type: Volume status: action: Delete description: It is an Orphan Volumes lastUpdateTime: "2023-06-14T08:55:25Z" ``` In this sample: The recommended TargetRef points to PV: pvc-6ce24277-24e9-4fcf-8e8a-f9bdb5694134 The recommendation type is PV recommendation The action is to Delete, and it is only a suggestion provided here. PV recommendation completes a recommendation process using the following steps: Scan all PVs in the cluster and find the list of Pods corresponding to each PV. If the PV does not have a corresponding PVC, it is considered an idle PV. If no Pods are associated with this PV and PVC, it is considered an idle PVC. Currently, there is no parameter configuration for PV recommendation. How to update recommendation configuration please refer to
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-7-3-1.md

_build: list: false labels: products: cloud enterprise oss title: Release notes for Grafana 7.3.1 <!-- Auto generated do not edit --> Cloudwatch: Fix duplicate metric data. , Loki: Fix error when some queries return zero results. , PanelMenu: Fix panel submenu not being accessible for panels close to the right edge of the screen. , Plugins: Fix descendent frontend plugin signature validation. , StatPanel: Fix value being under graph and reduced likelihood for white and dark value text mixing. , TextPanel: Fix problems where text panel would show old content. ,
Project: Trickster (Observability and Analysis / Observability)
File: adding-new-config.md

Trickster configurations are defined in `options` packages below each feature package (e.g., `/backends/options`, `caches/options`, etc) and are mapped to `yaml` struct tags. When adding a configuration value, there are several places to add references, which are described below. Each new configuration value must be defined in an `options` package under an existing Configuration collection (Origins, Caches, Paths, etc.). Make sure the YAML annotation uses a `lowercasenospaces` naming convention, while the configuration member name itself should be `CamelCase`. Follow the existing configs for guidance. Once you have defined your configuration value(s), you must put them to work by referencing them elsewhere in the Trickster code, and used to determine or customize the application functionality. Exactly where this happens in the code depends upon the context and reach of your new configuration, and what features its state affects. Consult with a project maintainer if you have any questions. All new values that you add should have accompanying unit tests to ensure the modifications the value makes to the application in the feature code work as designed. Unit Tests should include verification of: proper parsing of configuration value from test config files (in ./testdata), correct feature functionality enable/disable based on the configuration value, correct feature implementation, coverage of all executable lines of code. The feature should be documented under `./docs` directory, in a suitable existing or new markdown file based on the nature of the feature. The documentation should show the key example configuration options and describe their expected results, and point to the example config file for more information. The should be updated to include the exhaustive description and options for the configuration value(s). The `./deploy/kube/configmap.yaml` must be updated to include the new configuration option(s). Generally this file contains a copy/paste of . The `./deploy/helm/trickster/values.yaml` file must be updated to mirror the configuration option(s) in `example.full.yaml`, and `./deploy/helm/trickster/templates/configmap.yaml` must be updated to map any new `yamlCaseValues` to their respective snake case values for config file generation via the template.
Project: SkyWalking (Observability and Analysis / Observability)
File: Protoc-Plugin-Fails-When-Build.md

In maven build, the following error may occur with the protoc-plugin: ``` [ERROR] Failed to execute goal org.xolstice.maven.plugins:protobuf-maven-plugin:0.5.0:compile-custom (default) on project apm-network: Unable to copy the file to \skywalking\apm-network\target\protoc-plugins: \skywalking\apm-network\target\protoc-plugins\protoc-3.3.0-linux-x86_64.exe (The process cannot access the file because it is being used by another process) -> [Help 1] ``` The Protobuf compiler is dependent on the glibc. However, glibc has not been installed, or there is an old version already installed in the system. Install or upgrade to the latest version of the glibc library. Under the container environment, the latest glibc version of the alpine system is recommended. Please refer to http://www.gnu.org/software/libc/documentation.html.
Project: Pixie (Observability and Analysis / Observability)
File: feature_request.md

name: Feature request about: Suggest an idea 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 or screenshots about the feature request here.
Project: OpenSearch (Observability and Analysis / Observability)
File: CHANGELOG-3.0.md

All notable changes to this project are documented in this file. The format is based on , and this project adheres to . See the for instructions on how to add changelog entries. Support for HTTP/2 (server-side) () Allow mmap to use new JDK-19 preview APIs in Apache Lucene 9.4+ () Add events correlation engine plugin () Implement on behalf of token passing for extensions (, ) Provide service accounts tokens to extensions () GHA to verify checklist items completion in PR descriptions () Allow to pass the list settings through environment variables (like ) Views, simplify data access and manipulation by providing a virtual layer over one or more indices () Migrate client transports to Apache HttpClient / Core 5.x () Change http code on create index API with bad input raising NotXContentException from 500 to 400 () Improve summary error message for invalid setting updates () Return 409 Conflict HTTP status instead of 503 on failure to concurrently execute snapshots () Add task completion count in search backpressure stats API () Deprecate CamelCase `PathHierarchy` tokenizer name in favor to lowercase `path_hierarchy` () Breaking change: Do not request "search_pipelines" metrics by default in NodesInfoRequest () Remove deprecated code to add node name into log pattern of log4j property file () Unused object and import within TransportClusterAllocationExplainAction () Remove LegacyESVersion.V70* and V71* Constants () Remove LegacyESVersion.V72 and V73 Constants () Always auto release the flood stage block () Remove LegacyESVersion.V74 and V75 Constants () Remove Legacy Version support from Snapshot/Restore Service () Remove deprecated serialization logic from pipeline aggs () Remove unused private methods () Remove LegacyESVersion.V78 and V79 Constants () Remove LegacyESVersion.V76 and V77 Constants () Remove LegacyESVersion.V710_ Constants () Remove Version.V1 Constants () Remove custom Map, List and Set collection classes () Fix 'org.apache.hc.core5.http.ParseException: Invalid protocol version' under JDK 16+ () Fix compression support for h2c protocol () Don't over-allocate in HeapBufferedAsyncEntityConsumer in order to consume the response ()
Project: OpenSearch (Observability and Analysis / Observability)
File: opensearch.release-notes-2.11.0.md

Add coordinator level stats for search latency () Add metrics for thread_pool task wait time () Add parallel file download support for remote store based replication () Async blob read support for S3 plugin () ) Async blob read support for encrypted containers () Implement Visitor Design pattern in QueryBuilder to enable the capability to traverse through the complex QueryBuilder tree. () Add capability to restrict async durability mode for remote indexes () Add Doc Status Counter for Indexing Engine () Add unreferenced file cleanup count to merge stats () Configurable merge policy for index with an option to choose from LogByteSize and Tiered merge policy () ) Improve compressed request handling () Bump JNA version from 5.5 to 5.13 () Bump `peter-evans/create-or-update-comment` from 2 to 3 () Bump `actions/checkout` from 2 to 4 () Bump OpenTelemetry from 1.26.0 to 1.30.1 () Bump `org.apache.commons:commons-compress` from 1.23.0 to 1.24.0 () Bump `com.google.cloud:google-cloud-core-http` from 2.21.1 to 2.23.0 () Bump `mockito` from 5.4.0 to 5.5.0 () Bump `bytebuddy` from 1.14.3 to 1.14.7 () Bump `com.zaxxer:SparseBitSet` from 1.2 to 1.3 () Bump `tibdex/github-app-token` from 1.5.0 to 2.1.0 () Bump `org.wiremock:wiremock-standalone` from 2.35.0 to 3.1.0 () Bump `org.eclipse.jgit` from 6.5.0 to 6.7.0 () Bump `codecov/codecov-action` from 2 to 3 () Bump `com.google.http-client:google-http-client-jackson2` from 1.43.2 to 1.43.3 () Bump `org.xerial.snappy:snappy-java` from 1.1.10.3 to 1.1.10.5 (, ) Bump `org.bouncycastle:bcpkix-jdk15to18` from 1.75 to 1.76 ()` Bump `org.bouncycastle:bcprov-jdk15to18` from 1.75 to 1.76 ()` Bump `org.bouncycastle:bcmail-jdk15to18` from 1.75 to 1.76 ()` Bump asm from 9.5 to 9.6 () Bump netty from 4.1.97.Final to 4.1.99.Final () Bump `peter-evans/create-pull-request` from 3 to 5 () Bump `org.apache.avro:avro` from 1.11.2 to 1.11.3 () Bump `netty` from 4.1.99.Final to 4.1.100.Final () Add instrumentation in rest and network layer. () Allow parameterization of tests with OpenSearchIntegTestCase.SuiteScopeTestCase annotation () Add instrumentation in transport service. () ) Pass parent filter to inner query in nested query () Disable concurrent segment search when terminate_after is used () Add instrumentation in Inbound Handler. () Enable remote segment upload backpressure by default () ) ) Updating the separator for RemoteStoreLockManager since underscore is allowed in base64UUID url charset () Remove spurious SGID bit on directories () Fix ignore_missing parameter has no effect when using template snippet in rename ingest processor () Fix broken backward compatibility from 2.7 for IndexSorted field indices () Fix concurrent search NPE when tracktotalhits, terminate_after and size=0 are used () Fix remove ingest processor handing ignore_missing parameter not correctly () Fix registration and initialization of multiple extensions () Fix circular dependency in Settings initialization () Fix Segment Replication ShardLockObtainFailedException bug during index corruption ()
Project: Grafana Tempo (Observability and Analysis / Observability)
File: ipv6.md

title: Configure IPv6 description: Learn how to configure IPv6 for Tempo. menuTitle: Configure IPv6 aliases: ../../configuration/ipv6/ # /docs/tempo/<TEMPO_VERSION>/configuration/ipv6/ Tempo can be configured to communicate between the components using Internet Protocol Version 6, or IPv6. {{< admonition type="note" >}} The underlying infrastructure must support this address family. This configuration may be used in a single-stack IPv6 environment, or in a dual-stack environment where both IPv6 and IPv4 are present. In a dual-stack scenario, only one address family may be configured at a time, and all components must be configured for that address family. {{% /admonition %}} This sample listen configuration will allow the gRPC and HTTP servers to listen on IPv6, and configure the various memberlist components to enable IPv6. ```yaml memberlist: bind_addr: '::' bind_port: 7946 compactor: ring: kvstore: store: memberlist enable_inet6: true metrics_generator: ring: enable_inet6: true ingester: lifecycler: address: '::' enable_inet6: true server: grpclistenaddress: '::0' grpclistenport: 9095 httplistenaddress: '::0' httplistenport: 3200 ``` Each service fronting the workloads will need to be configured with with `spec.ipFamilies` and `spec.ipFamilyPolicy` set. See this `compactor` example. ```yaml apiVersion: v1 kind: Service metadata: labels: name: compactor name: compactor namespace: trace spec: clusterIP: fccb::31a7 clusterIPs: fccb::31a7 internalTrafficPolicy: Cluster ipFamilies: IPv6 ipFamilyPolicy: SingleStack ports: name: compactor-http-metrics port: 3200 protocol: TCP targetPort: 3200 selector: app: compactor name: compactor sessionAffinity: None type: ClusterIP ``` You can check the listening service from within a pod. ```sh k exec -it compactor-55c778b8d9-2kch2 -- sh / # apk add iproute2 OK: 12 MiB in 27 packages / # ss -ltn -f inet State Recv-Q Send-Q Local Address:Port Peer Address:Port Process / # ss -ltn -f inet6 State Recv-Q Send-Q Local Address:Port Peer Address:Port Process LISTEN 0 4096 :7946 :* LISTEN 0 4096 :9095 :* LISTEN 0 4096 :3200 :* ```
Project: Netdata (Observability and Analysis / Observability)
File: consul_raft_thread_main_saturation.md

This alert triggers when the main Raft goroutine's saturation percentage reaches a certain threshold. If you receive this alert, it means that your Consul server is experiencing high utilization of the main Raft goroutine. Consul is a service discovery, configuration, and orchestration solution developed by HashiCorp. It is used in microservice architectures and distributed systems to make services aware and discoverable by other services. Raft is a consensus-based algorithm used for maintaining the state of the Consul servers. The main Raft goroutine is responsible for carrying out consensus-related tasks in the Consul server. It ensures the consistency and reliability of the server's state. High saturation of this goroutine can lead to performance issues in the Consul server cluster. Verify the current status of the Consul server. Check the health status and logs of the Consul server using the following command: ``` consul monitor ``` Monitor Raft metrics. Use the Consul telemetry feature to collect and analyze Raft performance metrics. Consult the on setting up telemetry. Review the server's resources. Confirm whether the server hosting the Consul service has enough resources (CPU, memory, and disk space) to handle the current load. Upgrade the server resources or adjust the Consul configurations accordingly. Inspect the Consul server's log files. Analyze the log files to identify any errors or issues that could be affecting the performance of the main Raft goroutine. Monitor network latency between Consul servers. High network latency can affect the performance of the Raft algorithm. Use monitoring tools like `ping` or `traceroute` to measure the latency between the Consul servers. Check for disruptions in the Consul cluster. Investigate possible disruptions caused by external factors, such as server failures, network partitioning or misconfigurations in the cluster.
Project: M3 (Observability and Analysis / Observability)
File: update_cluster.md

title: "Updating a Cluster" menuTitle: "Updating a Cluster" weight: 13 chapter: true After your cluster has been running for some time you may decide you want to change the cluster's spec. For instance, you may want to upgrade to a newer release of M3DB or modify the cluster's config file. The operator can be used to safely rollout such changes so you don't need to do anything other than add an annotation to enable updates. The first step in updating a cluster is to update the cluster's `M3DBCluster` CRD with the changes you want to make. If you manage your cluster via manifests stored in YAML files then this is as simple as updating the manifest and applying your changes: ```bash kubectl apply -f example/my-cluster.yaml ``` As a precaution, the operator won't immediately begin updating a cluster after your changes have been applied. Instead, you'll need to add the following annotation on each `StatefulSet` in the cluster to indicate to the operator that it is safe to update that `StatefulSet`: ```bash kubectl annotate statefulset my-cluster-rep0 operator.m3db.io/update=enabled ``` When the operator sees this annotation, it will check if the current state of the `StatefulSet` differs from its desired state as defined by the `M3DBCluster` CRD. If so, the operator will update the `StatefulSet` to match its desired state, thereby triggering a rollout of the pods in the `StatefulSet`. The operator will also remove the `operator.m3db.io/update=enabled` annotation from the updated `StatefulSet`. If, on the other hand, the operator finds the update annotation on a `StatefulSet` but it doesn't need to be updated then the operator will remove the annotation but perform no other actions. Consequently, once you set the update annotation on a `StatefulSet`, you can watch for the annotation to be removed from it to know if the operator has seen and checked for an update. Since M3DB rollouts can take longer periods of time, it's often more convenient to set the annotation to enable updates on each `StatefulSet` in the cluster at once, and allow the operator to perform the rollout safely. The operator will update only one `StatefulSet` at a time and then wait for it to bootstrap and become healthy again before moving onto the next `StatefulSet` in the cluster so that no two replicas are ever down at the same time. ```bash kubectl annotate statefulset -l operator.m3db.io/cluster=my-cluster operator.m3db.io/update=enabled ```
Project: Grafana Tempo (Observability and Analysis / Observability)
File: pull_request_template.md

<!-- Thanks for sending a pull request! Before submitting: Read our CONTRIBUTING.md guide Rebase your PR if it gets out of sync with main --> What this PR does: Which issue(s) this PR fixes: Fixes #<issue number> Checklist [ ] Tests updated [ ] Documentation added [ ] `CHANGELOG.md` updated - the order of entries should be `[CHANGE]`, `[FEATURE]`, `[ENHANCEMENT]`, `[BUGFIX]`
Project: Netis (Observability and Analysis / Observability)
File: recvzmq.md

``` python recvzmq.py [--spantime seconds] -z portnum -t /path/file_template -a 4 -z or --zmq_port: zmq bind port -t or --filetemplate: file template. Examle: /opt/pcapcache/nic0/%Y%m%d%H%M%S -s or --span_time: pcap span time interval. Default: 15, Unit: seconds. -a or --total_workers: total worker process count of recvzmq. Default 1. -v or --version: version info -h or --help: help message ``` zmq_port<br> Zeromq bind port to receive message from remote packet agent client. <br> file_template<br> File path and file name of output pcap, the file name template will be formatted. Examle: /opt/pcap_cache/nic0/%Y%m%d%H%M%S %Y%m%d%H%M%S will be formatted to something like 20200415090530, pcap name will be 2020041509053020.pcap, 2020041509053021.pcap <br> span_time<br> Pcap span time interval. Default: 15, Unit: seconds. <br> total_workers<br> Total worker process count of recvzmq. Default 1. Usually, the max capacity for one worker process is 200Mbps. <br> Two child process workers ``` python recvzmq.py -s 15 -z 82 -f /opt/pcap_cache/nic0/%Y%m%d%H%M%S -a 2 ```
Project: EaseAgent (Observability and Analysis / Observability)
File: use-in-docker.md

Download the agent, The startup parameters of the Java application server must include the built-in argument -javaagent. It is recommended that you set this argument with the JAVA_OPTS environment variable. The value of that argument must contain the location where you ADD the easeagent.jar file to the image. For example, with Tomcat, use commands like these in the Dockerfile: ```dockerfile RUN mkdir -p /usr/local/tomcat/easeagent ADD ./easeagent/easeagent.jar /usr/local/tomcat/easeagent/easeagent.jar ENV JAVAOPTS="$JAVAOPTS -javaagent:/usr/local/tomcat/easeagent/easeagent.jar" ``` Deploy your application to start using the EaseAgent to send data to MegaCloud.