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

The uninstrumented gateways are not instrumented by the SkyWalking agent plugin when they start, but they can be configured in `gateways.yml` file or via . The reason why they can't register to backend automatically is that there are no suitable agent plugins. For example, there are no agent plugins for Nginx, HAProxy, etc. So to visualize the real topology, we provide a way to configure the gateways/proxies manually. The configuration content includes gateway names and their instances: ```yml gateways: name: proxy0 # the name is not used for now instances: host: 127.0.0.1 # the host/IP of this gateway instance port: 9099 # the port of this gateway instance defaults to 80 ``` Note: The `host` of the instance must be the one that is actually used on the client-side. For example, if instance `proxyA` has 2 IPs, say `192.168.1.110` and `192.168.1.111`, both of which delegate the target service, and the client connects to `192.168.1.110`, then configuring `192.168.1.111` as the `host` won't work properly.
Project: Grafana Mimir (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: Headlamp (Observability and Analysis / Observability)
File: lib_k8s_service.KubeService.md

title: "Interface: KubeService" linkTitle: "KubeService" slug: "libk8sservice.KubeService" .KubeService `KubeService` `Optional` apiVersion: `string` . _ kind: `string` Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. In CamelCase. Cannot be updated. `see` . _ metadata: . _ spec: `Object` | Name | Type | | : | : | | `clusterIP` | `string` | | `externalIPs` | `string`[] | | `ports` | { `name`: `string` ; `nodePort`: `number` ; `port`: `number` ; `protocol`: `string` ; `targetPort`: `string` \| `number` }[] | | `selector` | { `[key: string]`: `string`; } | | `type` | `string` | _ status: `Object` | Name | Type | | : | : | | `conditions?` | [] | | `loadBalancer?` | { `ingress`: [] } | | `loadBalancer.ingress` | [] |
Project: Vector (Observability and Analysis / Observability)
File: 2020-02-21-file-source-multiline-support.md

date: "2020-04-14" title: "Improved Multiline Support In The File Source" description: "Merge multiple lines together based on rules" authors: ["binarylogic"] pr_numbers: [1852] release: "0.8.0" hideonrelease_notes: false badges: type: "enhancement" domains: ["sources"] sources: ["file"] One of the biggest frustrations we've heard from users in this space is the inability to merge lines together. Such a simple task can be incredibly complex and hard. Fear not! We plan to add first-class support for solving this problem. In addition to the recently added [automatic merging of Docker logs][docs.sources.dockerlogs#autopartial_merge], we also added [better multi-line support]. These options are very expressive and should solve the vast majority of multi-line merging problems. For example. Given the following lines: ```text foobar.rb:6:in `/': divided by 0 (ZeroDivisionError) from foobar.rb:6:in `bar' from foobar.rb:2:in `foo' from foobar.rb:9:in `<main>' ``` You can merge them with the following config: ```toml title="vector.toml" [sources.myfilesource] type = "file" [sources.myfilesource.multiline] start_pattern = "^[^\\s]" mode = "continue_through" condition_pattern = "^[\\s]+from" timeout_ms = 1000 ``` And if this doesn't do it, you can always fall back to the .
Project: VictoriaMetrics (Observability and Analysis / Observability)
File: RELEASE.md

The `klog` is released on an as-needed basis. The process is as follows: An issue is proposing a new release with a changelog since the last release All must LGTM this release An OWNER runs `git tag -s $VERSION` and inserts the changelog and pushes the tag with `git push $VERSION` The release issue is closed An announcement email is sent to `kubernetes-dev@googlegroups.com` with the subject `[ANNOUNCE] kubernetes-template-project $VERSION is released`
Project: SkyWalking (Observability and Analysis / Observability)
File: CONTRIBUTING.md

Firstly, thanks for your interest in contributing! I hope that this will be a pleasant first experience for you, and that you will return to continue contributing. This project and everyone participating in it is governed by the Apache software Foundation's . By participating, you are expected to adhere to this code. If you are aware of unacceptable behavior, please visit the and follow the instructions there. Most of the contributions that we receive are code contributions, but you can also contribute to the documentation or simply report solid bugs for us to fix. Ensure the bug was not already reported* by searching on GitHub under . If you're unable to find an open issue addressing the problem, . Be sure to include a title and clear description, as much relevant information as possible, and a code sample or an executable test case* demonstrating the expected behavior that is not occurring. Before making any significant changes, please . Discussing your proposed changes ahead of time will make the contribution process smooth for everyone. Once we've discussed your changes and you've got your code ready, make sure that tests are passing and open your pull request. Your PR is most likely to be accepted if it: Update the README.md with details of changes to the interface. Includes tests for new functionality. References the original issue in description, e.g. "Resolves #123". Has a . Join `#skywalking` channel at
Project: Grafana Pyroscope (Observability and Analysis / Observability)
File: self-vs-total.md

title: Understand 'self' vs. 'total' metrics in profiling with Pyroscope menuTitle: Understand 'self' vs. 'total' metrics description: Learn the differences between 'self' and 'total' metrics in profiling and their specific applications in CPU and Memory profiling with Pyroscope. weight: 42 aliases: ../ingest-and-analyze-profile-data/self-vs-total/ keywords: pyroscope cpu profiling memory profiling self vs total performance analysis Profiling in Pyroscope provides many different ways of analyzing your profiling data. One of the key pieces of this analysis are the metrics 'self' and 'total', whose understanding is key for accurate interpretation of profiling data in both CPU and memory contexts. These metrics can be seen both within the table and the flame graph view of the UI. 'Self' refers to the resource usage (CPU time, memory allocation, etc.) directly attributed to a specific function or a code segment, excluding the resources used by its sub-functions or calls This metric helps isolate the direct impact of a specific code block, making it crucial for pinpointing primary resource consumers 'Total' encompasses the combined resource usage of a function along with all the functions it calls It provides a holistic view of a function's overall resource consumption, essential for understanding cumulative impacts In CPU profiling, 'self' indicates the CPU time consumed directly by the function, crucial for identifying functions with high CPU demand. The 'total' CPU time includes time spent in the function itself plus time in all called functions, highlighting comprehensive CPU usage The example below demonstrates a simplified pseudocode representation of a CPU-intensive process. This illustrates how 'self' and 'total' time would be calculated for different functions in a typical application. The following diagram provides a visual representation of these concepts. ```python def handle_request(): parse_json() process_data() def parse_json(): validate() def validate(): def process_data(): apply() def apply(): handle_request() ``` Self in Memory: For memory profiling, 'self' measures the memory allocated by the function itself, vital for detecting direct memory allocation issues. Total in Memory: 'Total' memory includes allocations by the function and it's called functions, essential for assessing overall memory footprint. The same example from the CPU profiling section can be used to illustrate the concepts of 'self' and 'total' in memory profiling, just with memory units instead of CPU. Grasping the distinction between 'self' and 'total' metrics is fundamental for effective performance analysis in Pyroscope. Whether in CPU or memory profiling (or any other type), these metrics provide value insights for optimizing applications and enhancing their efficiency and reliability.
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-user_get_teams.md

category: User apiurl: '/api/v1/user/u/:uid/teams' title: 'Get user teams' type: 'GET' sample_doc: 'user.html' layout: default Required ex. /api/v1/user/u/4/teams ```Status: 200``` ```{"teams": [{ "id":3, "name":"root", "resume":"", "creator":5}, {"id":32, "name":"testteam", "resume":"test22", "creator":5 }] } ``` For more example, see the . For errors responses, see the .
Project: Krkn (Observability and Analysis / Chaos Engineering)
File: getting_started.md

Adding a new scenario is as simple as adding a new config file under and defining it in the main kraken . You can either copy an existing yaml file and make it your own, or fill in one of the templates below to suit your needs. For example, for adding a pod level scenario for a new application, refer to the sample scenario below to know what fields are necessary and what to add in each location: ``` id: kill-pods config: namespace_pattern: ^<namespace>$ label_selector: <pod label> kill: <number of pods to kill> krknpodrecovery_time: <expected time for the pod to become ready> ``` ``` node_scenarios: actions: # Node chaos scenarios to be injected. <chaos scenario> <chaos scenario> node_name: <node name> # Can be left blank. label_selector: <node label> instancekillcount: <number of nodes on which to perform action> timeout: <duration to wait for completion> cloud_type: <cloud provider> ``` ``` time_scenarios: action: 'skewtime' or 'skewdate' object_type: 'pod' or 'node' label_selector: <label of pod or node> ``` If you just want to make small changes to pre-existing scenarios, feel free to edit the scenario file itself. If you want to kill 2 pods instead of 1 in any of the pre-existing scenarios, you can either edit the number located at filters -> randomSample -> size or the runs under the config -> runStrategy section. If your cluster is build on GCP instead of AWS, just change the cloud type in the nodescenariosexample.yml file.
Project: DeepFlow (Observability and Analysis / Observability)
File: how-to-profile-agent.md

Always use agent compiled with debug on to profile if possible, because it will provide more info in stack trace. Use the following command to compile agent: CARGOPROFILERELEASE_DEBUG=true cargo build --release Optional: Compress the binary for smaller size. is used to profile agent cpu usage. Use the following commands to record agent cpu usage. If agent is running as a container, run these commands in the same container. pid=`ps -ef | grep deepflow-agent | grep -v grep | awk '{print $2}'` perf record -F97 --call-graph=dwarf -g -p $pid -- sleep 60 It will generate a `perf.data` in current directory. Use `perf report -g` to view call stack. Additionally, a flame graph can be generated with . git clone https://github.com/brendangregg/FlameGraph perf script | ./FlameGraph/stackcollapse-perf.pl | ./FlameGraph/flamegraph.pl > perf.svg Agent binary must be compiled with glibc to use valgrind. Start agent with the following command: valgrind --tool=massif deepflow-agent Wait for memory consumption to increase, and use these commands to capture heap usage. `vgdb snapshot` `vgdb detailed_snapshot` `vgdb all_snapshots` Use `ms_print` to view captured snapshots. The operation steps are as follows: Modify code based on Jemalloc documentation or Compile the release version of the agent and run it Run the command to download the agent profile file: curl http://127.0.0.0:30038/debug/pprof/heap -o agent.profile Generating svg files using agent profile files: jeprof --svg ./deepflow-agen ./agent.profile
Project: Netdata (Observability and Analysis / Observability)
File: idle_os_jitter.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/idlejitter.plugin/README.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/idlejitter.plugin/metadata.yaml" sidebar_label: "Idle OS Jitter" learn_status: "Published" learnrelpath: "Collecting Metrics/Synthetic Checks" most_popular: False message: "DO NOT EDIT THIS FILE DIRECTLY, IT IS GENERATED BY THE COLLECTOR'S metadata.yaml FILE" endmeta--> <img src="https://netdata.cloud/img/syslog.png" width="150"/> Plugin: idlejitter.plugin Module: idlejitter.plugin <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> Monitor delays in timing for user processes caused by scheduling limitations to optimize the system to run latency sensitive applications with minimal jitter, improving consistency and quality of service. A thread is spawned that requests to sleep for fixed amount of time. When the system wakes it up, it measures how many microseconds have passed. The difference between the requested and the actual duration of the sleep, is the idle jitter. This is done dozens of times per second to ensure we have a representative sample. This collector is supported on all platforms. This collector only supports collecting metrics from a single instance of this integration. This integration will run by default on all supported systems. The default configuration for this integration does not impose any limits on data collection. The default configuration for this integration is not expected to impose a significant performance impact on the system. Metrics grouped by scope. The scope defines the instance that the metric belongs to. An instance is uniquely identified by a set of labels. This scope has no labels. Metrics: | Metric | Dimensions | Unit | |:|:-|:-| | system.idlejitter | min, max, average | microseconds lost/s | There are no alerts configured by default for this integration. No action required. The configuration file name for this integration is `netdata.conf`. The file format is a modified INI syntax. The general structure is: ```ini [section1] option1 = some value option2 = some other value [section2] option3 = some third value ``` You can edit the configuration file using the `edit-config` script from the Netdata . ```bash cd /etc/netdata 2>/dev/null || cd /opt/netdata/etc/netdata sudo ./edit-config netdata.conf ``` This integration only supports a single configuration option, and most users will not need to change it. | Name | Description | Default | Required | |:-|:--|:-|:--:| | loop time in ms | Specifies the target time for the data collection thread to sleep, measured in miliseconds. | 20 | no | There are no configuration examples.
Project: Vector (Observability and Analysis / Observability)
File: 2020-02-24-log-data-model-changes.md

date: "2020-04-13" title: "Log Data Model Changes and Disk Buffers" description: "We're bringing our log data model closer to JSON" authors: ["binarylogic"] pr_numbers: [1836, 1898] release: "0.8.0" hideonrelease_notes: true badges: type: "breaking change" domains: ["buffers"] "event type": "log" We are currently working to improve and optimize our [`log` data model][docs.data-model.log]. Initial versions of this data model were represented as a flat map for key access optimizations. This proved over time to not be as helpful as we had hoped. As a result we are working to move our data model to be as close to JSON as possible. This means: `null` values are now supported in Vector's data model. Nested fields are represented in an actual nested representation. Both of these changes bring Vector's internal data model closer to JSON. Unfortunately, this breaks disk buffer serialization which means you must drain your disk buffer before upgrading Vector. Make sure Vector shuts down normally to ensure your disk buffers are fully drained. That's it! Update Vector as usual. Note, Vector will discard invalid disk buffer data, bad data will not prevent Vector from starting.
Project: Thanos (Observability and Analysis / Observability)
File: https.md

Thanos supports basic authentication and TLS. This is experimental and might change in the future. To specify which HTTP TLS configuration file to load, use the `--http.config` flag. The file is written in , defined by the scheme described below. Brackets indicate that a parameter is optional. For non-list parameters the value is set to the specified default. The file is read upon every http request, such as any change in the configuration and the certificates is picked up immediately. Generic placeholders are defined as follows: `<boolean>`: a boolean that can take the values `true` or `false` `<filename>`: a valid path in the current working directory `<secret>`: a regular string that is a secret, such as a password `<string>`: a regular string ```yaml tlsserverconfig: cert_file: <filename> key_file: <filename> [ clientauthtype: <string> | default = "NoClientCert" ] [ clientcafile: <filename> ] [ min_version: <string> | default = "TLS12" ] [ max_version: <string> | default = "TLS13" ] [ cipher_suites: [ - <string> ] ] [ preferservercipher_suites: <bool> | default = true ] [ curve_preferences: [ - <string> ] ] httpserverconfig: [ http2: <boolean> | default = true ] basicauthusers: [ <string>: <secret> ... ] ``` An example configuration file is provided below, ```yaml tlsserverconfig: cert_file: server.crt key_file: server.key basicauthusers: alice: $2y$10$mDwo.lAisC94iLAyP81MCesa29IzH37oigHC/42V2pdJlUprsJPze bob: $2y$10$hLqFl9jSjoAAy95Z/zw8Ye8wkdMBM8c5Bn1ptYqP/AXyV0.oy0S8m ```
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-7-5-15.md

_build: list: false labels: products: cloud enterprise oss title: Release notes for Grafana 7.5.15 Security: Fixes CVE-2022-21702. For more information, see our Security: Fixes CVE-2022-21703. For more information, see our Security: Fixes CVE-2022-21713. For more information, see our
Project: OpenSearch (Observability and Analysis / Observability)
File: opensearch.release-notes-2.4.1.md

Fix 1.x compatibility bug with stored Tasks () () Use BuildParams.isCi() instead of checking env var () () ) () ) () Fix test to use a file from another temp directory () () Fix boundary condition in indexing pressure test () () ) () ) Change the output error message back to use OpenSearchException in the cause chain () () Revert changes in AbstractPointGeometryFieldMapper () Add support for skipping changelog () () ) () Update Apache Lucene to 9.4.2 () () Update Jackson to 2.14.1 () () Bump nebula-publishing-plugin from v4.4.0 to v4.6.0. () () Bump commons-compress from 1.21 to 1.22. () ()
Project: SOFATracer (Observability and Analysis / Observability)
File: CONTRIBUTING.md

SOFATracer is released under the Apache 2.0 license, and follows a very standard Github development process, using Github tracker for issues and merging pull requests into master . If you would like to contribute something, or simply want to hack on the code this document should help you get started. Before we accept a non-trivial patch or pull request we will need you to sign the Contributor License Agreement. Signing the contributors agreement does not grant anyone commit rights to the main repository, but it does mean that we can accept your contributions, and you will get an author credit if we do. Active contributors might be asked to join the core team, and given the ability to merge pull requests. None of these is essential for a pull request, but they will all help. we provided a , it will formatting automatically your project when during process of building. Make sure all new `.java` files to have a simple Javadoc class comment with at least an `@author` tag identifying you, and preferably at least a paragraph on what the class is for. Add the ASF license header comment to all new `.java` files (copy from existing files in the project) Add yourself as an `@author` to the `.java` files that you modify substantially (more than cosmetic changes). Add some Javadocs. A few unit tests would help a lot as wellsomeone has to do it. When writing a commit message please follow , if you are fixing an existing issue please add Fixes gh-XXXX at the end of the commit message (where XXXX is the issue number).
Project: Vector (Observability and Analysis / Observability)
File: pacman.md

title: Install Vector using pacman short: pacman weight: 7 {{< info title="Community Maintained" >}} The Vector pacman package is supported and maintained by the open source community. {{< /info >}} [pacman] is a utility which manages software packages in Linux, primarily on [Arch Linux] and its derivates. This covers installing and managing Vector through the Arch Linux [extra] package repository. ```shell sudo pacman -Syu vector ``` {{< tabs default="Uninstall Vector" >}} {{< tab title="Uninstall Vector" >}} ```shell sudo pacman -Rs vector ``` {{< /tab >}} {{< /tabs >}} {{< jump "/docs/administration/management" "apt-dpkg-rpm-yum-pacman" >}}