cwielenb/CNCF-Dataset huggingface dataset:
Project: OpenSearch (Observability and Analysis / Observability)
File: opensearch.release-notes-2.6.0.md

Add index create block when all nodes have breached high disk watermark () Add cluster manager throttling stats in nodes/stats API () Add support for feature flags in opensearch.yml () Add query for initialized extensions () Add update-index-settings allowlist for searchable snapshot () Add new cat/segment_replication API to surface Segment Replication metrics (). Replace latches with CompletableFutures for extensions () Add support to disallow search request with preference parameter with strict weighted shard routing() Add support to apply index create block () Add support for minimum compatible version for extensions () Add a guardrail to limit maximum number of shard on the cluster () Add cancellation of in-flight SearchTasks based on resource consumption () Add support for ppc64le architecture () Add a setting to control auto release of OpenSearch managed index creation block () Fix timeout error when adding a document to an index with extension running () Handle translog upload during primary relocation for remote-backed indexes () Batch translog sync/upload per x ms for remote-backed indexes () Update nebula-publishing-plugin to 19.2.0 () Bump `reactor-netty` from 1.1.1 to 1.1.2 () OpenJDK Update (January 2023 Patch releases) () Bump `Mockito` from 4.7.0 to 5.1.0, `ByteBuddy` from 1.12.18 to 1.12.22 () Bump `joda` from 2.10.13 to 2.12.2 () Upgrade to Lucene 9.5.0 () Bump antlr4 from 4.9.3 to 4.11.1 () Bump `Netty` from 4.1.86.Final to 4.1.87.Final () Bump `Jackson` from 2.14.1 to 2.14.2 () Bump `org.apache.ant:ant` from 1.10.12 to 1.10.13 () Bump `azure-core-http-netty` from 1.12.7 to 1.12.8 () Bump `com.azure:azure-storage-common` from 12.18.1 to 12.19.3 () Bump `reactor-netty-http` from 1.0.24 to 1.1.2 () Bump `com.google.protobuf:protobuf-java` from 3.21.12 to 3.22.0 () Bump `io.projectreactor.netty:reactor-netty` from 1.1.2 to 1.1.3 () Bump `com.diffplug.spotless` from 6.10.0 to 6.15.0 () Bump `jettison` from 1.5.1 to 1.5.3 () Use ReplicationFailedException instead of OpensearchException in ReplicationTarget () ) Cluster health call to throw decommissioned exception for local decommissioned node() ) Update API spec for cluster health API () Remove deprecated org.gradle.util.DistributionLocator usage () ) Fix weighted shard routing state across search requests() ) Enable numeric sort optimisation for few numerical sort types () Fix Opensearch repository-s3 plugin cannot read ServiceAccount token (
Project: Netdata (Observability and Analysis / Observability)
File: upsd_10min_ups_load.md

This alert is based on the `upsd10minups_load` metric, which measures the average UPS load over the last 10 minutes. If you receive this alert, it means that the load on your UPS is higher than expected, which may lead to an unstable power supply and ungraceful system shutdowns. Verify the UPS load status Check the current load on the UPS using the `upsc` command with your UPS identifier: ``` upsc <yourupsidentifier> ``` Look for the `ups.load` metric in the command output to identify the current load percentage. Analyze the connected devices Make an inventory of all devices connected to the UPS, including servers, networking devices, and other equipment. Determine if all devices are essential or if some can be moved to another power source or disconnected entirely. Balance the load between multiple UPS units (if available) If you have more than one UPS, consider distributing the connected devices across multiple units to balance the load and ensure that each UPS isn't overloaded. Upgrade or replace the UPS If necessary, consider upgrading your UPS to a higher capacity model to handle the increased load or replacing the current unit if it's malfunctioning or unable to provide the required power. Monitor power usage trends Regularly review your power usage patterns and system logs, and take action to prevent load spikes that could trigger the `nut10minups_load` alert. Optimize device power consumption Implement power-saving strategies for connected devices, such as enabling power-saving modes, reducing CPU usage, or using power-efficient networking equipment.
Project: Headlamp (Observability and Analysis / Observability)
File: plugin_lib.AppMenu.md

title: "Interface: AppMenu" linkTitle: "AppMenu" slug: "plugin_lib.AppMenu" .AppMenu The members of AppMenu should be the same as the options for the MenuItem in https://www.electronjs.org/docs/latest/api/menu-item except for the "submenu" (which is the AppMenu type) and "click" (which is not supported here, use the "url" field instead). Any other members from Electron's MenuItem. `Optional` submenu: [] The submenus of this menu _ `Optional` url: `string` A URL to open (if not starting with http, then it'll be opened in the external browser)
Project: GO Feature Flag (Observability and Analysis / Feature Flagging)
File: monitor_relay_proxy.md

sidebar_position: 80 description: Monitor the relay proxy. The relay proxy offer some endpoints for you to be able to see how it behaves. Making a GET request to the URL path `/health` will tell you if the relay proxy is ready to serve traffic. This is useful especially for loadbalancer to know that they can send traffic to the service. Making a GET request to the URL path `/info` will give you information about the actual state of the relay proxy. This endpoint is providing metrics about the relay proxy in the prometheus format.
Project: Vector (Observability and Analysis / Observability)
File: 2020-03-14-honeycomb-sink.md

date: "2020-07-13" title: "New Honeycomb Sink" description: "Sink logs to the Honeycomb logging service" authors: ["binarylogic"] pr_numbers: [1665] release: "0.9.0" hideonrelease_notes: true badges: type: "new feature" domains: ["sinks"] sinks: ["honeycomb"] For you fans we have a new . Keep an eye on , which will introduce a new `transaction` transform. This transform is designed to produce "canonical" events. These are flattened, wide events that represent an entire transaction, the concept that Honeycomb is built upon. Vector + Honeycomb = .
Project: Checkmk (Observability and Analysis / Observability)
File: 15725.md

key | value | date | 2024-02-27T09:23:01+00:00 version | 2.4.0b1 class | fix edition | cre component | core level | 1 compatible | yes This change prevents a problem which might occur in case the `omd update` did not finish successfully. In this situation, the Microcore might be started with a configuration file from the previous version. This could lead to unexpected behavior. Instead of keeping the old configuration, the update procedure now deletes the file which makes the Microcore fail during startup with a more helpful error message.
Project: Vector (Observability and Analysis / Observability)
File: 2020-03-31-filter-transform.md

date: "2020-04-16" title: "New Filter Transform" description: "Filter and route your logs based on defined conditions" authors: ["binarylogic"] pr_numbers: [2088] release: "0.9.0" hideonrelease_notes: false badges: type: "new feature" domains: ["transforms"] transforms: ["filter"] We recently introduced a concept of conditions, which you can see in our as well as our unit tests feature. This paved the way for a new `filter` transform, allowing you to filter events based on a set of conditions. This replaces our old `field_filter` transform since it is much more expressive. ```toml title="vector.toml" [transforms.haproxy_errors] type = "filter" inputs = ["my-source-id"] condition."level.eq" = "error" condition."service.eq" = "haproxy" ``` Check out the for a fill list of available conditions.
Project: Grafana Mimir (Observability and Analysis / Observability)
File: SPLIT_MERGE_COMPACTOR.md

Given the list of all blocks in the storage: Group blocks by resolution + external labels (excluding shard ID). For each group: Group blocks by compactable time ranges (eg. 2h, 6h, 12h, 24h) Given the time range, if the time range is the "smallest one" (eg. 2h) AND there are non-sharded blocks, then we should split the block Example: TR=2h Case 1: all the blocks for the 2h time range have the "shard ID" label in the meta.json. In this case, we shouldn't run the split stage anymore. Case 2: there is at least 1 block for the 2h time range NOT having "shard ID" in the meta.json. In this case, we should run the split stage on 2h blocks without the "shard ID". Horizontal sharding Each compactor will take decisions without a central coordination Each compactor will run the planning for ALL blocks Each compactor will only execute "jobs" belonging to its shard Splitting job (each job consists of a set of blocks which will be merged together calling CompactWithSplitting()) Which blocks should belong to a specific job? We don't want all blocks to be compacted together, otherwise doesn't scale We use the configured number of output shards to determine how many concurrent jobs we want to run to split/shard blocks For each block to split, we add it to the job with index `hash(blockID) % numShards` Output: up to `numShards` jobs (each job contain the set of blocks to be merged together when running CompactWithSplitting()) How can we know if the compactor instance should process a job or not? A job is owned if `hash(tenant + stage + time range + shard ID)` belongs to the compactor tokens If the previous check has not produced any job AT ALL it means all the blocks for the "smallest time range" are already split (or there are no blocks at all), so we can proceed with the merging stage: Group blocks by "shard ID" (taking in account the case a block doesn't have the shard ID) Create a job for each group that contains 2+ blocks (because they need to be merged together) Add the job to the list of "valid jobs to execute" only if for the job shard ID there are no other jobs already in the list of "valid jobs" overlapping its time range Execute the jobs that belong to the compactor instance Loop through jobs and filter out the jobs hashes not belonging to the compactor tokens
Project: Cortex (Observability and Analysis / Observability)
File: bug_report.md

name: Bug report about: Create a report to help us improve title: '' labels: '' assignees: '' Describe the bug A clear and concise description of what the bug is. To Reproduce Steps to reproduce the behavior: Start Cortex (SHA or version) Perform Operations(Read/Write/Others) 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] Additional Context <!-- Additional relevant info which can help us debug this issue easily like Logs, Configuration etc. -->
Project: VictoriaMetrics (Observability and Analysis / Observability)
File: vmalertmanagerconfig.md

sort: 4 weight: 4 title: VMAlertmanagerConfig menu: docs: parent: "operator-custom-resources" weight: 4 aliases: /operator/resources/vmalertmanagerconfig.html The `VMAlertmanagerConfig` provides way to configure configuration with CRD. It allows to define different configuration parts, which will be merged by operator into config. It behaves like other config parts - `VMServiceScrape` and etc. Read and before using. You can see the full actual specification of the `VMAlertmanagerConfig` resource in the . Also, you can check out the section. `VMAlertmanagerConfig` allows delegating notification configuration to the kubernetes cluster users. The application owner may configure notifications by defining it at `VMAlertmanagerConfig`. With the combination of `VMRule` and `VMServiceScrape` it allows delegating configuration observability to application owners, and uses popular `GitOps` practice. Operator combines `VMAlertmanagerConfig`s into a single configuration file for `VMAlertmanager`. ```yaml apiVersion: operator.victoriametrics.com/v1beta1 kind: VMAlertmanagerConfig metadata: name: example-email-web namespace: production spec: route: receiver: email group_interval: 1m routes: receiver: email matchers: {severity =~ "warning|critical", app_name = "blog"} receivers: name: email email_configs: to: some-email@example.com from: alerting@example.com smarthost: example.com:25 text: ALARM ``` VMAlertmanagerConfig has enforced namespace matcher. Alerts must have a proper namespace label, with the same value as name of namespace for VMAlertmanagerConfig. It can be disabled, by setting the following value to the VMAlertmanager: `spec.disableNamespaceMatcher: true`. ```yaml apiVersion: operator.victoriametrics.com/v1beta1 kind: VMAlertmanagerConfig metadata: name: example namespace: default spec: inhibit_rules: equals: [] target_matchers: [] source_matchers: [] route: routes: receiver: webhook continue: true receiver: email group_by: [] continue: false matchers: job = "alertmanager" group_wait: 30s group_interval: 45s repeat_interval: 1h mutetimeintervals: name: base time_intervals: times: start_time: "" end_time: "" weekdays: [] daysofmonth: [] months: [] years: [] receivers: email_configs: [] webhook_configs: url: http://some-other-wh pagerduty_configs: [] pushover_configs: [] slack_configs: [] opsgenie_configs: [] victorops_configs: [] wechat_configs: [] ```
Project: Netdata (Observability and Analysis / Observability)
File: 1m_received_packets_rate.md

1mreceivedpackets_rate alert indicates the average number of packets received by the network interface on your system over the last minute. If you receive this alert, it signifies higher than usual network traffic incoming. A received packet is a unit of data that is transmitted through the network interface to your system. Higher received packets rate means an increase in incoming network traffic to your system. It could be due to legitimate usage or could signal a potential issue such as a network misconfiguration, an attack, or a system malfunction. Analyze the network throughput: Use the `nload` or `iftop` command to check the incoming traffic on your system's network interfaces. These commands display the current network traffic and will help you monitor the incoming data. ``` sudo nload <network_interface> // or sudo iftop -i <network_interface> ``` Replace `<network_interface>` with your network interface (e.g., eth0). Check for specific processes consuming unusually high network bandwidth: Use the `netstat` command combined with `grep` to filter the results and find processes with high network traffic. ``` sudo netstat -tunap | grep <network_interface> ``` Replace `<network_interface>` with your network interface (e.g., eth0). Identify host-consuming bandwidth: After identifying the processes consuming a high network, you can trace back their respective hosts. Use the `tcpdump` command to capture live network traffic and analyze it for specific IP addresses causing the high packets rate. ``` sudo tcpdump -n -i <network_interface> -c 100 ``` Replace `<network_interface>` with your network interface (e.g., eth0). Mitigate the issue: Depending on the root cause, apply appropriate remedial actions. This may include: Adjusting application/service configuration to reduce network traffic Updating firewall rules to block undesired sources/IPs Ensuring network devices are appropriately configured Addressing system overload issues that hamper network performance
Project: Vector (Observability and Analysis / Observability)
File: 2020-04-20-improved-shutdown.md

date: "2020-04-20" title: "Improved Shutdown" description: "A faster and more reliable shutdown process" authors: ["binarylogic"] pr_numbers: [1994] release: "0.9.0" hideonrelease_notes: false badges: type: "enhancement" domains: ["topology"] A graceful shutdown process is often a problematic achievement in software. It takes a lot of coordination to ensure interconnected components shut down in the right order and in time. In the context of Vector, it's critically essential because it prevents data loss in real-world practice. As a result, this is one area we want to get right. introduces a clear shutdown strategy that moves the shutdown logic into Vector's topology, simplifying the shutdown implementation for each component. This change ensures that shutdown is easily and correctly implemented. The result is not only faster shutdowns but much higher confidence that components in the future will reliably shutdown.
Project: Vector (Observability and Analysis / Observability)
File: gcp_stackdriver_metrics.md

title: GCP Cloud Monitoring (formerly Stackdriver) description: Deliver metrics to GCP's system component_kind: sink layout: component tags: ["gcp", "stackdriver", "operations", "component", "sink", "metrics"] {{/* This doc is generated using: The template in layouts/docs/component.html The relevant CUE data in cue/reference/components/... */}}
Project: Headlamp (Observability and Analysis / Observability)
File: plugin_registry.TerminalEvent.md

title: "Interface: TerminalEvent" linkTitle: "TerminalEvent" slug: "plugin_registry.TerminalEvent" .TerminalEvent Event fired when using the terminal. data: `Object` | Name | Type | Description | | : | : | : | | `resource?` | `any` | The resource for which the terminal was opened (currently this only happens for Pod instances). | | `status` | `OPENED` \| `CLOSED` | What exactly this event represents. 'OPEN' when the terminal is opened. 'CLOSED' when it is closed. | _ type: `TERMINAL`
Project: Cortex (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: Grafana (Observability and Analysis / Observability)
File: release-notes-7-5-2.md

_build: list: false labels: products: cloud enterprise oss title: Release notes for Grafana 7.5.2 <!-- Auto generated by update changelog github action --> Explore: Set Explore's GraphNG to use default value for connected null values setting. , DashboardDataSource: Fix query not being executed after selecting source panel. , Graph: Fix setting right y-axis when standard option unit is configured. , Table: Fix links for image cells. , Variables: Fix data source variable when default data source is selected. , Variables: Fix manually entering non-matching custom value in variable input/picker error. ,
Project: PowerfulSeal (Observability and Analysis / Chaos Engineering)
File: 5_setup.md

layout: default title: Setup nav_order: 5 description: "" permalink: /setup has_children: true {: .no_toc } {: .no_toc .text-delta } TOC {:toc} `PowerfulSeal` has two main modes of operation: through `Kubernetes` or through `SSH`. `Kubernetes` mode is the default, and it's easier to use. It kills pods by deleting them through the API. `SSH` works by SSH-ing into the machine itself and executing command like `docker kill <pod ip>`. The pods then show as crashing. Unfortunately, it requires `SSH` access to all machines you're going to be doing chaos on, which is sometimes troublesome. Running on `Kubernetes` is easy. You can do that by: creating to allow the seal to list, get and delete pods and nodes, you might need to adjust it depending on what you are planning to do with the Seal creating a your scenarios will live in the configmap if you'd like to use the UI, you'll probably also need a service and ingress That's it. The Seal will self-discover the way to connect to `Kubernetes` and start executing your policy If you're running outside of your cluster, the setup will involve: pointing PowerfulSeal at your Kubernetes cluster by giving it a Kubernetes config file pointing PowerfulSeal at your cloud by specifying the cloud driver to use and providing credentials making sure the Seal can `SSH` into the nodes in order to execute `docker kill` command writing a set of policies It should look something like . The `powerfulseal` image packages a `kubectl` binary to execute the `kubectl` actions with. When executing the commands, the `http{s}_proxy` variables are overwritten by the contents of the `proxy` parameter from inside of the scenario. If you exec into the pod, you can `kubectl` directly, using the same RBAC permissions. For example, in the contains RBAC which allows the seal to: read from all namespaces delete pods in all namespaces do everything inside of the special `powerfulseal-sandbox` namespace all creation of new pods will need to happen inside of that namespace Remember, that in order to be able to execute the `kubectl` action payloads, you're going to need to give you pod necessary permissions. If you have a running `powerfulseal` pod executing scenario, you can always `kubectl exec -ti ps-pod -- bash` and then run `powerfulseal interactive` from inside of it. In order to interact with VMs, you're going to need to configure a cloud driver. It's easy to use `minikube` with the Seal. It should run well on the default settings. If you choose to use SSH access, you're going to need these options: ```sh --ssh-allow-missing-host-keys \ --remote-user docker \ --ssh-path-to-private-key `minikube ssh-key` \ --ssh-password `minikube ssh-password` \ --override-ssh-host `minikube ip` \ ``` In order to use `kubectl` action, you're going to need `kubectl` accessible in your path. The official images ship with the latest minor version of `kubectl` inside of the container.