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

PostgreSQL JDBC driver uses version 42.3.2. It supports PostgreSQL 8.2 or newer. Activate PostgreSQL as storage, and set storage provider to postgresql. ```yaml storage: selector: ${SW_STORAGE:postgresql} postgresql: properties: jdbcUrl: ${SWJDBCURL:"jdbc:postgresql://localhost:5432/skywalking"} dataSource.user: ${SWDATASOURCE_USER:postgres} dataSource.password: ${SWDATASOURCE_PASSWORD:123456} dataSource.cachePrepStmts: ${SWDATASOURCECACHEPREP_STMTS:true} dataSource.prepStmtCacheSize: ${SWDATASOURCEPREPSTMTCACHESQL_SIZE:250} dataSource.prepStmtCacheSqlLimit: ${SWDATASOURCEPREPSTMTCACHESQL_LIMIT:2048} dataSource.useServerPrepStmts: ${SWDATASOURCEUSESERVERPREPSTMTS:true} metadataQueryMaxSize: ${SWSTORAGEMYSQLQUERYMAX_SIZE:5000} maxSizeOfArrayColumn: ${SWSTORAGEMAXSIZEOFARRAYCOLUMN:20} numOfSearchableValuesPerTag: ${SWSTORAGENUMOFSEARCHABLEVALUESPER_TAG:2} maxSizeOfBatchSql: ${SWSTORAGEMAXSIZEOFBATCHSQL:2000} asyncBatchPersistentPoolSize: ${SWSTORAGEASYNCBATCHPERSISTENTPOOLSIZE:4} ``` All connection-related settings, including URL link, username, and password, are found in `application.yml`. Only part of the settings is listed here. Please follow connection pool document for full settings.
Project: Sensu (Observability and Analysis / Observability)
File: PULL_REQUEST_TEMPLATE.md

<!-- A brief one-sentence-ish description of the change. --> <!-- A brief description of why the change of behavior is necessary. --> <!-- Spoiler alert, it probably does. Generally speaking, your change needs a changelog. For more information, see . --> <!-- Is there anything the reviewer should specifically look at? Are you unsure of any portion of this change? Omit if not applicable. --> <!-- If anything went awry while working on this change or if you ran into systemic issues preventing progress, please leave feedback on those issues here. Examples might include: refactoring was required interfaces were unclear it was difficult to get the information you needed to complete the issue Feel free to edit this portion of the PR once the review is complete to add any comments about the review process itself. --> <!-- Read any documentation that relates to the change you're making. If it needs updating, update it and file a PR. The PR should be linked to this PR or the original issue. --> <!-- Aside from unit/integration tests, please describe the e2e steps to verify this change. Eng@Sensu: Add the test case to the TestRail QA plan, and write an automated Rspec test, if applicable. The corresponding sensu-go-qa-crucible PR or issue should be linked here. --> <!-- If so, you should be submitting this against the current release branch. Remember to merge the release branch back into main after merging this patch! If not, this feature work can go directly into the main branch. -->
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: disk_buffer.md

title: Syslog-ng DiskBuffer weight: 200 generated_file: true More info at https://www.syslog-ng.com/technical-documents/doc/syslog-ng-open-source-edition/3.37/administration-guide/32#kanchor2338 Documentation: https://www.syslog-ng.com/technical-documents/doc/syslog-ng-open-source-edition/3.37/administration-guide/56#TOPIC-1829124 This is a required option. The maximum size of the disk-buffer in bytes. The minimum value is 1048576 bytes. Default: - If set to yes, syslog-ng OSE cannot lose logs in case of reload/restart, unreachable destination or syslog-ng OSE crash. This solution provides a slower, but reliable disk-buffer option. Default: - Prunes the unused space in the LogMessage representation Default: - Description: Defines the folder where the disk-buffer files are stored. Default: - Use this option if the option reliable() is set to no. This option contains the number of messages stored in overflow queue. Default: - Use this option if the option reliable() is set to yes. This option contains the size of the messages in bytes that is used in the memory part of the disk buffer. Default: - The number of messages stored in the output buffer of the destination. Default: -
Project: Netdata (Observability and Analysis / Observability)
File: kubelet_1m_pleg_relist_latency_quantile_09.md

This alert calculates the average Pod Lifecycle Event Generator (PLEG) relisting latency over the period of one minute, using the 0.9 quantile. This alert is related to Kubelet, a critical component in the Kubernetes cluster that ensures the correct running of containers inside pods. If you receive this alert, it means that the relisting latency has increased in your Kubernetes cluster, possibly affecting the performance of your workloads. In Kubernetes, PLEG is responsible for keeping track of container lifecycle events, such as container start, stop, or pause. It periodically relists these events and updates the Kubernetes Pod status, ensuring the scheduler and other components know the correct state of the containers. An increased relisting latency could lead to slower updates on Pod status and overall degraded performance. The 0.9 quantile represents the value below which 90% of the latencies are. An alert based on the 0.9 quantile suggests that 90% of relisting latencies are below the specified threshold, meaning that the remaining 10% are experiencing increased latency, which could lead to issues in your cluster. Check Kubelet logs for errors or warnings related to PLEG: Access the logs of the Kubelet component running on the affected node: ``` sudo journalctl -u kubelet ``` Monitor the overall performance of your Kubernetes cluster: Use `kubectl top nodes` to check the resource usage of your nodes and identify any bottlenecks, such as high CPU or memory consumption. Check the status of Pods: Use `kubectl get pods --all-namespaces` to check the status of all Pods in your cluster. Look for Pods in an abnormal state (e.g., Pending, CrashLoopBackOff, or Terminating), which could be related to high PLEG relisting latency. Analyze Pod logs for issues: Investigate the logs of the affected Pods to understand any issues with the container lifecycle events: ``` kubectl logs <pod-name> -n <namespace> ``` Review the Kubelet configuration: Ensure that your Kubelet configuration is set up correctly to handle your workloads. If necessary, adjust the settings to improve PLEG relisting performance.
Project: Loggie (Observability and Analysis / Observability)
File: README_EN.md

This is a Golang SDK for Alibaba Cloud . API Reference : ](https://travis-ci.org/aliyun/aliyun-log-go-sdk) ](https://coveralls.io/github/aliyun/aliyun-log-go-sdk?branch=master) ``` go get github.com/aliyun/aliyun-log-go-sdk ``` `protoc -I=. -I=$GOPATH/src -I=$GOPATH/src/github.com/gogo/protobuf/protobuf --gofast_out=. log.proto`
Project: Hubble (Observability and Analysis / Observability)
File: CONTRIBUTING.md

Welcome to Kubernetes. We are excited about the prospect of you joining our ! The Kubernetes community abides by the CNCF . Here is an excerpt: As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities. We have full documentation on how to get started contributing here: <! If your repo has certain guidelines for contribution, put them here ahead of the general k8s resources --> Kubernetes projects require that you sign a Contributor License Agreement (CLA) before we can accept your pull requests - Main contributor documentation, or you can just jump directly to the - Common resources for existing developers - We have a diverse set of mentorship programs available that are always looking for volunteers! <! Custom Information - if you're copying this template for the first time you can add custom content here, for example: - Replace `kubernetes-users` with your slack channel string, this will send users directly to your channel. -->
Project: Grafana (Observability and Analysis / Observability)
File: notes.md

The API Key needed to connect to Sensu Go has to be created manually. `docker exec -it sensu-backend /bin/ash` Configure the `sensuctl` command using the pre-set username and password: ```bash sensuctl configure -n --url http://127.0.0.1:8080 --username admin --password 'Password123' --namespace default ``` Generate the API Key: ```bash sensuctl api-key grant admin ``` The output should look similar to this: ``` Created: /api/core/v2/apikeys/0a1b2c3d-4e5f-6a7b-8c9d-0e1f2a3b4c5d ``` The Backend URL is the API port (8080) forwarded to the container, it should be `http://localhost:8080` The `0a1b2c3d-4e5f-6a7b-8c9d-0e1f2a3b4c5d` in the output above is the API Key to use in configuring the Sensu Go notification channel.
Project: Elastic (Observability and Analysis / Observability)
File: sqrt.md

<!-- This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it. --> Returns the square root of a number. The input can be any numeric value, the return value is always a double. Square roots of negative numbers and infinities are null. ``` ROW d = 100.0 | EVAL s = SQRT(d) ```
Project: Checkmk (Observability and Analysis / Observability)
File: 15844.md

key | value | date | 2024-04-17T13:40:06+00:00 version | 2.3.0b6 class | feature edition | cre component | checks level | 2 compatible | no We've introduced a new `Microsoft SQL Server (Linux, Windows)` plug-in for MS SQL database monitoring, see . The new plugin extends the functionality of `Microsoft SQL Server (Windows)` by adding more options and features. We recommend that you upgrade to the `Microsoft SQL Server (Linux, Windows)` plug-in to monitor MS SQL databases. This new agent plugin can be deployed alongside the Checkmk agent on your database systems, just like the previous plugin. You can also use this plugin on any Windows or Linux server to monitor remote MSSQL servers over the network. The previous `Microsoft SQL Server (Windows)` rule set is deprecated and renamed to `Microsoft SQL Server (deprecated)`. Please note that you may need to adjust settings on your databases or continue running the old plug-in for the time being, as the agent plug-in cannot connect to local database instances that are not available over a TCP/IP connection.
Project: Elastic (Observability and Analysis / Observability)
File: greatest.md

<!-- This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it. --> Returns the maximum value from multiple columns. This is similar to <<esql-mv_max>> except it is intended to run on multiple columns at once. ``` ROW a = 10, b = 20 | EVAL g = GREATEST(a, b) ``` Note: When run on `keyword` or `text` fields, this returns the last string in alphabetical order. When run on `boolean` columns this will return `true` if any values are `true`.
Project: M3 (Observability and Analysis / Observability)
File: media.md

title: "Media" weight: 3 By Rob Skillington - Aug 7, 2018. By Nikunj Aggarwal and Ben Raskin - Dec 10, 2018. Recordings of all past meetups can be found on a . . . . . By Gibbs Cullen, October 2020. By Ryan Allen. By Rob Skillington & Gibbs Cullen By Shreyas Srivatsan. . By Matt Schallert. Aug 27, 2020. By Ryan Allen - Aug 6, 2020. By Matt Schallert. By Matt Schallert - Jul 18, 2019. By Martin Mao - June 5, 2019. Explains M3 Aggregator: Motivation (problems it aims to solve), the different implementations M3 went through to get to the current implementation, and a brief high level architecture, in 30min. By Rob Skillington - May 22, 2019. By Matt Schallert & Paul Schooss - Mar 11, 2019. By Rob Skillington - Feb 3, 2019. By Celina Ward & Matt Schallert - Dec 13, 2018. By Martin Mao - Dec 10, 2018. By Rob Skillington - Nov 5, 2018. By Richard Artoul & Prateek Rungta - Nov 4, 2018. by Nikunj Aggarwal - Aug 9, 2018. including highlights of the M3 stack by Nikunj Aggarwal - Aug 9, 2018. By Prateek Rungta - Jun 6, 2018.
Project: Weave Scope (Observability and Analysis / Observability)
File: fuzzy_mode_convert_table.md

| json type \ dest type | bool | int | uint | float |string| | | | | |--|--| | number | positive => true <br/> negative => true <br/> zero => false| 23.2 => 23 <br/> -32.1 => -32| 12.1 => 12 <br/> -12.1 => 0|as normal|same as origin| | string | empty string => false <br/> string "0" => false <br/> other strings => true | "123.32" => 123 <br/> "-123.4" => -123 <br/> "123.23xxxw" => 123 <br/> "abcde12" => 0 <br/> "-32.1" => -32| 13.2 => 13 <br/> -1.1 => 0 |12.1 => 12.1 <br/> -12.3 => -12.3<br/> 12.4xxa => 12.4 <br/> +1.1e2 =>110 |same as origin| | bool | true => true <br/> false => false| true => 1 <br/> false => 0 | true => 1 <br/> false => 0 |true => 1 <br/>false => 0|true => "true" <br/> false => "false"| | object | true | 0 | 0 |0|originnal json| | array | empty array => false <br/> nonempty array => true| [] => 0 <br/> [1,2] => 1 | [] => 0 <br/> [1,2] => 1 |[] => 0<br/>[1,2] => 1|original json|
Project: SkyWalking (Observability and Analysis / Observability)
File: Unexpected-endpoint-register.md

Since version 6.6.0, SkyWalking has removed the local and exit span registers. If an old java agent (before 6.6.0) is still running, which registers to the 6.6.0+ backend, you will face the following warning message. ``` class=RegisterServiceHandler, message = Unexpected endpoint register, endpoint isn't detected from server side. ``` This will not harm the backend or cause any issues, but serves as a reminder that your agent or other clients should follow the new protocol requirements. You could simply use `log4j2.xml` to filter this warning message out.
Project: Vector (Observability and Analysis / Observability)
File: 2020-01-20-splunk-hec-specify-indexed-fields.md

date: "2020-07-13" title: "The `splunk_hec` sink does not index fields by default" description: "This gives you full control over which fields are indexed" authors: ["binarylogic"] pr_numbers: [1537] release: "0.7.0" hideonrelease_notes: false badges: type: "breaking change" domains: ["sinks"] sinks: ["splunk_hec"] There is no longer a distinction within Vector between explicit and implicit event fields. All fields are now implicit and therefore the `splunk_hec` sink will not index any fields by default. In order to mark desired fields as indexed you can use the optional configuration option `indexed_fields`: ```toml title="vector.toml" [sinks.mysinkid] type = "splunk_hec" inputs = ["my-source-id"] indexed_fields = ["foo", "bar"] ```
Project: Kepler (Observability and Analysis / Observability)
File: SNAPSHOT.md

For ghw, snapshots are partial clones of the `/proc`, `/sys` (et. al.) subtrees copied from arbitrary machines, which ghw can consume later. "partial" is because the snapshot doesn't need to contain a complete copy of all the filesystem subtree (that is doable but inpractical). It only needs to contain the paths ghw cares about. The snapshot concept was introduced . The recommended way to create snapshots for ghw is to use the `ghw-snapshot` tool. This tool is maintained by the ghw authors, and snapshots created with this tool are guaranteed to work. To consume the ghw snapshots, please check the `README.md` document. The remainder of this document will describe how a snapshot looks like and provides rationale for all the major design decisions. Even though this document aims to provide all the necessary information to understand how ghw creates snapshots and what you should expect, we recommend to check also the and the `git` history to have the full picture. ghw supports snapshots only on linux platforms. This restriction may be lifted in future releases. Snapshots must be consumable in the following supported ways: (way 1) from docker (or podman), mounting them as volumes. See `hack/run-against-snapshot.sh` (way 2) using the environment variables `GHWSNAPSHOT*`. See `README.md` for the full documentation. Other combinations are possible, but are unsupported and may stop working any time. You should depend only on the supported ways to consume snapshots. Stemming from the use cases, the snapshot content must have the following properties: (constraint 0) MUST contain the same information as live system (obviously). Whatever you learn from a live system, you MUST be able to learn from a snapshot. (constraint 1) MUST NOT require any post processing before it is consumable besides, obviously, unpacking the `.tar.gz` on the right directory - and pointing ghw to that directory. (constraint 2) MUST NOT require any special handling nor special code path in ghw. From ghw perspective running against a live system or against a snapshot should be completely transparent. (constraint 3) MUST contain only data - no executable code is allowed ever. This makes snapshots trivially safe to share and consume. (constraint 4) MUST NOT contain any personally-identifiable data. Data gathered into a snapshot is for testing and troubleshooting purposes and should be safe to send to troubleshooters to analyze. It must be noted that trivially cloning subtrees from `/proc` and `/sys` and creating a tarball out of them doesn't work because both pseudo filesystems make use of symlinks, and . This conflcits with (way 1) above.
Project: Netdata (Observability and Analysis / Observability)
File: load_average_15.md

This alarm calculates the system `load average` (CPU and I/O demand) over the period of fifteen minutes. If you receive this alarm, it means that your system is "overloaded." The alert gets raised into warning if the metric is 2 times the expected value and cleared if the value is 1.75 times the expected value. For further information on how our alerts are calculated, please have a look at our . The term `system load average` on a Linux machine, measures the number of threads that are currently working and those waiting to work (CPU, disk, uninterruptible locks). So simply stated: System load average measures the number of threads that aren't idle. Let's look at a single core CPU system and think of its core count as car lanes on a bridge. A car represents a process in this example: On a 0.5 load average, the traffic on the bridge is fine, it is at 50% of its capacity. If the load average is at 1, then the bridge is full, and it is utilized 100%. If the load average gets to 2 (remember we are on a single core machine), it means that there is one car lane that is passing the bridge. However, there is another full car lane that waits to pass the bridge. So this is how you can imagine CPU load, but keep in mind that `load average` counts also I/O demand, so there is an analogous example there. Determine if the problem is CPU load or I/O load To get a report about your system statistics, use `vmstat` (or `vmstat 1`, to set a delay between updates in seconds): The `procs` column, shows: r: The number of runnable processes (running or waiting for run time). b: The number of processes blocked waiting for I/O to complete. Check per-process CPU/disk usage to find the top consumers To see the processes that are the main CPU consumers, use the task manager program `top` like this: ``` top -o +%CPU -i ``` Use `iotop`: `iotop` is a useful tool, similar to `top`, used to monitor Disk I/O usage, if you don't have it, then ``` sudo iotop ``` Minimize the load by closing any unnecessary main consumer processes. We strongly advise you to double-check if the process you want to close is necessary.
Project: SkyWalking (Observability and Analysis / Observability)
File: How-to-build-with-mac-m1.md

When compiling according to , The following problems may occur, causing the build to fail. ``` [ERROR] Failed to execute goal org.xolstice.maven.plugins:protobuf-maven-plugin:0.6.1:compile (grpc-build) on project apm-network: Unable to resolve artifact: Missing: [ERROR] - [ERROR] 1) com.google.protobuf:protoc:exe:osx-aarch_64:3.12.0 [ERROR] [ERROR] Try downloading the file manually from the project website. [ERROR] [ERROR] Then, install it using the command: [ERROR] mvn install:install-file -DgroupId=com.google.protobuf -DartifactId=protoc -Dversion=3.12.0 -Dclassifier=osx-aarch_64 -Dpackaging=exe -Dfile=/path/to/file [ERROR] [ERROR] Alternatively, if you host your own repository you can deploy the file there: [ERROR] mvn deploy:deploy-file -DgroupId=com.google.protobuf -DartifactId=protoc -Dversion=3.12.0 -Dclassifier=osx-aarch_64 -Dpackaging=exe -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] [ERROR] [ERROR] Path to dependency: [ERROR] 1) org.apache.skywalking:apm-network:jar:8.4.0-SNAPSHOT [ERROR] 2) com.google.protobuf:protoc:exe:osx-aarch_64:3.12.0 [ERROR] [ERROR] - [ERROR] 1 required artifact is missing. ``` The dependent Protocol Buffers v3.14.0 does not come with an osx-aarch64 version. You may find the osx-aarch64 version at the Protocol Buffers Releases link here: https://github.com/protocolbuffers/protobuf/releases. Since Mac's M1 is compatible with the osx-x8664 version, before this version is available for downloading, you need to manually specify the osx-x8664 version. You may add -Dos.detected.classifier=osx-x8664 after the original compilation parameters, such as: `./mvnw clean package -DskipTests -Dos.detected.classifier=osx-x8664`. After specifying the version, compile and run normally.
Project: Headlamp (Observability and Analysis / Observability)
File: plugin_registry.ScaleResourceEvent.md

title: "Interface: ScaleResourceEvent" linkTitle: "ScaleResourceEvent" slug: "plugin_registry.ScaleResourceEvent" .ScaleResourceEvent Event fired when scaling a resource. data: `Object` | Name | Type | Description | | : | : | : | | `resource` | `any` | The resource for which the deletion was called. | | `status` | `CONFIRMED` | What exactly this event represents. 'CONFIRMED' when the scaling is selected by the user. For now only 'CONFIRMED' is sent. | _ type: `SCALE_RESOURCE`