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

TCP reset is an abrupt closure of the session. It causes the resources allocated to the connection to be immediately released and all other information about the connection is erased. The Netdata Agent monitors the average number of sent TCP RESETS over the last 10 seconds. This can indicate a port scan or that a service running on the system has crashed. Additionally, it's a result of a high number of sent TCP RESETS. Furthermore, it can also indicate a SYN reset attack. TCP uses a three-way handshake to establish a reliable connection. The connection is full duplex, and both sides synchronize (SYN) and acknowledge (ACK) each other. The exchange of these four flags is performed in three steps: SYN, SYN-ACK, and ACK. When an unexpected TCP packet arrives at a host, that host usually responds by sending a reset packet back on the same connection. A reset packet is one with no payload and with the RST bit set in the TCP header flags. There are a few circumstances in which a TCP packet might not be expected. The most common cases are: A TCP packet received on a port that is not open. An aborting connection Half opened connections Time wait assassination Listening endpoint Queue is Full A TCP Buffer Overflow Basically, A TCP Reset usually occurs when a system receives data which doesn't agree with its view of the connection. When your system cannot establish a connection it will retry by default `net.ipv4.tcpsynretries` times. Use tcpdump to capture the traffic and use Wireshark to inspect the network packets. You must stop the capture after a certain observation period (60s up to 5 minutes). This command will create a dump file which can be interpreted by Wireshark that contains all the TCP packets with RST flag set. ``` tcpdump -i any 'tcp[tcpflags] & (tcp-rst) == (tcp-rst)' -s 65535 -w output.pcap ``` Identify which application sends TCP resets Check the instances of `RST` events of the TCP protocol. Wireshark also displays the ports on which the two systems tried to establish the TCP connection, (XXXXXX -> XXXXXX). To check which application is using this port, run the following code: ``` lsof -i:XXXXXX -P -n ```
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-9-0-7.md

aliases: [] hide_menu: true labels: products: cloud enterprise oss title: Release notes for Grafana 9.0.7 <!-- Auto generated by update changelog github action --> CloudMonitoring: Remove link setting for SLO queries. , GrafanaUI: Render PageToolbar's leftItems regardless of title's presence. , Reports: Fix inconsistency reports. (Enterprise) Reports: Set UID when it's not received in the query. (Enterprise) Reports: Save and update in reports should be transactional. (Enterprise)
Project: Grafana Tempo (Observability and Analysis / Observability)
File: response-too-large.md

title: Response larger than the max description: Troubleshoot response larger than the max error message weight: 477 aliases: ../operations/troubleshooting/response-too-large/ The error message will take a similar form to the following: ``` 500 Internal Server Error Body: response larger than the max (<size> vs <limit>) ``` This error indicates that the response received or sent is too large. This can happen in multiple places, but it's most commonly seen in the query path, with messages between the querier and the query frontend. Tempo components communicate with each other via gRPC requests. To increase the maximum message size, you can increase the gRPC message size limit in the server block. ```yaml server: grpcservermaxrecvmsg_size: <size> grpcservermaxsendmsg_size: <size> ``` The server config block is not synchronized across components. Most likely you will need to increase the message size limit in multiple components. Additionally, querier workers can be configured to use a larger message size limit. ```yaml querier: frontend_worker: grpcclientconfig: maxsendmsg_size: <size> ``` Lastly, message size is also limited in ingestion and can be modified in the distributor block. ```yaml distributor: receivers: otlp: grpc: maxrecvmsgsizemib: <size> ```
Project: Netdata (Observability and Analysis / Observability)
File: systemd_service_unit_failed_state.md

This alert is triggered when a `systemd service unit` enters the `failed state`. If you receive this alert, it means that a critical service on your system has stopped working, and it requires immediate attention. A `systemd service unit` is a simply stated, a service configuration file that describes how a specific service should be controlled and managed on a Linux system. It includes information about service dependencies, the order in which it should start, and more. Systemd is responsible for managing these services and making sure they are functioning as intended. When a `systemd service unit` enters the `failed state`, it indicates that the service has encountered a fault, such as an incorrect configuration file, crashing, or failing to start due to other dependencies. When this occurs, the service is rendered non-functional, and you should troubleshoot the issue to restore normal functionality. Identify the failed service unit Use the following command to list all failed service units: ``` systemctl --state=failed ``` Take note of the failed service unit name as you will use it in the next steps. Check the service unit status Use the following command to investigate the status and any error messages: ``` systemctl status <failedserviceunit> ``` Replace `<failedserviceunit>` with the name of the failed service unit you identified earlier. Examine the logs for the failed service Use the following command to inspect the logs for any clues: ``` journalctl -u <failedserviceunit> --since "1 hour ago" ``` Adjust the `--since` parameter to view logs from a specific timeframe. Resolve the issue Based on the information gathered from the status and logs, try to resolve the issue causing the failure. This can involve updating configuration files, installing missing dependencies, or addressing issues with other services that the failed service unit depends on. Restart the service Once the issue has been addressed, restart the service to restore functionality: ``` systemctl start <failedserviceunit> ``` Verify that the service has started successfully: ``` systemctl status <failedserviceunit> ```
Project: Grafana Loki (Observability and Analysis / Observability)
File: v2-8.md

title: V2.8 description: Version 2.8 release notes weight: 55 Grafana Labs is excited to announce the release of Loki 2.8. Here's a summary of new enhancements and important fixes: TSDB index no longer experimental After extensive testing of the new TSDB index in our Grafana Cloud Logs offering, we can safely announce that it is no longer experimental and encourage all Loki deployments to use it! Query blocker Queries can now be blocked in the Querier/Ruler via a per-tenant runtime configuration. New `backend` target A new, third target was added to Loki's scalable configuration, which is the default configuration used in the Loki helm chart. This allows Loki to be run as 3 targets (`read`, `write`, and `backend`) and makes the `read` target stateless and therefore able to be run as a Kubernetes deployment that can be scaled automatically. For a full list of all changes, look at the . As always, please read the before upgrading Loki. Upgrade go to v1.20.10, golang.org/x/net to v0.17.0 and grpc-go to v1.56.3 to patch CVE-2023-39325 / CVE-2023-44487 Update Docker base images to mitigate security vulnerability CVE-2022-48174 Update Go to 1.20.4 to address security vulnerabilities in the previous Go version. Promtail*: Add new `decompression` configuration to customize the decompressor behavior. Fix bug that was dropping index if period is a zero value. Fix redis client to prevent it from incorrectly choosing cluster mode with local address. Update go to 1.20.3 to address security vulnerabilities in the previous go version. Update alpine image to 3.16.5 to address security vulnerabilities in the previous version. Promtail*: Fix journald support in amd64 binary build. For a full list of all changes and fixes, look at the .
Project: Grafana (Observability and Analysis / Observability)
File: multiple-y-axes.md

title: Display multiple y-axes In some cases, you may want to display multiple y-axes. For example, if you have a dataset showing both temperature and humidity over time, you may want to show two y-axes with different units for these two series. You can do this by . Follow the steps as many times as required to add as many y-axes as you need.
Project: SkyWalking (Observability and Analysis / Observability)
File: dynamic-config-etcd.md

is also supported as a Dynamic Configuration Center (DCC). To use it, please configure it as follows: ```yaml configuration: selector: ${SW_CONFIGURATION:etcd} etcd: period: ${SWCONFIGETCD_PERIOD:60} # Unit seconds, sync period. Default fetch every 60 seconds. endpoints: ${SWCONFIGETCD_ENDPOINTS:http://localhost:2379} namespace: ${SWCONFIGETCD_NAMESPACE:/skywalking} authentication: ${SWCONFIGETCD_AUTHENTICATION:false} user: ${SWCONFIGETCD_USER:} password: ${SWCONFIGETCD_password:} ``` NOTE: Since 8.7.0, only the v3 protocol is supported. Single configs in etcd are key/value pairs: | Key | Value | |--|--| | {namespace}/configKey | configValue | e.g. The config is: ``` {agent-analyzer.default.slowDBAccessThreshold}:{default:200,mongodb:50} ``` If `namespace = /skywalking` the config in etcd is: | Key | Value | |--|--| | /skywalking/agent-analyzer.default.slowDBAccessThreshold | default:200,mongodb:50 | | ... | ... | Group config in etcd are key/value pairs as well, and the key is composited by configKey and subItemKey with `/`. | Key | Value | |--|--| | {namespace}/configKey/subItemkey1 | subItemValue1 | | {namespace}/configKey/subItemkey2 | subItemValue2 | | ... | ... | e.g. The config is: ``` {core.default.endpoint-name-grouping-openapi}:|{customerAPI-v1}:{value of customerAPI-v1} |{productAPI-v1}:{value of productAPI-v1} |{productAPI-v2}:{value of productAPI-v2} ``` If `namespace = /skywalking` the config in etcd is: | Key | Value | |--|--| | /skywalking/core.default.endpoint-name-grouping-openapi/customerAPI-v1 | value of customerAPI-v1 | | /skywalking/core.default.endpoint-name-grouping-openapi/productAPI-v1 | value of productAPI-v1 | | /skywalking/core.default.endpoint-name-grouping-openapi/productAPI-v2 | value of productAPI-v2 |
Project: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_configMap.ConfigMap.md

title: "Class: ConfigMap" linkTitle: "ConfigMap" slug: "libk8sconfigMap.ConfigMap" .ConfigMap `any` `ConfigMap` new ConfigMap(`json`) | Name | Type | | : | : | | `json` | | makeKubeObject<KubeConfigMap\>('configMap').constructor `Static` apiEndpoint: `Object` | Name | Type | | : | : | | `scale?` | { `get`: (`namespace`: `string`, `name`: `string`, `clusterName?`: `string`) => `Promise`<`any`\> ; `put`: (`body`: { `metadata`: ; `spec`: { `replicas`: `number` } }, `clusterName?`: `string`) => `Promise`<`any`\> } | | `scale.get` | (`namespace`: `string`, `name`: `string`, `clusterName?`: `string`) => `Promise`<`any`\> | | `scale.put` | (`body`: { `metadata`: ; `spec`: { `replicas`: `number` } }, `clusterName?`: `string`) => `Promise`<`any`\> | _ `Static` className: `string` makeKubeObject<KubeConfigMap\>('configMap').className `get` data(): `any` `any` `Static` apiList(`onList`, `onError?`, `opts?`): `any` | Name | Type | | : | : | | `onList` | (`arg`: `any`[]) => `void` | | `onError?` | (`err`: ) => `void` | | `opts?` | | `any` makeKubeObject<KubeConfigMap\>('configMap').apiList _ `Static` `Optional` getAuthorization(`arg`, `resourceAttrs?`): `any` | Name | Type | | : | : | | `arg` | `string` | | `resourceAttrs?` | | `any` makeKubeObject<KubeConfigMap\>('configMap').getAuthorization _ `Static` getErrorMessage(`err?`): ``null`` \| `string` | Name | Type | | : | : | | `err?` | ``null`` \| | ``null`` \| `string` makeKubeObject<KubeConfigMap\>('configMap').getErrorMessage _ `Static` useApiGet(`onGet`, `name`, `namespace?`, `onError?`): `void` | Name | Type | | : | : | | `onGet` | (...`args`: `any`) => `void` | | `name` | `string` | | `namespace?` | `string` | | `onError?` | (`err`: ) => `void` | `void` makeKubeObject<KubeConfigMap\>('configMap').useApiGet _ `Static` useApiList(`onList`, `onError?`, `opts?`): `any` | Name | Type | | : | : | | `onList` | (`arg`: `any`[]) => `void` | | `onError?` | (`err`: ) => `void` | | `opts?` | | `any` makeKubeObject<KubeConfigMap\>('configMap').useApiList _ `Static` useGet(`name`, `namespace?`): , (`item`: `any`) => `void`, (`err`: ``null`` \| ) => `void`] | Name | Type | | : | : | | `name` | `string` | | `namespace?` | `string` | , (`item`: `any`) => `void`, (`err`: ``null`` \| ) => `void`] makeKubeObject<KubeConfigMap\>('configMap').useGet _ `Static` useList(`opts?`): , (`items`: `any`) => `void`] | Name | Type | | : | : | | `opts?` | | , (`items`: `any`) => `void`] makeKubeObject<KubeConfigMap\>('configMap').useList
Project: Cortex (Observability and Analysis / Observability)
File: learn-more.md

title: "Learn more" linkTitle: "Learn more" weight: 100 slug: learn-more In this page we're listing some external resources to learn more about the Cortex blocks storage. <iframe width="560" height="315" src="https://www.youtube.com/embed/Z5OJzRogAS4" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> (Oct 2020) (Oct 2020) (Aug 2020) (Jul 2020)
Project: gocrane (Observability and Analysis / Continuous Optimization)
File: bug_report.md

name: Bug report about: Create a report to help us improve title: '' labels: kind/bug assignees: '' Describe the bug Reproduce steps Expected behavior Screenshots Environment (please complete the following information): K8S Version: [e.g. 1.19] Crane Version: [e.g. 0.1.0] Browser [e.g. chrome, safari]
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: k6-load-test.md

| title | authors | creation-date | last-updated | | -- | -- | - | | | Adding a New Chaos Fault - Load Testing with k6 | | 2023-11-23 | 2023-11-23 | - - is an open-source load testing tool managed by . It supports various types of load tests, is easy to use(simply write js script), and is fully open-source. So I want to add a new chaos fault(k6 load test) to Litmus ChaosHub. Litmus ChaosHub has plenty of Chaos Faults. And we already have and . But These do not cover all of Load testing. k6 supports many types of load testing such as smoke testing and stress testing. You can check all types in this . Plus, this open-source is already mature, with 22k GitHub stars and a strong community with robust use cases. Adding 'k6 load testing' Chaos Fault in ChaosHub can help create a more resilient system. Adding a 'k6 load testing' Chaos Fault to Fixing and codes Fixing k6 codes is a non-goal Using is a non-goal Fixing Litmus codes except for and is a non-goal In Chaos Studio, Users can select 'k6 load testing' Chaos Fault as part of the Chaos Experiment. They can compose it with other Chaos Faults. Here's a Chaos Fault Scenario. I will use `litmuschaos/go-runner` image. So I am going to add a new case in the litmus-go repository. After Phase 1 PR gets merged, I will raise a PR that adds a 'k6 load testing' Chaos Fault to the `chaos-charts` repository. When all is done, the user can easily use k6 in Chaos Studio. We need to grant proper RBAC permissions to the runner container. Granting override permissions may affect other systems. As I mentioned earlier, we already have and . If we adopt k6, we can test not only in the pod, and node layer but also service, load-balancer, or any layer that has ip. can be a alternative. it supports python script based load testing. I prefer k6 over locust because k6 supports more load testing types and has cloud-native open-source integrations like Prometheus and Grafana.
Project: Netdata (Observability and Analysis / Observability)
File: beanstalk_tube_buried_jobs.md

This alert monitors the number of buried jobs in each beanstalkd tube. If you receive this alert, it means that there are jobs that have been buried, and you need to investigate the cause. The warning threshold is set at more than zero buried jobs, and the critical threshold is set at more than ten buried jobs. In Beanstalkd, buried jobs are jobs that were moved to the buried state deliberately or jobs that have failed repeatedly. They're kept in a separate queue and will not be processed by workers until they're explicitly handled or deleted. Check the Beanstalkd logs for any errors or pertinent information related to the buried jobs. You can find the logs in the `/var/log/beanstalkd.log` file (the default log file location) or any other custom location defined for Beanstalkd. Use the `beanstalk-console` or a similar tool to inspect the buried jobs to determine their causes. You can download `beanstalk-console` . Review the applications or workers that are interacting with the affected tubes to find any possible issues or bugs. If the buried jobs are blocking the processing of other jobs, consider moving them to another tube with higher priority or increase the number of workers processing the tube. If the buried jobs are safe to delete or requeue, do so to clear the count and alleviate the alert. You can use the following commands to kick or delete jobs using the `beanstalk-cli`: ``` beanstalk-cli kick-job [<job-id>] beanstalk-cli delete-job [<job-id>] ``` If none of the steps above help mitigate the issue, consider contacting the sysadmin or developers of the application using Beanstalkd.
Project: Infracost (Observability and Analysis / Continuous Optimization)
File: README.md

This folder contains legacy CI scripts that are no longer maintained by the Infracost team. These script have been replaced by dedicated integrations with most CI/CD platforms, which we recommend you upgrade to: Please visit for other CI/CD integrations and more information. These scripts will be removed September 2022. If you are pulling them directly from this repository and cannot upgrade before then, we recommend you keep a copy in your own repositories.
Project: M3 (Observability and Analysis / Observability)
File: docker_cluster.md

linktitle: "Docker" weight: 3 draft: true This guide shows you the steps involved in creating an M3 cluster using Docker containers, typically you would automate this with infrastructure as code tools such as Terraform or Kubernetes. {{% notice note %}} This guide assumes you have read the , and builds upon the concepts in that guide. {{% /notice %}} Here's a typical M3 deployment: <!-- TODO: Update image --> An M3 deployment typically has two main node types: Coordinator node: `m3coordinator` nodes coordinate reads and writes across all nodes in the cluster. It's a lightweight process, and does not store any data. This role typically runs alongside a Prometheus instance, or is part of a collector agent. Storage node: The `m3dbnode` processes are the workhorses of M3, they store data and serve reads and writes. And exposes two ports: `7201` to manage the cluster topology, you make most API calls to this endpoint `7203` for Prometheus to scrape the metrics produced by M3DB and M3Coordinator M3 uses as a distributed key-value storage for the following functions: Update cluster configuration in realtime Manage placements for distributed and sharded clusters {{% notice note %}} M3 storage nodes have an embedded etcd server you can use for small test clusters which we call a Seed Node when run this way. See the `etcdClusters` section of . {{% /notice %}} You can download the latest release as . Inside the expanded archive are binaries for `m3dbnode`, which combines a coordinator and storage node, and a binary for `m3coordinator`, which is a standalone coordinator node.
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-9-1-6.md

aliases: [] hide_menu: true labels: products: cloud enterprise oss title: Release notes for Grafana 9.1.6 <!-- Auto generated by update changelog github action --> Auth: Trigger auth token cleanup job. (Enterprise) DataSource: Adding possibility to hide queries from the inspector. , Inspect: Hide Actions tab when it is empty. , PanelMenu: Remove hide legend action as it was showing on all panel types. , Provisioning Contact points: Support disableResolveMessage via YAML. , PublicDashboards: Support subpaths when generating pubdash url. , Alerting: Fix legacy migration crash when rule name is too long. , Alerting: Fix send resolved notifications. , Azure Monitor: Fix migration issue with MetricDefinitionsQuery template variable query types. , Browse: Hide dashboard actions if user does not have enough permission. , ElasticSearch: Fix dispatching queries at a wrong time. , Panel: Disable legends when showLegend is false prior to schema v37. , Prometheus: Fix metadata requests for browser access mode. , Search: Avoid requesting all dashboards when in Folder View. , TablePanel/StatPanel: Fix values not being visible when background transparent. ,
Project: Vector (Observability and Analysis / Observability)
File: 2020-02-24-rename-fields-transform.md

date: "2020-04-13" title: "New Rename Fields Transform" description: "An easier way to rename fields" authors: ["binarylogic"] pr_numbers: [1800] release: "0.8.0" hideonrelease_notes: false badges: type: "new feature" domains: ["transforms"] transforms: ["rename_fields"] Vector has a long overdue . This does exactly what it says, rename fields :).
Project: Botkube (Observability and Analysis / Observability)
File: mattermost-help.golden.md

Basic commands `@Botkube ping` - ping your cluster and check its status `@Botkube list [source|executor|action|alias]` - list available plugins and features `@Botkube ping` `@Botkube list sources` `@Botkube list executors` Notifications `@Botkube [enable|disable|status] notifications` - set or query your notification status `@Botkube edit sourcebindings` - select notification sources for this channel `@Botkube enable notifications` `@Botkube disable notifications` `@Botkube status notifications` Run kubectl commands (if enabled) `@Botkube kubectl help` Multi-cluster mode If you have multiple clusters configured for this channel, specify the cluster name when typing commands. ``` --cluster-name=Stage US ``` Other features Automation: https://docs.botkube.io/usage/automated-actions Give feedback: https://feedback.botkube.io Read our docs: https://docs.botkube.io Join our Slack: https://join.botkube.io Follow us on Twitter/X: https://twitter.com/botkube_io
Project: Elastic (Observability and Analysis / Observability)
File: trim.md

<!-- This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it. --> Removes leading and trailing whitespaces from a string. ``` ROW message = " some text ", color = " red " | EVAL message = TRIM(message) | EVAL color = TRIM(color) ```