cwielenb/CNCF-Dataset huggingface dataset:
Project: Trickster (Observability and Analysis / Observability)
File: collapsed-forwarding.md

Collapsed Forwarding is feature common among Reverse Proxy Cache solutions like Squid, Varnish and Apache Traffic Server. It works by ensuring only a single request to the upstream origin is performed for any object on a cache miss or revalidation attempt, no matter how many users are requesting the object at the same time. Trickster has support for two types of Collapsed Forwarding: Basic (default) and Progressive Basic Collapsed Forwarding is the default functionality for Trickster, and works by waitlisting all requests for a cacheable object while a cache miss is being serviced for the object, and then serving the waitlisted requests once the cache has been populated. The feature is further detailed in the following diagram: <img src="./images/basic-collapsed-forwarding.png" width="800"> Progressive Collapsed Forwarding (PCF) is an improvement upon the basic version, in that it eliminates the waitlist and serves all simultaneous requests concurrently while the object is still downloading from the server, similar to Apache Traffic Server's "read-while-write" feature. This may be useful in low-latency applications such as DASH or HLS video delivery, since PCF minimizes Time to First Byte latency for extremely popular objects. The feature is further detailed in the following diagram: <img src="./images/progressive-collapsed-forwarding-cache.png" width="800"> Trickster provides a unique feature that implements PCF in Proxy-Only configurations, to bring the benefits of Collapsed Forwarding to HTTP Paths that are not configured to be routed through the Reverse Proxy Cache. (See documentation for more info on routing). The feature is further detailed in the following diagram: <img src="./images/progressive-collapsed-forwarding-proxy.png" width="800"> When configuring path configs as described in you simply need to add `progressivecollapsedforwarding = true` in any path config using the `proxy` or `proxycache` handlers. Example: ```yaml origins: test: paths: thing1: path: /test_path1/ match_type: prefix handler: proxycache progressivecollapsedforwarding: true thing2: path: /test_path2/ match_type: prefix handler: proxy progressivecollapsedforwarding: true ``` See the for more configuration examples. An easy way to test PCF is to set up your favorite file server to host a large file(Lighttpd, Nginx, Apache WS, etc.), In Trickster turn on PCF for that path config and try make simultaneous requests. If the networking between your machine and Trickster has enough bandwidth you should see both streaming at the equivalent rate as the origin request. Example: Run a Lighttpd instance or docker container on your local machine and make a large file available to be served Run Trickster locally Make multiple curl requests of the same object You should see the speed limited on the origin request by your disk IO, and your speed between Trickster limited by Memory/CPU
Project: Netdata (Observability and Analysis / Observability)
File: synology.md

<!-- title: "Install Netdata on Synology" description: "The Netdata Agent can be installed on AMD64-compatible NAS systems using the 64-bit pre-compiled static binary." customediturl: https://github.com/netdata/netdata/edit/master/packaging/installer/methods/synology.md sidebar_label: "Synology" learn_status: "Published" learnrelpath: "Installation/Install on specific environments" --> This document is maintained by Netdata's community, and may not be completely up-to-date. Please double-check the details of the installation process, before proceeding. You can help improve this document by with your recommended improvements or changes. Thank you! The good news is that our works fine if your NAS is one that uses the amd64 architecture. It will install the content into `/opt/netdata`, making future removal safe and simple. When Netdata is first installed, it will run as root. This may or may not be acceptable for you, and since other installations run it as the `netdata` user, you might wish to do the same. This requires some extra work: Create a group `netdata` via the Synology group interface. Give it no access to anything. Create a user `netdata` via the Synology user interface. Give it no access to anything and a random password. Assign the user to the `netdata` group. Netdata will chuid to this user when running. Change ownership of the following directories: ```sh chown -R root:netdata /opt/netdata/usr/share/netdata chown -R netdata:netdata /opt/netdata/var/lib/netdata /opt/netdata/var/cache/netdata chown -R netdata:root /opt/netdata/var/log/netdata ``` Restart Netdata ```sh /etc/rc.netdata restart ``` Additionally, as of 2018/06/24, the Netdata installer doesn't recognize DSM as an operating system, so no init script is installed. You'll have to do this manually: Add as `/etc/rc.netdata`. Make it executable with `chmod 0755 /etc/rc.netdata`. Add or edit `/etc/rc.local` and add a line calling `/etc/rc.netdata` to have it start on boot: ```conf [ -x /etc/rc.netdata ] && /etc/rc.netdata start ``` Make sure `/etc/rc.local` is executable: `chmod 0755 /etc/rc.local`.
Project: Grafana Loki (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: Netdata (Observability and Analysis / Observability)
File: systemd_scope_unit_failed_state.md

This alert is triggered when a systemd scope unit enters a failed state. If you receive this alert, it means that one of your systemd scope units is not working properly and requires attention. Systemd is the system and service manager on modern Linux systems. It is responsible for managing and controlling system processes, services, and units. A scope unit is a type of systemd unit that groups several processes together in a single unit. It is used to organize and manage resources of a group of processes. Identify the systemd scope unit in the failed state To list all the systemd scope units on the system, run the following command: ``` systemctl list-units --type=scope ``` Look for the units with a 'failed' state. Check the status of the systemd scope unit To get more information about the failed systemd scope unit, use the `systemctl status` command followed by the unit name: ``` systemctl status UNIT_NAME ``` This command will display the unit status, any error messages, and the last few lines of the unit logs. Consult the logs for further details To get additional information about the unit's failure, you can use the `journalctl` command for the specific unit: ``` journalctl -u UNIT_NAME ``` This command will display the logs of the systemd scope unit, allowing you to identify any issues or error messages. Restart the systemd scope unit If the issue appears to be temporary, try restarting the unit using the following command: ``` systemctl restart UNIT_NAME ``` This will attempt to stop the failed unit and start it again. Debug and fix the issue If the systemd scope unit keeps failing, refer to the documentation and logs to debug the issue and apply the necessary fixes. You might need to update the unit's configuration, fix application issues, or address system resource limitations.
Project: Checkmk (Observability and Analysis / Observability)
File: 16310.md

key | value | date | 2024-01-19T12:59:21+00:00 version | 2.3.0b1 class | feature edition | cre component | wato level | 1 compatible | yes This option is used in the service discovery rule "Periodic service discovery" and the global option "Bulk discovery" and offers now the possibility to choose between a refresh of all services and host labels or a custom configuration. If you choose a custom one, you can select "Monitor undecided services", "Remove vanished services" and/or "Update host labels".
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: engine-specification.md

It embeds the ChaosEngine as a template inside schedule CR. Which contains the chaosexperiment and target application details. ??? info "View the engine details" <table> <tr> <th>Field</th> <td><code>.spec.engineTemplateSpec</code></td> </tr> <tr> <th>Description</th> <td>Flag to control chaosengine to be formed </td> </tr> <tr> <th>Type</th> <td>Mandatory</td> </tr> <tr> <th>Range</th> <td><i>n/a</i></td> </tr> <tr> <th>Default</th> <td><i>n/a</i></td> </tr> <tr> <th>Notes</th> <td>The <code>engineTemplateSpec</code> is the ChaosEngineSpec of ChaosEngine that is to be formed.</td> </tr> </table> Specify the chaosengine details at `spec.engineTemplateSpec` inside schedule CR ```yaml apiVersion: litmuschaos.io/v1alpha1 kind: ChaosSchedule metadata: name: schedule-nginx spec: schedule: repeat: properties: minChaosInterval: "2m" engineTemplateSpec: engineState: 'active' appinfo: appns: 'default' applabel: 'app=nginx' appkind: 'deployment' annotationCheck: 'true' chaosServiceAccount: pod-delete-sa jobCleanUpPolicy: 'delete' experiments: name: pod-delete spec: components: env: name: TOTALCHAOSDURATION value: '30' name: CHAOS_INTERVAL value: '10' name: FORCE value: 'false' ```
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-nodata_info_by_id.md

category: NoData apiurl: '/api/v1/nodata/#{nodata_id}' title: "Get Nodata Info by id" type: 'GET' sample_doc: 'nodata.html' layout: default Required ex. /api/v1/nodata/2 ```Status: 200``` ```{ "id": 2, "name": "owl_nodate", "obj": "docker-agent", "obj_type": "host", "metric": "test.metric", "tags": "", "dstype": "GAUGE", "step": 60, "mock": -2, "creator": "root" }```
Project: Promscale (Observability and Analysis / Observability)
File: epochs.readme.md

Previously our SeriesID cache would never delete entries. This could cause issues as SeriesIDs are deleted from the database if we see that no data table uses them; in the event that the series is resurrected after that, new rows in that series would contain an ID that did not refer to any series set stored. In order to fix this, we introduce an epoch mechanism to validate that the SeriesIDs and INSERT is adding to the DB could not have been deleted. At a high level, the mechanism works as follows: The database stores an epoch counter that monotonically increases whenever SeriesIDs are deleted. The SeriesID cache stores the smallest epoch at which it read an ID from the DB. This epoch is sent to the inserter along with the data to be inserted. As the first statement of the INSERT transaction, the inserter validates that the epoch at the DB is low enough that none of the SeriesIDs being inserted could have been deleted. If the epoch isn't valid the INSERT transaction is aborted. Choosing which epochs are valid for insertions has subtle performance implications. While we could dictate that the epoch we read must match the epoch we see during an INSERT exactly, this would cause thundering herd aborts whenever we delete SeriesIDs. Instead, we allow the epoch at insert to be 1 greater than the one we saw at read time, and delay the deletion of SeriesIDs until after they've been unused for at least a full epoch. Graphically, with R being the earliest point in the epoch numberline at which we read, and I being the point we write, we allow read/insert combinations like: ``` R R 0|1|2|3 or 0|1|2|3 I I ``` but not ones like ``` R R 0|1|2|3 or 0|1|2|3 I I ``` Similarly, if M is the first time we mark a SeriesID as being deletable because there are no data columns that reference it, and D is the point at which we actually delete it (note that it is these deletes that increment the epoch, so they properly happen /between/ epochs. We allow mark/delete combinations like: ``` M 0|1|2|3 D ``` but not ones like ``` M M M 0|1|2|3 or 0|1|2|3 or 0|1|2|3 D D D ``` Over all the valid read/insert and mark/delete combinations nest something like one of: ``` M R M R 0|1|2|3 or 0|1|2|3 I D ID ``` So a recheck to see if SeriesIDs are still live before actual deletion ensures that no dead IDs are inserted.
Project: HertzBeat (Observability and Analysis / Observability)
File: elasticsearch.md

id: elasticsearch title: MonitoringElasticSearch sidebar_label: ElasticSearch keywords: [ open source monitoring tool, monitoring ElasticSearch metrics ] Collect and monitor the general performance Metrics of ElasticSearch | Parameter name | Parameter help description | ||--| | Monitoring Host | Monitored IPV4, IPV6. NoteWithout protocol header (eg: https://, http://). | | Monitoring name | Identify the name of this monitoring. The name needs to be unique. | | Monitoring port | The HTTP API port opened by Elasticsearch,default is 9200. | | SSL | Whether SSL is enabled for connecting to Elasticsearch. | | Auth Type | Authentication type,Optional. | | Username | Username,Optional. | | Password | Password,Optional. | | Connect Timeout | Set the timeout for elasticsearch query, default is 6000 milliseconds. | | Collection interval | Interval time of monitor periodic data collection, unit: second, and the minimum interval that can be set is 30 seconds. | | Bind Tags | Used to classify and manage monitoring resources. | | Description remarks | For more information about identifying and describing this monitoring, users can note information here. | | Metric name | Metric unit | Metric help description | |--|-|-| | cluster_name | none | Cluster Name | | status | none | status | | nodes | none | Number of nodes in the cluster. | | data_nodes | none | Number of data nodes in the cluster. | | activeprimaryshards | none | Number of active shards on primary nodes. | | active_shards | none | Number of active shards. | | active_percentage | % | Active Percentage | | initializing_shards | none | Number of initialized shards. | | unassigned_shards | none | Number of unassigned shards. | | Metric name | Metric unit | Metric help description | |-|-|--| | total | none | Number of nodes. | | successful | none | Number of online nodes. | | failed | none | Number of offline nodes. | | Metric name | Metric unit | Metric help description | |-|-|-| | node_name | none | Node Name | | ip | none | IP Address | | cpuloadaverage | none | Cpu Load Average | | cpu_percent | % | Cpu Percent | | heap_used | MB | Heap Used | | heapusedpercent | % | Heap Used Percent | | heap_total | MB | Heap Total | | disk_free | GB | Disk Free | | disk_total | GB | Disk Total | | diskusedpercent | % | Disk Used Percent |
Project: Netdata (Observability and Analysis / Observability)
File: md_raid.md

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/src/collectors/proc.plugin/integrations/md_raid.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/src/collectors/proc.plugin/metadata.yaml" sidebar_label: "MD RAID" learn_status: "Published" learnrelpath: "Collecting Metrics/Linux Systems/Disk" 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/hard-drive.svg" width="150"/> Plugin: proc.plugin Module: /proc/mdstat <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> This integration monitors the status of MD RAID devices. This collector is supported on all platforms. This collector supports collecting metrics from multiple instances of this integration, including remote instances. This integration doesn't support auto-detection. 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 | |:|:-|:-| | md.health | a dimension per md array | failed disks | Labels: | Label | Description | |:--|:-| | device | TBD | | raid_level | TBD | Metrics: | Metric | Dimensions | Unit | |:|:-|:-| | md.disks | inuse, down | disks | | md.mismatch_cnt | count | unsynchronized blocks | | md.status | check, resync, recovery, reshape | percent | | md.expectedtimeuntiloperationfinish | finish_in | seconds | | md.operation_speed | speed | KiB/s | | md.nonredundant | available | boolean | The following alerts are available: | Alert name | On metric | Description | |:|:-|:| | | md.disks | number of seconds since the last successful data collection | | | md.disks | number of devices in the down state for the ${label:device} ${label:raid_level} array. Any number > 0 indicates that the array is degraded. | | | md.mismatchcnt | number of unsynchronized blocks for the ${label:device} ${label:raidlevel} array | | | md.nonredundant | number of seconds since the last successful data collection | No action required. There is no configuration file. There are no configuration options. There are no configuration examples.
Project: Vector (Observability and Analysis / Observability)
File: minor-release.md

name: Vector minor release about: Use this template for a new minor release. title: "Vector [version] release" labels: "domain: releasing" The week before the release: and take them (or have someone help you take them) [ ] Create a new release branch from master to freeze commits `git fetch && git checkout origin/master && git checkout -b v0.<new version number> && git push -u` [ ] Create a new release preparation branch from `master` `git checkout -b prepare-v0.<new version number> && git push -u` [ ] Check if there is a newer version of Alpine or Debian available to update the release images in `distribution/docker/`. Update if so. [ ] Run `cargo vdev build release-cue` to generate a new cue file for the release [ ] Add description key to the generated cue file with a description of the release (see previous releases for examples). [ ] Ensure any breaking changes are highlighted in the release upgrade guide [ ] Ensure any deprecations are highlighted in the release upgrade guide [ ] Update version number in `website/cue/reference/administration/interfaces/kubectl.cue` [ ] Update version number in `distribution/install.sh` [ ] Add new version to `website/cue/reference/versions.cue` [ ] Create new release md file by copying an existing one in `./website/content/en/releases/` and updating version number [ ] Commit these changes [ ] Open PR against the release branch (`v0.<new version number>`) for review [ ] PR approval On the day of release: [ ] Rebase the release preparation branch on the release branch [ ] Squash the release preparation commits (but not the cherry-picked commits!) to a single commit. This makes it easier to cherry-pick to master after the release. [ ] Ensure release date in cue matches current date. [ ] Merge release preparation branch into the release branch `git co v0.<new version number> && git merge --ff-only prepare-v0.<new version number>` [ ] Tag new release [ ] `git tag v0.<minor>.0 -a -m v0.<minor>.0` [ ] `git push origin v0.<minor>.0` [ ] Wait for release workflow to complete Discoverable via . . [ ] Once Helm chart is released, updated Vector manifests Run `cargo vdev build manifests` and open a PR with changes to have them available internally. [ ] Cherry-pick any release commits from the release branch that are not on `master`, to `master` [ ] Bump the release number in the `Cargo.toml` on master to the next major release [ ] Reset the `website` branch to the `HEAD` of the release branch to update https://vector.dev [ ] `git checkout website && git reset --hard origin/v0.<new version number> && git push` [ ] Kick-off post-mortems for any regressions resolved by the release
Project: EaseAgent (Observability and Analysis / Observability)
File: megacloud-config.md

Modify the agent.properties file to configure your information. You'll name to find your data later. It's important to use a unique and meaningful name. The service name of megacloud consists of three parts: zone, domain, name. They are joined by `.` into `ServiceName` ```properties name=zone.domain.service ``` MTLS is a secure authentication protocol for EaseAgent to connect to MegaCloud. Config: Get TLS ```properties reporter.outputServer.tls.enable=true reporter.outputServer.tls.key=YOURTLSKEY reporter.outputServer.tls.cert=YOURTLSCERT ``` MegaCloud uses http to receive data, so you need to change the configuration to http and MegaCloud's address. ```properties reporter.outputServer.bootstrapServer={MEGACLOUDURL} reporter.outputServer.appendType=http reporter.tracing.sender.appendType=http reporter.metric.sender.appendType=http plugin.observability.global.metric.url=/platform-metrics plugin.observability.global.log.url=/application-log plugin.observability.access.log.url=/application-access-log reporter.tracing.sender.url=/application-tracing-log reporter.tracing.encoder=SpanJsonEncoder ``` Other configurations are EaseAgent related configurations such as Tracing, Metric, etc. For details, please refer to When you download the `easeagent.jar` file through our megacloud, `MEGACLOUDURL` and `TLS` will be filled in for you automatically. If you need it separately, please download the `easeagent.jar` and get it by yourself. You can use the command to get config: ```bash jar xf easeagent.jar agent.properties ```